Libro de Trabajos Foro tecnológico y Posters

CASE 2013CONGRESO ARGENTINO DE SISTEMAS EMBEBIDOS

Libro de TrabajosForo tecnológico y Posters

www.sase.com.ar 14 al 16 de agosto

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

Facultad de Ingeniería | UBA

Buenos Aires, Argentina

CASE 2013CASE 2013

Libro de TrabajosModalidades Foro Tecnológico y Póster

Congreso Argentino de

Sistemas Embebidos

14 al 16 de Agosto de 2013FIUBA, Buenos Aires, Argentina

i

Libro de TrabajosModalidades Foro Tecnológico y PósterCASE-Congreso Argentino de Sistemas Embebidos 2013

Editores:

Diego Brengi, INTI/UNLaMLuciana De Micco, UNMDP/CONICETJosé Lipovetzky, UBA/CONICETAriel Lutenberg, UBA/CONICET/UTN-FRBA

Copyright © 2013. Asociación civil para la investigación, promoción y desarrollo de los sistemas electrónicos embebidos.

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

ii

Prefacio

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

El SASE busca fomentar esta temática realizando las siguientes actividades:

• CASE: Congreso Argentino de Sistemas Embebidos, presentación trabajos científicos.

• Workshops: Talleres prácticos en la modalidad hands-on.• Tutoriales: Charlas de capacitación.• Plenarias: Conferencias y debates abiertos.• Concurso de proyectos tecnológicos: sobre trabajos finales y

materias de grado.• Concurso de emprendimientos tecnológicos: destinado a

promover emprendimientos electrónicos con viabilidad económica.

• Programa de equipamiento para universidades: para transferir a las universidades las donaciones de los auspiciantes.

• Becas de viaje y alojamiento: Ayudas económicas para viaje y estadía a estudiantes de grado, estudiantes de doctorado, docentes e investigadores, de Argentina y Latinoamérica.

Los objetivos que persigue el CASE son:

• Ofrecer un lugar de encuentro para investigadores y becarios de todo el país, fomentando la colaboración.

• Difundir en el medio académico los adelantos científicos y tecnológicos producidos a nivel mundial.

• Propiciar la presentación y discusión de trabajos de investigación desarrollados en Argentina.

• Estimular en los estudiantes universitarios avanzados el interés por la investigación en el área de los S.E.

• Difundir los proyectos de investigación mediante el desarrollo de un sitio web.

• Coordinar y actualizar los contenidos de S.E. de los programas de grado y posgrado de las universidades argentinas.

Este año, las áreas temáticas del CASE se organizan de la siguiente manera: Arquitecturas de Microprocesadores, ASICs, DSPs, FPGAs y HDLs, Implementación de Sistemas Embebidos, Protocolos y

iii

Comunicaciones, Robótica, RTOS y Software Embebido. Dentro de cada una de estas áreas se permiten las modalidades Artículo, Foro Tecnológico y Póster, según el tipo de trabajo.

Los trabajos presentados al CASE fueron sometidos a un proceso de revisión por pares y posterior corrección. De este modo fueron seleccionados 29 trabajos en la modalidad foro tecnológico y 20 pósters.

Esta publicación se encuentra también disponible en forma online en la página www.sase.com.ar.

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

Atentamente,

Comité Organizador CASE 2013

iv

Auspiciantes Diamond

● ARM Ltd.● ARROW Argentina● CIKA S.R.L. ● CORADIR S.A. ● ELECTROCOMPONENTES S.A.● Electrónica ELEMON S.A.

Auspiciantes Platinum

● Atmel Corp. ● Emtech● Freescale Semiconductor● NXP Semiconductors ● Quectel● Synopsys ● Telit Wireless Solutions ● Texas Instruments Inc. ● Vicda Argentina S.R.L.

Auspiciantes Gold

● Dai Ichi Circuitos S.A.● Digi International● Edasim● Ernesto Mayer S.A.● INVAP S.E.● INTEL● Macon Máquinarias y consumibles S.R.L.● Microchip Technology Inc.● Orbcomm● Probattery● Sur Emprendimientos Tecnológicos● Unitec Blue

Auspiciantes Silver

● ARSAT● Asissi● Clariphy Argentina S.A. ● Globallogic● Renesas● Revista Mercado Electrónico ● Saber Electrónica ● SMT Solutions● ST Microelectronics Inc.

v

Instituciones Auspiciantes

● Agencia Nacional de Promoción de la Ciencia y la Tecnología (ANCPyT)

● Asociación Argentina de Control Automático (AADECA)● Cámara Argentina de Industrias Electrónicas,

Electromecánicas y Luminotécnicas (CADIEEL)● Centro de Investigaciones Tecnológicas para la Defensa

(CITEDEF)● Centro Argentino de Ingenieros (CAI)● Comisión Nacional de Actividades Espaciales (CoNAE)● Comisión Nacional de Energía Atómica (CNEA)● Consejo Federal de Decanos de Ingeniería (CONFEDI)● IEEE Argentina● IEEE Circuits and Systems Society (CASS)● Institute of Electrical and Electronics Engineers (IEEE)● Instituto Nacional de Tecnología Industrial (INTI)● Instituto ORT Argentina● Ministerio de Ciencia, Tecnología e Innovación Productiva

(MinCyT)● Ministerio de Industria● Secretaría de Políticas Universitarias (SPU)

Universidades Auspiciantes

● UBA: Universidad de Buenos Aires

● UNC: Universidad Nacional de Córdoba

● UNCA: Universidad Nacional de Catamarca

● UNCOMA: Universidad Nacional del Comahue

● UNCUYO: Universidad Nacional de Cuyo

● UNER: Universidad Nacional de Entre Ríos

● UNJ: Universidad Nacional Arturo Jauretche

● UNICEN: Universidad Nacional del Centro de la Provincia de Buenos Aires

● UNLAM: Universidad Nacional de La Matanza

● UNLP: Universidad Nacional de La Plata

● UNLu: Universidad Nacional de Luján

● UNM: Universidad Nacional de Misiones

● UNMDP: Universidad Nacional de Mar del Plata

● UNPA: Universidad Nacional de La Patagonia Austral

● UNPSJB: Universidad Nacional de la Patagonia San Juan Bosco

vi

● UNQ: Universidad Nacional de Quilmes

● UNR: Universidad Nacional de Rosario

● UNRC: Universidad Nacional de Río Cuarto

● UNS: Universidad Nacional del Sur

● UNSA: Universidad Nacional de Salta

● UNSJ: Universidad Nacional de San Juan

● UNSL: Universidad Nacional de San Luis

● UNSM: Universidad Nacional de San Martín

● UNT: Universidad Nacional de Tucumán

● UNTF: Universidad Nacional de Tres de Febrero

● UTN-FRA: Universidad Tecnológica Nacional – Facultad Regional Avellaneda

● UTN-FRBA: Universidad Tecnológica Nacional – Facultad Regional Buenos

Aires

● UTN-FRBB: Universidad Tecnológica Nacional – Facultad Regional Bahía

Blanca

● UTN-FRD: Universidad Tecnológica Nacional – Facultad Regional Delta

● UTN-FRH: Universidad Tecnológica Nacional – Facultad Regional Haedo

● UTN-FRLR: Universidad Tecnológica Nacional – Facultad Regional La Rioja

● UTN-FRM: Universidad Tecnológica Nacional – Facultad Regional Mendoza

● UTN-FRN: Universidad Tecnológica Nacional – Facultad Regional Neuquén

● UTN-FRRG: Universidad Tecnológica Nacional – Facultad Regional Rio Grande

● UTN-FRSF: Universidad Tecnológica Nacional – Facultad Regional San

Francisco

● UTN-FRSN: Universidad Tecnológica Nacional – Facultad Regional San Nicolás

● UTN-FRVT: Universidad Tecnológica Nacional – Facultad Regional Venado

Tuerto

● UTN-FRVM: Universidad Tecnológica Nacional – Facultad Regional Villa

Mercedes

● UTN-FRT: Universidad Tecnológica Nacional – Facultad Regional Tucumán

● UADE: Universidad Argentina de la Empresa

● CAECE: Universidad CAECE

● ITBA: Instituto Tecnológico de Buenos Aires

● IUA: Instituto Universitario Aeronáutico

● UBP: Universidad Blas Pascal

● UCC: Universidad Católica de Córdoba

● UCU: Universidad Católica de Uruguay

● UCSE: Universidad Católica de Santiago del Estero

● UM: Universidad de Mendoza

● UREP: Universidad de la República del Uruguay

vii

Coordinación General SASE● Dr. Ariel Lutenberg (UBA/CONICET/UTN-FRBA)

Coordinación CASE● Dr. José Lipovetzky (UBA/CONICET)

● Dra. Luciana De Micco (UNMDP/CONICET)

● Mg. Diego Brengi (INTI/UNLaM)

Chairs● Arq. de Procesadores: Ing. Alejandro Furfaro (UTN-FRBA)● ASICs: Dr. Martín Di Federico (FIUBA) ● Bioingeniería: Ing. Juan Manuel Reta (UNER)● DSPs: Dra. María Liz Crespo (ICTP) ● FPGAs y HDLs: Ing. Salvador Tropea (INTI/UTN-FRBA)● Linux embebido: Ing. Lucas Chiesa (FIUBA)● Protocolos y Comunicaciones: Ing. Gustavo Mercado (UTN-FRM)● Robótica: Dr. Luis Canali (UTN-FRC)● RTOS: Dr. Ricardo Cayssials (UNS)● Sistemas Embebidos: Msc. Cristian Sisterna (UNSJ)● Software Embebido: Dr. Ricardo Medel (INTEL)

viii

Revisores

Subrevisiones

Alejandro Pasciaroni Martin VillemurAndrés P. Djordjalian Niria OstermanAngel Jose Soto Omar LifschitzDiego Beltramone Aciti, ClaudioMarcelo L. Moreyra Friedrich, Guillermo

ix

Abraham, Jorge Larrondo, Hilda AngelaAldonate, Julio Leiva, LucasAlessandrini, Gustavo Lipovetzky, JoseAlpago, Octavio Lozano, ClevisAntonelli, Maximiliano Lutenberg, ArielArias, Ricardo Marchi, EdgardoArias-Garcia, Janier Martos, PedroBrengi, Diego Masrur, AlejandroBriff, Pablo Mata, Walter A.Canali, Luis Rafael Medel, RicardoCarbajales, Rodrigo Melo, RodrigoCarbonetto, Sebastián Mercado, GustavoCayssials, Ricardo Meza-Benavides, CarlosChiesa, Lucas Monte, GustavoCrespo, Maria Liz Oliva, RafaelDe Marziani, Carlos Orallo, CarlosDe Micco, Luciana Perez, JorgeDellavale, Damian Perez, SantiagoDi Federico, Martin Petrashin, PabloEscudero, Gustavo Pucheta, JuliánFerrao, Hilda Reta, JuanFerreira, Fabiana Ridolfi, PabloFerreyra, Pablo Alejandro Risco Castillo, Miguel AlbertoFerro, Edgardo Rocha, FábioFilomena, Eduardo Rodriguez Rivero, CristianFranco, Leonardo Sager, Gerardo EnriqueFurfaro, Alejandro Sambuco, LucasGarcia, Javier Santos, RodrigoGarcia Inza, Mariano Sisterna, CristianGayoso, Carlos Arturo Tacca, HernánGiribet, Juan Ignacio Taffernaberry, CarlosGonzalez, Apolinar Toccaceli, GracielaGonzález, Rodrigo Todorovich, ElíasGrimblatt, Victor Tropea, SalvadorGutierrez Andrade, Jose Antonio Weizs, MariaGwirc, Sergio N. Zabaleta, Omar GustavoHernandez Tabares, Lorenzo Zacchigna, Federico G.Juarez, Gustavo Eduardo Zaradnik, Ignacio

ÍNDICE

Arquitectura de Procesadores 1

IP Core for Timed Petri Nets. 3

Implementation of an 8-BIT softcore microcontroller in a XILINX Spartan FPGA. 9

ASICs 11

Diseño completo de un microprocesador de 8 bits. 13

FPGAs y HDLs 15

Analysis and Implementation of Adaptive Models LMK and LM-Skewness on FPGA. 17Desing and Implementation of FPGA-Based TRUE-RMS Voltmeter Using CORDIC Algorithm. 23

Estrategias de Optimización de Hardware para Máquinas de Estado en VHDL. 28

FPGA based spectrum analyzer. 34

FPGA based system for RF communications in relative positioning systems. 39

Wavelet Decomposition over FPGA. 45

FPGA del Kit al prototipo. 50Implementación de algoritmo genético para la búsqueda automática de caos en sistemas multiatractores. 51

Sistema de visión artificial para la detección de proximidad de dos objetos mediante el conteo de píxeles implementado en un FPGA. 53

Una Herramienta para Generación Automática de Descripciones Sintetizables de Circuitos Combinacionales. 54

Implementación de Sistemas Embebidos 55

Banco de medición de variables eléctricas con LPC1769. 57Design of a low cost multifunction visual navigation display for Argentinean military aircraft. 63

Detector de Misfire a través del sensor de rotación de cigüeñal CKP. 69Diseño e implementación de un sistema embebido de control de actitud para aeronaves no tripuladas. 75

Embedded System to Monitoring and Control Irrigation System in Real Time – Integro. 81

Real-Time Image Processing System Based on Android Embedded Operating System. 87

Microcontrolled based traffic monitoring system. 93Modernización, simulación e implementación en una computadora robusta, de un sistema de medición angular mediante un sensor sincrónico. 98

Multi-Client Application for Electric Arc Furnaces, using Compact RIO and FPGA. 103

PLC programable en lenguaje C. 109

Sensado INS/GPS con monitoreo en tiempo real. 115Sistema de adquisición de datos y control en tiempo real para bancos de ensayos de motores. 119

x

Sistema inalámbrico de microestaciones meteorológicas para aplicaciones agropecuarias. 125

Smart wireless sensor for industrial machinery health monitoring. 131

Data Logger con Interface Digital, Analógica, Óptica e Inalámbrica. 135

Brújula Electrónica. 136Control de una red domótica ZigBee a través de un servidor web embebido en un microcontrolador. 137

Aplicación Domótica Empleando LaunchPad MSP430: Experiencia en Formación Investigativa. 138

Nodo de comunicaciones M2M multiacceso. 139

Sistema de dinero virtual. 140

Linux Embebido 141Compilación e Instalación de Linux Embebido con Yocto para Placa de Desarrollo Intel. 143

Reverse-Engineering a Closed-Box Hardware and Software Linux Embedded System. 148

Protocolos y Comunicaciones 153Proposal for the design of a System Integration Laboratory for the new generation of avionics systems. 155

Implementación de una red de sensores inalámbricos para el registro de variables fisiológicas emulando un monitor multiparamétrico. 162

SAR: Diseño y Desarrollo de un sistema de automatización de riego con comunicación inalámbrica IEEE 802.15.4. 163

Transmisión de Datos de Sensores de Aceleración Mediante Bluetooth y su Análisis en PC. 164

Robótica 165

Control de la marcha de un robot hexápodo autónomo implementado en un FPGA. 167

Sistema de control distribuido para una máquina caminante de 6 patas. 173

Clasificador inteligente de objetos con visión artificial utilizando un brazo articulado. 179

Force-Feedback Manipulator Based on the Delta Robot. 180

RTOS 181Diseño, Implementación y Validación de una biblioteca de algoritmos de control para sistemas embebidos. 183

Implementación de un Kernel de Tiempo Real para Arquitectura ARMv7-M 189

Software Embebido 195Modeling and Rapid Prototyping applied to the Upgrade of Mission-Critical Applications using AADL. 197

Graphic Equalizer System Development Using ARM Architecture. 203

xi

��ABC��

DAEF��E��

��AB

C�B

D�E��ACE��A

www.sase.com.arwww.sase.com.ar14 al 16 de Agosto de 201314 al 16 de Agosto de 2013FIUBA, Buenos Aires, ArgentinaFIUBA, Buenos Aires, Argentina

1


2

IP Core for Timed Petri Nets

Orlando Micolini Laboratorio de Arquitectura

de Computadoras FCEFyN-UNC

Córdoba, Argentina [email protected]

Julián Nonino [email protected]

Carlos R. Pisetta [email protected]

Abstract— In this article, we present a Timed Petri Nets

Processor which can be directly programmed using Petri Nets formalism vectors and matrixes. This processor can leverage the power of Petri Nets for modeling real-time systems and formally verify their properties, which prevent programming errors.

The Petri Nets Processor was developed as an IP-core to be inserted in a Multi-Core system. Therefore, we can model the system requirements with Petri Nets, formally verifying all its properties and by using the IP-core to implement the system is possible to ensure that all properties will be met.

Keywords—Multi-Core, Petri Net, Processor.

I. INTRODUCTION

The evolution of processors is consequence of greater integration and composition of different types of functionalities integrated into a single processor. The availability of transistors has made possible to integrate several processor cores on a single chip, which has resulted in the development of Multi-Core technology [1].

Diminishing returns of Instruction Level Parallelism (ILP) and the cost of the frequency increase, mainly due to power limitations (suggests that a 1% increase in clock speed, results in a power increase of 3%) [2] , leads to the use of Multi-Core processors to improve performance. This increase deficiency results in lower run times, lower consumption, lower energy density, lower latency and higher inter-core communications bandwidth.

Therefore Multi-Core processors are a proposal to obtain higher performance. This arises as a better performance of each of those parameters. Furthermore, the heterogeneous Multi-Core systems have the advantage of employing specialized cores, each one of them designed for specific tasks. That is, optimized for a particular need. These processors have the ability to use the available hardware resources when they are specifically required by the software [3].

In order to increase performance, these systems make use of multi-threading and/or multi-tasking which allows taking advantage of the Multi-Cores. However, it takes more effort to design applications because they must provide solutions to the problems of concurrent systems.

That is the reason why with these processors, the parallel programming is essential for improving the performance in all segments of software development and even more so in the segment of real-time systems.

The Petri model is suitable to implement, validate and verify a parallel system with concurrence, At the Computer Architecture Laboratory of the FCEFyN-UNC a Petri processor has been developed to directly execute ordinary Petri Nets. In this article, we present a new Petri Nets Processor capable to execute Timed Petri Nets and to be programmed directly with the vectors and matrixes that define the system and its state.

There are different ways to implement software and hardware's Petri Nets. It's remarkable that, through our research, no work similar to ours has been found. Here we enumerate the most distinguished ones, and the main difference between them and our work.

Gary A. Bundell only implements the shoot algorithm of a transition [4].

Hideki Murakoshi, Miki Sugiyama, and Guojun Ding describe a Petri controller matrix, which it is not programmable [5].

Sergio C. Brofferio has implemented a controller without using a state equation [6].

Ramón Piedrafita Moreno and José Luis Villarroel Salcedo. They have programmed a high level software controller [7].

Xianwen Fang, Zhicai XU y Zhixiang Yin don‟t use the state equation as a program. They only program with a high level language [8].

Another researchers:

o Murakoshi, Hideki [9].

o Wegrzyn, Marek; Wolanski, Pawel; Adamski [10].

o Aybar, Aydın and Iftar, Altuğ [11].

o Murakoshi, Hideki [12].

II. OBJECTIVES

A. Main Objective

The main objective of this work is to design and implement a Petri Nets Processor capable to execute the Timed Petri Nets semantics and to be programmed directly from the model‟s state equations

B. Secondary Objectives

The secondary objectives are:


3

To briefly describe Timed Petri Nets in order to implement a processor capable of execute them.

To keep executing ordinary Petri Nets with time parameters on two processor clock cycles

To implement the Timed Petri Nets Processor as an IP-core.

III. PETRI NETS CONSIDERING TIME

In the formalism of Ordinary Petri Nets, the time is not considered and this results in indeterminism regarding to time. It isn't specified when a sensibilized transition will be fired or even if it will be fired. Neither can be said which transition, from a group of transitions in conflict, will be fired.

There are three different interpretations about how the time should be considered. All of them have its focus on the reduction of the indeterminism regarding time in Petri Nets [13]:

Stochastic Petri Nets: Introduces a stochastic estimation on the instant of firing of a transition.

Timed Petri Nets: Introduces a time condition, which specifies the duration of the transition.

Time Petri Nets: Introduces temporary dimensions between which the transition should be fired.

µ 〃 [a,b]

A) B) C)

Figure 1 Different ways to introduce time in Petri Nets

The temporal parameters associated with transitions can be interpreted in these three different ways1:

1. Generalized Stochastic Petri Nets (GSPNs) [14]have two different types of transitions: immediate transitions and timed transitions. When a transition 建 is sensitized, its firing could be: a) with a duration equal to zero if the transition 建 is immediate. b) after a lapse of a random time. This random time is expressed by an exponential distribution. The A Net from the figure 1 graphically represents a stochastic timed transition where its probability to be fired is represented by µ.

2. Timed Petri Nets have two different types of transitions: immediate transitions and timed transitions. When a transition t is sensitized, its firing could be: a) with a

1ぇ建 is the set of places that are inputs to a transition, mathematically defined as: ぇ建噺岶喧樺鶏┺ 岫喧┸ 建岻樺繋岼建ぇ is the set of positions that are outputs of a transition, mathematically defined as: 建ぇ噺岶喧樺鶏┺ 岫建┸ 喧岻樺繋岼繋 is the set of arcs, input and output to the transitions

duration equal to zero if the transition t is immediate. b) with immediate removal of tokens from set •t but placing the tokens in the 建ぇ only after time 酵 has elapsed. Meanwhile, the transition cannot be sensitized. The B Net from the figure 1 graphically represents a timed transition with a delay equal to k.

3. Timed Petri Nets have two different types of transitions: immediate transitions and time transitions. When a transition 建 is sensitized, its firing could be: a) with a duration equal to zero if the transition 建 is immediate. b) if it is a time transition, at the time it is sensitized, a timer starts. The transition can only be fired when the timer value is between the limits of the interval [a, b]. Otherwise, the transition cannot be fired. Once the firing was performed, the timer is restarted. The C Net from the figure 1 graphically represents a time transition with an associated interval equal to [a, b].

Should be noted that all the firings are performed in two steps: a) the removal of the tokens from the set ぇ建. This is an atomic action and the amount of tokens removed from each place is equal to the weight of the arcs joining each place in •t with the transition 建. b) The atomic action of placing at each place of set 建ぇ the amount of tokens indicated by the weight of the arcs joining each place of t• with the transition 建.

IV. TIMED PETRI NETS

In this nets, each timed transition has an associated parameter 酵 which represents the duration of the transition. In order to standardize the mathematical definition we will call “immediate” those transitions where k is zero.

A. Mathematical Definition

A Marked Timed Petri Net [13], is mathematically defined as a 8-tuple as follows: 岶鶏┸ 劇┸ 荊袋┸ 荊貸┸ 茎┸ 系┸ 兼待┸ 康岼

Where the terms 岶P┸ T┸ Pre┸ P t┸M待岼 represent a marked Petri Net with inhibitors arcs and bounded places. 康 is a vector composed of the values of duration 酵 associated to each transition.

The meaning of each term of the tuple is:

P: is a non-empty finite set of places

T: is a non-empty finite set of transitions, 鶏堪劇噺叶.

I+, I- : are the positive and negative incidence matrixes 鶏捲劇蝦傑

H: is the inhibitors arcs matrix. 鶏捲劇蝦岶ど┸な岼 C: is a vector containing the values that represent the maximum amount of tokens that each place of the net can hold. 系蝦軽師: is the set of static intervals associated with each transition 劇蝦卸袋抜岫卸袋姦タ岻


4

For each transition 建 the associated value 建件兼結堅痛 is: 康岫建岻噺酵痛 ┸ 拳月結堅結建樺劇欠券穴康蝦卸袋建件兼結堅痛 represents the time elapsed since the firing of the transition start and its value is zero at any other moment. 酵痛 is the duration of the transition. For those reasons, the following conditions must be met: ど判建件兼結堅痛判酵痛┻ ど判酵痛隼タ

m0: is the net initial marking and must fulfill that: ち噺ど┻ 鶏蝦軽

B. States of a Timed Petri Net

In these Petri Nets, the net state is defined by the marking vector (兼沈) and a timer vector that indicates the timestamp of each transition. Therefore the net state is:

S= (mi,建件兼結堅)

C. Sensitization of the Transitions and Firing Rules

When we refer to transitions, we have to establish the difference between an enabled or sensitized transition, a not enabled or sensitized transition and the firing of a transition.

In a Marked Petri Net whose current mark is 仕暫, we say that transition 建珍 is enabled or sensitized if, and only if, 建件兼結堅痛噺ど and the amount of tokens in all places 喧沈 belonging to these ぇ建珍 is at least equal to the weight of the arc that

connects them with the transition 嗣斬岾拳盤喧件┸ 建倹匪峇. Mathematically: 喧沈樺ぇ建沈 ┸ 兼盤喧珍匪半拳盤喧沈 ┸ 建珍匪巻建件兼結堅痛乳噺ど

In summary, every place connected to the transition 建珍 has at least the number of tokens indicated by the weight of the arc, and there is no firing in progress for that transition.

Sensitized transitions can be fired and every time the firing of a transition is completed it generates a new marking for the Petri Net. This means that the net changes its state.

The equation to calculate the new state or the new marking reached by the firing of 建珍 is 項盤兼賃┸ 建珍匪, and it is defined as:

項盤兼賃┸ 建珍匪噺菌衿衿芹衿衿緊兼賃袋怠岫喧沈岻噺兼賃岫喧沈岻伐拳沈珍 ┸ 褐喧沈樺ぇ建珍建件兼結堅痛乳嫌建欠堅建 ┹ 兼賃袋怠岫喧沈岻噺兼賃岫喧沈岻髪拳珍沈 ┸ 褐喧沈樺建珍ぇ巻建件兼結堅痛乳噺ど┹ 建件兼結堅噺酵珍兼賃袋怠岫喧沈岻噺兼賃岫喧沈岻┹ 件券建月結堅結嫌建剣血建月結潔欠嫌結嫌┹

建件兼結堅痛乳 is incremented in every clock cycle after the firing of the transition has started.

D. Interpretation of the firing of transitions in the system

The Figure 2 represents a reactive system that responds to events, which come from the environment, in other words the system interacts with the environment. Those events are directed to the Time Petri Nets Processor.

The responsibility of the processor is to arrange events according to the system constraints. These constraints are modeled by the Timed Petri Net which is used to program the processor. On the other hand, Multi-Core system threads also generate events (to request resources, to synchronize) that are directed to the processor to be sorted according to system constraints.

Module 1 from the Figure 2 receives unsorted events from the environment and from the system itself. After sorting them, the Timed Petri Nets Processor transmits the result to the threads execution cores (module 2) of the system and the proper actions are taken [15].

Environment Event

System

Timed Petri

Nets

processor

Cores running

Threads

Sorted Events to Threads

Thread's Events to event Controller

1 2

Figure 2 Reactive systems

In our system the fulfillment of program conditions is associated to sensitized transitions, the resolution of a shot represents the fulfillment of those restrictions and if we associate the request for verification of the conditions to a shot request, the resolution of a shot communicates that conditions have been met.

Definition: conditions for firing a transition from Timed Petri Process:

1. The transition must meet the sensitization conditions of section IV.C

2. The shot must be explicitly communicated by the processes or implicitly recorded in the automatic shots module.

3. Since it is possible that multiple transitions simultaneously satisfy the conditions described in paragraphs 1 and 2, the Timed Petri Nets Processor will execute first the firing with higher priority.

Figure 3 show us how the Timed Petri Nets Processor is connected in a Multi-Core system.

In case that the firing of the transition cannot be resolved, it is queued in the input queue, as shown in Figure 3, until the conditions of the system allow its resolution. The solution of the firing is notified to threads through the system bus, using


5

the output queue. The threads of the system will execute the proper actions as indicated by the firings that have been resolved, since the resolution of the firings depends on the Time Petri Nets Processor‟s state, which itself represents the state of the system.

Core n

Timed Petri

Nets

Processor

Input

queue

Output

queue

System bus

Multi-Core Processor

Core 2Core 1

Figure 3 Multi-Core with Timed Petri Nets Processor

The explicit shots require an external event, if this event does not occur the system must contemplate it at the network design. On the other hand the implicit shots automatically generate events due to the fulfillment of the transition conditions. In both cases it is necessary to take into account the priorities, so a shot can be delayed for not being the one with the highest priority. In both cases, the non-fulfillment of the times, deadlock the system, for which the active system signal is tested. This signal is included for debugging and / or to recover the system from a deadlock.

V. TIMED PETRI NETS PROCESSOR ARCHITECTURE AND

OPERATION

The processor executes the state equation solving only one transition firing at a time, this way it can solve all cases of firings, the simple ones (single firings) and the multiple firings, performing as a single-firing sequence, as a result, the hardware is simpler.

The resolution of firings is requested by the threads running on the cores through the system bus, as emerging requests that the system is running. These firing requests are received by the Timed Petri processor and stored in the input queue. Each transition has a FIFO queue, the output of each queue is a part of the composition of all outputs, which are all shots, if it forms a word the size output of this queue is a word equal to the number of transitions. This word has bits equal to one in the positions corresponding to transitions with requested firings. The order of the bit in the word equals the number of transition over which the firing is requested. The bits that correspond to the transitions which have no firing request are zero.

The output queue has a similar structure, but its function is to communicate to the threads those firings that have been resolved.

The data I/O module manages the cores access to the matrixes and vectors that program the system. The module manages the cores access to the matrixes and vectors that program the system.

The matrixes and vectors described in the state equation are the system program. This allows us to program the processor directly from the Timed Petri Net.

Mu

lti-

Co

re s

yste

m b

us

Output

queue

Input

queue

I/O Data

Matrix I+

Matrix I-

Matrix H

Bound of

place

Automatic

transition

Vector ȳ

Vector

Timer

Calculation

of state

equation

module

Marking

Data

Structures

Transition

state

Calculated

next state

matrix

sensitized

state

Active net

signal

Timed Petri Net Processor

Priority

matrix

Interrupt

Module

Figure 4 Timed Petri Nets Processor

Here we added the inhibitor arcs matrix to the vector indicating the maximum number of tokens in each places. These terms are not present in the state equations shown in this work but you can consult them [16].

The module in charge of solving the Petri's state equation has the following responsibilities:

1. To calculate the new state that would result from each transition firing only once, thereby generating a number of vectors calculated states equal to the number of transitions. Then, these vectors are stored. This is performed by subtracting the current state parallel to each column of 荊貸 and storing all resulting vectors, which will be evaluated to determine if the new state that each transition would produce is valid. This operation is performed whenever you change the timed Petri Nets Processor status (current marking vector).

2. To determine which transition is sensitized. To do this, take all vectors calculated in step 1 and verify that there is no place to have a negative marking and neither to exceed the limit2 of tokens it can hold.

2 It is noted that this is a weak bound, since the marks in the squares are incremented in step 4 and the limit is checked in step 2. This simplification facilitates hardware implementation.


6

3. From the group of sensitized transitions determined at the 2nd step and its firing it has been requested we select the one with higher priority. This transition will be used to determine the new state of the net. This update of the marking vector will be performed by replacing of the current vector with the one calculated in step 1 corresponding to the selected transition. At that moment, in Timer Module, the timer corresponding to the transition fired starts.

4. To compare each component of the 康 vector with the one at the Timer vector and to verify that it meets the following condition: Ve t r 康痛判 Ve t r T mer痛

5. The fulfillment of this condition means that the transition 建 has reached the delay time required. Then, the transition of higher priority that meets the above condition is chosen to update the marking vector. This means, add to the current marking vector the column of the matrix 荊袋 corresponding to the transition t. At the same time the position t of the 劇件兼結堅 vector is set to zero (劇件兼結堅痛噺ど).

6. To execute the steps 1, 2, 3 and 4 as a continuous cycle.

The system also has a unit that detects when no transition is sensitized and the 劇件兼結堅 vector is zero. When this happens, the system generates an interruption notifying that the system has finished its execution or is deadlocked. This feature is very useful to verify the operation of the design and implementation of the system.

VI. PERFORMANCE ANALYSIS

System implementation has been performed on an Atlys ™ Spartan-6 Digilent platform [17], the cores used are MicroBlaze v8.40 [18] running an XilKernel v5.01a operating system. Interconnected with Timed Petri Processor by AXI bus [19].

To verify the correct operation and to analyze the IP Core synchronization times, measurements were made for different numbers of iterations and numbers of threads trying to access a shared variable in mutual exclusion. Then we compared the Petri Processor with an implementation using semaphores, both solving the same problem. The choice of this second synchronization method is based on that they are the lightest mechanism to perform these tasks.

From these measurements, Speedup was calculated. The results are shown in Figure 5, where can be observed that for all cases, the processor is on average between 15% and 30% faster than use of semaphores to solve the trouble of synchronizing multiple threads that want to accesses a shared resource and even show peaks up to 70%.

This paper establishes that synchronization performance improvements could be obtained over semaphores, and it compares the resources used by the Petri Processor with others of the same kind.

Figure 5 Synchronization Speedup per iteration

Taking into account that the processing times are composed by:

Runtime: These correspond to the execution of sequential operations.

Waiting time: own of the algorithm, to synchronize, to avoid race conditions, etc.

Times to determine synchronization, race conditions, etc.

Developing a Petri processor seeks to reduce this last timeslot, which rely exclusively on Petri processor's ability to perform this task (such as semaphores depend on OS implementation). With the incorporation of temporal semantics, the processors can check on execute conditions compliance own to the algorithm. Currently this work is done with soft or hard timers own to the microcontroller or outside. On the other hand the execution time depends on the other processors of the Multi-Core system which we do not consider in the analysis. To evaluate the synchronization ability of our processor, the execution times and waiting times must be zero. The result will be compared to the time that semaphores consume to perform the same synchronization task, which is done in the performance analysis section.

As observed in Figure 6, the processor needs only one half-clock cycle being that the counter reaches the value ぷ until a shot is placed in the output queue. The delay introduced is insignificant in relation to the time that takes a 絞建 to complete one clock cycle.

Figure 6 Running on hardware

VII. IP CORE GROWTH

The processor's growth was analyzed in function of the parameters that it has. For this purpose, processors of 8x8, 16x16 and 32x32 (places x transitions) were generated, with 7

1,35

1,73 1,74

1,101,24 1,241,16 1,26

1,26

0,0

0,5

1,0

1,5

2,0

10 1000 10000

Sp

ee

d u

p

2 Writers

4 Writers

5 Writers


7

bits of capacity by place and elements of time of 48 bits. The results are plotted in Figure 7.

Figure 7 IP Core Growth

The growth of IP Core is not something to ignore, since the number of elements used grows quickly with the product of places and transitions.

VIII. CONCLUSION AND CONTRIBUTIONS

In this paper, a Timed Petri Processor is developed, which decouples the concurrency from sequential processing, and it has the following particularities:

Development time can be reduced, since the system is verified in analysis and design stages

On tasks, where measurements have been done, the processor allows synchronization of threads, with improvements up to 70%.

There is a direct relationship between the graph and the processor program, since this is programmed with the matrixes and vectors of the state equation.

Are admitted multiple shots simultaneously in the same transition.

Allows programming priorities; since the shots are solved in parallel and are selected according to priorities module.

Decides if the shot can be executed or not in 2 clock cycles.

The system programming is easier to do, since the processes are decoupled from the concurrency.

This processor can be programmed at run time, thus it is possible to decrease the size of the matrix in hardware by using spatial and temporal locality.

The difficulty of this implementation is because of the resources growth needed by the increase of places and transitions. It implies that is difficult to implement a system for

dimensions greater than 32x32 in ZedBoard, to mitigate this difficulty new designs have been proposed and are being worked on, these are: Petri Net Processor with pipeline architecture and support for Hierarchical Petri Nets.

REFERENCES

[1] J. L. Hennessy, Computer Architecture A Quantitative Approach, Denise E. M. Penrose, 2007.

[2] M. Domeika, Software Development for Embedded Multi-core Systems, 0 Corporate Drive, Suite 400, Burlington, MA 01803, USA: Linacre House, Jordan Hill, Oxford OX2 8DP, UK., 2008.

[3] S. S. B. Sundararajan Sriram, EMBEDDED MULTIPROCESSORS, Scheduling and Synchronization, Boca Raton, 2009.

[4] G. A. Bundell, «An FPGA Implementation of the Petri net Firing Algorithm,» Department of Electrical and Electronic Engineering Information Systems Engineering Research Group, The University of Western Australia, 1997.

[5] H. Murakoshi y M. a. D. G. Sugiyama, «A High Speed Programmable Controller Based on Petrinet,» Faculty of Engineering Yokohama National University, Japan, 1966.

[6] S. Brofferio, «A Petri Net Control Unit for High-speed Modular Signal Processors,» IEEE Transactions on Communications, 1987.

[7] R. Piedrafita Moreno y J. L. Villarroel Salcedo, «Adaptive Petri Nets Implementation. The Execution Time Controller,» de Workshop on Discrete Event Systems, Göteborg, Sweden, 2008.

[8] X. Fang y Z. a. Y. Z. Xu, A Study about the Mapping of Process-Processor based on Petri Nets, Anhui University of Science and Technology, 2006.

[9] H. Murakoshi, «Memory Reduction of Fire Unit for Petri Net Controlled Multiprocessor,» IEEE, 1991.

[10] M. Wegrzyn, P. Wolanski y M. a. M. J. L. Adamski, «Coloured Petri Net Model of Application Specific Logic Controller Programs,» de ISIE, Portugal, 1997.

[11] A. Aybar y A. Iftar, «Deadlock Avoidance Controller Design for Timed Petri Nets Using Stretching,» IEEE Systems Journal, vol. 2, nº 2, pp. 178-189, 2008.

[12] H. Murakoshi, «Hardware Architecture for Hierarchical Control of Large Petri Net,» 1993.

[13] G. Izquierdo, Modelado e implementación de sistemas de tiempo real mediante redes de petri con tiempo, Zaragoza, 1999.

[14] F. Bause y P. Kritzinger, Stochastic Petri Nets: An Introduction to the Theory, Vieweg, 2002.

[15] J. L. Peterson, Petri Nets, ACM Computing Surveys: 223-252, 1997.

[16] O. Micolini, M. Pereyra, N. A. Gallia y M. A. Alasia, «Procesador de Petri para la Sincronización de Sistemas Multi-Core Homogéneos,» de CASE 2012, Buenos Aires, Argentina, 2012.

[17] Atlys, «Digilent,» 2012. [En línea]. Available: Digilent.com.

[18] Xilinx, «MicroBlaze (UG708),» 2012.

[19] Xilinx, «AXI Interconnect (DS768),» 2012.

0

20000

40000

60000

80000

8 16 32

Flip-Flops Timed Petri

LUTs Timed Petri


8

�Implementación de un microcontrolador softcore de 8 bits en

una FPGA de la familia Spartan de Xilinx� Rodriguez J.; Martinez F.; Jacinto E.

Estudiante de Tecnología en Electrónica. U. Distrital Francisco José de Caldas Ingeniero en control electrónico. U. Distrital Francisco José de Caldas Ingeniero en control electrónico. U. Distrital Francisco José de Caldas

El trabajo presenta el diseño de un microcontrolador RISC de 8 bits en VHDL y su implementación en una FPGA, teniendo como referencia el núcleo de los microcontroladores de gama media de Microchip 16FXXX. Dicho microcontrolador ha sido diseñado mediante bloques modulares y responde a una arquitectura de tipo Harvard. Tiene una pila de ocho niveles. Posee una unidad de memoria de programa de 8K x 14 bits y un bloque de memoria de datos de 512 x 8 bits. El número de posiciones de almacenamiento de estos módulos de memoria es fácilmente escalable y/o modificable según la necesidad del diseñador gracias a la alta abstracción que se ha utilizado en su descripción. De igual forma, los demás bloques (así como el microcontrolador en general) son de fácil modificación, ofreciendo como resultado un sistema modular de excelente versatilidad al que se le pueden adaptar módulos adicionales como por ejemplo: puertos de entrada y salida; temporizadores; bloques para comunicación entre otros. El dispositivo planteado, manifiesta concurrencia con el OPCODE de instrucciones de los PIC16FXX, es decir que el sistema se puede programar con el mismo lenguaje de máquina. Además presenta compatibilidad con compiladores fuertes como MPLAB (Microchip Assembler), PIC-C (CCS) y sus correspondientes IDEs. La funcionalidad con el compilador en C (PIC-C) es bastante interesante ya que es una herramienta que facilita en gran magnitud el desarrollo de diseños digitales, gracias a la existencia de extensas librerías y bibliotecas en éste lenguaje de programación.


9


10

��ABC��

DAEF��E��

� �


11


12

“Diseño completo de un microprocesador de 8 bits” Makar, Guillermo; Rigoni, Nicolás; Alpago, Octavio; Martin Diego

[email protected]; [email protected] Laboratorio de Sistemas Digitales

Facultad de Ingeniería, UBA

Resumen – En este poster presentamos los distintos pasos del proceso de diseño de un microprocesador de 8 bits en un proceso CMOS estándar de 90nm. Como resultado se obtuvieron los circuitos esquemáticos sintetizados y el layout completo del mismo listo para ser fabricado.

El microprocesador diseñado cuenta con una arquitectura de tipo Harvard, con un bus de datos y direcciones de 8 bits cada uno. Se implementó un set reducido de 24 instrucciones con modos de direccionamiento directo e inmediato, un contador de programa que permite direccionar 256 palabras de memoria y los indicadores de estados (flags) necesarios para realizar las distintas operaciones.

Dadas las especificaciones requeridas se diseñó a nivel RTL, utilizando lenguaje Verilog, un circuito lógico que cumple con las mismas y los bancos de prueba necesarios para verificar su correcto funcionamiento.

Mediante las herramientas de la firma Synopsys Inc. y la definición previa de las directivas de diseño (design constraints) adecuadas para el procedimiento, se sintetizó el código y se generó el layout para la fabricación del integrado sobre un kit de proceso abierto CMOS de 90nm que incluye las celdas necesarias a fin de acotar el problema.

Se realizaron varias corridas de síntesis para evaluar la versatilidad del sintetizador en base a las directivas definidas pudiéndose comparar los reportes entregados en cada caso y comprender la relación de compromiso entre las tres variables principales de diseño: área, tamaño y velocidad de operación. Junto con esto, se realizó una simulación a nivel de compuertas con la que se corrobora que el layout final cumple con las especificaciones de hardware planteadas.

En todos los pasos de diseño se tuvo en cuenta la versatilidad del código a fin de que este pueda ser escalable a microprocesadores con mayor capacidad de direccionamiento de datos, conjunto de instrucciones más amplio o mayor memoria de programa. Es decir que las posibles aplicaciones son muy variadas ya que presenta la posibilidad de extender sus funcionalidades a lo que la aplicación particular requiera.


13


14

��ABC��

DAEF��E��

��A


15


16

Analysis and Implementation of Adaptive Models LMK and LM-Skewness on FPGA.

Application to Noise Cancellation

Miguel Enrique Iglesias Martínez Research and Development Department

Center of Development of Electronics and Automatic, CDEA Pinar del Río, Cuba

[email protected]

Abstract� This work describes the implementation of adaptive

algorithms based on higher order statistical characteristics such

as the Kurtosis and the proposed algorithm based on the error

Skewness, using the cost function approach proposed in [1].

Furthermore, a comparison of different implementations of these

algorithms in terms of hardware resource consumption, and

convergence speed is made. Besides of its compare with the

results of LMS algorithm for different noise levels. Taking as

central axis of the work, the flexibility of FPGAS devices and the

advantages of algorithms acceleration for hardware in specific

applications.

Keywords- FPGA; Kurtosis; Skewness; Noise Cancellation

I. INTRODUCTION

Today adaptive systems have found applications into many areas where the system learning capacity is an important factor. These applications range from the modeling of plants with unknown properties, until the use of these systems to noise reduction [2].

Square error cost function in all adaptive filtering algorithms is the simplest function in minimization mathematics processing of the cost function. In real applications fields, Least Means Squarre (LMS) algorithm is a basic algorithm and based on second order statistics, its performance in handling environmental noise is lower and its computational complex is high [3] [4].

In adaptive FIR systems, LMK (Least Means Kurtosis) algorithm is very robust to impulsive noise distribution, uniform noise distributions, but its computational complexity is fairly high in comparison with LMS algorithm, and this can be a disadvantage for low cost hardware architectures.

Using higher order Statistics filters some related works have been done and its topics are about the cross-cumulant computation or the realization of a higher order median filter for image processing and Measurement Instrumentation [5][6]. But none of these works covers the FPGA implementation and the algorithm employment, using the signal skewness.

The aim of this work is to show the LMK algorithm implementation on a reconfigurable architecture, likewise the model based implementation of error skewness (LM-

Skewness). Firstly, analyzing Matlab simulation of both algorithm, and its synthesis by means of Xilinx System Generator working platform.

The paper is organized as follows: Section 2 explains the basic concepts of adaptive models used to FPGA implementation, as well as the proposed model based on the error skewness as cost function. Section 3 shows the architecture and design platform. Section 4 shows the obtained results from the proposed design and its comparison with simulation results. Finally sections 5 and 6 reflect the obtained conclusions from this work and the consulted references.

II. ADAPTIVE ALGORITHMS

A. LMS Algorithm

The cost function of LMS algorithm is given in [7] as follow:

)]([)( 2 neEnJ LMS = (1)

where is error signal and:

∑=

−⋅−=P

k

k knxbndne1

)()()( (2)

where is reference signal, is weight vector, is input signal. The recursive relation of the LMS algorithm is written by:

)]([)()1( nJnbnb LMS−∇⋅+=+ µ )()(2)( nxnenb µ+ (3)

where µ is a step size, and 10 << µ , [3].

This algorithm is computationally easy but its main disadvantage lies in the non-modification of ȝ factor through the adaptation process. This is not good for dynamic environments, where noise characteristics fluctuate.


17

B. LMK Algorithm

The Kurtosis of a signal is defined as the fourth-order

cumulant of the source signal [8], that is )0,0,0(4CKurt =. The fourth order cumulant of the error signal is defined by:

)]()()()([),,( 3213214 ττττττ +⋅+⋅+⋅= teteteteEC e

)()( 32212 τττ −− ee CC

)()( 13222 τττ −− ee CC

)()( 21232 τττ −− ee CC (4)

)]([3)]([)0,0,0( 2244 neEneECKurt e −== (5)

When the contaminated signal is affected by Gaussian noise, this noise is suppressed completely theoretically, since the cumulant of a Gaussian distribution for higher orders than two is zero. LMK algorithm for its ideal performance surface is given by the negative of error signal Kurtosis [1] [4].

)]([)]([ neKurtneJ LMK −=

)]([)]([3 422 neEneE −= (6)

The LMK algorithm is a steepest descent procedure, which

uses a stochastic approximation of the gradient of (6). It is defined by the following recursions:

)]([)()1( nJnbnb LMK−∇⋅+=+ µ (7)

)()()}()]([3{4)]([ 22 nxneneneEnJ LMK −=−∇ (8)

where 22 )]([ σ=neE , is the variance of error signal, for real-time algorithm implementation, has to be estimated. This can be done using the following [1]:

)()1()( 222 nenn +−= βσσ (9)

where 10 << β is a forgetting factor [1][3].

C. Least Means Skewness Algorithm

In this work the computational complexity and hardware

resource consumption diminishes, using signal skewnnes in place of the kurtosis. Furthermore the skewnnes properties, for Gaussian signals are maintained as to the kurtosis.

The signal Skewness concept is based on the third order cumulant calculation, which similarly to (4),it is given by:

)]()()([),( 21213 ττττ +⋅+⋅= teteteEC e

SkewnessteEC e == )]([)0,0,0( 33 (10)

to update the filter coefficients is used the following :

)]([)()1( nJnbnb Skewness−∇⋅+=+ µ (11)

k

e

Skewnessb

CnJ

∂∂

=−∇2/)0.0.0(

)]([2

3 (12)

2

}])()({[2/)0.0.0(

23

12

3∑=

−⋅−=

∂∂

P

k

k

k

e knxbndE

b

C

⋅−⋅−∑=

}])()({[2 3

1

P

k

k knxbndE

2

))(()]()([31

2∑=

−−⋅−⋅−⋅P

k

k knxknxbnd

))(()()}({3)]([ 23 knxneneEnJ Skewness −−⋅⋅=−∇ (13)

then substituting (13) in (11), it is obtained the final equation to update the filter coefficients using Least Means Skewness Algorithm:

)()()}({3)()1( 23 nxneneEnbnb ⋅⋅⋅+=+ µ (14)

III. ARCHITECTURE AND DESIGN PLATFORM

A. Simulation Analysis

Once fact the theoretical analysis, simulation analysis begin using both algorithms (Least Means Skewness and LMK). Furthermore, a comparison is made with LMS variant, according to the signal parameters, for that which the system must respond according to noise characteristics present in the useful signal. White Gaussian noise of zero mean and constant variance is used as interference signal. A sinusoidal tone of frequency 50Hz sampling to 50 KHz is used as useful signal. The signal/noise ratio (SNR) at input was of -20.97dB. In figure 1 and figure 2 it is shown the useful signal and the noisy signal respectively.


18

Fig 1. Useful Signal

Fig 2. Noisy Signal SNR==-20.97dB

The obtained results for the Least Means Skewness and LMK algorithms it is shown respectively in figures 3 and 4. By other side, the figure 5 shows the obtained result for LMS filter, using convergence factor and filter order, similar to those used by the statistical models.

Fig 3. Output using LMK Algorithm µ=1 , filter order3

Fig 4. Output using LM-Skewness Algorithm µ=1 ,filter order 3

Fig 5. Output using LMS Algorithm µ=1 , filter order 3

Concluding simulation analysis, Figure 6 shows the convergence analysis in order to minimize mean square error in both algorithms LMK and LM-skewness, besides of to do a comparison with the LMS model. The convergence factor used to each algorithm were ,

and respectively. This experiment was repeated for 100 iterations and the resulting curve is shown below.

Fig 6. Convergence Analysis for White Gaussian Noise

Table I lists the obtained data from signal/noise ratio estimation at output with respect to the obtained power in each case for a common input SNR of -20.97dB.


19

TABLE I. SIGNAL/NOISE RATIO ESTIMATION

Algorithm Output SNR (dB)

LMK 13.54

LM-Skewness 13.09

LMS 1.0024

B. FPGA Implementation

Once seen, simulation analysis, the architecture implementation of adaptive noise cancellation algorithm it is initiated, for both, LMK and the corresponding variant using the error signal skewness as cost function.

The system was synthesized in SPARTAN-3E Xilinx FPGA architecture and was performed through Xilinx System Generator tool, by means of functional blocks of the tool itself.

The used structure to FIR (Finite Impulse Response) filter design was The Direct Form [9], and hardware architecture used it is shown in Figure 7. As can be seen, this is a simple structure of three coefficients.

Fig 7. The used FIR Structure of Three Coefficients

Should be noted that multipliers for FIR filter synthesis were described in VHDL to avoid the latency blocks from multiplication in System Generator library. Then, after obtaining the FIR filter, LMK algorithm implementation in System Generator is performed, for its next inclusion in a noise cancellation system.

In figure 8 the LMK algorithm hardware architecture is observed, besides in the figure 9 the scheme implementation of LM-Skewness algorithm in System Generator is seen. Also in Figure 10 it is shown the hardware architecture for adaptive noise cancellation system, which it include the VHDL block for DAC (Digital Analog Converter) controller in SPARTAN-3E starter kit.

Fig 8. Hardware Architecture for LMK Algorithm,µ=1 , filter order 3

Fig 9. Hardware architecture for LM-Skewness Algorithm, µ=1 , filter

order 3

As it is shown in the above figures, the LMK algorithm has a computational complexity higher than the LM-Skewness; this is due to multipliers consumption in the associated hardware, and the iterative calculation of the variance contribution in each sample, to the error signal for each clock cycle. In addition to that, the signal skewness algorithm has almost 22% multipliers less than LMK algorithm.


20

Fig 10. Hardware Architecture for Adaptive Noise Cancellation System

In Figure 11 it is shown, the resources consumption used in adaptive filter algorithms implementation, through reference summary of ISE XST (Integrate Software Environment) .

As it is shown in Figure 11 a higher resources consumption in terms of embedded multipliers exist in LMK algorithm implementation, not in the case of LM-Skewness, that which is more viable its hardware synthesis.

On the other hand, the performance in terms of signal to noise ratio at the output is similar for each algorithm, this validates the proposal for use the LM-skewness algorithm, to adaptive noise cancellation tasks.

Fig 11. Comparison of resource consumption that originated both

implementations.

In Figure 12 it is shown the output signal of each algorithm during fpga implementation. Note that the data processing in both algorithms was made on the maximum length of 16 bits, using fixed point precision, with 12 bits for the fractional part and the rest for the integer part. Likewise all the inside processing is performed with a precision fixed point format of [32 24].

All operations in this design were forced to work with this precision without overflow, taking into account the device resources and without compromising the efficiency of the

algorithm to obtain optimal results, consistent with the obtained results in simulation.

Fig 12. Output Signal of each Algorithm during FPGA Iimplementation.

In Figure 13 it can be seen a comparison of frequency

spectra at output of each algorithm LMK and LM-skewness; having similar results, for the noise treatment in environments with low SNR (Table I).

Achieving an output signal power of 0.5263 units for the LMK algorithm and 0.5183 units in the LM-Skewness. This result is close to the original power of the useful signal employed, which is 0.5 units. Another parameters as correlation is used as similarity measurement, the obtained value from LMK algorithm in comparison with useful signal was 0.9203 and for LM-Skewness algorithm was 0.9184.

Fig. 13 Illustration of: a) LMK Algorithm Frequency Spectrum b) Least

Means Skewness Algorithm Frequency Spectrum .

About timing response and work frequency of both algorithms, the table II shows the results. These results were obtained in post place and route simulation and taking into account that the selected sampling frequency is the board base clock in this case, 50MHz.


21

TABLE II. DESING TIMING ANALYSIS

Algorithm Minimum Period (ns)

Maximum Frequency(MHz)

LMK 31.581 31.665

LM-Skewness 27.342 36.574

In order to see the power consumption of each algorithm it is used the Xilinx XPower tool. A summary of the obtained results to each algorithm, it is shown below in the table III and IV respectively.

TABLE III. LM SKEWNESS ALGORITHM POWER CONSUMPTION

On- Chip Power (mW) Used Available %

Clocks 5.23 1 ------ ------

Logic 9.74 1132 29504 4

Signals 19.36 2179 ------ ------

IOs 0.32 7 250 3

BRAMs 0.34 2 36 6

MULTs 2.47 21 36 58

Quiescent 204.31

Total 241.78

TABLE IV. LMK ALGORITHM POWER CONSUMPTION

On- Chip Power (mW) Used Available %

Clocks 3.61 1 -------- -------

Logic 15.67 1465 29504 5

Signals 48.81 2787 -------- -------

IOs 2.09 7 250 3

BRAMs 1.36 2 36 6

MULTs 7.15 29 36 81

Quiescent 205.47

Total 284.17

IV. CONCLUSIONS

The implementation of adaptive filtering models using higher order statistics can be an excellent way to filter any

signal using a reference signal as a model, taking into account that all statistical Gaussian processes are cancelled, but unfortunately, its implementation can result in a high computational cost, although designs as it is shown here, using the Least Means Skewness algorithm it is a good choice, taking the correct arithmetic and without compromising the expected results; representing a work area saving if this represents a turning point in the implementation. Since involved operations are between vectors, means that there is a large consumption of dedicated elements, in this case multipliers as critical case in the design.

The proposed algorithm using the signal Skewness and not the Kurtosis reveal the possibility of synthesis for intermediate complexity architectures and guarantees similarity analysis convergence and noise reduction in a wide range of signals, furthermore, showing a bigger tendency to minimize the mean square error than the LMS algorithm.

ACKNOWLEDGMENT

I appreciate all the support of the Centre of Development of Electronics and Automatic, CDEA, in the development of this research. Thanks to all

REFERENCES

[1] O.Tanrikulu, A.G.Constantinides. Least mean kurt-osis: A novel higher-

order statistics based adaptive filtering algorithm. Electronics letters. 1994,30(3):189-190.

[2] Saeed V. Vaseghi, Advanced Digital Signal Processing and Noise Reduction, Four Edition, 2008, John Wiley & Sons Ltd.

[3] JI-CHENG LING1,LONG-QING HE1, YE-CAI GUO2.SIGNED LEAST MEAN KURTOSIS-BASED ADAPTIVE LINE ENHANCER .Proceedings of the Fifth International Conference on Machine Learning and Cybernetics, Dalian, 13-16 August 2006

[4] Jin Woo Yoo ,PooGyeon Park,An Improved Least Mean Kurtosis (LMK) Algorithm for Sparse System Identification. International Journal of Information and Electronics Engineering, Vol. 2, No. 6, November 2012

[5] Design of a configurable order statistic filter with FPGAs, Instrumentation and Measurement Technology Conference ISSN :1091-5281, Proceedings of the 17th IEEE (Volume:2 ),2000. obtained of: http://ieeexplore.ieee.org

[6] Realization of algorithm for the computation of third-order cross moments using FPGA, 9th International Symposium on Signal Processing and Its Applications, 2007, E-ISBN :978-1-4244-1779-8, obtained of: http://ieeexplore.ieee.org

[7] S. Haykin, �Adaptive filter theory,� 4th ed. Upper Saddle River, NJ:Prentice-Hall, 2002 .

[8] Nikias.C.L., Petropulu. A.P. Higher-order spectra analysis: A nonlinear signal processing framework.. Prentice-Hall International, Inc., New Jersey, 1993 .

[9] Roger Woods, John McAllister, Gaye Lightbody, Ying Yi, FPGA-based Implementation of Signal Processing Systems , Cap 2, page 35, John Wiley and Sons, Ltd., Publication, 2008 .


22

Design and Implementation of FPGA-Based TRUE-RMS Voltmeter Using CORDIC Algorithm

Donovan Camilo Platero Plazas Technology Department

Universidad Distrital Francisco José de Caldas Bogotá, Colombia

Email: [email protected]

Edwar Jacinto Gómez Technology Department



Abstract— Estimate the true-rms of an AC signal, it is an issue of accuracy and accessibility. First of all the results can be upset depending on the wave type, and secondly, when the complex operations processing on a true-rms multi meter is required, e.g., based on simple microcontrollers, this requires a high computation resource eventually expensive. This article, describes the research to route to the implementations of a true-rms voltmeter on a FPGA (Field Programmable Gate Array), using VHDL; it measures with plausible accuracy, the true-rms of a signal, on any circuit which do not get over 240Vp and 30KHz of frequency. The innovation is located in applying the CORDIC (COordinate Rotation Digital Computer) algorithm to solve the math operations - the extraction of square roots and so on- resulting in a practical digital device and computationally with a better performance.

Keywords— approximation algorithms; cordic; fpga; square root; true-rms; vectors

I. INTRODUCTION

At present, digital instrumentation devices which can calculate the true-rms of an AC signal can be found; these ones have a big accuracy, but they are not approachable to the most of the academic users.

When a midrange or low-end multi meter is purchased, it is able to measure DC voltages with an accuracy of 10% or bigger, but it does not measure the true-rms of an AC signal because of that, it always takes the input signal as a sine wave and the results are altered depending on the kind of wave,[1].

On the other hand, when an application that needs complex operations processing is performed,, like a true-rms multimeter, is possible to use a microcontroller to realize these process, but they will never be reliable because on simple microcontrollers, the operations, as multiplications and divisions, become it is a imprecise task, and in most times the internal hardware does not have the necessary to the application. About, a multiplication process can delay several machine cycles of the device, also it depends of how big is the bit quantity; other operations (square roots, exponentials, logarithms, trigonometric functions, hyperbolic functions) require a higher time and it means that the process of complex operations on simple microcontrollers demand a high computational resource, reducing noticeably the performance‟s application.

Nowadays, although the digital hardware has advanced, it is necessary the more intensive implementation of math tools that they raise the performance on the calculation of operations like the above. Therefore, to the instrument development has been implemented, the CORDIC algorithm [2],[3] , which enables to realize math operations just with sums and bit shifts [4-6] , this does that the application has an immense performance with low cost and a high DSP (Digital Signal Processing) speed, it also achieve, that the developed device, besides efficient[7-9] , it‟s approachable for the academic community.

II. CORDIC ALGORITHM

CORDIC is an efficient algorithm that provides an iterative method for the calculation of some complex math operations rotating a bidimentional vector in circular, linear and hyperbolic coordinate systems, using only add and shift operations. It operates in two modes, rotate mode and vectoring mode. In the rotation mode, the vector (x, y) is rotated a specific angle (し) to obtain a new vector (x‟, y‟); and in the vectoring mode, the vector is rotated to the x-axis, accumulating the necessary angle to effect this rotation. The CORDIC algorithm was developed by Jack Volder [2] in 1959 only for calculating trigonometric functions (circular coordinate system) to solve navigation problems on planes. Later, the algorithm was generalized by J. S. Walther, extending it to the linear and hyperbolic coordinate systems, and converting it, in a powerful math tool to the compute of complex operations, [3].

The CORDIC iteration equations are: 捲沈袋怠噺捲沈伐憲ぇ検沈ぇ穴沈ぇに貸沈検沈袋怠噺検沈髪捲沈ぇ穴沈ぇに貸沈権沈袋怠噺権沈伐穴沈ぇ血岫に貸沈岻

Where 血岫捲岻 and 憲 change depending on the coordinate system as:

血岫捲岻噺崔建欠券貸怠岫捲岻┸ 潔件堅潔憲健欠堅捲┸ 健件券結欠堅建欠券月貸怠岫捲岻┸ 月検喧結堅決剣健件潔


23

TABLE I. GENERALIZED CORDIC ALGORITHM.

Mode _________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Rotation mode (権津噺ど岻 Vectoring mode(検津噺ど岻

Circular

捲津噺畦津岫捲待岫権待岻伐検待岫権待岻岻検津噺畦津岫検待岫権待岻髪捲待岫権待岻岻

畦津噺敷紐な髪に貸態沈津貸怠沈退待簡ど┻はどばぬ

捲津噺畦津盤紐捲待態髪検待態匪権津噺権待髪建欠券貸怠磐検待捲待卑

畦津噺敷紐な髪に貸態沈津貸怠沈退待

Linear

捲津噺捲待検津噺検待髪捲待権待

捲津噺捲待権津噺権待髪検待捲待

Hyperbolic

捲津噺畦津岫捲待月岫権待岻髪検待月岫権待岻岻検津噺畦津岫検待月岫権待岻髪捲待岫権待岻岻

畦津噺敷紐な伐に貸態沈簡ど┻ぱど津沈退怠

捲津噺畦津盤紐捲待態伐検待態匪権津噺権待髪建欠券月貸怠磐検待捲待卑

畦津噺敷紐な伐に貸態沈津沈退怠

憲噺班な┸ 潔件堅潔憲健欠堅ど┸ 健件券結欠堅伐な┸ 月検喧結堅決剣健件潔

The 穴沈 value depends on the mode; in rotation mode the equation is: 穴沈噺峽伐な件血権沈隼どな剣建月結堅拳件嫌結

And in vectoring mode: 穴沈噺峽な件血検沈隼ど伐な剣建月結堅拳件嫌結

By selecting appropriate values for each parameter of the CORDIC equations, a different coordinate system can be selected; also, a different math operation can be effected. For a straightforward interpretation of the algorithm, Table 1 is introduced for the parameters, and after 券 iterations, results the different equations to obtain 捲津, 検津 and 権津.

The rotations on hyperbolic coordinate system do not converge, however Walther demonstrated that convergence is achieved if specific iterations are repeated (件噺ね┸ なぬ┸ ねど┸ ┼ ┸ 倦┸ ぬ倦髪な┸┼), [4-12].

A. CORDIC Square Root

To know the true-rms of a signal the computation of square root operation is necessary, for this, CORDIC provides a simple method to extract it, only using the hyperbolic rotation in vectoring mode.

In vectoring mode for hyperbolic coordinate system, after 券 iterations, the equations are: 捲津噺畦津岾紐捲待態伐検待態峇 (8) 権津噺権待髪建欠券月貸怠岾槻轍掴轍峇 (9)

畦津噺敷紐な伐に貸態沈津沈退怠岫など岻

If: 捲待噺欠髪怠替検待噺欠伐怠替

By replace these values in (8), the result obtained is: 捲津噺畦津ヂ欠 (13)

Whereupon, the square root of 欠, has been found, but with a scaled factor 畦津, [13],[14] .

B. Quantization Effects on CORDIC

By Implementing the CORDIC algorithm on hardware, a previous quantization must be done. When it is done, two types of quantization errors are found: first, the approximation error due to the quantization of rotation angles and the second is the rounding error because it has a finite precision arithmetic. By rotating an angle in the CORDIC algorithm, it affects micro-rotations of predetermined angles to reach the needed angle. By doing it, maybe the arrival angle cannot be exact; and thus, an approximation error is introduced by CORDIC.

Therefore in the rounding error, each CORDIC iteration can introduce or propagate two error types. One of them is the rounding error propagated from the previous iteration (except on the first), and the other is the rounding error introduced in the present iteration.

The specific study can be viewed in [15].

III. TRUE-RMS CALCULATION

A. Measurement of Root Mean Square value

The RMS true value of a continuous signal of a continuous time is defined as:

撃追陳鎚噺俵な劇豹血岫建岻態痛轍袋脹痛轍穴建岫なね岻

However, the calculation of TRUE-RMS on digital devices is completely different; the signal has to be discretized (sampled) and quantized. The TRUE-RMS of a discrete time signal can be seen in (15):

撃追陳鎚噺彪な軽布捲岷券峅態朝貸怠津退待岫なの岻

Where 捲岷券峅 is the sample signal and 軽 is the sample number in a period. [16].

B. Sampling

By sampling a signal, its frequency has to be considered. According to the Nyquist-Shannon theorem, the input signal, must be sampled at least with twice the maximum signal


24

frequency, this prevents that the aliasing occurs, but a big error is produced by approximating the signal, [17].

Therefore, a bigger frequency must be used for decreasing the error. In Figure 1, a sine wave sampled with twice its frequency is shown.

Fig. 1. Sampled signal with twice its frequency.

The blue points indicate the taken samples of the red signal; however, it is a poor approximation of the signal. Otherwise, if a bigger frequency is used to sampling the signal, better approximation and smaller error are achieved. To show this, in Figure 2 a better approximation of the signal when the sampling frequency is 8 times higher than its frequency is shown.

Fig. 2. Sampled signal with 8 times its frequency.

If the first approximation is interpolated, the obtained function is the zero constant, with an error of 100%; while, if the second is interpolated, this is similar to the original, the new function is the shown in Figure 3.

Further on, it is shown, what it was the frequency sampling used.

C. Quantization and Codification

When the data is quantized, these ones take specific values before defined by the conversion system. By quantizing, a level voltage is measured at each sample obtained on the previous process and a value corresponding to the sample is assigned codifying it. This process has a level of accuracy, and

it depends on the bits of resolution that the ADC has. This quantization process generates a difference between the original signal and the quantized signal; it is called quantization noise, which can be corrected with a better bit resolution[18],[19] .

Fig. 3. Interpolated Signal.

IV. DEVICE IMPLEMENTATION

A. Block Diagram

The block diagram of the device is shown in Figure 4:

Fig. 4. Block Diagram.

First, on the diagram block, a voltage divider is found, which has some resistors to do the voltage reduction, thus, the device can measure high voltages and also avoid being damaged. After that, it is a Zero-Crossing Detector, it uses to generate the necessary clock that the FPGA will send to the ADC device to the signal sampling. On the Signal Conditioning block, the signal from the voltage divider is inverted (because before the ADC, the Spartan 3E Starter Kit has an inverting PGA (Programmable Gain Preamplifier)) and mounted on DC level insomuch as, the ADC has a reference voltage.

The Spartan-3E Starter Kit contains FPGA device, Programmable Gain Amplifier, Analog-Digital Converter,


25

LCD display and other modules which are not used on the device implementation. The ADC device is a LTC1407A, which has two 1.5Msps simultaneously sampled differential inputs. On the Starter Kit, the ADC has a 1.65V reference voltage thus differentiating, positive and negative voltages. Finally, the ADC presents a 14-bit; two‟s complement digital output [20]. The XC3S500E is responsible to control all necessary processes that the True-RMS calculation requires, starts with ADC and amplifier programming to the LCD visualization. On the FPGA, the square root operation is effected by implementing the CORDIC square root algorithm. Also, FPGA device calculates the necessary clock for the ADC to do that, this takes 16 samples for any input signal, the received data are saved on RAM then the respective operations with them are done. Finally, a Xilinx Picoblaze processor was used for the LCD visualization, providing an easier device implementation [21],[22] . On Figure 5, the FPGA design block is shown.

Fig. 5. FPGA Design.

ANALYSIS AND RESULTS

It can be said that an analog-digital instrumentation device was obtained that it can be used on any type of electronic system, which analyzes DC and AC signals. An excellent accuracy device made in Colombia, special to the analysis of DSP applications, implementing a practically new technology that it has not been used in our country and it can be implemented on hardware due that the computational resource required is little.

Figure 6 shows a measurement example of a square signal with peak voltage of 7.4V and frequency of 20.15 KHz.

Fig. 6. Voltage measurement on Square Wave.

Now, on Table 2, a comparison of the measured voltage by the TRUE-RMS implemented voltmeter and the Fluke 87 TRUE-RMS multi meter.

TABLE II. COMPARISON BETWEEN IMPLEMENTED VOLTMETER AND FLUKE 87.

Number of meas.

Frequency(Hz) Type of wave Peak

Voltage (V)

Measured Voltage FPGA (V)

Measured Voltage Fluke 87 V(V)

Real Vrms(V)

Ec. 14

Relative FPGA error

Relative Fluke error

1 3061 sine 10 7.301 6.75 7.071067812 3.24% 5% 2 3061 triangular 10 5.976 5.76 5.773502692 3.51% 0% 3 3061 square 10 10.120 9.60 10 1.20% 4% 4 0 dc 10 10.231 9.80 10 2.30% 2% 5 60 sine 10 7.271 6.75 7.071067812 2.81% 5% 6 60 triangular 10 5.930 5.70 5.773502692 2.71% 1% 7 60 square 10 10.121 9.60 10 1.20% 4% 8 0 dc 10 10.223 9.80 10 2.23% 2% 9 60 sine 5 3.632 3.40 3.535533906 2.73% 4% 10 60 triangular 5 2.951 2.76 2.886751346 2.19% 4% 11 60 square 5 5.310 4.80 5 6.00% 4% 12 0 dc 5 5.211 4.98 5 4.00% 0% 13 4549 sine 5 3.291 3.10 3.535533906 6.94% 12% 14 4529 sine 10 7.310 6.68 7.071067812 3.38% 6% 15 4529 triangular 5 3.024 2.59 2.886751346 4.75% 10% 16 1000 square 5 5.017 4.55 5 0.34% 9% 17 4529 square 5 5.101 4.27 5 2.00% 15% 18 12930 sine 6.24 4.197 3.97 4.412346315 4.88% 10% 19 12930 triangular 6.24 3.391 3.28 3.60266568 5.90% 9%


26

20 12930 square 6.24 6.102 5.38 6.24 2.24% 14% 21 20000 sine 7.2 5.041 4.96 5.091168825 1.01% 3% 22 20000 triangular 7.2 4.178 4.08 4.156921938 0.51% 2% 23 20000 square 7.2 7.030 6.57 7.2 2.36% 9%

TABLE III. USED FPGA RESOURCES

On-Chip Power(W) Used Available Utilization (%)

Clocks 0.000 10 -- -- Logic 0.000 1662 9312 18

Signals 0.000 2182 -- -- BRAMs 0.000 1 20 5 MULTs 0.000 3 20 15 DCMs 0.014 0 4 0

IOs 0.000 27 232 12 Leakage 0.084

Total 0.098

The Fluke 87 multi meter has an average relative error of 5%, while the TRUE-RMS implemented voltmeter has a relative error of 2.98%, improving the accuracy.

Table 3 shows the used resources of the XC3S500E FPGA.

V. CONCLUSIONS

A FPGA-Based Voltmeter was successfully implemented, which measures the TRUE-RMS with an accuracy of 2.98% to AC signals not exceeding 240Vp and 30 KHz. If the voltage is exceeded the device could be damaged, on the other hand, if it exceeds the 30 KHz, the error measure could exceed the 20% or more.

An advantage of the device is that it is FPGA-Based, and it can be reprogrammed to improve its function.

REFERENCES [1] M. Electr and P. F. P., “Curso de Capacitación en Medidas Electrónicas

Año 1999,” 1999. [Online]. Avaliable: http:// http://www.frm.utn.edu.ar/medidase2/varios/tester1.pdf.

[2] J. E. Volder, “The CORDIC Trigonometric Computing Technique *,” pp. 330–334, 1959.

[3] J. S. Walther, “A Unified Algorithm for Elementary Functions”, Spring Joint Computer Conference, pp. 379-385, 1971

[4] R. Andraka, “A survey of CORDIC algorithms for FPGA based computers,” Proceedings of the 1998 ACM/SIGDA sixth international symposium on Field programmable gate arrays - FPGA ‟98, pp. 191–200, 1998.

[5] E. Garcia, R. Cumplido, and M. Arias, “Pipelined CORDIC Design on FPGA for a Digital Sine and Cosine Waves Generator,” 2006 3rd International Conference on Electrical and Electronics Engineering, vol. 1, no. 3, pp. 1–4, 2006.

[6] O. N. Bria and H. A. Villagarc, “Descripción en VHDL de arquitecturas para implementar el algoritmo CORDIC.”,2002.

[7] F. Angarita, A. Perez-Pascual, T. Sansaloni, and J. Valls, “Efficient fpga implementation of cordic algorithm for circular and linear coordinates,” International Conference on Field Programmable Logic and Applications 2005, no. 1, pp. 535–538, 2005.

[8] J. Valls, M. Kuhlmann, and K. K. Parhi, “EFFICIENT MAPPING OF CORDIC ALGORITHMS ON FPGA,” 2000 IEEE Workshop on SiGNAL PROCESSING SYSTEMS SiPS 2000 Design and Implementation Cat No00TH8528, pp. 336–345, 2000.

[9] L. Vachhani, K. Sridharan, and P. K. Meher, Efficient CORDIC Algorithms and Architectures for Low Area and High Throughput Implementation, vol. 56, no. 1. 2009, pp. 61–65.

[10] S. Yang, Z. Wu, and G. Ren, “Design and Implementation of FPGA-Based FSK IF Digital Receiver V ~~~~~ ACEAXIKEPKIOOQC208-3 ).”

[11] M. Ye, T. Liu, Y. Ye, G. Xu, and T. Xu, “FPGA Implementation of CORDIC-Based Square Root Operation for Parameter Extraction of Digital Pre-Distortion for Power Amplifiers,” 2010 International Conference on Computational Intelligence and Software Engineering, pp. 1–4, Sep. 2010.

[12] P. K. Meher, S. Member, J. Valls, T. Juang, K. Sridharan, and K. Maharatna, “50 Years of CORDIC鳥: Algorithms , Architectures , and Applications,” vol. 56, no. 9, pp. 1893–1907, 2009.

[13] B. Yang, D. Wang, L. Liu, and A. Notations, “Complex Division and Square-Root Using CORDIC,” no. 61106022, pp. 2464–2468, 2012.

[14] C. Agurto, “IMPLEMENTACIÓN DE ARQUITECTURAS PARA EL CÁLCULO DE FUNCIONES TRASCENDENTALES EMPLEANDO EL ALGORITMO CORDIC EN UN FPGA.”, 2006.

[15] Y. Hen Hu, “T H E QUANTIZATION EFFECTS OF,” no. i, pp. 1822–1825, 1988.

[16] U. B. Mujumdar and J. S. Joshi, “Microcontroller based true RMS current measurement under harmonic conditions,” 2010 IEEE International Conference on Sustainable Energy Technologies (ICSET), pp. 1–5, Dec. 2010.

[17] A. Oppenheim, A. Willsky“ Signals and Systems.”,Ed. Prentice Hall, 1998.

[18] Muestreo y Cuantificacion. [Online]. Available: http://ceres.ugr.es/~alumnos/luis/mycuan.htm

[19] Cuantificacion. [Online]. Available: http://prof.usb.ve/tperez/docencia/2422/contenido/Cuantifico/CUANTIFICO.htm

[20] S. S. Kit, “Amplifier and A / D Converter Control,” no. February, 2006. [Online]. Available: http://www.xilinx.com/products/boards/s3estarter/files/s3esk_picoblaze_amplifier_and_adc_control.pdf.

[21] PicoBlaze 8-bit Embedded Microcontroller User Guide, 2011. [Online]. Available: http://www.xilinx.com/support/documentation/ip_documentation/ug129.pdf.

[22] F. Poderico, Picoblaze C Compiler, 2005. [Online]. Available: http://www.ux.uis.no/~karlsk/ELE610/dok/pccomp_manual.pdf


27

1

Estrategias de Optimización de Hardware para Máquinas de Estados en VHDL

Edwar Jacinto Gómez Departamento de Tecnología



Mario Fernando Robayo Restrepo Departamento de Tecnología



Abstract—Una de las metodologías más utilizadas cuando se diseñan procesos secuenciales en VHDL son las máquinas de estados, ya que en la mayoría de estos diseños, se hace necesario su uso. Para la implementación de una máquina de estados se pueden usar diferentes metodologías de diseño, algunas de ellas utilizando herramientas CAD (Diseño Asistido por Computadora en español). En este artículo se dan a conocer las distintas caracterizaciones de las máquinas de estados y de que forma la comprensión de éstas junto con su correcto desarrollo en VHDL dentro de una FPGA (Field ProgrammableGateArray) y una CPLD (ComplexProgrammableLogicDevice), puede mejorar drásticamente la velocidad de respuesta de ésta y además optimizar el hardware utilizado normalmente.

Keywords—fpga; máquinas de estados; optimización; rom; vhdl

I. INTRODUCCIÓN

La limitante más importante cuando se realizan diseños utilizando dispositivos de lógica programable como FPGA o CPLD, es la cantidad de hardware utilizado en la aplicación por ésta razón se hace necesario realizar un diseño óptimo, aprovechando al máximo los recursos disponibles.

Las máquinas de estados finitos (siglas en inglés FSM), son el modelo más utilizado para describir un proceso secuencial en sistemas digitales. La descripción de éstas, en un lenguaje de alto nivel como VHDL se realiza de una forma sencilla, pero la mayoría de veces ésta parte del diseño utiliza bastantes recursos del dispositivo, y además el tiempo de respuesta de éste es mayor que la usada en un PIC convencional. De aquí la necesidad de aprender a describirlas de formas diferentes buscando el diseño más eficiente. [1-3]

Debido a esto, se plantean un conjunto de ideas obtenidas a partir de la compilación de una serie de trabajos en diseño digital avanzado, que pueden dar una perspectiva al diseñador de cómo enfocar sus esfuerzos para la optimización de diseños en VHDL.

II. MÁQUINA DE ESTADOS FINITOS

Una máquina de estados finitos es un sistema sincrónico (gobernado por un reloj), el cual tiene un número fijo de estados. Un ejemplo de una máquina de estados puede ser una secuencia de un semáforo, en la cual hay tres posibles salidas: rojo, amarillo y verde. [4-5]

En las máquinas de estados el valor de sus salidas puede depender, de las entradas y del estado actual (Máquina de

Mealy) Figura 1-a, o únicamente del estado en el que se encuentre ésta (Máquina de Moore)Figura 1-b

Fig. 1. a) Máquina de Mealy, b) Máquina de Moore.

III. CARACTERIZACIÓN DE LAS MAQUINAS DE ESTADOS

Si cuando se va a diseñar un proceso secuencial, como primera medida se revisara el tipo de máquina de estados a implementar, seguramente se lograrían mejores resultados en cuanto a la optimización del hardware. A continuación se muestran algunas caracterizaciones de las máquinas de estados logradas a través de la práctica. [6-9]

Cada una de las siguientes caracterizaciones aplica sin importar que la máquina de estados sea de tipo Mealy o Moore.

A. Caracterización en Dependencia de su Geometría

Lineal. En este tipo de máquinas los estados están geométricamente alineados uno después del otro, son ideales para procesos de comunicaciones, en que el reinicio depende de una señal externa. En la Figura 2, se muestra un diagrama ejemplo de una máquina lineal.[1,10]


28

2

Fig. 2. Máquina de estados Lineal

Multicolumna (Figura 3): Son máquinas de estado donde existe un punto que se bifurca dependiendo de las señales de entrada y cada brazo retorna a un estado inicial. Es usado típicamente para las unidades de control de procesos complejos.

Fig. 3. Máquina de estados Multicolumna para la unidad de control de un procesador

Multicolumna Bidireccional (Figura 4). Este tipo de máquinas de estado se diferencian de las anteriores porque éstas retornan al estado inicial por el mismo brazo. Son utilizadas en secuencias con un punto común.

Fig. 4. Máquina de estados Multicolumna Bidireccional para el Control de un Robot en una carpinteria

Caótica. Las máquinas de estado caóticas no tienen una forma geométrica definida.

Concéntrica: El ejemplo típico de estas máquinas es el sistema de control de luces de un semáforo (Figura 5), secuenciadores o controles de motores de paso. Se diferencia de las lineales en que estas últimas son mucho más largas y no necesariamente son cíclicas.

Fig. 5. Máquina de estados Concéntrica


29

3

B. Caracterización en Dependencia de su Codificacion de Estados

Codificación de estados hecha automáticamente por las herramientas CAD:

One Hot: Codificación de estados donde hay solamente un uno por código y se utilizan tantos flip-flops como estados existan. “Utilizada típicamente en FPGAs”.

Mínimo cambio de Bit (código Grey): Codificación de estados donde solamente hay un cambio de bit entre códigos adyacentes. “Utilizada típicamente en PLDs Y CPLDs”.

Conteo Enumerado (binario): Codificación de estados que utiliza la numeración binaria como asignación de códigos.

Codificación de estados realizada directamente por el diseñador:

Aleatorio (Random): Codificación de estados sin orden aparente.

Two Hot: Codificación de estados donde hay dos unos por código. También utiliza tantos flip-flops como estados existan. “Utilizada típicamente en FPGAs”.

Igual a las salidas: Codificación de estados donde el código del estado es igual a la salida de la máquina de estados.

IV. FORMAS DE IMPLEMENTACIÓN DE LAS MÁQUINAS DE

ESTADOS

Como primera medida si dentro de una aplicación existe una máquina de estados finitos muy compleja se debe contemplar la posibilidad de dividirla en varias máquinas más pequeñas, con funciones mucho más simples. En este caso las herramientas CAD soportan el diseño de más de un diagrama de estados y su posterior unión en una sola entidad final. [1,11-13]

Una máquina de estados se puede desarrollar en una de las siguientes formas según la descripción en alto nivel que de ella se haga, específicamente en este caso se da mediante un estilo de diseño donde se ve una única entidad y se dividen cada una de sus partes internas en procesos independientes y paralelos. Para este caso es bueno recordar que cuando se utiliza este estilo de descripción de hardware, el diseñador debe crear tantas señales como sean necesarias para concatenar cada uno de los procesos o partes del diseño implícitas, y que estas señales deben estar nombradas en las listas de sensibilidad indicadas, para que el proceso que describe cada una de las partes de la máquina de estados cambie cuando sea el momento indicado. Nombrando como ejemplo un caso específico como lo es la lógica de salida de la máquina, si dentro de la lista de sensibilidad, se nombra el reloj y dentro de la descripción se hace referencia a un flanco del mismo, cada una de las salidas de este proceso será asignada a un flip-flop.[14-16]

A. Toda la Máquina en un Proceso Ej:

Semáf: PROCESS (CLK,Estado[0 to 3]);

BEGIN

....

If (Estado = ´Siga´) Then

Sig_Estado<= ´Precaucion´;

Amarillo<= ´1´;

....

Como se puede ver en el texto anterior, en un solo proceso se asigna el código del siguiente estado y se asigna la salida.

B. El Control en un Proceso y las Salidas en OtroEj:

A0: PROCESS (CLK,Estado[0 to 3],

Í[0 TO 3]);

BEGIN

....

If (Estado = ´Llenado´) Then

Sig_Estado<= ´Mezcla´;

....

A1: PROCESS (Estado [0 to 3]);

BEGIN

....

A1: PROCESS (Estado [0 to 3]);

BEGIN

....

Case Estado is

When ’Llenado´=> Válvula<=´1´;

When ’Mezcla´ => Motor <=´1´; ....

En un proceso se encuentra el siguiente estado y en otro proceso se asignan los valores a las salidas.

C. Cada uno de los Bloques por SeparadoEj:

A0: PROCESS (Op_code[0 to 3],

Estado[0 to 3]);

BEGIN

....

CASE Op_code=>

When “add” =>

Estado_sig<= “post_write”; A1: PROCESS(CLK,Estado_sig[0 to 3]);


30

4

.... If rising_edge (clk) If reset = ‘0’ then Estado<= “cero”;

Else

Estado<= Estado_sig;

....

A2: PROCESS (Estado [0 to 3],

Op_code[0 to 3]);

....

CASE Estado=>

When “fetch” =>

Control_line<= “memory_acc”;

....

D. Los Estados son Iguales a las Salidas Ej:

Multi: PROCESS (CLK,Salidas[0 to 3], I[0 to 3]);

BEGIN

....

If (Sumar= ´1´) Then

Comp<= ´1´;

Elsif (Correr =´1´Then

....

Cuando se puede aprovechar ésta característica, la máquina de estados se minimiza al máximo, y se toman las salidas como buffer para no tener que declararlos. [17-19]

V. RESULTADOS

A partir de la caracterización, que es producto del trabajo en diseño de hardware de varios años de los escritores del artículo, se plantea la siguiente metodología de diseño de máquinas de estados con la cual se podría lograr reducción de hardware, todo esto se realizó sobre los parámetros de la metodología Top-Down:

Diseño del diagrama de estados. En este paso el diseñador, debe dibujar el diagrama de estados examinando si hay estados repetidos, o señales que se comporten igual utilizando solo una de ellas, o si la máquina es de mucha complejidad y lo apropiado es subdividirla.

En seguida el diseñador observando el diagrama de estados, puede determinar su tamaño, forma y número de estados y salidas como principales características. En este paso es donde el usuario debe determinar si vale la pena realizar la descripción por código o simplemente, se debe utilizar una herramienta CAD que arroje una descripción estándar.

Es aquí donde el diseñador tomando en cuenta las características de la máquina debe remitirse a las tablas que a continuación se muestran. Para determinar el tipo de descripción de hardware más apropiado.

Además como consejos adicionales, el diseñador después de terminar con la descripción y al mirar el reporte observa que su diseño:

a.) Ocupa muchos Flip-flops: Debería tratar de Codificar los estados por código, o contemplar la posibilidad de utilizar una ROM (como se muestra posteriormente).

b.) Las salidas presentan Glitch: EL diseñador debería realizar la lógica de salida, donde la salida que presente problemas se encuentre en un proceso dependiente del reloj.

c.) Ocupa muchas LUT o compuertas: El diseñador debería utilizar una codificación One-hotóTwo-hot.

A. Mejores Implementacionespor Codificación de los Estados

A partir de la arquitectura del PLD se tienen diferentes resultados para cada una de las caracterizaciones, el resumen se puede observar en la tabla 1.

Tabla 1. Mejores Implementaciones experimentadas, por codificación de los estados

No Caracterización CPLD FPGA

1 Lineal Gray, One Hot,

Igual a la salida.

Two Hot

2 Multicolumna Binay,

One Hot Gray

3 Multicolumna bidireccional

Gray Two Hot

4 Caótico Gray Gray,

Igual a la salida

Igual a la salida

5 Concéntrico Gray Binary

B. Mejores Implementaciones por Tamaño

Cuando se realiza la minimización de los estados de una máquina en dependencia de la geometría y el tamaño se debe implementar según la tabla2.

C. Mejores Implementaciones para Máquinas muy Grandes

Se consideran máquinas muy grandes a las máquinas de estados con 32 estados o más, claro que alguien más podría considerar que este número es un poco grande. [20-21]

A continuación se muestra un par de arquitecturas posibles (figura 6 y figura 7) para este tipo de máquinas de estados, que son muy apropiadas cuando se trabaja con FPGA que poseen LUTs que fácilmente se puedan convertir en ROM [2].


31

5

Tabla 2. Mejores implementaciones experimentadas, por tamaño

No Caracterización Pequeña Mediana Grande

1 Lineal A ,D B B

2 Multicolumna A ,D B, C B,C

3 Multicolumna

A ,D C C bidireccional

4 Caótico A ,D A, B B

5 Concéntrico A ,D A, B B

Tabla3. Siglas Utilizadas.

No. Forma de Implementar Sigla

1 Toda la máquina en un proceso A

2 El control en un proceso y las salidas en otro B

3 Cada uno de los bloques por separado C

4 Los Estados son iguales a las salidas D

Fig. 6. Máquina de estados Lineal con ROM

Fig. 7. . Máquina de Estados Multicolumna con ROM “el contador tiene carga paralela”

Tomando como base el desarrollo de 11(once) máquinas de estados en forma tradicional y luego modificándolas para desarrollarlas en cada caracterización se obtuvieron los resultados de la tabla 4

Tabla No. 4, Comparación retardo de máquina normal y maquina en ROM

CONCLUSIONES

Se puede concluir que por medio de la comprensión de las tipos de máquinas de estados se puede escoger el más apropiado para cada desarrollo.

Se planteó una metodología de diseño para máquinas de

estados en VHDLque desemboca en diversas formas de implementar las máquinas de estados, con la cual se mejora notablemente el uso de los recursos de los diferentes PLDs, y se muestran unos resultados experimentales que no son conclusiones absolutas, sino son la base para generar un pensamiento crítico en los diseñadores de hardware.

Se generó una caracterización de las Máquinas de Estados por su forma geométrica, su forma de descripción y el número de estados que ella misma posea, a partir de la cual se dan unas sugerencias de diseño que podrían producir una optimización del hardware, sin necesidad de que se experimente con los diferentes tipos de implementación.

A partir del análisis de las diferentes arquitecturas tanto de los PLDs, CPLDs y FPGAs se presentó una tabla a modo de sugerencia de cual tipo de codificación es la más indicada según la codificación de los estados. En esta instancia se debe recordar que en algunos

CLK

ENTRADAS INC

ESTADOS SALIDAS CLK

RESET

ROM

C O N T A D O R

ESTADOS

INC

SALTO DE ESTADO

LOAD

CLK

RESET

ROM

C O N T A D O R

SALIDAS

ENTRADAS

Número de Ejemplo

Max Delays(ns) % Reducción al usar ROM Normal

Usando ROM

1 0,190 0,199 -4,7%

2 0,190 0,199 -4,7%

3 0,194 0,203 -4,6%

4 0,175 0,180 -2,9%

5 2,092 0,174 91,7%

6 3,339 0,197 94,1%

7 1,524 0,196 87,1%

8 1,155 0,196 83,0%

9 1,155 0,199 82,8%

10 0,553 0,197 64,4%

11 1,853 0,199 89,3%

Promedio 1,1290909 0,19445455 52,3%


32

6

compiladores existen Ítems que permiten determinar el tipo de codificación de estados, además el usuario con el simple hecho de cambiar el orden en que nombra los estados durante su declaración podría lograr cambios significativos en el Hardware.

Se desarrollaron diferentes estilos de programación en VHDL, buscando la reducción del uso de Hardware en diferentes diseños, todos estos soportados por el correcto uso de las herramientas CAD que ofrecen gran variedad de posibilidades de entradas de Diseño, como lo son el CORE Generator, el Mega-Wizard, State CAD, y la misma entrada esquemática de diferentes fabricantes, solo por nombrar unas cuantas.

REFERENCIAS [1] R. Senhadji-Navarro, I. García-Vargas, G. Jimenez-

Moreno and A. Civit- Ballcels „ROM-based FSM implementation using input multiplexing‟, Electronics Letters, Vol. 40, N. 20, September 2004

[2] Rawski M., Selvaraj H., and Łuba, T.: „An Application of Functional Decomposition in ROM-Based FSM Implementation in FPGA Devices‟, Proc. Euromicro Symposium on Digital System Design, 2003, Belek-Antalya (Turkey), pp. 104-110

[3] Valery Sklyarov, „Synthesis and Implementation of RAM-Based Finite State Machines in FPGAs‟, Proc. Field Programmable Logic and its applications (FPL), 2000, pp. 718-727

[4] Anurag Tiwari and Karen a. Tomko, „Saving Power by Mapping Finite-State Machines into Embedded Memory Blocks in FPGAs‟, Design, Automation and Test in Europe Conference and Exhibition Volume II (DATE'04), Feb. 2004

[5] Garcia, E.: „Xilinx: Creating Finite State Machines‟, Xcell Journal, 2000, 38

[6] Xilinx, Inc: „ISE Foundation‟ (www.xilinx.com) [7] Katz, R. H.: „Contemporary Logic Design‟ (The

Benjamin/Cummings Publishing Company, Inc., California, 1994)

[8] Altera, Corp.: „Stratix II Device Handbook‟, 2004, Ver. 1.0, Chapter 2

[9] Krueger, R.: „Xilinx Virtex Devices: Variable Input LUT Architecture‟, The Syndicated, 2004, Vol. 4, Issue I

[10] Xilinx, Inc.: „Using Dedicated Multiplexers in Spartan-3 Generation FPGAs‟, XAPP466 (v1.1) May 20, 2005

[11] Xilinx, Inc.: „XST User Guide‟, 2005 [12] McElvain, K.: „IWLS'93 Benchmark Set: Version 4.0‟,

1993 [13] Garey, M. R. and Johnson, D. S. Computers and

Intractability: A Guideto the Theory of NP-Completeness. New York: W. H. Freeman, 1983.

[14] Burns M., Perkowski M., Jówiak L. „An EfficientApproach to Decomposition of Multi-OutputBoolean Functions with Large Set of Bound Variables”, Proc. of the Euromicro Conference,Vasteras, 1998

[15] Brzozowski I., Kos A., “Minimisation of Power Consumption in Digital Integrated Circuits by Reduction of Switching Activity”, Proc. of the Euromicro Conference, pp.376-380. Vol. 1, Milan, 1999

[16] Brzozowski J. A., Luba T., “Decomposition of Boolean Functions Specified by Cubes”, Research Report CS-97-01, University of Waterloo, Waterloo; REVISED October 1998.

[17] Chang S.C., Marek-Sadowska M., Hwang T.T., „Technology Mapping for TLU FPGAs Based on Decomposition of Binary Decision Diagrams”, IEEE Trans. on CAD, Vol. 15, No. 10, pp. 1226-1236, 1996

[18] De Micheli G., “Synthesis and Optimization of Digital Circuits”, McGraw-Hill, New York, 1994

[19] Hartmanis J., Stearns R.E., “Algebraic Structure Theory of Sequential Machines”, Prentice-Hall, 1966

[20] Jozwiak L., Chojnacki A., “Functional Decomposition Based on Information Relationship Measures Extremely Effective and Efficient for Symmetric Functions”, Proc of the Euromicro Conference, pp.150-159. Vol. 1, Milan, 1999

[21] Kravets V. N., Sakallah K. A., “Constructive library-aware synthesis using symmetries”, Proc. Of Design, Automation and Test in Europe Conference, 2000

[22] Luba T., “Multi-level logic synthesis based on decomposition”, Microprocessors and Microsystems, 18, No. 8, pp. 429-437, 1994 .


33

FPGA based spectrum analyzer

Bárbaro M. López-Portilla Vigil, Wilfredo Falcón Urquiaga

Department of Electronics and Telecommunications University of Pinar del Río

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

David Bardera Barbolla

[email protected]

Susel Góngora Alonso Department of Quality Management Electronic Components Company

Pinar del Río, Cuba [email protected]

Abstract� This paper describes the design and

implementation of a spectrum analyzer on FPGA. Although all

processing is performed within the Cyclone II EP2C35 FPGA of

the Altera DE2 Development Board by modules described in

VHDL and using Megacore functions, also a conditioning stage

and digitizing the signal is developed. The spectrum obtained

after performing all processing is displayed on a computer

monitor.

It evaluates the operation of the modules implemented in the

FPGA by performing two simulations using Matlab and

ModelSim-Altera softwares, obtaining in both cases very similar

results, demonstrating the proper functioning of the system.

As a result of this research are obtained an economically

feasible instrument, flexible, easy to handle and with enough

features for displaying the frequency spectrum of real signals.

The instrument obtained can to interact with signals up to 20

kHz and has a group of options, such as windowing, zoom

spectral and scaling, which makes it ideal for using in research

and teaching activities.

Keywords� FPGA, signal, frequency, spectrum.

I. INTRODUCTION

At present, the electronic and telecommunications systems use algorithms and signal processing techniques characterized by a high level of complexity and very specific hardware requirements [1] [2]. For this reason, and given its flexibility, possibility of parallel implementation and high integration capacity has extended the use of FPGAs (Field Programmable Gate Array) for such applications. Among these applications are included those focused on the design of instruments measuring electrical signals, such as multimeters, oscilloscopes, logic analyzers, spectrum analyzers, among others.

Sometimes the temporal analysis of certain signals with the use of the oscilloscope is difficult and inefficient, however, in these cases analysis must be performed in the frequency domain, which is equivalent to using a spectrum analyzer. These are extremely useful to obtain a good characterization of masked signals with noise or distorted, dynamic signals, electromagnetic interference, among other [3] [4].

This research aims to design, implement and validate a digital spectrum analyzer based on an FPGA, so that the end result is an easy to handle, reliable, and above all low cost.

The paper was developed in sections that facilitate understanding. First is a description of the stages that make up the spectrum analyzer, with special emphasis on the functional modules developed to be embedded in the FPGA. Then analyzes the results obtained from simulation and experiment.

II. FUNCTIONAL DESCRIPTION

The system in question comprises three stages, as shown in Figure 1. Initially the signal to be processed enters the conditioning stage constructed by analog components, and is then digitized by an analog to digital converter (ADC). The digitized data entering the Cyclone II EP2C35 FPGA included in the Altera DE2 Board, from which performs all the processing necessary to obtain the spectrum and other elements of the signal. Finally, it is sent to the computer monitor since the FPGA, the required signals so they can be properly displayed the spectrum image and other data.

Fig. 1. Scheme of the spectrum analyzer.

A. Signal conditioning and digitizing stage

At the entrance to this stage is placed a diodes configuration for limiting the input signal between -5 V and +5 V, so the instrument is protected against signals of greater amplitudes, as seen in the Figure 2. Subsequently employs an operational amplifier in non-inverting configuration adder, which has the function of converting the input signal from bipolar to unipolar. The latter is due to characteristics of the analog to digital converter used later. The mentioned above configuration has the transfer function shown in the following equation:

2

51

iV

V (1)


34

Fig. 2. Voltage limiter circuit, voltage follower and non-inverting adder.

Between the two configurations described above, is placed a voltage follower with the objective of coupling impedances.

Then the signal goes through a filtering stage, which is to avoid the Aliasing phenomenon. For this purpose, specified a maximum sampling frequency of 48 kHz and a maximum frequency of the signal to be analyzed to 20 kHz, we decided to design a low-pass filter (anti-aliassing) with a cutoff frequency of 24 kHz, successfully fulfilling Nyquist criterion.

The configuration chosen is a Butterworth low-pass filter of the third order based on unity-gain Sallen-Key topology [5], as shown in the Figure 3. This filter has the characteristic of having a maximally flat response in the pass band, being often used in data conversion applications, which require precise levels of the signals across the passband.

Fig. 3. Sallen-Key low-pass filter.

It performs its simulation by using Proteus software to verify correct operation of the filter, obtaining a frequency response as shown in Figure 4.

Fig. 4. Frequency response of the low-pass filter.

Once filtered signal, it becomes digitized using MAX163 analog to digital converter, which has the following features [6]:

- Resolution: 12 bits.

- Polarity: Unipolar.

- Input voltage: 0 - 5V.

- Conversion time: 8.33 us.

- Error offset: 4 LSB.

- Output Data Format: Parallel.

- Maximum power consumption: 180 mW.

The Figure 5 shows the circuit diagram of the MAX163 converter and its corresponding configuration.

Fig. 5. Configuring the MAX163 converter.

B. Altera DE2 Development Board

For the development of this research is used DE2 Board of the Altera company [7], which has as central device a Cyclone II EP2C35 FPGA with 475 pins available (packing 672), contains 33216 LEs (Logic Elements), 480K of on-chip RAM (Random Access Memory) bits, 35 embedded 9-bit multipliers and 4 PLLs (Phase-Locked Loops).

Also inside the board will have a number of components connected to a particular pin of FPGA, such as: memory (SRAM 512 kbytre, 8 Mbyte SDRAM, FLASH 4 MB), audio encoder, VGA (Video Graphic Array), RS-232 and PS2 controllers, USB (Universal Serial Bus) and Ethernet, seven-segment displays and LCD (Liquid Crystal Display), etc.. See Figure 6.


35

"Multiplexer 1": It performs the inverse process of the Demultiplexer module.

"Window Selector": The process of the window election is analogous to frequency selection.

"Windowing": It performs the function of multiplying 1024 samples of the signal and the coefficients of the selected window by the previous module. The four windows that you can choose are: rectangular, Hamming, Hanning and Blackman. This process is necessary to avoid spectral dispersion.

Fig. 6. Connective schematic of the DE2 Development Board components.

C. Functional modules implemented in the FPGA

All processing performed within the FPGA and required to obtain the spectrum of the signal to be analyzed is performed using the hardware description language VHDL (Very High Speed Integrated Circuit Hardware Description Language) and Megacore functions. The Quartus II software is used for this.

In the Figure 7 shows the functional modules diagram implemented in the FPGA, which is detailed below.

"Converter Controller": It is responsible for sending / receiving properly control signals and data (as appropriate) to / from the analog to digital converter, Among these is the signal that tells the converter to begin the conversion process, which has a frequency of 48 kHz, this being the maximum sample rate in the system.

"Frequency Selector": It performs the count of the number of pulses (from an external key) received. The count is cyclical and upward, taking values between zero and three. The count value is then used by the demultiplexer.

"Demultiplexer": Depending on the value that is received from the previous module, causes the data to pass or not by any of the FIR (Finite Impulse Response) filters. Thus, if you have not pressed the key mentioned above, the data does not pass through any filter. If pressed once, the data passes through the FIR 1 filter, if pressed twice, the data passes through the FIR 2 filter, and so on. The fourth time you press the key, it returns to the initial state, so the system has a cyclic behavior.

"FIR 1 Filter": It is a low-pass FIR filter decimator, has 100 coefficients and uses a structure of parallel distributed arithmetic [8]. For design employs a Megacore function. The operation of the three filters (FIR 1 FIR 2 and FIR 3) is identical, only differ in details shown in Table I.

"Calculate FFT": It is responsible for calculating the Fast Fourier Transform by Radix-2 algorithm. In order to achieve good precision, is takes of 1024 points for which it is employed a Megacore function configured to operate in continuous mode [9]. In this calculation, as in the remaining modules is used fixed-point arithmetic.

"Calculate Module": This module calculates the module of the values of the Fourier coefficients obtained from the previous module, because these coefficients are complex numbers.

"Calculate Linear Values�: This module calculates in so far as the values are received from the previous module, the size (in number of pixels) each having harmonics that will be represented below. Considering the characteristic equation of a unipolar analog to digital converter, the denominator of Equation 1 and the height in the region used to represent the spectrum is 500 pixels; we obtain the equation 2, which shows a linear relationship.

DCP102

500 (2)

Where CP is the number of pixels and D is the data obtained from the "Calculate Module� module.

"Calculate Logarithmic Values�: It has the same function as the previous module, with the only difference that in this case the values obtained are in logarithmic scale, that is, in dB..

"Multiplexer 2": In dependence on the value of the scale selection input, allows data from one of two previous modules are used for the representation of the spectrum.

"RAM Memory": This module consists of a RAM (Random Access Memory) dual port with independent clocks. Because of this feature can perform reading and writing actions at the same time. The data bus is ten bits and the address is nine bits, since only 512 data are stored. This is due to the frequency spectrum of real signals is always symmetrical about the origin, so that it represents only the positive part.

TABLE I. FEATURES OF THE THREE FIR FILTERS.

Filter Cutoff Frequency

(kHz)

Decimation

Factor

FIR 1 12 2 FIR 2 4 6 FIR 3 1 24

"SVGA Controller": It is in charge of generating timing signals and video to get a graphical view of the spectrum on an external monitor computer, following the standard SVGA (Super Video Graphic Array), which corresponds to a


36

Fig. 7. Connective schematic of the DE2 Development Board components.

resolution 1024x768 pixel. As part of the graphic display generates two types of drawings: static and dynamic. The first corresponds to the axis, grid and some text, while the second corresponds to values of amplitude, frequency and other texts.

D. Display stage

This stage is constructed only by a computer monitor with VGA connector, because it is by this means that it displays the frequency spectrum of the signal.

III. RESULTS

In order to evaluate the performance of the functional modules implemented in the FPGA (except the first and last), that is, the thicker portion of the spectrum analyzer, two simulations are performed using Matlab and ModelSim-Altera softwares respectively. In both simulations are used the same 1024 input samples from a txt file, and then, once completing all processing, both generate a file of the same type with the values of the harmonics size (expressed in pixels). For example: for a single digitized signal, if not activated the frequency selection signal (the samples do not pass through the decimated filters), selecting a Blackman window and working in linear scale, is obtained the graph shown in Figure 8.

The Figure 9 shows an image of the spectrum analyzer in full operation. For generating the input signal is used a signal generator, said signal passes through the conditioning and digitization circuit. The supply voltage for this phase is taken from the voltage sources. Subsequently, the digitized samples passed to FPGA which is in the DE2 Development Board. Finally, the frequency spectrum of the signal is displayed on a computer monitor.

Fig. 8. Comparison of the results obtained from the Matlab and ModelSim-Altera softwares.

Fig. 9. Spectrum analyzer operation.


37

The resource utilization summary for the Cyclone II EP2C35 FPGA is presented in Table II.

TABLE II. SUMMARY OF RESOURCE UTILIZATION FOR THE FPGA-BASED IMPLEMENTATION.

IV. CONCLUSIONS

With the completion of this research is obtained an economically feasible instrument, easy to handle and with enough features for displaying the frequency spectrum of real signals.

It is achieved the design and implementation of a spectrum analyzer on FPGA. The system can interact with signals up to 20 kHz, spectral zoom enables and windowing choice. The output of the analyzer can be represented in linear or logarithmic scale.

It is obtained a very useful tool in research or teaching laboratories related to the world of the electronic, which inherits the good feature of the flexibility of the FPGA device, so there is the possibility of reconfiguration according to user needs.

ACKNOWLEDGMENT

The authors wish to express their gratitude to the Spanish Agency for International Cooperation for Development (AECID) and the Public University of Navarra (Spain) for giving them the opportunity to work together faculty and students from both countries.

REFERENCES [1] V. Yelpo, D. Costa, C. Sosa, �Fast Fourier Transform calculation

module for FPGA based spectrum analyzer in real time,� First Congress of Applied Microelectronics, Buenos Aires, Argentina, 2010.

[2] T. Sansaloni, A. Perez-Pascual, V. Torres, V. Almenar, J. Toledo, J. Valls, �FFT Spectrum Analyzer Project for Teaching Digital Signal Processing With FPGA Devices,� IEEE Transactions on Education, vol. 50, no. 3, pp. 229-235, Aug. 2007.

[3] A. Venkatesh, S. Chauhan, S. Hiranya, M. Mathivanan, �Design of FFT Spectrum Analyzer on PC Platform using Labview and Microcontroller based Data Acquisition System,� Journal of Instrumentation Society of India, Volume 36, Issue 1, pp. 1-7, 2006.

[4] S. Payam, C. Barnwell, R. Mulagada, T. Weldon, �A Prototype Single-Chip Spectrum Analyzer with Integrated Frequency-Synthesized Tunning,� IEEE SoutheastCon 2010 Conference, Clarlotte, North Carolina, USA, 2010.

[5] T. Dealiyannys, Y. Sun, J. Kidler, Continuous-Time Active Filter Design, CRC Press LLC, 1999.

[6] MAX163 analog to digital converter data sheet, http://www.datasheetcatalog.com/datasheets_pdf/M/A/X/1/MAX163.shtml

[7] Cyclone II FPGA Starter Development Kit User Guide, http://www.altera.com/literature/ug/ug_cii_starter_board.pdf

[8] A. Oppenheim, A. Willsky, S. Nawab, Signal and Systems, 2nd ed., Prentice-Hall, 1997.

[9] FFT MegaCore Function User Guide, http://www.altera.com/literature/ug/ug_fft.pdf

Resources Use in the FPGA

Total Logic Elements 21753 / 33216 (65 %) Total Memory Bits 79404 / 483840 (16 %) Embedded Multiplier 9-bits Elements

29/ 35 (83 %)

Total PLLs 1 / 4 (25 %)


38

Abstract— The computation of positions among a set of

objects is essential information in those applications where the objects are not restricted to a particular environment (i.e. smart spaces, ubiquitous computing, distributed sensing systems and mobile robot teams). In these cases, usually, the distances among objects are computed in a cooperative way by using acoustic signals. Thus, it is necessary to distribute the information collected by each one before computing the object positions. This paper describes the hardware implementation, using programmable logic devices, of a data communication scheme by radio frequency signals based on ZigBee protocol through low-cost and low power commercial devices. In this way, a low increment in the implemented hardware and a real-time operation of the system is obtained.

Index Terms—Relative positioning systems, Sensor networks ZigBee Protocols, FPGA.

I. INTRODUCTION

elative localization systems [1] require the design of sensory architectures which allows to compute, in the

smallest time, the spatial relationships between nodes before the conditions of environment changes. In this way, it is necessary an active and simultaneous operation among nodes to collect and distribute the obtained information. In the case of indoor spaces, acoustic transducers are widely used as sensory system [2] due to the low cost, easy implementation and availability in several mobile systems. For example, Millibots [3], is focused on the design of small robot team for navigation in different indoor spaces using ultrasonic transducers. The distributed mobile computing systems are a new field of application for relative location, which is being developed significantly in recent years [4, 5]. In [4] a localization system for general-purpose computer (GPC General Purpose Computer) such as computers, laptops or PDA's is described. In this case, the RF and acoustic transducers that they carry are used as sensory mechanism. Likewise in [6] an ultrasonic system for locating laptops connected to ultrasonic sensor node through the USB ports is described. In [5] a relative localization

system for robots and mobile computing devices is described. The objects determine the distances between them only by using acoustic encoded signals as ranging mechanism, which is called S-RTOF (Simultaneous Round-Trip-Time-of-Flight) [7]. Due to the cooperative nature of the system, it is necessary to distribute the data collected by every node for computing the positioning algorithm. In this case, RF signals are usually used to distribute the data collected [8, 9]. This article presents the hardware implementation on an FPGA of a cooperative communication system. In this case, RF modules based on Zigbee protocols [9] are used for distributing the information collected by the ranging mechanism. Thus, a low increment on the implemented hardware is obtained. The work is organized as follows: Section 2 shows the architecture of the sensory system under development. Section 3 describes the proposed RF system for data communication. Section 4 presents the hardware implementation and then, experimental results are described in Section 5. Finally, the conclusions obtained in this work are presented.

II. SYSTEM ARCHITECTURE

The basic architecture of the system is shown in Fig. 1, where every object Mbq (q ∈ {1,2,···,Q} (Q is the maximum number of objects) has a node with acoustic transducers as sensory technology and the hardware associated which performs the computation of distances by a ranging mechanism called S-RTOF. In this case only acoustics emissions are used to compute the spatial relation among nodes, reason why additional links will not be required for synchronization.

FPGA based system for RF communications in relative positioning systems

Santiago Murano1, Jonatan Santana1, Carlos De Marziani1,2, Rómulo Alcoleas1 1Dto.de Electrónica, Univ. Nacional de la Patagonia San Juan Bosco, Ciudad Universitaria, Ruta Pcial. 1, Km.4.

2Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET), Argentina.

R

Fig. 1 General scheme of the proposed relative positioning system.


39

A. Distance measurement principle

The determination of distances between objects dql (q,l ∈ {1,2,···,Q} q�l) is performed by S-RTOF ranging mechanism. In this case, two types of measurements are available: in one hand, the propagation time of emissions between a node that acts as the coordinator (Master node) and the rest ones of the system (Slave nodes); in the other hand the computation of propagation time of emissions between Slave nodes. Assuming that Master node has a position on the environment that is described through the vector pM in a TS instant of time, this node broadcasts its coded acoustic signal, called Master Request, through its speaker SpkM. At these TS instant starts the computation of the elapsed time until the responses of slave nodes are detected in the Master node. The temporal connections computed with the Slave nodes, ignoring the delays in the processing of the encoded signals can be described as:

ˆ ·M q q M

M q emi CODEt n Tc c−

− −= + +

p p p p (1)

Where �� is the propagation time, measured in the

Master node with the slave node q; c is the speed of propagation of the acoustic emissions, TCODE is the encoding time duration and nemi the number encoded emissions performed by every node. Furthermore, pM=(xM,yM,zM) represents the Master node coordinates, and the positions of the slave nodes q and l are given by pq=(xq,yq,zq), pl=(xl,yl,zl), respectively.

Also, taking advantage of the simultaneous Slave node emissions, it is possible to compute temporal links among them. For that, the interval of time from the Master Request detection until the detection of every Ack. Node is measured, obtaining a temporal relation in every slave node with the others according to their position in the environment.

ˆ ·l q M qM l

q l emi CODEt n Tc c c−

− −−= + − +

p p p pp p

(2)

Where is the time measured in the slave node q, from

the detection of the Master Request with the slave node l. Assuming that the speed of the nodes is lower than the

propagation speed of the acoustic waves, it is possible to compute the distances between the Master and every Slave node by (1) as follows:

( )CODEˆ[ ]

2M q M q

M q M q

t tp tp Td c

−−

− + += − = ⋅p p (3)

In the same way, with the data collected by all the Slave

nodes, it is possible to compute their relative distances from (2) as follows:

1ˆ ˆ· 2

2q l l q q l l q q CODE

cd t t tp tp T− − −� �= − = + − − −� �p p (4)

B. Node hardware architecture

A significant capability of relative positioning is the measurement in a short time of all the spatial links among objects. Therefore, in the proposed system, a multi-user schemes based on Direct-Sequence Code-Division Multiple-Access (DS-CDMA) is used; which allows to simultaneously discriminate the emissions from every user or sensor. In this way, every emitter encodes their emissions with binary sequences and transmitting it by a simple phase modulation. These encoded signals are detected in a given receptor by performing the correlation with the available sequences in the system. In the proposed system the encoded scheme is based on the arrangement of Complementary Sets of Sequences (CSS) [10]. This scheme have suitable correlation properties and it is possible a high reduction in hardware complexity and computational load by using optimized correlators as it is described in [11].

According to this, in [7], the proposed signal processing algorithms have been implemented in a development Digilent Nexys 2 board based on Xilinx XC3S1200E FPGA [12]. The node architecture implemented in the FPGA board consists of a transmitter block, a receiver block with the corresponding A/D converter, and the block required to compute the temporal relations among emissions which are stored in different 16 bit register in order to be distributed to the rest of nodes.

III. NETWORK TOPOLOGY AND DATA COMMUNICATION

With the S-RTOF ranging mechanism, the Master node determines, with every slave node, the propagation time (1), but has not information about the rest of Slave nodes. Moreover, the Slave nodes can determine temporal connections (2) with each other, but not with the Master node. Therefore, it is necessary certain connection or connectivity among nodes to communicate the information gathered by each of them. Radio Frequency signals are frequently used to distribute the data collected [8, 9]. In this case, taking advantage of the low cost, low power consumption and easy interface, XBeePro® RF modules based on ZigBee communication protocol (IEEE 802.15.14.) are used [13]. These modules provide reliable delivery of data between remote devices. Also, they operate within the ISM 2.4 GHz frequency band, and can be configured by AT commands at the AT commands mode. In contrast to Bluetooth, this protocol does not use FHSS (Frequency Hooping), but performs communications over a single frequency, that is one channel. Finally, in ZigBee, the maximum operating speed is 250kbps, very low compared to Bluetooth or WIFI, but it is enough for the distribution of the data collected by the S-RTOF mechanism.

A. Network Topology

ZigBee standard defines three types of nodes, Coordinator, End Device and Router [14]. The coordinator is the one which initializes the network, stores the information of the nodes in the network, manages the network once it has been initiated and implements the routing techniques used to transfer data to different network nodes. The Router node supports the data routing

q lt −


40

functionality, including acting as an intermediate device to link different components of the network and forwarding message between remote devices across multi hop paths. A router can communicate with other routers and End Devices. Finally, an End Device at the network level is sending and receiving messages. It cannot relay messages and cannot allow other nodes to connect to the network through them.

According to the features of the described acoustic sensor network, the network topology is based on a Coordinator (Master node) and Q Router modules (Slaves nodes) [14], as it is described in Fig. 2. It allows other devices to join the network by extending the reach of it using a mesh network. Mesh routing allows data packets to traverse multiple nodes (hops) in a network to route data from a source to a destination. Before transmitting a data packet from a source to destination nodes, a route must be established. Route discovery is based on the AODV (Ad-hoc On-demand Distance Vector routing) protocol [12].

A Node Identifier (NI) can be assigned to each module and it is stored as string identifier in AT Command Mode. This string is returned as part of the ND (Node Discover) command. This identifier is also used with the DN (Destination Node) command. In this case, the NI consists of a letter (R) followed by the number of device that identifies the module as a member of the network member, and also it is used to count the number of connected modules. For example, ROUTER 1 is identified as R1. For that, a custom command in XBeePro® scans the communication channels and detects the modules that are available in the environment; also provides detailed information about each one of them. This information is stored in a memory block implemented in each node in order to send the information available to the rest of modules.

In order to distribute the data collected, every RF module is configured in broadcast mode, which allows that the rest of nodes receive the data transmitted. After that, every node will be able to start the transmission of their data or to collect the data gathered by the rest of nodes.

The operation consists in all modules must share the data from the other modules. This is possible due to the advantages of the mesh network which provide RF modules, XBee Pro® Series 2

B. Data Communication

A data communication package have been designed for transmission of temporal relations in a cooperatively way. The packets have 32 bits; the 16 MSB are used as a header and the 16 LSB contents the data collected in every temporal relation.

As shown Fig. 3, the less significant nibble indicates the measurement between the emissions of a pair of nodes. The next two nibbles are used to indicate the nodes involved in the measurement, the following nibble indicates the destination where the data goes, and finally 4 bits are reserved for future usage; i.e, in Fig. 3, module 2 send to module 1 the data between node 2 relative to node 3.

�

IV. HARDWARE ARCHITECTURE OF EACH MODULE

According to the proposed network and data package, the hardware architecture of Router Module (Slave node) is shown in Fig 4 and Coordinator (Master node) is described in Fig 5.

In both cases there are a transmission and reception data blocks, which consist of an UART and Xbee RF module, also a block that processes the frames to be sent or received, that previously pass through a flow control used to determines the sequence to follow based on the incoming data. Additionally, a BRAM memory, which stores the data of temporal relations, along with reading and writing module is implemented in the Slave and Master module.

The Master Module also has a Network Scan stage, which determines the modules around it, and the Node Identifier of those slave nodes which are in the range; then start a transmission sequence according to the order in which were detected. The slave modules, also have this stage, but only to know how many and which modules are active, to access only the memory locations corresponding to the active modules.

Fig. 2 General scheme of the proposed communication protocol in relative

positioning system

Fig. 3. Data package proposed to distribute information in the network.


41

Fig. 4 Detailed block diagram of the FPGA hardware architecture of the Slave node

Fig. 5 Detailed block diagram of the FPGA hardware architecture of the Master node

V. HARDWARE IMPLEMENTATION

The required algorithms for data frames processing have been implemented into the Digilent Nexys 2 development board used for signal processing in the SRTOF ranging stage [12]. In this way, a low increment in the hardware associated to the node is obtained. The RF module connected to the FPGA have been the XBeePro® provided by Digi®[13]. That has a low cost, low power, easy interface and suitable coverage range.

A. Network scanning, detection of nearby modules

This block allows the detection of active modules located in the range of coverage. In order to detect the modules that are available, this block scans the network using the AT ND command of the XBee, then reads the Node Identifier of each module and counts the number of letters Ri being i the number assigned to every node, as explained in the network topology. In this way it is possible to determine which modules are active in the system.

The data obtained about the recognized active modules is

saved in a register, in the same order that the modules appear, and afterwards the reading memory block use this information for transmitting the distance data to the active modules.

B. Process control

This block, enables other blocks of the system in the router system. The slave read the start frame sent by the Master node at the beginning of communication, the next frame contains the temporal relation between the Master node and one of the Slave nodes. The current Slave node detects the incoming frame, and determines if the temporal data is related to himself, depending on the Dist nibble of the frame (See Fig. 3). If the nibble corresponds to the current router Node Identifier number, then start to send the stored data on its own memory to the other active modules, included to the Master node; otherwise stored in the BRAM the received frames from the Master and the other modules until the system receives the END frame from the Slaves, waiting for a new frame, and its turn to transmit its stored data.

When all the modules have transmitted their information,

the Master node sends an END OF TRANSMISSION frame to all the nodes in the network, to finish the communication until a new round of Temporal Relation data begins.


42

C. Storage device

In the storage device, three blocks are implemented. The writing block receives the frames and store in a certain memory location depending on who sent it and the temporal relation. The reading block assembles the header of the frame to be transmitted. According to this, depending on the memory location where the data is load, determines the content of the header, which were described in the system communication protocol. The memory used was the BRAM of the FPGA as a Dual memory. In this case, a port for writing and other one for reading have been used.

Once all the data is sent on available modules, this block transmits the frame that indicates the END OF TRANSMISSION, who will notify the Master of changing the sequence of transmission to another module.

VI. EXPERIMENTAL TESTS

Experimental tests have been accomplished in order to verify the performance of the cooperative communication with the proposed protocol. The system was tested with the modules at different distances. To confirm the correct transmission of the data frames, a Xbee® module was connected to the network as a spy monitor to observe communications. The performed tests shown that the transmissions and receptions are correctly established as seen in X-CTU interface (See Fig. 6).

The results were also displayed in a user interface

implemented in Matlab ® connecting the boards by the USB port of the Master module (See Fig. 7). The data collected from every node in a 16 bits package is converted to distances by (3) and (4) in Matlab program. However this block could be implemented in every FPGA by using the available multipliers resources.

Finally, Table 1 shows a summary of the resources used in the FPGA of both modules. In this case, the implementation of the communication control block requires a lot of resources, so they must be reduced by taking advantage of the FPGA by using parallel processing.

Table 1 Comparative of Hardware Implementation resources on the FPGA between Coordinator (Master)

and Router (Slave).

Resources Coordinator

(% used) Router

(% used) Slices

Registers 1242 (13%) 1174 (12%)

LUTs 1630 (17%) 1748 (18%) Occupied Slices

1078 (23%) 1064 (22%)

CONCLUSIONS

In this paper a hardware implementation of a RF data communication protocol based on low complexity RF modules based on ZigBee protocol as the transmission medium has been presented. The processing algorithms have been implemented in reconfigurable logic devices, which allow to obtain a real-time operation of the system. The data transmission between master and slave, and vice versa, was performed with a good reliability.

REFERENCES

[1] N. Patwari, A. Hero, M. Perkins, N. Correal, and R. O’dea,

"Relative location estimation in wireless sensor networks," IEEE Transactions on Signal Processing, vol. 51, pp. 2137-2148, August 2005.

[2] J. Higtower and G. Borriello, "Location systems for ubiquitous computing," IEEE Computer, vol. 34, pp. 57-66, August 2001.

[3] L. Navarro-Serment, R. Grabowski, C. Paredis, and P. Kohsla. (2002, December) Millibots. IEEE Robotics & Automation Magazine. 31-40.

[4] V. Raykar, I. Kozintsev, and R. Lienhart, "Position calibration of microphones and loudspeakers in distributed computing platforms," IEEE Transactions on Speech and Audio Processing, vol. 13, pp. 70-83, January 2005.

[5] C. De Marziani, J. Ureña, A. Hernández, M. Mazo, J. J. García, A. Jiménez, M. C. Perez, F. Alvarez, and J. M. Villadangos, "Acoustic Sensor Network for Relative Positioning of Nodes," Sensor Basel vol. 9, pp. 8490-8507, 2009.

[6] M. Hazas, C. Kray, H. Gellersen, H. Agbota, G. Kortuem, and A. Krohn, "A relative positioning system for co-located mobile devices," presented at the Third International Conference on Mobile Systems, Applications, and Services (MobiSys'05), Seattle, 2005.

[7] C. De Marziani, J. Urena Urena, A. Hernandez Alonso, J. Garcia, F. Alvarez, A. Jimenez, C. Perez Rubio, J. Villadangos, J. Aparicio, and R. Alcoleas, "Simultaneous Round-Trip Time-of-Flight Measurements with Encoded Acoustic Signals," Sensors Journal, IEEE, vol. PP, pp. 1-1, 2012.

[8] K. Lutvica, N. Kadic, G. Dzampo, H. Muminovic, J. Velagic, and N. Osmic, "Remote position control of mobile robot based on visual feedback and ZigBee communication," in ELMAR, 2011 Proceedings, 2011, pp. 169-172.

Fig. 6 Frames visualization on XCTU

Fig. 7 Matlab graphic interface


43

[9] M. Tingting, C. Wu, S. Bo, G. Chengxi, and Z. Yunzhou, "Design of Point to Multi-Point Wireless Communication System Based on ZigBee," in Wireless Communications, Networking and Mobile Computing (WiCOM), 2011 7th International Conference on, 2011, pp. 1-4.

[10] C.-C. Tseng and C. L. Liu, "Complementary Set of Sequences," IEEE Transactions on Information Theory, vol. IT-18, pp. 644-652, September 1972.

[11] C. De Marziani, J. Ureña, Á. Hernández, J. J. García, F. J. Álvarez, A. Jiménez, and M. C. Pérez, "Recursive Algorithm to Directly Obtain the Sum of Correlations in a CSS Signal Processing”," Elsevier Signal Processing, Fast Communications, vol. 91, pp. 1343-1346, Mayo 2011.

[12] I. Digilent. (2012, 20 March). Digilent Inc. Digital Design Engenieer´s Sources. Available: http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS2

[13] Digi. (2010, Mayo). XBee-PRO 802.15.4 (Formerly Series 1) OEM RF Modules. Available: http://www.digi.com/products/wireless/point-multipoint/xbee-pro-series1-module.jsp

[14] (2013, December 1th, 2011). ZigBee Alliance. Available: http://www.zigbee.org


44

Wavelet Decomposition over FPGA

Andres Leonardo Di Donato†Email: [email protected]

Santiago Francisco Maudet†Email: [email protected]

Alejandro Julio Furfaro†Email: [email protected]

†Digital Processing Laboratory, Electronic Engineering Department, Facultad Regional Buenos Aires,Universidad Tecnologica Nacional, Buenos Aires, Argentina

Abstract—The application of Wavelet Decomposition in DigitalProcessing Signals field is increasing in the last years. In thiswork, an implementation of the Wavelet Decomposition overXilinx Spartan6 FPGA, as a method for intensive Image Pro-cessing is presented. The main objective of our work is to takeadvantage of the hardware resources availables in a FPGA toimprove the performance in the parallel precessing of severalclusters of pixels, reaching a clear improve in time of satelliteimage processing with the aim of detecting flooded areas. Theresults were contrasted with a matlab algorithm taken as a goodstandard. The problematic of timefrequency analysis is described,in addition with strategies to cope with this issue. On the otherhand, the advantages and limitations of Wavelet Decompositionare explained. An implementation based on the recursive use ofdigital filter banks and decimation is presented along with theresources employed and the results obtained using the Meyer’swavelet as mother wavelet are shown. Finally, we present ourconclusions.

Keywords—Wavelet Decomposition, Timefrequency Analysis,FPGA, Xilinx, Spartan 6, Image processing

I. INTRODUCTION

Fourier Transform is a mathematical tool that allows de-scribe the spectral content of a certain signal. However, if thetime location of the spectral components has importance, thismethod is inappropriate [1].

The formal definition of the latter transform is given by (1)[2].

F(ω) =

∫ ∞

−∞f(t) e

iωt dt (1)

As the integration interval goes from −∞ to +∞, the resultobtained by the transform considers the complete evolutionof the signal in time, without any temporal reference. Then,Fourier Analysis is inappropriate when the analyzed signal isnot stationary as regards its spectrum.

A. Multirate Wavelet Analysis

To avoid the trade off between temporal and spectral res-olution multirate analysis is an alternative [3], that consists ofanalyze the signal with different temporal/spectral resolutions.

The key concept of the Wavelet Decomposition is theseparation of the original signal in different bands of highfrequency (details) and low frequency (coefficients). Afterthis decomposition process, the analyzed signal is representedby a set of new signals of different frequency bands (also

called scales) which modify their amplitude through time. Thetemporal/spectral resolution change can be explained as theFig. 1 [1].

Fig. 1: Representation of the dyadic scale

The horizontal and vertical distances between points rep-resent both spectral and temporal resolution of each bandrespectively. As we can see, for high frequencies, the spectralresolution is poor but the temporal resolution is fine, whereasfor low frequencies, the spectral resolution is fine and thetemporal resolution is poor.

B. Formal Definition of the Continuous Wavelet Transform

The Continuous Wavelet Transform (CWT) is mathemati-cally defined as shown by (2) [3]

C(τ,s) =

∫ ∞

−∞f(t)Ψ

∗τ,s(t)

dt (2)

In (2), the function Ψ∗ corresponds to the window appliedto the sampled signal. This window is defined according to (3)[3], by applying a scale factor (s) and a temporal shift (τ ) overthe Ψ function, called Mother Wavelet.

Ψ∗τ,s(t)

=1√|s|

Ψ( t−τs ) (3)

In conclusion, we use a scalable window, generated fromthe Mother Wavelet function. The operation is very similar to acorrelation between the original signal and the window, whichmeans that the results obtained will depend on the chosenMother Wavelet.


45

II. DISCRETE WAVELET TRANSFORM

The Discrete Wavelet Transform (DWT) can be consideredas the discrete version of the CWT. In this implementation,digital filters have been used, and a dyadic scales is donethrough decimation. The DWT expression is shown in (4)[1].

C[j, k] =∑

nǫZ

f [n]Ψj,k[n] (4)

The analyzed signal is a discrete sequence and the windowapplied to it, is defined by 5.

Ψj,k[n] = 2−j2 ·Ψ[2−jn− k] (5)

The time shift of the window is done sample by sample,and the chosen scale will be dyadic, so in every level, thewidth of the window is multiplied by two.

A. Digital filters

In order to obtain every band content, we use two digitalhalf band filters [4]: a lowpass h[n] and a highpass g[n],followed in both cases by a two decimation for dyadic scaleimplementation.Ci and Di are coefficients and details respec-tively Both filters are defined by the Wavelet mother andfollows the relationship established by (6) [1].

g[L− 1− n] = (−1)n · h[n] (6)

B. Scales decomposition

Once the filters have been obtained, the first decompositionlevel is obtained by applying both filters with decimation tothe original signal, as shown by (7) and (8) [1].

yHP [k] =∑

n

x[n] · g[2k − n] (7)

yLP [k] =∑

n

x[n] · h[2k − n] (8)

To obtain further decomposition levels, the lowpass output(coefficient) must be considered as the new signal, applyingthe same filters. This decomposition process can be thoughtin a tree structure as shown in Fig. 2. This operation can berepeated a limited number of times, because decimation halvesthe number of samples.

In this way, the original signal is decompose in variousscales expressed in the details, which show the existence ofspectral components, with their corresponding time location.

Fig. 2: Discrete Wavelet Decomposition in tree shape

III. IMPLEMENTATION OVER FPGA

A. Materials

The implementation was made on a Xilinx Spartan6 FPGAdevelopment kit, by Digilent ATLYS [5], with Xilinx Spartan-6 XC6SLX45 FPGA. The Spartan-6 LX45 FPGA has 6,822slices each containing four 6-input LUTs and eight flip-flop,2.1Mbits of fast block RAM, 4 clock tiles (8 DCMs & 4PLLs), 6 phased locked loops, 58 DSP slices, and 500MHz+clock speeds. The Atlys Spartan-6 FPGA Development Boardhave a Xilinx Spartan-6 LX45 FPGA in 324-pin BGA package,128Mbyte DDR2 16-bit wide data 10/100/1000 Ethernet PHY,On board USB2 ports for programming & data transfer,USB-UART and USB-HID port (for mouse/keyboard) TwoHDMI video input ports & two HDMI output ports, AC-97Codec with line in, line out, mic, & headphone, Real timepower monitors on all power rails, 16Mbyte x4 SPI Flash forconfiguration & data storage, 100MHz CMOS oscillator, 48I/O’s routed to expansion connectors. and GPIO includes 8LEDs, 6 buttons, & 8 slide switches. The Xilinx Design Suit13.4 was used as Integrated Development Environment.

B. Methods

The coefficients for the lowpass and highpass digital filtersare obtained from the Mother Wavelet by means of MATLABVersion 2008a Toolbox Wavelet. The function used was:

[ low , h igh ]= w f i l t e r s ( d m e y , d ) ;

Where the d parameter is a coefficient vector that will beobtained at the return of the Wavelet Decomposition function,and dmey implies that we are wanting to use Meyer’s Dis-crete Wavelet as Wavelet mother.This coefficients was usedin both MATLAB algorithm and FPGA implementation. Oncecoefficients was obtained, the quantification for arithmetic wasevaluated.

For that, using MATLAB we arrived to the frequencyresponse associated to the coefficients, that conduces to thefilter quantification depicted in Fig. 5.

C. Block diagram of implementation

Fig. 3 describe the implementation of the entire system.

D. Quantification of the filters’s coefficients

To obtain the multirate analysis, the filter bank with deci-mation was implemented as shown in Fig. 4.


46

Fig. 3: Block diagram of implementation

Fig. 4: Filter bank with decimation

As an example, in Fig. 5 we show the frequency responseof the lowpass and highpass filter corresponding to the Meyer’smother wavelet. In continuous trace, the 1.15 quantized filterresponse is depicted, while the dashed trace shows the fre-quency response in double precision. As we can see, there areno significant differences in the passband, while the attenuationin the stopband is higher for the 1:15 quantized, but stillacceptable since it is bigger than 80 dB. The whole systemwill work with 16-bit data, 1.15 fixed point.

Fig. 5: 1.15 Quantification of the filters h[n] and g[n]

E. Filters’s implementation

Both lowpass and highpass filters are Finite Impulse Re-sponse filters. To implement the FIR filters, the Direct Form Itopology was chosen. In Fig. 6, the latter topology is depicted[6].

An important characteristic of the implemented filters is itssymmetry. Both filters have type I symmetry (odd length, odd

Fig. 6: Graphic representation of the FIR Direct Form I

symmetry) and consequently, it introduces a constant groupdelay [7].

F. Optimized topology of Direct Form I

The symmetry in DF1 allows to optimize the implemen-tation of the FIR filter, with a consequent saving of FPGAresources [6]. By using an add tree, the number of multiplierscan be reduced to half, as shown in Fig. 7.. Fig. 7.

Fig. 7: Optimizaded FIR DF1

Since the filter has type I symmetry, the central value isunique and so it must be processed independently, and anyadder is needed. The number of multipliers saving previouslymentioned, will allow to add more filters in the same FPGA,and thus rising the capabilities for parallel processing.

G. Multipliers implementation

The multipliers were implemented with Xilinx’s IP cores,using constant coefficients multipliers. The selected platformprovides two different alternatives to build multipliers: hard-ware multipliers or memory based multipliers. The number ofhardware multipliers is limited by the number of DSP Slices.In this case, we only have 58 DSP Slices. For this reason,we’ve decided to use memory based multipliers.

All the multipliers are essentially equal, except for theirconstant multiplication factor.

The multiplier’s synthesis procedure can be summarized inthree steps: First, using MATLAB, the coefficients are savedwith 16 bits precision in a CSV file. Second, by means ofa simple bash script which reads the CSV file, a batch file isgenerated for every single multiplier. This script uses a generictemplate and modifies the values needed for every particularmultiplier. Third, the Xilinx IP Core Generator Tool is executedonce for every batch file, synthesizing all the multipliers.


47

Once the multipliers have been obtained, they are simplyinstanced in the top-level description.

Even though the coefficients can not be modified in run-time, the multipliers value can be changed only by re-writingthe CSV file and executing the bash script again.

H. Decimation

Decimation is done by enabling or disabling the outputgenerated by the products accumulation. A different approachmay be to implement a polyphase filter to avoid discarding thegenerated result. This alternative was rejected since it wouldnot allow to obtain best profit of the filter’s simmetry alreadymentioned.

I. Fixed point arithmetic

In order to grant saturation and avoid overflow, we haveused the Fixed Point HDL standard library (FPHDL) [8] whichdefines the data types signed fixed point (sfixed) and unsignedfixed point (ufixed). Using these data types, is much simpler towork with saturated arithmetic’s, avoiding the natural overflowproblem of the Standard Logic data type.

J. Communication Interface

As communication interface, we have used USB 2.0. Thecommunication uses the USB programming interface of thedevelopment kit. The host must perform a reenumeration ofthe mentioned key in order to allow USB bulk transfers, inorder to exchange binary data [9]. USB 2.0 requires a speedof 48 MHz.

On the host side, there is a dynamic-link library to managethe data exchange.

On the FPGA side, a simple interface module must beinstantiated in the top level. This interface works as a FIFOread/write memory.

The data written from host to device and the resultsprovided by the FPGA are stored in separate FIFO interfaces.

K. Byte-Word Interface

Since the USB communication is solved on byte-levelbasis, and this implementation uses two bytes as one singledata value, a block is necessary to compose the values out ofthe recieved bytes.

After the processing is done, the opposite process shouldbe implemented: the obtained data must be split into bytes inorder to send them through the USB bus. Every detail obtainedhas a different FIFO output memory to simplify the read/writeprocess, avoiding data overlap.

L. Endianness

Internally, the system works in big-endian. Since the hostused is little endian, the implementation must receive and senddata in little endian to maintain compatibility with the host.The problem is solved by swapping bytes when they are readfrom the input FIFO and before they are written into the outputFIFO memory.

M. Input transient

In the present implementation, input transient is ignored,since assuming zero-padding as initial condition for the delayline may not be acceptable in some applications. The input datamust be previously expanded (i.e. symmetrically) according tothe needs of the specific application.

N. System clocking

According to the synthesis results, the maximum frequencyachievable for the system is 62 MHz. The board clock isfixed in 50 MHz, high enough to grant the correct USB com-munication. Considering that the processing of a single byterequires one cycle and every input/output value has 2 bytes,the maximum processing speed result in 25 MegaSamples persecond.

O. FPGA Occupation factor

In this implementation, the critical factor is the number oflookup tables, since their use is related with the number ofmultipliers needed. In our work the number of lookup tablesused for one bank was 6,628 of 27,288, that is 24% of theresources of Spartan6 FPGA.

IV. MEASUREMENTS

In order to validate the results obtained by the FPGA,the digital filter bank simulation and the arithmetic neededwas made on MATLAB. Thus, the decomposition process wasdone for different signals in both environments. The resultsobtained are not bit compatible, because that the simulationenvironment does not include the Direct Form I optimizationexplained before, which produces changes in the final results.

A. Decomposition of a test signal

In order to show the results obtained by the MultirateWavelet Decomposition analysis with Meyer’s mother wavelet,we will show the decomposition of a signal with non stationaryspectral components, as shown in Fig. 8.

Fig. 8: Test signal to be decomposed

As can be seen the signal is formed by two sinusoidaltones clearly located in two different time intervals, spitted bytwo sequences in which the signal’s amplitude remains at zerovalue. The decomposition will be done in three levels.


48

1) Coefficients: Despite the coefficient analysis is not verysignificant in interpreting the spectral content of the analyzedsignal, anyway the results are shown to reveal the wholedecomposition process.

Fig. 9: Coefficientes of the signal of Fig. 8

2) Details: Fig. 10 shows a comparison between the MAT-LAB simulation and Spartan6 FPGA hardware implementa-tion experimental data. In the first scale, corresponding tothe higher frequencies, three areas with non zero value areobserved. These corresponds to points where the signal ofFig. 8 changes abruptly in time, in other words, where thesignal shifts from a zero sequence to a sinusoidal oscillationand vice versa. The highest peak is obtained at the momentwhen the highest frequency oscillation begins. In the next levelof decomposition, can be observed that non zero values appearin the time interval where the original signal oscillates with thehigher frequency. In the third scale of details, the influence ofthe low frequency oscillation is shown. This way, the originalsignal is characterized by the three details and the last of thecoefficients shown in Fig.9. Even if the results obtained arenot perfectly equal, the morphology of the signal is clearlymaintained.

Fig. 10: Details of the signal shown in Fig. 8

B. Decomposition of a sample image

After processing the test signal, we have used a sample ofpixels of one satellite image and it was processed using thearchitecture proposed. The results were successful.

C. Resulting speed

As a result of experimental data we obtained a 20MSa/sover Spartan6 FPGA. In practice, the major limitation is thepenalty paid by using the USB as a bulk device. Basically weneed to wait one USB frame for each transmission. So thelatency between every read and write communication is about1ms.

V. CONCLUSIONS

From the results showed, some of the capabilities of theWavelet Multirate analysis could be verified. More specifically,the method is capable of estimate the time location of thespectral components of a non stationary signal. The perfor-mance obtained by the HDL synthesis would allow a frequencysampling of 20 MegaSamples per second.

The Filter bank implementation allows the implementationof the Wavelet Decomposition by the recursive use of thesame bank, achieving a flexible implementation that can obtaindifferent decomposition levels using the same hardware.

Besides, the results obtained processing pixels from satel-lite images where successful.

As future work, we plan to complete the implementationto process a complete sequence of images and obtain thenecessary information to analyze the existence of floodedareas, with minimum time of processing in order to let thesystem emit early alerts for the evacuation facilities. Alsowe expect to implement the wavelet algorithm on GPGPU tocompare the performance with FPGA synthesis.

ACKNOWLEDGEMENTS

The authors would like to thank to Mariano Llamedo Soria,Julin Santiago Bruno and Alfredo Nicols Campos for theirinvaluable help.

REFERENCES

[1] Martnez Malo, J., de Castro Fernndez, R.M., Anlisis de la teora de ond-culas orientada a las aplicaciones en ingeniera elctrica: Fundamentos,E.T.S.I. Industriales Dpt. de Ingeniera Elctrica, Madrid, 2002

[2] Oppenheim, A.N., Willsky, A.S., Signals and Systems, 2nd ed PrenticeHall, Boston, USA

[3] Akansu, A.N., Haddad R.A., Multiresolution Signal Decomposition,2nd ed Academic Press, San Diego, CA, USA

[4] Lyons, R.G., Understanding Digital Signal Processing, Prentice Hall,Boston, Maryland, USA, 2011.

[5] Brochure de Digilent Atlys[6] U. Meyer-Baese, Digital Signal Processing with Field Programmable

Gate Arrays, 3rd ed. Springer, New York, USA, 2007.[7] Ifeachor, E.C., Jervis, B.W., Digital Signal Processing: A Practical

Approach, Prentice Hall, Edinburgh Gate, Harlow, England,2002.[8] Bishop, D.W., FPHDL Support Library, http://www.vhdl.org/fphdl/[9] McClellan, C., FPGA Link User Manual,

http://www.makestuff.eu/wordpress/software/fpgalink/, 2012[10] Campos, A.N. , Di Bella C.M., Multi Temporal Analysis of Remotely

Sensed Information Using Wavelets, Journal of Geographic InformationSystem, 2012,4,383-391


49

��AB�C��DEFBFBADF��ABCDE�F��B�D

BCD�� !��"��#��$��%�&��'��$�(

%�)��*��!��"��B��%�D

+��$��" ��,��-�F�� .�.��#�%�)��%� ��

/��.�� (�%� ��

�� 0��)��

B�D�� !��"��

+��$��" ��,��-�F�� .�.��

.��1��.��(�%� ��

2��02�33��

�� 3�4� �� 3�� )�� *#� �F/�%(�� 3��

��5�� )�� 6�)��"� � ��5�� 7�� 8�� $� � ��

�� )��3��*��!��$��4��)��$��

�� 9�� *��2�9��( ��)��1 � ��)3�:��$��

��8��)�� 9��( � ��)� � �� *��

��5��A�� 8��*��*��2��*�8��)��

�� 2��( � �� ;� � * � ��"� � ��

��7��(�8�� )��*#��F/�%��3��)��)�

�� *�8��8��

��2��)��(��3��8�� 1��*��4��

�� $� � �� 3�� )�� :��( � � � 2�� 3��

��3��8��2��)��

�� ;� � * � �� 2�5 � �� )�� 2��

��)� ��F/�%��%��<��6�!��4��4��

��)��2��"�� =>�A(��3��8��3�4"��=>�A��&��(��

��)��$��12��2�3��)3�� (��"��

��$��" ��8��5��(��3�� 2��)��2��"�� =>�A

8��2��2� ��"��

'��"��8��31��)��8��2� ��9��

3�4�( � �� ;�� 2�� )�� ?@ �A>5 �,� ��3��( � ��

��$�� "�� )��"�8�� )&��$�� )�� 3�4��

2��8��)��8��3��)��(��8��

��;��2��(��3��*��2��3��

!��B)��)��"��)��&��)��)��"�(��)3�:��2��

��3�� B�C��1��"�D�,��"��

��)��4��$�(��8��)3�:��3��

��)��

A��)��4��$��)��1��B��!D��)�*�B��

�� 3��)�� )�� ;�( � �� 5�� )��)��"� �!��

�)��(��8��/�.(��)� ��(��

��)��*��

%��)��)�( � �� ;� �� ( � 8�� )��

��)��D@�E�(��)��"��8��3��

��2��)�;��(�� )��


50

Implementación de algoritmo genético para la búsqueda automática decaos en sistemas multiatractoresMaximiliano Antonelli; Luciana De Micco

Laboratorio de Mecánica Estadística, UNMdPCONICET

Ya sea para la generación de ruido, encriptación de datos o generación de claves, los sistemas caóticosmultiatractor son muy atractivos por generar secuencias distintas para distintos valores de sus pará-metros, manteniendo el sistema de ecuaciones. Gracias a esto, en una implementación en hardwarepueden obtenerse diferentes salidas con distinto comportamiento caótico sin modificar el circuito quelas genera.

Dado un sistema complejo con parámetros libres, no existe un método analítico sencillo para encon-trar el o los parámetros que provocan comportamiento caótico, en general se busca exhaustivamentebarriendo todas las combinaciones de parámetros posibles y calculando para cada una de ellas algúncuantificador de caoticidad.

El indicador de caoticidad más conocido y directo es el Máximo Exponente de Lyapnov (MLE), esteexponente cuantifica la separación entre dos trayectorias que parten de puntos vecinos en el espaciode fase. Un MLE<0 indica la convergencia a puntos fijos, un MLE=0 indica la existencia de ciclosperiódicos y un MLE>0 indica la existencia de comportamiento caótico.

Para nuestro caso, tenemos más de un parámetro libre, por lo que la búsqueda exhaustiva se haceprohibitiva por el tiempo de cómputo. Se hace necesario, entonces, un algoritmo de búsqueda dirigida,en donde no se calculen todos los puntos del espacio de parámatros, sinó solo los que maximizan lacaoticidad del sistema.

Se generó una lógica basada en algoritmos genéticos, encargada de evolucionar los parámetros delsistema de modo que cada generación tenga un comportamiento caótico mejor que la anterior. El tar-get, por lo tanto, es el MLE. El sistema se inicializa en un conjunto de coeficientes llamado poblacióninicial o semilla, a partir de allí, se comienzan a variar los coeficientes de a pasos consiguiendo nue-vas generaciones. Cada generación es comparada con la anterior para descartar la “peor adaptada” ymutar los coeficientes (cromosomas) a partir de la “mejor adaptada”.

Este algoritmo se puede aplicar sobre cualquier plataforma a cualquier sistema complejo al que se ten-ga acceso a los parámetros, para este trabajo, la plataforma es un kit de desarrollo DK-DEV-3C120Nde Altera que monta un chip Cyclone III EP3C120F780C7 y el sistema son los mapas cuadráticos bi-dimensionales de 12 parámetros. Estos mapas fueron ampliamente estudiados desde el punto de vistamatemático, sin embargo, la aritmética discreta en una implementación genera un sistema distinto deloriginal que queremos emular y la gran sensibilidad de estos sistemas a las condiciones iniciales pue-de provocar que se pierda el comportamiento caótico o éste sea muy distinto al previsto con aritméticareal. Por esto, es necesario el estudio del comportamiento del sistema no ideal corriendo en hardware.

Como resultado de la compilación, se utilizaron un 9 % de los elementos lógicos, 5093 registros,menos del 1 % de bits de memoria, y ningún multiplicador ni ningún pll. Esta implementación correuna aritmética de 32 bits en punto flotante en norma IEEE 754, aunque la modularización del diseñopermite una fácil migración a cualquier otra aritmética.

Este tipo de algoritmos converge siempre al máximo local para funciones continuas, sin embargo, parasistemas complejos el espacio de estados suele ser fractal, es decir que se encuentran puntos adyacen-tes en donde el MLE es positivo, negativo, cero, o no existente. Por lo tanto, para un trabajo futuro, lasemilla deberá ser elegida aleatoriamente para el descubrimiento de nuevos "buenos atractores".


51

�Sistema de visión artificial para la detección de proximidad de dos objetos mediante el conteo de pixeles implementado en un FPGA�.

Á. Anzueto, A. Avila y J. Quiroz

Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas Instituto Politécnico Nacional

Distrito Federal, México { aanzuetor, aavilar0803, jquirozm0800} @ipn.mx

En este trabajo se expone la implementación, en un dispositivo FPGA, de un sistema de visión artificial para la identificación de la proximidad de objetos. El sistema tiene la capacidad de identificar entre dos objetos de igual tamaño pero diferente color cuál se encuentra más próximo, teniendo como premisa que el objeto más cercano contendrá una mayor cantidad de píxeles en la imagen.

El sistema está compuesto por un sensor de video analógico, una tarjeta digitalizadora VDEC-1, y una tarjeta Nexys 2 la cual cuenta con un FPGA Spartan 3E (XC3S1200E), así mismo se cuenta con monitor con entrada VGA donde se muestra el resultado del procesamiento.

La tarjeta VDEC-1 envía la información de la imagen al FPGA en un formato digital. A continuación se realiza la segmentación de los colores, en el espacio YCbCr, obteniendo así una imagen binaria para cada color, posteriormente se cuenta el número de píxeles con valor de �1� que contienen cada una de las imágenes, a partir de esto es posible determinar el color del objeto más próximo. Por último se muestran en el monitor los objetos segmentados, encuadrando el más próximo.

El sistema anteriormente descrito es utilizado para el control del movimiento de un robot hexápodo autónomo, el cual utiliza un modo de marcha dependiendo del color del objeto más próximo a él. El sistema reconoce círculos de color verde y rojo de un diámetro de 14 cm, los cuales están localizados a una distancia de 50 cm a 1.5 m.

Ejemplo de los objetos identificados y encuadrados, de acuerdo a las características mencionadas con anterioridad, desplegados en un monitor.

Información VDEC-1:

http://www.digilentinc.com/Products/Detail.cfm?Prod=VDEC1 Información Nexys 2: http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS2


52

Una Herramienta para Generación Automática de

Descripciones Sintetizables de Circuitos Combinacionales Salvadeo P. A.

1; Leguizamón G.

2; Veca A.

3, Castro-López R.

4

1Laboratorio de Computación Reconfigurable, FRM, UTN, Mendoza, Arg.

2Laboratorio de Inteligencia Computacional, FCFMN, UNSL, San Luis, Arg.

3Instituto de Automática, FI, UNSJ, San Juan, Arg.

4Instituto de Microelectrónica de Sevilla, CNM, CSIC, Sevilla, Esp.

El trabajo consiste en el desarrollo de una aplicación para generar hardware evolutivo

extrínseco. El programa se basa en un algoritmo genético con tasa de mutación variable,

capaz de crear descripciones en VHDL (Very High Speed Integrated Circuit Hardware Des-

cription Language) de circuitos combinacionales que pueden sintetizarse en un FPGA (Field

Programmable Gate Array). La evaluación de los candidatos se realiza simulando el circuito

descripto empleando GHDL (G. Hardware Description Language). Ello optimiza el consu-

mo de recursos durante el proceso evolutivo, ya que el ciclo compilación–simulación utili-

zado es más eficiente que el ciclo síntesis–simulación. Tal elección permite realizar el dise-

ño automático empleando computadoras de pequeña capacidad de cómputo en tiempos

aceptables.

El proceso de traducción diseñado permite pasar sencillamente de un genoma binario a una

descripción en VHDL del tipo Flujo de Datos. Además, salva la restricción de múltiples

manejadores que VHDL impone sobre las señales. Ello porque, durante la codificación se

considera al circuito como una red, donde cada nodo define su función y conexión, y duran-

te la decodificación se asocia cada nodo con una única señal.

La codificación del genotipo permite la aparición de loops combinacionales en el fenotipo.

Si durante la simulación el comportamiento observado es secuencial, el candidato tendrá la

peor calificación y no prosperará. Sin embargo, si el comportamiento es combinacional el

circuito podría tener loops. Al correr el proceso evolutivo con distintas funciones deseadas,

se observa la aparición frecuente de loops en los circuitos. En ocasiones estos no son intui-

tivamente combinacionales para el observador, pero aún así lo son y pueden sintetizarse.


53


54

��ABC��

DAEF��E��

�� AB�C

D�C

EAF��FC��AD�FC


55


56

Banco de medición de variables eléctricas con LPC1769

Desarrollo aplicado a motores trifásicos tipo Jaula de Ardilla

Gutierrez Guillermo; Ponce Joaquín; Storello Federico; Yoaquino Lucas Universidad Tecnológica Nacional

Facultad Regional Córdoba Centro Universitario de Desarrollo en Automación y Robótica

Córdoba, Argentina [email protected]; [email protected]; [email protected]; [email protected]

Resumen—Se presenta el desarrollo y construcción de un banco para mediciones de variables eléctricas de motores trifásicos, basado en el microcontrolador LPC1769 con núcleo ARM -Cortex M3 fabricado por NXP, aplicado a un motor tipo jaula de ardilla.

Palabras claves—Cortex-M3; LPC1769; ARM; ADC; Filtro de Butterworth; Tensión; Corriente; cos phi; SPI; Memoria SD;FAT 32

I. INTRODUCCIÓN

El banco desarrollado forma parte de un sistema para pruebas de motores trifásicos. La función principal del sistema es adquirir, almacenar y transmitir las magnitudes de tensión, corriente y coseno phi. Esta última magnitud es calculada en el microcontrolador.

Para la medición de la corriente se utilizan los sensores de efecto hall TAMURA S22P015S05, y para la medición de las tensiones los amplificadores operacionales aislados AMC1100 de Texas Instruments. Las salida de estos sensores, son acondicionadas con un filtro pasa bajos de frecuencia de corte de 2000 Hz. Para la selección de la frecuencia de corte del filtro se tuvo en cuenta la frecuencia de conmutación de los transistores bipolares de compuerta aislada (IGBT), la cual se

estima en unos 1000 Hz. Luego del filtrado, las señales pasan por un circuito acondicionador y finalmente llegan al microcontrolador LPC1769.

Se utiliza el conversor analógico digital interno del procesador para analizar las señales analógicas de los sensores. La tasa de muestreo se fija en un milisegundo asegurando unas veinte muestras para la frecuencia más alta, es decir, diez veces la frecuencia de Nyquist. Se procesan los datos y se obtienen los valores RMS de tensión, corriente, potencia y coseno phi que se muestran en un display lcd. El usuario cuenta con un teclado que le permite navegar por el menú del sistema.

El sistema cuenta con una memoria SD como elemento de almacenamiento secundario. Esta memoria permite transportar el resultado de un ensayo a una PC compatible, en donde es analizado con el programa de cálculo numérico Qt-Octave. Para facilitar la lectura de la memoria se utiliza un sistema de archivos FAT 32 que fue implementado con las librerías GNU FatFs [1].

Fig. 2 Banco de medición de variables eléctricas

Fig. 1 Esquema general del sistema


57

II. IMPLEMENTACIÓN

A. Medición de tensión.

La medición de tensión se realiza con un amplificador

operacional de precisión con salida aislada (AMC 1100 de Texas Instruments [2]). Este dispositivo posee el circuito de salida aislado con respecto a la entrada por medio de una barrera de dióxido de silicio. Esto le otorga al CI aislación galvánica para tensiones de pico de hasta 4250 V.

Para mejorar la exactitud de la medición, los AMC1100 fueron sometidos a ensayos y se obtuvo la función de transferencia del sensor que se observa en la Fig. 3. La misma fue utilizada para obtener una función de compensación.

En la hoja de datos del amplificador el fabricante especifica una tensión diferencial máxima de ±250 兼撃 para la zona lineal de trabajo. Para cumplir con este requerimiento se ha diseñado un divisor resistivo entre la fase y el neutro de la línea (se tomó un margen de seguridad acotando la señal a ±200 兼撃).

220 ヂ2迎1 + 迎2

迎2 = ±200 兼撃 (1)

迎1 = 560倦迎2 = 390 (2)

荊 =220 ヂ2迎1 + 迎2

=220 ヂ2

560倦 + 390= 0.55 兼畦

(3)

B. Medición de corriente

Para la medición de corriente se utilizó un sensor de efecto hall (S22P015S05 de la empresa TAMURA [3]). Este sensor posee una gran exactitud y linealidad para las magnitudes de corriente esperadas. El dispositivo permite tres configuraciones diferentes dependiendo de la corriente que se espera que circule por él (varían las conexiones de los terminales de acuerdo a si la corriente a sensar es 荊血, 荊血/2 剣荊血/3).

Como en el caso de la medición de tensión, y para mejorar la exactitud en la lectura, se realizaron ensayos para obtener la función de transferencia del sensor y de allí determinar la compensación necesaria. Los resultados del mismo se observan en la Fig.4

Fig. 3 Función de transferencia del sensor S22P015S05

Luego de la etapa de medición de corriente y tensión se aplica un filtro pasabajos de butterworth de segundo orden para filtrar el ruido de alta frecuencia. Además, como la frecuencia de muestreo del conversor A/D es mayor que la frecuencia de corte del filtro se garantiza el cumplimiento del teorema del muestreo.

A continuación se detallan las consideraciones de diseño de la configuración sallen key aplicada.

A partir del esquema circuital de la Fig.5 y de la función de transferencia del circuito (4), se reemplaza cada admitancia por su valor correspondiente en el mismo.

継剣憲建継件券 =1

1 +桁1桁4

+桁1桁3桁4桁2

+桁1桁2

(4)

継剣憲建継件券 =1

1 + 降潔系2岫迎1+迎2岻嫌 + 降潔2系2系1迎1迎2嫌2 (5)

Se utilizaron tablas para determinar los coeficientes en (5)

que corresponden a la configuración sallen key: 犯欠1 = 1.4142 = 降潔系2岫迎1+迎2岻決1 = 1 = 降潔2系2系1迎1迎2

(6)

Despejando de este sistema de ecuaciones los valores de resistencias se obtiene (7). 迎1,2 =

欠1系1 ± 紐(欠1系1)2 伐 4決1系1系2

4講血潔系1系2

(7)

Fig. 5 Configuración Sallen Key.

Y1

V31Vac

0Vdc

0

Y2

0

Y4U1A

TL084

3

2

411

1

+

-

V+

V-

OUT

Y3

Fig. 4 Función de transferencia del amplificador operacional aislado AMC1100


58

Para garantizar que los valores de resistencias sean reales se utiliza la consideración de diseño mostrada en (8).

(欠1系1)2 伐 4決1系1系2 半 0 (8)

Lo que implica que: 系1 半系2 4決1 欠1

2 (9)

Eligiendo 系1 = 1 µ繋検系1 = 220 券繋 se cumple la condición antes mencionada (9).

A partir de estos datos, de la ecuación (7) y de la consideración de que la frecuencia de corte se sitúa en 2KHz, se calculan los valores de 迎1,2: 迎1 = 447硬蛤 470硬 (10) 迎2 = 64硬蛤 68硬 (11)

C. Acondicionador de señal.

Para el diseño de los acondicionadores de señales se debieron realizar ensayos sobre el motor con el objetivo de adaptar la excursión de las señales intervinientes al rango de entrada del conversor analógico digital del microcontrolador (0 a 3.3 V). Se ensayaron los sensores con el motor elegido para el banco de pruebas y se relevó la excursión de entrada al circuito acondicionador. Se aclara que si el banco se utiliza con un motor diferente se pueden realizar los ajustes necesarios a través de resistores regulables.

Circuito acondicionador de señal para el sensor AMC1100.

En la Fig. 6 se muestra el grafico de la relación de voltajes de entrada salida del circuito acondicionador de señal.

Según la ecuación de una recta se calcula la pendiente y la ordenada al origen. 検(捲) = 兼捲 + 決 (12)

兼 =3.3 伐 0

2.2 伐 0.4= 1.8333

(13)

Evaluando (12) para 検岫捲岻 = 0. 検 = 0 = 1.8333 0.4 + 決 (14) 決 = 伐0.7333 (15)

Fig. 6 Función de transferencia del circuito acondiciondor de señal.

Se concluye por lo tanto que: 検 = 1.8333 撃件券伐 0.7333 (16)

Esta función de transferencia se logra a través de dos amplificadores operacionales en configuración inversor y sumador inversor. En la Fig. 7 se muestra el circuito y su función de transferencia en (17). 撃剣憲建 = 伐磐伐撃嫌結券嫌剣堅迎4迎3

+ 撃2

迎4迎5

卑 (17)

Se igualan (16) y (17) y se obtiene lo siguiente: 迎4迎3

= 1.8333 (18)

伐撃2迎4迎5

= 伐0.7333 (19)

Se define 撃2 = 5撃 y 迎4 = 390 y se calculan los resistores faltantes de la siguiente manera:

迎3 =390

1.8333= 212.73 硬蛤 220 硬

(20)

迎5 = 5390

0.7333= 2659.21 硬

(21)

Circuito acondicionador de señal para el sensor TAMURA S22P015S05.

Para el sensor de corriente se aplica un circuito similar al del sensor de tensión, por lo tanto solo se describe aquí la selección de las resistencias. A partir de la Fig. 8 se desarrolla (22). 兼 =

3.3 伐 0

3.1 伐 2.05= 3.1428 =

迎4迎3

(22)

Evaluando la expresión de una recta para 検 (捲) =0: 検 = 0 = 3.1428 2.05 + 決 (23) 決 = 伐6.44 = 伐撃2迎4迎5

(24)

Se definió que 撃2 = 5撃 y 迎4 = 5600 y se calculan los demás resistores componentes del acondicionador: 迎3 =

5600

3.1428= 1783 蛤 1700 硬 (25)

Fig. 7 Circuito acondicionador de señal.

U1A

TL084

3

2

411

1

+

-

V+

V-

OUT

0V

R3

0V

Vsensor

R4

0

V20

0

0

U2A

TL084

3

2

411

1

+

-

V+

V-

OUT

R1

0V

R5

2659

R1


59

Fig. 8 Función de tansferencia del circuito acondicionador.

迎5 = 55600

3.1428= 4347 硬 (26)

En la Fig.7 y Fig.8 se muestran el circuito y el gráfico correspondiente al acondicionador.

D. Microcontroldor LPC1769.

El microcontrolador LPC1769 concentra todas las funciones de procesamiento, interfaces y control del sistema.

Se utilizó el conversor analógico digital interno para digitalizar las señales del sistema en general, el mismo es de 12 bits con 8 canales multiplexados de los cuales se utilizan 6 (dos por cada fase, uno para la medición de tensión y otro para la de corriente).

La conversión comienza cada un milisegundo (se define el periodo de muestreo) a través de la rutina de interrupción SysTicks. Allí se activa el bit burst del registro de control del módulo (ADC0R) habilitando la conversión por hardware. En este modo, la conversión de los 6 canales se ejecuta progresivamente un canal tras otro en un tiempo total de 62.4 microsegundos, siendo despreciable el mismo en comparación con el periodo de muestreo. Esto permite suponer que las seis muestras han sido tomadas en el mismo instante, condición necesaria para el cálculo del factor de potencia.

Al finalizar la conversión se activa una interrupción propia del ADC, en la cual se almacenan los resultados extraídos del registro ADDR en seis vectores.

Una vez almacenados 200 datos (10 periodos), se procesan los vectores con las conversiones para obtener la frecuencia, el coseno phi y los valores RMS de las corrientes y tensiones de cada fase. A continuación se desarrolla sintéticamente el método que se utilizó para la obtención de cada uno de los parámetros:

Cálculo de la frecuencia de la señal La misma se obtiene contabilizando la cantidad de muestras entre los cruces por cero de la señal y multiplicando por el período de muestreo.

Cálculo de los máximos de las señales eléctricas y valores RMS Se realiza un promedio de los valores absolutos de los picos máximos por periodo. Luego para obtener los valores eficaces se afectan estos resultados por raíz de dos

Cálculo del coseno phi. Se considera que las señales a medir son senoidales y se aplica el siguiente método: 撃(建) = 撃兼欠捲潔剣嫌降建 (27)

荊(建) = 荊兼欠捲潔剣嫌(降建 + 砿) (28)

Debido al multiplexado casi instantáneo que nos ofrece el microcontrolador se puede considerar que se conoce un valor de tensión y corriente en un tiempo determinado.

建1 =

潔剣嫌伐1 磐撃(建1)撃兼欠捲卑降 (29)

Se reemplaza luego (29) en (28) y se obtiene: 砿 = 潔剣嫌伐1 磐荊(建1)荊兼欠捲卑伐降建1 (30)

Fig. 9 Esquema del muestreo digital de señales

Fig. 10 Procesamiento y cálculo de las señales


60

Finalmente con este resultado se obtiene el factor de potencia de (31). Se aclara que el factor de potencia es igual al desfasaje entre las señales cuando las mismas son senoidales puras. En este desarrollo se realizó esta consideración. 血欠潔建剣堅穴結喧剣建結券潔件欠 = cos砿

(31)

En lo que respecta al control del menú se realizó con una máquina de estado. La evolución de la misma depende de la presión de las teclas. Además, el teclado cuenta con un anti rebote implementado por software.

Tres de los cinco estados del menú son destinados a mostrar los valores de corrientes y tensión RMS de cada fase, la potencia total, el factor de potencia y la frecuencia. Los otros dos estados están destinados a la carga de datos en la tarjeta de memoria SD y al borrado de la misma.

E. Interfaz SPI

El SPI, o Serial Peripheral Interface (Interfaz de Periféricos en Serie) es un bus de comunicaciones entre dos dispositivos, uniéndolos de forma síncrona y mediante un enlace serie que funciona en modo full dúplex.

Desarrollado por Motorola, SPI distribuye los dispositivos entre maestros y esclavos, siendo el primero el que inicia la comunicación con los esclavos. Se conoce también como bus serie de cuatro cables.

La conexión entre dispositivos se realiza como lo indica la Fig.11.

De donde se desprende la descripción de los pines: SLCK: Señal de reloj, comandada por el maestro. MOSI: Master Output, Slave Input. Transmisión

de maestro a esclavo. MISO: Master Input, Slave Output. Transmisión

de esclavo a maestro. SS: Slave Select. El maestro activa el dispositivo

esclavo correspondiente mediante esta salida activa por nivel bajo.

F. Memorias Secure Digital(SD)

Es un formato de tarjeta de memoria ampliamente utilizado en dispositivos portátiles como cámaras fotográficas, celulares, etc.

Internamente tiene celdas de memoria flash y un controlador que acepta comandos para leer y escribir en la memoria.

Las especificaciones simplificadas son gratuitas pero las especificaciones completas no. Se debe ser miembro de la SD association para tener acceso a ellas.

La tensión de operación es 2.7-3.6V

Fig. 11 Conexión entre dispositivos mediante la interfaz SPI

G. Tarjeta SD en modo SPI

Es un modo alternativo con menos funcionalidad que el modo nativo pero más simple para implementar. El set de comandos es reducido pero permite realizar las funciones básicas de leer y escribir, suficientes para almacenar datos o incluso trabajar con un sistema de archivos FAT/FAT32.

En modo SPI, la SD funciona como slave en modo 0. La frecuencia máxima de clock es de 25MHz, aunque durante la inicialización debe estar entre 100KHz y 400KHz.

Las memorias MMC también son soportadas. 1) Trama de comandos Todas las tramas que se envían y reciben de la memoria

SD están compuestas por una determinada cantidad de bytes. La comunicación se hace a través de comandos. La trama a enviar está formada por 6 bytes como se puede observar en la Fig. 12.

La memoria debe inicializarse antes de ser escrita o leída. 2) Envío de comandos y respuestas Una transacción completa está formada por una trama de

comando enviada por el maestro, una trama de respuesta enviada por la memoria y de acuerdo al comando puede haber tramas de datos en ambas direcciones como se observa en la Fig.13.

3) Comando de lectura Para leer datos de la memoria debe enviarse el comando de

lectura (CMD18) y se espera la respuesta tal como lo muestra la Fig.14.

4) Escritura Para escribir datos en la memoria se debe enviar el

comando de escritura (CMD25) y se debe indicar el fin de escritura de datos tal como lo indica la Fig.15.

1) Tramas de respuesta Cuando se envía un comando de lectura o escritura, la

memoria SD responde con una determinada trama. La más general es la trama R1 y se observa en la Fig.16

Fig. 12 Trama de comandos a enviar.

Fig. 13 Envios y respuestas de comandos.

Fig. 13 Respuesta al comando de lectura.


61

Fig. 14

Fig. 15 Trama de respuesta R1.

H. FAT 32(Tabla de Asignación de Archivos)

Se utilizó un sistema de archivos FAT de 32 bits para almacenar los datos en la memoria SD, esto permite que la misma sea leída por cualquier sistema operativo presente en la PC.

FAT es relativamente sencillo. A causa de ello, es un formato popular para disquetes admitido prácticamente por todos los sistemas operativos existentes para computadora personal. Se utiliza como mecanismo de intercambio de datos entre sistemas operativos distintos que coexisten en la misma computadora, lo que se conoce como entorno multiarranque. También se utiliza en tarjetas de memoria y dispositivos similares.

En la actualidad coexisten tres sistemas de archivos tipo FAT: FAT12, FAT16 y FAT32. Las diferencias básicas entre esos subtipos, y la razón de sus nombres, es el tamaño, en bits, de las entradas en la estructura FAT en el disco.

Es decir, hay 12 bits en una FAT12, 16 bits en una FAT16 y 32 bits en una FAT32.

Las implementaciones más extendidas de FAT tienen algunas desventajas. Cuando se borran y se escriben nuevos archivos tiende a dejar fragmentos dispersos de éstos por todo el soporte. Con el tiempo, esto hace que el proceso de lectura o escritura sea cada vez más lento. FAT tampoco fue diseñado para ser redundante ante fallos. Inicialmente solo soportaba nombres cortos de archivo.

Se implementaron las librerías provistas en el módulo FatFs mediante las cuales se realiza lo siguiente:

f_mount: crea el área de trabajo f_mkdir: crea el sistema de carpetas f_chdir: se utiliza para cambiar de carpeta f_open: se crean los archivos de destino de los datos f_lseek: se lleva el puntero al archivo al final del archivo f_printf: escribe en el archivo con formato string f_close: cierra el archivo con los datos.

I. Script de qt-octave.

Se utilizó un script para el programa qt-octave para mostrar y analizar los datos obtenidos durante los ensayos en una PC.

Fig. 16 Ensayo a modo de ejemplo en Qt-Octave.

El programa recibe desde la tarjeta de memoria SD un archivo “.txt” que posee un vector con todas las muestras tomadas a lo largo de la medición. El script separa las muestras de cada canal, grafica las curvas correspondientes a las tensiones y corrientes de cada fase y la potencia instantánea. Se muestra en la Fig.17 un ensayo a modo de ejemplo.

III. CONCLUSIONES

Más allá de la aplicación inmediata del desarrollo como sistema de medición de banco de pruebas de motores trifásicos, el mismo forma parte de la placa de adquisición de un control de velocidad para motores de alterna con el método DTC (Direct Torque Control). Este método es usado en variadores de velocidad para controlar el torque de motores trifásicos. El mismo consiste en calcular una aproximación del flujo magnético y la cupla del motor basándose precisamente en las mediciones de voltaje y corrientes que plantea el sistema descripto.

Para detallar más lo indicado en el párrafo anterior se explicita que la aproximación del flujo se realiza a través de una integración del voltaje en el estator. Por otro lado, la estimación del torque se realiza a través del producto vectorial del flujo magnético calculado anteriormente y la corriente.

Las futuras mejoras aplicables a este proyecto se centran en lograr la transmisión y el análisis en tiempo real del sistema utilizando una interface Ethernet. Además se planea controlar el sistema embebido a través de un sistema operativo en tiempo real con el objetivo de optimizar la temporización y el sincronismo de los procesos.

REFERENCIAS [1] Librerias GNU FatFs de:

http://elm-chan.org/fsw/ff/00index_e.html

[2] Datasheet AMC1100 de la página de texas instruments: http://www.ti.com/lit/ds/symlink/amc1100.pdf

[3] Datasheet S22P015S05 http://www.tamuracorp.com/clientuploads/pdfs/engineeringdocs/S22PXXXS05.pdf

[4] User Manual microcontrolador LPC1769 de NXP

http://www.nxp.com/documents/user_manual/UM10360.pdf


62

Design of a low cost multifunction visual navigation display for Argentinean military aircraft .

Mauricio D. Principi- Ariel C. Principi- Ariel Cararo Centro de I+D de Tecnologías Aeronáuticas.

Dirección General de Investigación y Desarrollo- FAA. Río Cuarto- Argentina. [email protected]

Gustavo M. Rodriguez- Roberto H. Manno Facultad de Ingeniería.

Universidad Nacional de Río Cuarto. Río Cuarto- Argentina

Abstract— Development of an avionics system prototype for viewing multiple applications of navigation data, using a low cost commercial off the shelf touch screen display, a PC-104+, a GPS and a special case designed for that purpose, in order to provide information to military or civilian aircraft, the prototype will be installed in the cockpit of the new version of FAA Pucará aircraft.

Keywords—avionics; display; navigation; low cost; embedded .

I. INTRODUCTION

Avionics began due to military necessity, reflected later in civil aviation. In the seventies, military aircraft became air sensor platforms, concentrating a large amount of electronic equipment.

A multi function display (MFD) [1], is a liquid crystal monitor that displays visual navigation information. It is connected to a computer with a power supply and peripherals that capture dynamics flight information. All this is integrated and encapsulated in a specially designed case, which should be located in an accessible place in the cockpit of an aircraft and can be used to display information in different ways to the pilot.

The aim of this paper is to report the design, manufacture and implementation of national avionics equipment with multiple visual navigation applications. The prototype is composed of commercial of the shelf industrial components, mostly marketed in the country, which will allow gaining experience for future assistance tools navigation designs for military and civilian aircraft.

Nowadays in the Argentine Air Force there exists the need to display real time navigation information on a touch screen monitor, using navigation software. The MFD is designed to select navigation data source from an internal GPS, or from an external serial communication module which controls a military standard 1553 communication bus of an “Embedded GPS in Inertial and Radio Altimeter System EGIR”.

Regarding the development standards for the system design, we use ECSS “European Cooperation for Space Standardization” from ESA “European Space Agency” and DO-160 “Environmental Conditions and Test Procedures for Airborne Equipment” from RTCA “Radio Technical

Commission for Aeronautics” for environmental avionics hardware test.

II. METHODOLOGY

The prototype design includes the following steps:

A. Specification of baseline requirements and task distribution.

B. Standards applied.

C. Embedded system architecture design.

D. External interfaces.

E. Hardware components selection criteria.

F. Implementation of Calnav software in the multi function display hardware.

G. Case design and manufacture.

H. Embedded system hardware and software integration and verification testing .

I. Environmental prototype testing using RTCA/DO-160 standard.

J. Requirements validation of the prototype.

III. DEVELOPMENT

A. Specification of baseline requirements and task distribution.

1) General requirements. Using standards:

a) For systems development.

b) For avionics environmental testing.

2) System requirements. a) Design and manufacture a man machine interface

system to display real time navigation information in an aircraft.


63

b) Navigation data autonomy by using its own GPS.

c) Execution of RTCA DO-160 environmental tests.

d) Implement the prototype in the aircraft cockpit.

e) Integration with UIE “EGIR Initializer Unit” module, for prototype nonautonomous navigation.

f) Earth and flight validation testing in the aircraft.

3) Interface requirements. a) Interface to control on/off by a cockpit switch.

b) Interface for own protothype GPS antenna.

c) USB 2.0 serial external interface, for data loading.

d) Interface with inertial system for protothype nonautonomous mode operation by using UIE module.

4) Software requirements.

a) Run different software that supports GPS navigation, in special Calnav software for this prototype.

b) Preflight ground mission planning.

c) Prototype mission charging by pen drive.

d) Visual real time navigation assistance during the flight, with or without a loaded mission.

e) Software switching key between standalone GPS authonomous mode navigation to nonauthonomous mode by using EGIR inertial system as a data source for navigation.

f) Flight data recording.

g) Ground mission processing flight logged data.

5) Task distribution. Tasks were divided as follows to implement the Pucará aircraft navigation system: CITEA “Research and Development Center of Aerospace Technology”, see Fig. 1, is responsible for developing the multi function display prototype. FAdeA, the Argentina Aircraft Factory, is responsible for the design and testing of the UIE hardware module that performs the inertial system initialization, and then transfers the EGIR navigation data to the multi function display prototype by a preexistent protocol, then Calnav software which is running on MFD, shows navigation data, see Fig. 2. That RS-232 communication protocol between software Calnav and UIE module is jointly specified by Navy personnel, owner of the navigation soft and FAdeA personnel, owner of the hardware module, see Fig. 3.

EGIR

INITIALIZER

UNIT

28VDC airplane electric source

GPS

ANTENNA

EGIR

PEN DRIVE

On/Off

switch

MIL

-ST

D 1

55

3

CITeA task

MFD

PUCARAPRESENTER

RS-232

28-V

DC

RF

US

B

DISCRETE I/O

||

Fig. 1. Multi function display prototype in Pucará aircraft.

EGIR

INITIALIZER

UNIT


GPS

ANTENNA

EGIR

PEN DRIVE

On/Off switch

MIL

-ST

D 1

55

3

FAdeA task

MFD

PUCARAPRESENTER

RS-232

28-V

DC

RF

US

B

DISCRETE I/O

Fig. 2. Design and test of the UIE hardware (MFD<->UIE<->EGIR)

EGIR

INITIALIZER

UNIT


GPS

ANTENNA

EGIR

PEN DRIVE

On/Off switch

MIL

-ST

D 1

553

FAdeA and

Navy task

MFD

PUCARAPRESENTER

RS-232

28-V

DC

RF

US

B

DISCRETE I/O

Fig. 3. RS-232 Calnav UIE communication protocol.

B. Standards applied.

The MFD is an aerospace equipment, so we apply ESA ECSS standards as a guide during the hardware development process of the prototype, after tailoring the standard according to this kind of project, focusing particularly in the E-10 Series, where the “E” letter refers to "Engineering", in which we can mention the next ones:

ECSS-E-ST-10C. [2] "System engineering general requirements", which specifies the requirements implementation for space equipment development.

ECSS-E-ST-10-02C. [3] “Verification", which establishes requirements for space systems verification.


64

ECSS-E-10-03A. [4] “Testing" standard which facilitates the requirements development of performance and environmental systems spatial components.

Regard the execution of environmental tests, we apply the avionics hardware environmental standard DO-160 "Environmental Conditions and Test Procedures for Airborne Equipment", for aeronautical equipment test procedures [5].

C. Embedded system architecture design.

The system has a PC-104 plus [6] computer with an Intel 1.1GHz Pentium M processor , 1 Gbyte of RAM memory and a Windows XP operating system embedded in a 64Gbytes solid state disk, in which also runs a navigation software called Calnav. The computer has enough serial ports, two RS-232 and six USB 2.0 ports, see Fig. 4.

DISPLAY

LCD TOUCH

SCREEN

MFD BLOCK DIAGRAM

PC-104

COMPUTER

PC-104

ENERGY SOURCE

GPS

RS-232

VGA

12 y 5 VDC

US

B

I/O

I/O

J1, J2, J3 SOLID STATE

DISK

IDE

I/O

Fig. 4. Block diagram.

The information is displayed by a touch screen 6.5-inch liquid crystal display, which at the same time works as a communication interface with the pilot, since he interacts with the computer using the touch screen. The touch feedback is performed via a RS-232 port.

The system has an internal GPS [8] for an independently and autonomous operation, this is implemented on a board to deliver the information to the PC via an USB bus, its communication protocol uses NMEA 0183 standard.

The power supply is type PC-104 too, input can vary over a range from 10 to 40 Vdc, 28 Vdc in our case because of the aircraft feed voltage bar, the outputs are 5 and 12 Vdc.

D. External interfaces.

The system has J1, J2 and J3 connectors for the MFD communication with its environment see Fig. 5.

EGIR

INITIALIZER

UNIT


GPS

ANTENNA

EGIR

PEN DRIVE

On/Off

switch

MIL

-ST

D 1

553

MFD INTERFACE

CONNECTORS Jn:

MFD

PUCARAPRESENTER

RS-232

28-V

DC

RF

US

B

DISCRETE I/O

||

J3

J1

J2

J1J1

Fig. 5. MFD connectors.

The J1 aviation connector provides the supply voltage of the system, the thermal switch discrete key on / off signal from the right side panel of the aircraft cockpit, which turns on or off the MFD and the serial communication with the module UIE [7] that initializes the Pucará aircraft inertial system called EGIR through a communication RS-232 serial port, see Fig. 6.

Fig. 6. aviation connector used.

The GPS signal enters by the J2 connector type TNC female RF-for chassis.

The J3 connector is a USB port designed to upload and download the mission information related to the flight using the navigation ground mission planning software.

E. Hardware components selection criteria.

The selection is based on commercials off the shelf items mostly marketed in the country; this mainly facilitates the maintenance due to the interchangeability of components.

We must emphasize the support provided by the Argentinean navy personnel regarding the selection criteria, because they have extensive experience in similar systems operating in their airplanes and helicopters, as in the case of the Super Etendard aircraft display among others.

The equipment must be robust because of the environmental stresses, it was designed to work in hostile environments, such as the unpressurized Pucará aircraft cockpit, operating at a 9000 meters altitude. The elements support mechanical vibration and temperature ranges above and below celsius zero degrees, as well as high levels of humidity and impact resistance more than 6g, this for example, ensures its operation after a crash landing. Regarding the power consumption, this has been minimized keeping the functionality stipulated by the line base requirements, as well as the weight which does not exceed three kilograms.

F. Implementation of Calnav software in the multi function display hardware, functionality.

The device has been designed to support different kind of software navigation tasks, this quality is very important in the development, because ensuring its operation at aeronautical environment then you just have to develop software applications that support flight navigation utilities like Calnav software, whose creator is Mr. Arturo Tomás Medici. Calnav functions are next detailed:

1) Mission Planning. Calnav allows loading by a pen drive in the MFD a planned

mission on a PC with another instance of the same software


65

called ground mission planning system, generating a file with waypoints and flight plan information by the available J3 USB port connector on the MFD, enabling to executing the mission in flight assisted by GPS or EGIR in the particular case of the Pucara aircraft. It also displays information of flight parameters in real time without having a mission charged, so we can see the aircraft position with flight important parameters in real time projected onto the mapping without a necessary mission.

2) Full screen display mode. Calnav software has multiple applications as we explain in

1), so we use full screen presentation as the default mode for a better mission viewing in the MFD display during the flight.

3) GPS – EGIR navigation. The GPS position (latitude, longitude and altitude) [8] of

the mobile is represented itself at all times in the open mission in the working session of the MFD, as well as kinematic data (bearing, distance, time, etc.) to any of the legs or points of the active navigation table VOR, NDB and others. On the other hand, selecting the inertial Honeywel Pucará navigation system as data source, Calnav will also represent the same information by using a predetermined communication protocol between the Navy Calnav software designer and the UIE manufacturer.

4) Own position indicator. The mobile is represented in the mission geographical

framework as a single plane graph with swept wings. The color depends on the navigation source GPS/EGIR state: [Red, yellow or green]. Red: without communication with the data source. Yellow: waiting for data reception. Green: safe to navigate, as seen in the center of Fig. 7.

Fig. 7. Own position indicator and Command system.

For example, the nose of the plane matches the true course.

5) Command system. During the flight, in the full screen display mode, the command system consists of two lateral vertical bars with large buttons corresponding to the program command menu and to critical functions, see Fig.8. Each button is labeled with a symbol and a small caption below.

The bars are displayed when you tap the touch screen on the strip, near the left and right edges. Close when the selected

command is activated by touching the button, or when you touch outside the boundaries of the buttons. Some of the most used commands are listed below.

See scale: [increase decrease] and brightness [darken, lighten, neutral], north focused or free frame, course centering, latitude and longitude reticulated, distance scale, and geographical grid.

Cartography: Raster aeronautical, ICAO satellite images.

Tools: Alarms and warnings, virtual mouse and keyboard.

G. Case design and manufacture

The case design was performed in the engineering department of Río Cuarto material area using Catia software. All system components were relieved, and then dimensionally modeled by software, also 3D represented, and finally the MFD case model was made, as shown in Fig. 8.

Fig. 8. MFD 3D software Catia model.

Regarding the redesign, in the new Pucará aircraft cockpit model dimensional specifications, we work together with FAdeA, defining the MFD location and its mechanical support, achieving an appropriate distribution of the instruments and the MFD, which is located in the center due to its importance in real time navigation decisions, as shown in Fig.9.

Fig. 9. Location of the MFD and mechanical support.


66

Once they designed the MFD case technical drawings, it was discharged with an Argentine air force part number and finally, it was made in the Rio Cuarto, using a machining center controlled by a computer running a manufacturing software file generated by Catia software, making it available for industry mass production.

The design is comprised of two lateral racks, three covers and a front frame, all duralumin machined elements, as shown in Fig. 10.

Fig. 10. mechanical design.

H. Embedded system hardware and software integration and verification testing .

The components integration process was carried out in an iterative and incremental methodology [9], with partial functional checks, up to the total system verification as suggested in ECSS-E-10-03A [4], achieving full compliance with the preset requirements for GPS autonomous operation. Currently, we are working with the UIE unit integration, for inertial system navigation data acquisition.

Fig. 11 shows the distribution of the components from a top view, the GPS is on the left, while the disc, the power source and the computer are on the right.

Fig. 11. MFD hardware integration.

Regarding the software, the correct operation of Calnav with the operating system and associated serial ports software interfaces were correctly verified, including, GPS data and the external USB storage device.

In the Fig. 12, we can appreciate different views of the finished prototype. Below, on the right, we can see the

distribution of the connectors J1, J2 and J3 mentioned in C, see also the pen drive connected to J3.

Fig. 12. MFD finished prototype .

Fig.13. shows Calnav software execution, after activating the power ignition key, then the MFD displays on the center the own position airplane indicator, which is positioned at the coordinates where it is receiving the GPS signal.

Fig. 13. MFD prototype in operation.

I. Environmental prototype testing using RTCA/DO-160 standard.

The MFD met successfully the next requirements verification items:

1) Thermal tests: a) Resistance and operation at low temperature,

according to RTCA/DO-160D 4.5.1: (minus) -20ºC with inoperative equipment and -15° C with operating prototype.

b) Resistance and operation at high temperature, according to RTCA/DO-160D 4.5.2: +75ºC with inoperative equipment and +55 ° C with operating equipment.

c) High temperature operation, RTCA/DO-160D 4.5.3: operative equipement at +55 º C.

d) Temperature variation, RTCA/DC-160D 5.3: Cyclic temperature variation between +55 ° C and -15 ° C with the prototype in operation.


67

2) Altitude test according to RTCA/DO-160D 2.6 4.6.1: Was successful up to 6000 meters of height in a vacuum

chamber, pending the implementation of MFD in the Pucará cockpit to complete the test at 10000 meters of height which is the operational ceiling of that aircraft system.

3) Vibration test with RTCA/DO-160D 8.5.1: Consists of a three axes (x,y,z) frequency sweep (one hour

per axis), 1g of 10-500 Hz

4) Crash tests, according to RTCA/DO-160D 7.1.1: The MFD met the "B" category, which consists of applying

a sawtooth pulse in both directions of the orthogonal axes, 6g amplitude of 11 ms duration.

5) Relative humidity: This trial is still pending due to lack of proper equipment

for testing.

J. Requirements validation of the prototype.

As regards CITEA, baseline requirements have been almost entirely achieved. A man machine interface prototype to display aircraft navigation information that can operate autonomously with GPS, with an available data USB 2.0 serial port, was designed and fabricated.

Environmental tests were carried out according to RTCA DO-160. Regarding the GPS switch to UIE unit for inertial EGIR data source for Pucará, we have taken all the software necessary precautions, in order to design available interfaces and systems to integrate that capacity.

Actually, we are working on the integration of the software interface for the UIE unit and Calnav software, between FAdeA and Navy personnel, by implementing a serial RS-232 communication protocol. Also ground and flight testing campaign of MFD instrumented on Pucará aircraft cockpit integrated with the new avionics system is in planning stage.

Regarding software requirements, the system can run with different kinds of software that supports GPS navigation, currently for this prototype it is working with Calnav, which facilitates preflight ground mission planning, subsequent MFD loading by pen drive, allows a visual navigation, data logging by mission recording during flight and finally the ground mission post flight data processing.

IV. CONCLUSIONS

This paper attempts to describe an integrated and interdisciplinary work between Air Force, Navy and FAdeA aircraft factory, with the aim of developing a national low cost product with a potential possibility to be mass manufactured, leaving us the knowhow.

This device has been designed to meet different types of tasks that require visual interface with the pilot, ensuring its operation in an aeronautic hostile environment.

The environmental testing of this prototype in FAdeA allowed winning experience in order to apply it in future designs of avionic general systems, showing that we can manufacture avionics with commercial off the shelf items at

affordable costs and flight safety certifiable.

Among the advantages of this development we can cite the versatility for implementation in different types of aircraft, both military and civilian. Also, it serves as a platform for evaluating several types of navigation software, allowing metrics and comparative analysis between them, as well as the performance of different kind of real time operating systems.

The manipulation of the device is simple and allows the interaction between the pilot and the navigation system. The MFD can be manufactured entirely in Argentina Air Force, using the resources available in the Rio Cuarto material area, the aircraft factory test laboratories and the army experience.

In future publications, we will report the results from the flight test campaign in order to complete the full test procedure, we also will report the software and hardware integration tests performance between the UIE and the MFD.

ACKNOWLEDGMENTS

We are grateful with Arturo Tomas Medici (Calnav creator) for the help provided by the Argentine army during prototype development, because of their experience in similar avionics systems.

Also, we are very satisfied with FAdeA´s coordination work team, particularly with Gustavo Lamarque and his staff, included Boris Estudiez, the UIE designer.

We are thankful to the Rio Cuarto Engineering Division team, particularly with Carlos Bortis, as well as to machinery repair section, among others.

Finally, we thank the Argentine Air Force General Directorate of Research and Development work team, in special to C. Gonzales del Solar and M. Pereyra.

REFERENCES [1] J. S. Pruitt Collins “A Large Flat Panel Multifunction Display for

Mil itary and Space Applications” Avionics and Communications Division Rockwell International Cedar Rapids, IA

[2] ECSS-E-ST-10C. “System engineering general requirements”. [3] ECSS-E-ST-10-02C. “Verification requirements”. [4] ECSS-E-10-03A. “Enviromental requirements for Testing”. [5] RTCA/DO-160D (2000). Environmental Conditions and Test

Procedures for Airborne Equipent. http://www.rtca.org

[6] D. Li, R. Landry and P. Lavoie, ”PC104 Based Low-cost Inertial/GPS Integrated Navigation Platform: Design and Experiments” LACIME, Department of Electrical Engineering École de Technologie Supérieure (ÉTS), University of Quebec, Montreal, Quebec, Canada, H3C 1K3. Publication: 2007.

[7] B. Estudiez, S. Moyano, C. Ramón,” DISEÑO DE UN CONTROLADOR DE BUS 1553 PARA UNA PLATAFORMA INS-GPS” Congreso Argentino de Tecnología Espacial. 2011.

[8] M. Grewal, L. Weill, A. Andrews “Global Positioning Systems, Inertial Navigation, and Integration”, Copyright 2001 John Wiley & Sons, Inc. Print ISBN 0-471-35032-X Electroic ISBN 0471-20071-9.

[9] I. Moir and A. Seabridge “Aircraft systems Mechanical, electrical and avionics subsystems Integration”. Third Edition. Ed: Wiley. ISBN 978-0-470-05996-8. May 2008.

[10] X. He and Y. Chen “Development of a Low-Cost Integrated GPS/IMU System”. The Hong Kong Polytechnic University and Jianye Liu. Nanjing University of Aeronautics and Astronautics


68

Abstract� El artículo describe el desarrollo de un

instrumento para detectar y medir la falla en un cilindro/s

(Misfire) de un motor de Combustión interna, dando una

magnitud de la misma.

Se hace el análisis de variables e incertidumbre del

instrumento para las magnitudes involucradas en la detección

de la falla, dando la pauta de que el hardware, el método de

medición y algoritmo son adecuados para la tarea dentro del

rango especificado.

Keywords� Algoritmo, Detección Misfire, Falla de

Cilindro, CKP, Cigüeñal, Incertidumbre, Sistema embebido.

I. INTRODUCCION

OS motores modernos de combustión interna (SI y CI engines), son sometidos a especificaciones cada vez más rigurosas respecto a contaminación ambiental y

performance de los mismos. Es por eso que las ECU (Electrónica Control Unit) de gestión de combustible modernas, cumplen con normas de contaminación Euro IV y Euro V, las cuales tienen una serie de requisitos de contaminación y de diagnostico de fallas bastante exigente. Estos eventos de diagnostico los tiene que reportar por una interfaz llamada OBD II (On Board Diagnostics), que estipula que detectar, y como informarlo [1]. Uno de esos diagnósticos principales, es la detección de una falla (Misfire) en uno o varios cilindros.

¿Qué es la falla del cilindro? es la ausencia, o parcialidad

del torque generado por él. Esto puede implicar que, o no se produjo la combustión interna, o por algún motivo, fue deficiente (mezcla rica/pobre, ausencia/desfasaje de encendido, falta de compresión del cilindro, etc.) [2]. En base a la detección de estos fenómenos, la ECU tiene que, aparte de detectarlos en tiempo real, tomar decisiones en base a ellos, como por ejemplo, �apagar� el cilindro que presenta el problema e informar por tablero (y puerto de diagnostico) que hay un problema con el motor y el cilindro especifico (check engine, MIL). Descripción del fenómeno físico:

Los impulsos de torque generados por cada cilindro, producen en el cigüeñal una velocidad angular proporcional

a ellos, la cual es filtrada por toda la masa y la fricción del sistema.

Combustión

Escape

Admisión

Compresión

Fig.1 Grafico de los 4 estados (motor 4 tiempos) del cilindro, y su respectiva generación de torque, con ejemplos de 1, 4 y 8 cilindros.

Si analizamos la velocidad angular de manera instantánea, podemos ver las aceleraciones angulares producidas por el torque generado de cada cilindro.

Fig. 2 Motor V8, 3 ciclos de motor con todos sus cilindros generando torque. Se aprecian 8 picos por ciclo.

Si por algún motivo, alguno de los cilindros no genera torque (o menor al esperado) podría detectarse viendo una desaceleración angular en la posición angular relativa del mismo.

Fig. 3 Mismo motor V8, 3 ciclos de motor con el cilindro #5 fallando continuamente, sin generar torque (falta de encendido).

Detector de Misfire a través del sensor de rotación de cigüeñal CKP.

Pablo Andrés Grass. Ing. Electrónica UTN.BA, FRBA; Departamento R&D T.A Gas Technology

Bueno Aires, Argentina.

[email protected], [email protected]

L


69

Hay varios métodos de detección a través de distintos sensores del fenómeno mencionado [2]. El método más usado (porque el sensor siempre está presente para sincronizar las fases de inyección y encendido del combustible), es la detección a través del sensor de posición angular del cigüeñal CKP (CrankShaft Position Sensor).

Fig 4. Distribución y sensores típicos de un motor moderno con los cilindros �en línea�.

II. FUNCIONAMIENTO DEL DETECTOR

Fig. 5 Diagrama en Bloques del Detector.

La detección de la falla a través de este sensor se propone de varias maneras de distinta complejidad práctica, como por ejemplo en [3], [4], [5] y [6].

El sistema de detección consta de 5 bloques. Se explicara el funcionamiento de cada bloque del sistema detector.

1. Sensor.

El encoder con el cual se mide la velocidad angular del cigüeñal, normalmente es una �rueda� dentada solidaria al mismo, con alguna característica mecánica para definir un punto de referencia absoluto de posición angular. Por ejemplo, la rueda más común es 60-2 �dientes�. Hay otros fabricantes, que usan 36-1, 36-2, 30-2, 12-1 o incluso con doble referencia de posición angular. El segundo número indica la cantidad de dientes ausentes como referencia. Esta rueda es leída eléctricamente a través de un sensor Inductivo, o HALL, según lo montado por el fabricante.

Fig 6. Configuración del sistema de medición de la velocidad angular del cigüeñal.

Todo esto implica que el dispositivo detector presentado tiene que aceptar los dos tipos de sensores, y los algoritmos deben ajustarse a las distintas geometrías y cantidad total de dientes (D) del encoder.

2. Etapa de entrada.

La entrada del sensor Inductivo, tiene más circuitos de acondicionamiento analógico que la del sensor HALL, así que dicha etapa es la que se va a considerar para el cálculo de incertidumbre.

Fig 7. Diagrama en bloques del circuito de acondicionamiento canal Inductivo.

La señal de entrada está conectada a 4 bloques, dos

detectores de pico y dos comparadores analógicos. Esto se hace para tener una buena sensibilidad de entrada, ya que la señal de los sensores inductivos varía su amplitud en función de: - Régimen de giro del motor (a mas RPM, mayor amplitud) - De la distancia entre la rueda dentada y el sensor (a más distancia, menor amplitud).

3. Circuito de captura del timer.

Este circuito es el encargado de capturar el valor de un timer al instante que ocurre un evento determinado de la entrada (flanco de un diente). Esta acción la realiza el hardware del µC. El Periodo T puede ser calculado de dos maneras, una como la diferencia de dos valores de captura cuando el timer corre continuamente hasta llegar al desborde, o como el valor de captura y luego vuelto a 0 en el instante de la misma. Se implemento el segundo método, por tener aparejado menor incertidumbre en el periodo calculado.

4. Calculo de RPM y CP.

En el evento de diente, una interrupción se genera y calcula en tiempo real dos valores, el periodo de una revolución ோௌ y el periodo de combustión ܥ (Combustion Period).

ோௌ = ୀ ܥ ݕ (1) = (2) =

ݕܥܦ.2ୀ ௐ

Siendo: : Periodo medido para el diente i. ܦ: Cantidad total de dientes del encoder. ݕܥ: Cantidad de cilindros del motor. : Cantidad de dientes que equivalen en grados al segmento que dura el periodo de combustión ܥ. Ejemplo: Para un motor de 8 cilindros, el CP es el tiempo que tarda en girar el motor 90º (: 15); para uno de 4 cilindros 180º (: 30). Y las ܯ se calculan como:


70

ܯ =.ቂ ೞቃೃುೄ ܯ (3) =

.ቂ ೞቃ.

La segunda ecuación fue teniendo en cuenta la equivalencia del valor medio de haciendo la relación:

= ோௌ ൗܦ

5. Calculo del índice de ER.

El balance de torque en el cigüeñal esta dado por la ecuación: ܯ = + ߠ כ

ݐݓ

Donde: ܯ: Torque generado por el motor. : Torque de la carga. ߠ: Momento de inercia. ݓ: Velocidad angular del motor.

Como se aclaro anteriormente, las fluctuaciones en el torque del motor producidas por las fallas conllevan a

fluctuaciones డ௪డ௧ del cigüeñal. La velocidad angular en el

periodo de tiempo ܥ , definido como el tiempo que transcurre de una ignición de un cilindro (n) a la de otro cilindro consecutivo (n-1 o n+1), está dada por: ݓ =

ݐ = ݕܥߨ4 כ

ܥ1

Donde: ߨ4 = Numero de radianes en dos revoluciones (motor 4 tiempos). ݕܥ: Cantidad de cilindros del motor. ܥ = Periodo de combustión del cilindro n. Entonces, calculo la aceleración: ߙ =

డ௪డ௧ ൎ ο௪ο௧ ൎ ௪௪షభ ൎ

ସగ௬כ כ ቀ ଵ െ ଵషభቁ

ߙ ൎ ସగ௬ כ ቀషభమ.షభቁ ൎ

ସగ௬ כ ቀషభయ ቁ ቂௗ௦మ ቃ Donde la ultima aproximación se puede hacer debido a la naturaleza de ܥ , el cual varia muy poco respecto de su valor medio elevado, incluso con falla en cilindro.

Fig. 8 Mismo motor V8, Cálculo de los CP con MatLab, Valor pico negativo 8,87mS y positivo 8,92mS.

Aquí, estamos en condiciones de definir un índice, llamado ER (Engine Roughness) [7], basado en la diferencia de dos aceleraciones angulares consecutivas: ܧ =

ο(ο)య =(షభషమ)(షభ)య ቂ ଵ௦మቃ

Como lo que se evalúa son dos aceleraciones consecutivas cualesquiera, se puede redefinir para un ο= ܥ ାଵ െ ܥ : ܧ =

ο(ο)య =(శభ)(శమశభ)య ቂ ଵ௦మቃ

Bajo condiciones de operación estables, un evento de falla causa un alto valor relativo de ER para el cilindro (n). Los cambios de carga y de velocidad de motor no generan condiciones estables de funcionamiento. Para tener en cuenta estos factores, el segundo término del numerador será el promedio aritmético de todos los ο presentes en el entorno del punto ο. ܧ =

(శభష)ଵ ௬ൗ σ (శభష)/మసష/మయ ቂ ଵ௦మቃ Que se puede poner en función de ο quedando: ܧ =

οଵ ௬ൗ σ ο/మసష/మయ ቂ ଵ௦మቃ (4)

6. Detección de la falla de cilindro.

La detección del evento, consta simplemente de comparar si el valor del índice ER es mayor a una tabla de valores fijos que el fabricante calibra en el banco de motores, con el motor funcionando en distintas condiciones de carga.

III. RANGO DE MEDICION DEL INSTRUMENTO

RPM: El rango de medición del instrumento va a estar limitado

principalmente por la capacidad del mismo en cuanto: - El periodo máximo que puede medir. - Resolución con la cual mide dicho periodo.

El primer caso, limita la mínima cantidad de RPM que va a medir el sistema. Haciendo un análisis, el timer encargado de medir el sensor, es un timer de 32bit con un clock de 72MHz. Así que, el máximo periodo que se puede medir es: =

1

72. 10[ݖܪ]. 2ଷଶ = [ݏ] 59,6

Si consideramos el peor caso, de un encoder de D = 1, ܯ =60. ቂ ܦ.ቃݏ = [ܯ] 1,005

Se puede concluir que en cuanto a las RPM mínimas, el timer tiene un alcance más que suficiente para leerlas. Ahí entra en juego otro factor, como ser la amplitud de entrada (que en un sensor inductivo depende de la velocidad angular del motor) limitando las RPM mínimas que lee el dispositivo. De forma empírica, probando en distintos vehículos, el dispositivo lee perfectamente de 200RPM en adelante. El segundo caso, limita las máximas RPM que el sistema puede leer y procesar correctamente. Para el dispositivo, se propuso un máximo de 10000 RPM de lectura. Haciendo unos cálculos, y considerando el peor caso, un encoder de D=60, vemos que: =

.ቂ ೞቃோெ. = 100. 10 [ݏ]

Representado en cuentas del timer: ݏݐݑܥ = . 72. 10[ݖܪ] = 7200 Podemos ver que el mínimo periodo que debe medir el sistema, está representado por una cantidad más que suficiente de cuentas para procesarlo. ER: Para el rango de medición de este índice, podemos considerar dos aspectos:

- Rango de RPM sobre el cual se va a medir. - Valores que se van a medir.


71

En el primer caso, el rango de RPM donde se va a medir el índice y detectar la falla es programable, pudiendo activar o desactivar la detección en función de ellas y su evolución. Igualmente, los rangos típicos van de 700 a 7000 RPM. Respecto al segundo caso, el cálculo se implemento con matemática de punto flotante, asegurando una buena resolución.

IV. ANALISIS DE LA INCERTIDUMBRE DEL

INSTRUMENTO

1. Sensor.

Este ítem, que no es parte del dispositivo, es provisto por el fabricante del vehículo. Es por eso que no se tiene en cuenta para la incertidumbre del equipo. Cabe aclarar que el error por mecanizado del encoder, es considerado por el algoritmo, ya que bajo ciertas condiciones de carga estables puede aprenderlo.

2. Etapa de Entrada.

La etapa de entrada, genera dos errores en la medición de periodos . Uno se debe al error de trigger (disparo) ோெௌ ଵque genera el comparador analógico, el cual compara la señal de entrada con una fracción de su valor pico negativo. Luego, dicha salida, alimenta una compuerta schmitt trigger, la cual genera otro error de trigger ோெௌ ଶ. La forma en que se calcula la incertidumbre por error de trigger, ha sido estudiada por la firma Agilent Technologies [8], y sigue la ley: ோெௌ ଵ =

ߨ2

Donde: : Ruido de la señal de entrada. Como ella es inyectada a cuatro entradas de operacionales (AOPs, ver Fig. 7), el ruido es inducido por ellos (recordar que no tenemos en cuenta el ruido propio de la señal, que depende del sensor del fabricante y el entorno). El ruido que induce un AOP, es proporcional a la raíz de la frecuencia de entrada [9]. Además, como son cuatro niveles de ruido, deben ser combinados cuadráticamente. La constante se saco de la hoja de datos del AOP TLV2374. ோெௌ ଵ =

ξସ.ඥ ଷଽ.ଵషబవቂ ೇξಹቃଶగ =ඥ ଷଽ.ଵషబవቂ ೇξಹቃ.గ [ݏ]

Slew Rate de una señal senoidal, de frecuencia y :ߨ2valor pico . ோெௌ ଶ =

ଶௌௐோಲೀು =ଶଶ,ସ ೇഋೄ = 8,33. 10ଽ[ݏ]

Donde: 20 =Ruido medido a la salida del AOP. ை = Slew Rate del AOP.

Ahora combinamos ambos errores cuadráticamente y teniendo en cuenta que el error por trigger genera error dos veces en la medición de un único periodo (un periodo son dos eventos, uno de comienzo y otro de fin) queda: ோூଶ = 2. (ோெௌ ଵଶ + ோெௌ ଶଶ) ோூଶ =

ଷ,ଶ.ଵషభలమ௦൧.మ + 1,388. 10ଵ[ݏଶ]

3. Circuito de captura del Timer.

En la configuración del timer elegida (que genera menos error) un evento de entrada genera el valor del periodo y luego pone a 0 el timer. = .ܥ = .ܥ

ଵೖ [s]

Donde: ܥ: Cuentas de timer capturadas en el evento. : Frecuencia del clock del timer. Si propagamos errores: ߤଶ = ଶܥ ቀ ଵೖమቁଶ ଶߤ + ቀ ଵೖቁଶ [ଶݏ] ܥଶߤ

Que lo podemos escribir en función de : ߤଶ = ቀ ଵೖቁଶ ଶߤଶ + [ଶݏ] ൧ܥଶߤ

Calculamos la incertidumbre de la frecuencia, partiendo de su definición: = . ௦ Donde: : Factor de multiplicación del PLL. ௦: Frecuencia del oscilador externo del microcontrolador. ଶߤ =

ଶ. ଶߤ ௦ [ଶݖܪ] (El error del PLL se considera despreciable).

Estamos en condiciones de calcular la incertidumbre total al medir un periodo (de cualquier diente, índice i o n) con nuestro sistema: ߤଶ = ଶߤ + ோூଶ [ݏଶ] ߤଶ = ቀ ଵೖቁଶ [ଶߤଶ + [ܥଶߤ +

ଷ,ଶ.ଵషభలమ௦൧.మ +

1,388. 10ଵ[ݏଶ] (5)

4. Calculo de RPM y CP.

Propagando errores en la formula (3): ߤଶܯ = ቆെ .ቂ ೞቃೃುೄమ ቇଶ . ଶߤ ோௌ

Teniendo en cuenta (1): ோௌ = σ ୀ ՜ ߤ ோௌ .ܦ= ߤY poniendo ோௌ en función de ܯ queda: ߤଶܯ = ቆെ ோெమ.ቂ ೞቃቇଶ ଶܦ. ଶߤ.

Queda simplemente reemplazar la incertidumbre del periodo individual medido (5), y operando matemáticamente se llega a: ܯଶߤ ଶܯ= ൭3,8510ݔଶ[ଶ] +

మೞమ ൨ଷ.ೖమ൱ܦଶ.ܯଶ +

,ଷ௫ଵషభఴమ൧మ ܯ.ܦ +ఓమೖೖమ ൩ (6)

Para tener la incertidumbre de las RPM del instrumento

final, reemplazamos las constantes del sistema de medición. ௦ = 8. 10[ݖܪ] ; = 9 ; = 72. 10 [ݖܪ] ߤଶ = 691,11. 10ଷ [ݖܪଶ] y = 5 [] , que es la mínima amplitud presente en todo el rango de operación (y genera mayor incertidumbre):


72

ܯߤ = 1. 10ହ.ܯ.ξܦ.1ܭଶ.ܯଶ + ܯ.ܦ.2ܭ + 3ܭ +

(7) [ܯ] 0,1 Con: 1ܭ = 9,12. 10ଵ[ଶ]; 2ܭ = 2,54. 10ଽ[]; 3ܭ = 1,33

Esa es la especificación del instrumento. La suma final, es el error debido a la resolución de las RPM que utiliza el sistema para sus procesos de control. Si quisiéramos obtener la incertidumbre Tipo B del mismo, deberíamos dividir dicha fórmula por ξ3.

5. Calculo del índice de ER.

Si tomamos la formula de ER (4) y teniendo en cuenta que en la sumatoria del término de compensación, se encuentra el valor de ο, lo extraigo y queda:

ܧ =

ο ቀ1 െ 1 ൗݕܥ ቁ െ 1 ൗݕܥ σ ο௬/ଶୀ௬ଶ ଵܥ ଷ ଶ൨ݏ1Ecuación que resulta más práctica para calcular su

incertidumbre. Para proceder, calculamos antes: ܥ :(2) = σ ୀ ௪ ՜ ܥߤ = . ߤ=ଶοߤ =ଶοߤ ܥଶߤ ାଵ + ܥଶߤ =ଶοߤ =ଶοߤ 2. ܥଶߤ = 2.ଶ. ଶߤLas igualdades se aplican ya que, pese a que tienen distinto índice ο y ܥ, la formula de la incertidumbre es la misma.

Aplicando la incertidumbre y operando matemáticamente, se llega a: ܧଶߤ =

2.ቆ .ோெ.ቂ ೞቃቇଶ . ቀ1െ 1 ൗݕܥ ቁ .ቆ௬.ோெଵଶ.ቂ ೞቃቇସ + ଶ൩ܧ.4,5 . ଶߤ

Al igual que como se procedió en el cálculo de la

incertidumbre de las RPM, ahora queda reemplazar la incertidumbre del periodo individual ߤ, y operar matemáticamente. ܧଶߤ =

2. ቀ1 െ 1 ൗݕܥ ቁ .ቆ ௬.ோெଵଶ.ቂ ೞቃቇସ +

ଶܧ.4,5 . ቈቆ3.85. 10ଶ[ଶ] +ቂ ೞቃమଷ ೖమቇ ଶܯ.ଶܦ. +

,ଷ.ଵషభఴమ൧మ ܯ.ܦ. +

ఓమೖೖమ ቂ ଵ௦రቃ Si aplicamos la raíz cuadrada, obtenemos la incertidumbre

con la cual el instrumento calcula el índice ܧ ܧߤ = ξ2. 10ହඨቀ1െ 1 ൗݕܥ ቁ .ቆ ௬.ோெଵଶ.ቂ ೞቃቇସ + ଶ൩ܧ.4,5 ଶܯ.ଶܦ.1ܭ]ඥכ + ܯ.ܦ.2ܭ + [3ܭ + 0,1 ቂ ଵ௦రቃ (8)

Con: 1ܭ = 9,12. 10ଵ[ଶ]; 2ܭ = 2,54. 10ଽ[]; 3ܭ = 1,33 (Las mismas constantes que la incertidumbre de las RPM). La suma final, es el error por la resolución. Si quisiéramos obtener la incertidumbre tipo B del mismo, deberíamos dividir dicha fórmula por ξ3.

V. IMPLEMENTACION DEL FIRMWARE

El microcontrolador utilizado es un STM32F103CBT6, con núcleo CORTEX-M3 que corre a 72MHz (90MIPS). El Firmware fue desarrollado bajo el IDE µVision 4.60 y con la herramienta de depuración ULINK2. Como sistema operativo de tiempo real, se utilizo FreeRTOS.

En la ISR de la interrupción del flanco negativo de la entrada del CKP se calcula lo siguiente. a) Almacenamiento del valor de periodo leído en cola, y cálculo del filtro de promedio móvil del periodo de las RPS. a) Calculo del tiempo de combustión. Es otro filtro de promedio móvil más elaborado, que calcula el tiempo que tardo en girar el motor cierta cantidad de grados, (cantidad que fue pasada como parámetro por la tarea de control), en cada captura de diente. Luego lo guarda en una cola, para que la tarea que mida el índice ER en una capa superior, pueda procesarlo. Este algoritmo tiene que tener en cuenta las asimetrías debido a los dientes faltantes y las imperfecciones mecánicas del encoder. b) Detección de tipo de punto de sincronismo. Aquí, según los periodos medidos, se calcula si el último diente fue el punto de sincronismo seleccionado. Si así lo fue, calcula todos los parámetros que se le pasa a la tarea de control para que los procese, y se habilita a la misma. Esta detección es debido a la diversidad de tipos de encoders mecánicos que hay en los vehículos. c) Sistema de generación del pulso de sincronismo de instrumental. Genera un pulso sincrónico con la entrada de CKP, generando un pulso por ciclo del mismo.

En la tarea de mayor prioridad (pero menor que una ISR) se calcula los ER según formulas anteriormente descriptas. Cabe aclarar que estrictamente se calcula un valor de ER por cada cilindro, pese a que la ISR de captura pasa una cola donde está el valor de ܥ para cada pulso de entrada. Actualmente solo existe un parámetro de ajuste para calibrar el valor óptimo de detección (una especie de sintonización). Esto se implemento así, para que en el futuro, si se desarrolla una manera más sofisticada y precisa de detectar misfire utilizando un filtrado sobre ܦ muestras y no sobre ݕܥ muestras (que están separadas muestras), esté disponible la secuencia de valores necesarios.

Para más detalles de los módulos de control del programa, muestreo filtrado de los canales analógicos y protocolo ver [10].

VI. EVALUACION EXPERIMENTAL DEL SISTEMA

Antes de completar el diseño se hicieron evaluaciones experimentales para comprobar la funcionalidad de los algoritmos, la incertidumbre de los cálculos y valores informados por el dispositivo. Estas evaluaciones se dividieron en tres procesos. A. Muestreo de las señales CKP, simulación y contraste de

los algoritmos de cálculos.

Se realizaron mediante un osciloscopio Tektronix DPO4034 varias adquisiciones de la señal CKP en distintas condiciones de carga de una Chevrolet Silverado, con motor Vortec 5.3litros, 8 cilindros en V con orden de encendido 1-8-6-2-7-3-4-5 y 4 válvulas por cada uno, con potencia de 315HP @5200RPM. Teniendo dicha adquisición, se las proceso en MatLab® para calcular los periodos de toda la secuencia y posiciones angulares de misfire y además se implemento el algoritmo a usar en el detector bajo desarrollo. Se compararon los resultados para


73

ver que se detectaba valores altos de ER en los lugares donde efectivamente se producían las fallas [11].

B. Evaluación incertidumbre teórica en caso práctico.

Parte del objetivo del presente documento era verificar si la incertidumbre del índice es lo suficientemente pequeña como para que en condiciones de carga desfavorables se detecte correctamente. Se procedió a tomar del trabajo [12] valores de ER medidos y calculados en condiciones de carga desfavorables, en un motor V8 de alta performance. Así que para: ܦ = ݕܥ;60 = 8; ܯ = 6440; ;ݎ 20% ܧ =

400 ቂ1 ଶൗݏ ቃ ՜ ܧߤ = 28,73 ቂ1 ଶൗݏ ቃ Si dividimos ese valor para obtener la incertidumbre tipo B del instrumento por ξ3 , y tomamos que es una incertidumbre Tipo B dominante, calculamos la incertidumbre expandida con K=1,65 para el 95.45% de confianza, quedando: ܧ = 400 ± 27 ቂ1 2ൗݏ ቃ Con un error relativo del 6,8%

Planteando un segundo caso y calculando de igual manera: ܦ = ݕܥ;60 = 8; ܯ = 6440; ;ݎ 60% ܧ = 700 ቂ1 ଶൗݏ ቃ ܧߤ = 28,73 ቂ1 2ൗݏ ቃ ܧ = 700 ± 27 ቂ1 2ൗݏ ቃ Con un error relativo del 3,8%

Podemos observar que pese a las condiciones de operación desfavorables, se puede medir el índice con un error relativo bajo. Además, se puede observar que para ese régimen pesa más en la incertidumbre de ER el valor de las RPM que el de ER. C. Implementación en sistema embebido, calibración y

aplicación.

Para ver la calibración del sistema, referirse a [13]. Se probó el detector ya implementado en el hardware

embebido en un vehículo [14]. Se pudo obtener los siguientes valores y calculo de incertidumbre.

Tabla 1. Valores medidos de RPM/ER, y su respectiva incertidumbre para el caso dado (Cyl= 4; D = 36).

VII. CONCLUSIONES

Analizando la formula (8), podemos ver que la incertidumbre del índice ER, depende fuertemente de las RPM, D y Cyl. Su dependencia de las RPM tiene sentido físico, ya que a mayores velocidades angulares, toda la inercia del sistema filtra las variaciones de aceleración angular. Respecto a D, hay una especie de balance, ya que con D alto (60max.) tenemos buena resolución angular para sincronizar todo un sistema de inyección de combustible, pero para minimizar errores en el cálculo de ER necesitamos que sea lo más bajo posible, un D igual a tantos como cilindros haya. Igualmente se demostró con valores empíricos, que la incertidumbre tipo B del instrumento de este índice alcanza para detectar los valores en condiciones de carga totalmente desfavorables (altas RPM y poca carga) para el cálculo del mismo. Así que, la técnica de detección y

modulo de firmware que lo implementa, es perfectamente

portable y aplicable al firmware de un sistema de inyección

en desarrollo.

Pese a que hay productos comerciales, como las ECU de los vehículos que detectan este fenómeno, la idea de generar un escáner de mano que en �tiempo real� informe el estado de los cilindros tanto para el ajuste de combustible o detección de la falla, y se ajuste a cualquier vehículo comercial fácilmente, fue alcanzada satisfactoriamente.

VIII. TRABAJOS FUTUROS

En cuanto al índice ER, para poder minimizar dicha incertidumbre, se podría pensar un sistema con un segundo timer. El anterior que siga midiendo periodos y eventos para sincronizar fases de inyección por ejemplo, pero el segundo timer sea disparado cada W eventos y capture el valor de CP directamente por hardware, minimizando el error. Sino mediante algoritmo, utilizar el timer en modo libre y capturar los valores del mismo en cada punto donde se va a medir el CP, haciendo que la incertidumbre baje, pero complicando el algoritmo y usando mayor cantidad de memoria. Igualmente, estoy serviría para calibrar o corroborar el error del instrumento, pero como sabemos por experiencia, dichos valores de comparación deben ser ajustados finalmente en el motor de aplicación, que contempla todas las variables físicas del mismo, esta práctica es como regularmente se hace.

Queda pendiente también, agregar funcionalidades mas amigables al usuario, como ser autoset de la tabla de comparación de detección de fallas y procesos más autónomos.

AGRADECIMIENTOS

A mi hija Olivia, y mi familia Horacio, Liliana, Silvana y Natalia; Mis incondicionales amigos, Leonardo y Juan. También agradecer de la siempre buena predisposición del Jefe del departamento de R&D de electrónica de T.A Gas Technology, el Sr. Daniel Crespo.

REFERENCIAS [1] Wikipedia, �Definición de OBD� http://es.wikipedia.org/wiki/OBD [2] J. Merkiszt, P. BogusZ, R. Grzeszczyk . �Overview of engine misfire

detection methods used in on board diagnostics�. [3] U. Kiencke �Engine Misfire Detection�, Control Engineering Practice

7 203-308 [4] A. Stotsky �Statistical Engine Misfire Detection� [5] G. Malaczynski, R. Van der Poel �Pahse Diagrams of Different

Modes of Misfire Calculated from the DFT of CKP Velocity� [6] Y. Wang, F. Chu �Real time misfire detection via sliding mode

observer� [7] M. Klenk, W. Moser, W. Muller W. Wimmer, �Misfire Detection by

evaluating Crankshaft speed- A means to comply with OBDII�, SAE paper 930399.

[8] Agilent Technologies, �Understanding frecuency counter Specifications�, Application note 200-4

[9] Texas Instruments, �Op Amp Noise Theory and Applications�, literature number SLOA082.

[10] https://docs.google.com/file/d/0BzTEIMz5Ps9jSE9ZRmtqcS1ETmM/edit?usp=sharing

[11] https://docs.google.com/file/d/0BzTEIMz5Ps9jaHhac1VDMVFBakE/edit?usp=sharing

[12] D. Moro, F. Ponti, G.M Mammetti, L. Poggio, �An Approach for Misfire Diagnosis in Critical Zones of the Operating Range of a High Performance Engine�. SAE publication.

[13] https://docs.google.com/file/d/0BzTEIMz5Ps9jODAyVWxhVzFnZFU/edit?usp=sharing

[14] http://www.youtube.com/watch?v=vUr4DRU9tHE (ver canal para más videos).

Prueba 1

Ford Focus

Revoluciones

[RPM] (3)

ER Medido

[1/s^2] (4)

Incertidumbre

expandida ER

[1/s^2] (8)

Error Relativo

[%]

750 63.30 0.11 0.17

Cyl 720 74.50 0.11 0.14

4 800 67.30 0.11 0.16

D 790 60.00 0.11 0.18

36 3860 21.20 0.94 4.43

3760 16.80 0.88 5.22

3770 17.90 0.88 4.93

3610 23.60 0.79 3.35


74

1

Diseno e implementacion de un sistema embebidode control de actitud para aeronaves no tripuladas

Alan Kharsansky, Ariel Lutenberg, Member, IEEE,[email protected], [email protected]

Laboratorio de Sistemas Embebidos (FI-UBA), Buenos Aires, Argentina

Resumen—En este trabajo se presenta el diseno de unacomputadora de vuelo que permite implementar un controlautomatico para estabilizar el vuelo de una aeronave no tripulada,particularmente un quadrotor. El diseno comienza luego de undesarrollo teorico en donde se demuestra que es posible utilizarcontroladores simples PID para estabilizar por velocidad angularo por actitud, cada eje del quadrotor. Se presentan los resultadosen vuelo en donde mediante la telemetrıa descargada en tiemporeal es posible observar el comportamiento de la aeronave frentea diversas condiciones.

Palabras clave—Quadrotor, Sistema embebido de control, Controlautomatico, PID, ARM, Cortex-M3

I. INTRODUCCION

LAS aeronaves pequenas no tripuladas se utilizan paratareas de investigacion, aplicaciones comerciales, apli-

caciones civiles de busqueda y rescate y para seguridad. Engeneral estas aeronaves suelen agruparse en aquellas capacesde realizar una mision sin intervencion humana, las llamadasautonomas, y aquellas controladas de manera remota por unoperador humano, llamadas controladas.

Dentro de las mas populares, se encuentra la aeronave decuatro rotores denominada quadrotor1. Estas se popularizaronen los ultimos anos debido a su bajo costo, su relativa facilidadde construccion y su reducida cantidad de partes moviles. Estopermitio que muchos laboratorios de diferentes universidadesdel mundo [1], [2] lo utilicen como plataforma de estudio paraaplicaciones de control.

Algunas de las diferentes areas de investigacion y aplicacionque se desprenden de los quadrotores son:

Modelado de sistemasTeorıa de controlSistemas EmbebidosProcesamiento de senalesFusion de datosProcesamiento de imagenes y video

Estas areas de estudio se engloban en una rama de laingenierıa que se denomina ”Navegacion, control y guiado”,donde:

Navegacion: determinacion de la posicion, velocidad yactitud, la orientacion de un objeto con respecto a unmarco de referencia inercial u otro objeto, del vehıculo.

Manuscrito entregado el dia 25 de Abril de 20131por su nombre en ingles que significa ”de cuatro rotores”

Control: Manipulacion de fuerzas sobre el vehıculo paralograr la estabilidad de la misma y cumplir con losrequerimientos de guiado.Guiado: Determinacion y control del recorrido que elvehıculo debe realizar.

Este trabajo se centra principalmente en el area de control yen el diseno e implementacion de una computadora de vuelocapaz de estabilizar y controlar el vuelo del quadrotor paraluego poder usarlo junto a tecnicas de navegacion y guiadopara aplicaciones de alto nivel.

La organizacion de este trabajo es la siguiente: en el capituloII se analizan los aspectos fundamentales de este trabajo queson los controladores PID y la dinamica del quadrotor. Luegoen el capitulo de III se presentan las hipotesis y decisiones quefueron tomadas para obtener un modelo matematico sencillopor cada eje para luego aplicar la teorıa de control basicapara controlarlo. En la seccion IV se presenta la plataforma devalidacion desarrollada para poner a prueba el trabajo en unescenario real, es decir, implementar los controladores digitalesy hacer un control en tiempo real de la aeronave. Y por ultimoen la seccion V se presenta el desempeno del quadrotor endiferentes situaciones reales de vuelo.

II. DESARROLLO TEORICO

Dos aspectos fundamentales surgen al disenar un sistema decontrol: primero obtener un modelo de la planta, y segundo,la eleccion y ajuste de los controladores. En esta seccion sedetallan brevemente ambos aspectos.

II-A. Modelo fısico del quadrotorEl primer paso para disenar un sistema de control es tener un

buen conocimiento del modelo matematico de la planta que sebusca controlar. Este debe representar matematicamente comoevolucionara la planta dada una cierta condicion inicial, susentradas en cada instante de tiempo y su evolucion interna.Para este trabajo se busca un modelo que describa la dinamicadel quadrotor segun el diagrama de bloques de la fig. 1. Estedebera tener cuatro entradas que representen la senales decontrol, y sus salidas se corresponderan con los parametrosobservables de la aeronave como ser actitud y posicion enfuncion del tiempo, ası tambien como sus derivadas.

Si bien la aeronave bajo estudio no es estrictamente uncuerpo rıgido, para este trabajo, resulta suficiente considerarlocomo tal suponiendo las siguientes consideraciones:

1. La estructura es perfectamente rıgida.


75

2

Dinamica delquadrotor

+

+

M1

Actuador 1

Actuador 2

Actuador 3

Actuador 4

MMIX

Fuerzasaerodinamicas

Fuerzasaerodinamicas

Posicion xb, yb, zbvxb

, vyb , vzb

Actitud φ, θ, ψp, q, r

∑F

∑M

Fact

Mact

Faero

Maero

M1, T1

M2, T2

M3, T3

M4, T4

y1

y2

y3

y4

Zc

φc

θc

ψc

MQ

Figura 1. Modelo matematico completo del quadrotor

2. La estructura es perfectamente simetrica.3. No se consideran efectos giroscopicos de los motores

y helices debido a su pequena inercia en comparacioncon la aeronave.

4. El tensor de inercia del rıgido es diagonal y por endeno existen productos de inercia en el mismo.

En la bibliografıa[3] se deduce a partir de estas hipotesisque las ecuaciones que describen la dinamica de cuerpo rıgidocon seis grados de libertad (DOF) son:

Fx = m (u+ qw − rv) (1)Fy = m (v + ru− pw)

Fz = m (w + pv − qu)

L = Ixxp+ qr (Izz − Iyy) (2)M = Iyy q + pr (Ixx − Izz)

N = Izz r + pq (Iyy − Ixx)

para la traslacion y la rotacion respectivamente. Donde Fi sonlas fuerzas aplicadas en el centro de masa del rıgido en el ejecon i = x, y, z, L, M y N los torques aplicados en los tresejes respectivamente, m la masa del objeto, Iii los momentosde inercia del objeto en cada eje, u, v, w las velocidades detraslacion y p, q, r las velocidades angulares de rotacion. Estasecuaciones completan el modelo matematico que describe ladinamica de la aeronave conociendo los parametros constantes(m, Ixx, Iyy ,, Izz), el estado inicial y las entradas de fuerza(Fx, Fy, Fz) y momentos (L,M,N ) sobre el centro de masadel rıgido y se ven representadas en el diagrama de bloques dela fig. 1 con el bloque deoniminado “Dinamica del quadrotor”.

Para conocer como son esas fuerzas y momentos sobreel centro de masa se estudiaron y ensayaron los actuadores(helices con motores electricos BLDC y variadores develocidad) y se comprobo que cada actuador puede serconsiderado como un generador de empuje en el sentidonormal al plano del giro de las helices y de torque en el eje

del motor en sentido contrario a la rotacion del mismo, segunse puede ver en el diagrama de cuerpo libre de la fig. 2.

El empuje estatico generado por una helice i en aire libre [4]esta dado por:

T (ωi) = KTωi2 (3)

De manera similar al empuje, el torque generador por unahelice en rotacion [4] se puede determinar con la ecuacion:

M(ωi) = KMωi2 (4)

En general, las constantes KT y KM suelen ser difıcil deestimar sin conocer los perfiles aerodinamicos de la helice conexactitud y si no es provista por el fabricante, como sucedio eneste caso, es necesario determinarla mediante experimentosen bancos de prueba. En este trabajo en particular seutilizaron variadores de velocidad comerciales de la marcaDJI Innovations con entrada de control porcentual digital yse encontro que el controlador aplicaba una correccion a lasenal de control para linealizar el empuje y el torque y hacermas sencillo la utilizacion del actuador completo. El modeloentonces del mismo se corresponde con una recta que no pasapor el origen para cada uno de los actuadores.

Figura 2. Diagrama de cuerpo libre del quadrotor


76

3

Para poder trabajar con modelos lineales se debio linealizarel sistema. Dado que el objetivo de este trabajo es poderestabilizar en vuelo la aeronave y que la misma permanezcapracticamente estatica (sin perturbaciones externas), conceptodenominado “hovering” en ingles, el punto de trabajo escogidoes aquel para el cual cada actuador entrega 1/4 del peso totalde la aeronave de modo de sostener entre todos a la aeronaveen vuelo. Esto resulto ser aproximadamente cerca de un 55 %en la entrada de control. Finalmente se obtuvo que el modelolinealizado en el punto de trabajo para cada actuador es:

∆Ti(yi) = KTω∆yi (5)∆Mi(yi) = KMω∆yi (6)

Si se combinan los resultados de los actuadores y se utilizael diagrama de cuerpo libre para determinar el efecto de cadafuerza y torque sobre el centro de masa del cuerpo rıgido sepuede obtener una matriz MQ que relaciona las cuatro entradasde control a los actuadores en expresadas en %, con las fuerzasy momentos sobre el centro de masa. Esta matriz resulta ser:

FzLMN

= MQ ·

y1y2y3y4

+

mg000

(7)

donde

MQ =

−KTw

−KTw−KTw

−KTw

−dKTw−dKTw

dKTwdKTw

−dKTw dKTw dKTw −dKTw

−KMw KMw −KMw KMw

(8)

donde d es un parametro geometrico del quadrotor y KTω

y KMω son las constantes de los actuadores. Es decir quelos actuadores de la aeronave solo aportan fuerza en el eje Zque le da sustentacion, y mediante la accion diferencial de losactuadores torque de control en los 3 ejes. Este concepto esposible verlo en el diagrama de bloques de la fig. 1 comoel bloque punteado que abarca los actuadores y la matrizM1. Finalmente y para comodidad del modelo, es posiblecombinar las acciones de los diferentes actuadores para generarmovimientos mas conocidos en la aeronautica, como el controlde roll, pitch y yaw (rotaciones sobre los ejes X, Y y Zrespectivamente). Para eso se diseno una matriz de mezclatal que:

y1y2y3y4

=

Kz −Kφ −Kθ −Kψ

Kz −Kφ Kθ Kψ

Kz Kφ Kθ −Kψ

Kz Kφ −Kθ Kψ

·

Zcφcθcψc

(9)

Donde Zc, φc, θc y ψc representan el control del colectivo(o indirectamente la altura) y el control de movimientos deroll, pitch y yaw respectivamente. Esta matriz representada enel diagrama de bloques como ¯Mmix completa ası un modelode quadrotor que puede resumirse a cuatro entradas de controly una aeronave que gira y se traslada en el espacio.

II-B. Controladores PIDSe eligio para este trabajo la utilizacion del controlador

clasico PID. Su modelo mas sencillo o “de libro” se puederepresentar segun:

u(t) = K

[e(t) +

1

Ti

∫ t

0

e(τ) dτ + Tdde(t)

dt

](10)

Donde los diferentes terminos son:u(t): Salida del controladore(t): Error entre la variable de proceso y el punto detrabajo deseado, y(t)− ysp(t)K,Ti, Td: Constantes del controlador

Este conocido controlador puede ser utilizado para hacer queuna variable de determinado proceso siga de la mejor maneraposible una referencia introducida por el usuario o bien otrocontrolador. Es posible ajustarlo de diferentes maneras paraevitar errores de estado estacionario u optimizar su desempenofrente a perturbaciones. Para este trabajo se desarrollo unmodelo ligeramente mas complejo cuyas diferencias con elmodelo de la ecuacion de libro son:

Control antiwindupFiltro en el termino derivativo para disminucion delruidoImplementacion de realimentacion directa del terminoderivativo para evitar el “derivative Kick”[5]Diseno digital en ecuaciones de diferencias

III. IMPLEMENTACION

III-A. Linealizacion de la plantaEn este trabajo se busca trabajar con modelos lineales.

Entonces lo primero que se debe hacer es eliminar las ali-nealidades y acoples que se observan en 1 y 2. Para poderlinealizar el sistema se debe escoger un punto de trabajo. Paraencontrar este punto de trabajo se supondra que la aeronavese encuentra suspendida en el aire lo suficientemente altocomo para no sufrir efectos del suelo y su condicion iniciales estable y paralela al piso. Dado que el sistema de controlbusca estabilizar la actitud, entonces se podra suponer unmodelo de pequenas desviaciones del punto de trabajo. Estahipotesis permite descartar el efecto de productos cruzados develocidades angulares de las ecuaciones 2 y entonces el sistemade ecuaciones resulta el sistema de ecuaciones:

Fx = mu, Fy = mv, Fz = mw (11)L = Ixxp,M = Iyy q, N = Izz r

El sistema de ecuaciones 11 representa el modelo matematicobasico que se utilizara en el resto de este trabajo pero, dado queel objetivo de este trabajo es solamente realizar un controladorde actitud, las primeras tres ecuaciones no se estudiaran endetalle, en cambio las ultimas tres conforman la base deltrabajo. Si se observa con detalle es posible ver que, ahoralas tres ecuaciones de rotaciones se encuentran desacopladas,es decir no hay influencia de una velocidad angular en ejescruzados. Esto permite entonces dividir al problema del controldel quadrotor en tres problemas de control de angulo de un


77

4

objeto rıgido con determinado momento de inercia. Si se tomapor ejemplo el eje de roll, y se combinan las ecuaciones 7, 9 y11 con θc = 0 y ψc = 0 se obtiene una funcion de transferenciapara el eje segun:

Hroll(s) =p(s)

φc(s)= 4dKφ

KTω

(sIxx)(12)

con φc entre -1 y 1. Y analogamente resulta para el eje depitch y yaw como:

Hpitch(s) =q(s)

θc(s)= 4dKθ

KTω

(sIyy)(13)

Hpitch(s) =r(s)

ψc(s)= 4Kψ

KMω

(sIzz)(14)

Esta simplificacion permite trabajar con un modelo sencillo deplanta cuyo analisis es conocido y ampliamente estudiado enel area de la teorıa de control.

III-B. Control de velocidad angular y actitudEn la aeronautica se suele encontrar [6] un sistema de

control dado por dos lazos en cascada. El primero denomi-nado SAS (Stability augmentation system) es el encargado decontrolar y estabilizar la velocidad angular en uno o mas ejes yel segundo, ya opcional y comunmente conocido como “pilotoautomatico” denominado CAS (Control augmentation system)es el encargado de asegurar una actitud determinada en elespacio que puede ser en el ejemplo de este caso, vuelo enhovering paralelo al piso. En la fig. 3 se puede observar undiagrama de bloques del sistema de piloto automatico completopara un eje de la aeronave. Es importante destacar que sinel SAS mantener a la aeronave en hovering demandarıa unesfuerzo del piloto enorme ya que las asimetrıas del disenoencontradas por ejemplo en la estructura o las disparidadesentre actuadores y helices por desgaste y/o fabricacion hacenque la aeronave tenga una estabilidad reducida o inexistente.En este trabajo donde la aeronave tiene un tensor de inerciay masa pequenas las dinamicas de la misma se vuelvenmuy rapidas y por ende es posible que un piloto humanodirectamente no pueda volar la nave sin la presencia de unSAS. En cambio el CAS es un agregado optativo y un pilotopuede volar sin este, pero al estar activado es posible hacervuelos controlados con intervencion mınima o nula por partedel piloto.

III-C. Implementacion digital de controladores PIDSe opto por utilizar el lenguaje de programacion C para la

implementacion digital de este controlador ya que el mismo

φspCAS

pspSAS Hroll(s)

φc 1s

p φ

--

Figura 3. Sistema de control del piloto automatico completo

es ampliamente aceptado por diferentes arquitecturas y tecno-logıas de sistemas embebidos. El mismo se diseno para cumplirlos siguientes requerimientos:

1. Poder ser compilado como una biblioteca estatica,dinamica o bien embebido en el firmware

2. Arquitectura multi-usuario: permite ejecutar en paralelomultiples controladores

3. Arquitectura reentrante: toda la informacion esta inclui-da en el objeto del controlador

4. Utilizar aritmetica de punto flotante: facilita la utiliza-cion del mismo ya que puede ser usado con unidadesfısicas y no con enteros representativos.

En todos los casos las pruebas fueron realizadas para unprocesador ARM Cortex-M3 sobre un LPC1769 a 100MHzsin unidad de punto flotante. Los resultados al compilar labibliotecas de PID desarrollada fueron:

Tamano de compilacion del algoritmo: 984 Bytes deFLASHTamano del objeto controlador por cada instancia: 56Bytes de RAMTiempo de ejecucion de cada instancia: aproximadamen-te 24 µS

Con una huella en memoria tan pequena y un tiempo deejecucion menor al milisegundo se observa que es facilmenteutilizable en sistemas embebidos pequenos sin inconvenientes,y es posible utilizar multiples controladores en paralelo conuna latencia muy baja. Es posible encontrar el codigo fuenteimplementado para este controlador en [7].

IV. PLATAFORMA DE VALIDACION

Como se menciono en las seccion anteriores, este trabajose baso en el diseno e implementacion del hardware, firmwarey software de una computadora de vuelo que permita hacerde piloto automatico para la aeronave. Para poder validarse utilizo una estructura de quadrotor comercial F450 dela firma DJI Innovations compuesta por motores, variadoresde velocidad, helices y el chasis para darle forma. En lasiguientes subsecciones se detallan las partes desarrolladasespecıficamente para este trabajo que fueron necesarias parala validacion.

IV-A. Computadora de vueloLa computadora de vuelo se diseno de manera tal que,

es pequena, liviana y potente para no tener limitaciones dehardware a la hora de probar los controladores. En la fig. 4 sepuede observar una imagen de la misma ya terminada y listapara volar.

La misma cuenta con:Microcontrolador LPC1769 Cortex M3 @ 120 Mhz con512KB de flash y 64 KB de RAM.6 interfaces para actuadores con salida de PWM yentrada para un sensor digital o analogico por cada unoConexion USBtarjeta de memoria microSD para almacenamiento dedatos de vuelo.


78

5

Figura 4. Imagen de la computadora de vuelo final.

Giroscopo y acelerometro integrado capaz de entregarvelocidad angular y actitud en forma de quaternion auna frecuencia de 200 Hz.Magnetometro digital de 3 ejes y alta resolucionBarometro digital con resolucion de 1mRadio 2.4 Ghz tipo XbeeMemoria I2C para guardar parametros de config.cionSensor de nivel de baterıaSensor de temperatura

IV-B. FirmwareEl firmware se basa en el sistema operativo de tiempo

real FreeRTOS. Implementa los controladores por ejes que seobservan en la fig. 3 salvo para el caso del eje de yaw quesolo utiliza un SAS para mantener el quadrotor alineado conla posicion de despegue. En todos los casos los controladoresson del tipo PI y se ajustaron primero mediante el simuladorpara obtener las constantes de config.cion de los mismos. Eltermino derivativo de los PID no fue utilizado ya que por unlado no fue necesario para lograr respuestas subamortiguadas ypor otra parte, la adicion de este termino suele ser susceptiblea ruidos y necesita de un esfuerzo enorme para poder serusado correctamente. El sensado de la velocidad angular y dela actitud en cada eje es realizado por la IMU MPU6050 dela firma Invensense de 6 DOF integrada en la computadorade vuelo que utiliza un filtro para fusionar los datos delacelerometro y giroscopo para obtener estos datos.

Luego se utilizo el controlador digital PID desarrolladoen las secciones anteriores para implementar el SAS y elCAS y por ultimo los actuadores son controlados por PWMutilizando la matriz de mezcla Mmix. El sistema efectuaconcurrentemente las siguientes acciones:

Controladores PID (5 en total) a 200 Hz cada unoRecepcion de setpoints vıa radio a 50 HzDescarga de telemetrıa vıa radio a 20 Hz.

V. RESULTADOS

V-A. Identificacion de la planta1) Parametros del rıgido: Mediante el diseno de un modelo

CAD y validado mediante un pendulo bifilar [8] se deter-

mino que el tensor de inercia del quadrotor se correspondecon:

I =

[Ixx Ixy IxzIyx Iyy IyzIzx Izy Izz

]=

[9400 0 00 10000 00 0 18700

]·10−6·Kg·m2

(15)siendo la masa total del modelo:

m = 1037gr (16)

2) Actuadores: Se realizo la identificacion de los actuadoresmediante un experimento de torque y empuje estatico en unbanco de pruebas equipado con un tacometro y una celda decarga mediante el cual se determino que las constantes para elactuador usado (en promedio para los cuatro diferentes) sonKTω = 0,0667N% y KMω = 0,0346Nm% .

V-B. Sistema de control1) Control de velocidad angular: Para las pruebas de ve-

locidad angular se utilizo un banco de prueba en donde elquadrotor fue colgado de un techo lo que permitıa un girolibre sobre el eje de yaw y una buena simulacion del vuelo real.Se controlo el setpoint mediante un joystick externo y luegose utilizo este mismo setpoint como entrada en la simulacionpara correlacionar ambos resultados. En el grafico 5 se puedenobservar los resultados. Se observa que el sistema puede seguirla referencia sin problemas y que la simulacion y el quadrotorreal se comportan de manera similar.

0 2 4 6 8 10 12 14 16 18(200

(150

(100

(50

0

50

100

150

200

250

t[s]

Velo

cid

ad a

ngula

r [g

rados/s

eg]

SetPoint

Simulación

Datos reales

Figura 5. Resultados de utilizar el SAS de control de yaw para mantener lavelocidad angular segun el setpoint. Las constantes del PID del SAS utilizadasfueron: K = 0,05, T i = 1/0,1 y Td = 0,0.

2) Control de actitud: En un experimento similar pero estavez utilizando tambien el CAS controlando para control deactitud en yaw se obtuvieron resultados satisfactorios que sepueden observar en la fig. 6. Es posible observar que ambos, lasimulacion y la aeronave real, se comportan de manera similar.Se observa tambien un primer pico en la actitud real y sedebe a una perturbacion externa que el sistema rapidamenteelimina a los dos segundos del experimento. Por otra parte,se observa la presencia de sobrepicos en la respuesta y estose debe a que se busco un ajuste del controlador que dierauna respuesta subamortiguada a fin de evaluar la concordancia


79

6

entre el modelo simulado y el real lo cual se logro con exito.En el resto de los experimentos se ajusto el controlador massuavemente para evitar este sobrepico y lograr una respuestasobreamortiguada.

0 2 4 6 8 10 12 14 16(60

(40

(20

0

20

40

60

t[s]

Angulo

en y

aw

[gra

dos]

SetPoint

Simulación

Datos reales

Figura 6. Resultados de utilizar el CAS de control de yaw para mantenerla orientacion en yaw segun el setpoint. Las constantes del PID del CASutilizadas fueron: K = 11,0, T i = 1/0,17 y Td = 0,0.

3) Vuelo libre: Para implementar el sistema completo seutilizo la misma tecnica de simulacion y luego validacion enlos otros dos ejes para dar lugar a la plataforma de vuelocompleta. En el caso del eje de yaw, se dejo solo el SAS yaque resulta mas sencillo poder rotar el quadrotor sin tener unareferencia de norte absoluta. Finalmente las pruebas de vuelolibre se realizaron en entornos cerrados con mınimas perturba-ciones por viento y en entornos abiertos. En ambos casos laspruebas se realizaron con exito y se concluye que el sistema dedesacople de las actuaciones y el control mediante un SAS yun CAS en cascada resulta ser una solucion valida. Es posiblever en el video http://laboratorios.fi.uba.ar/lse/tesis.htmlQuad-2 los resultados en un entorno cerrado. En la fig. 7 se puedeobservar un recorte de la telemetrıa descargada en tiempo realdurante un vuelo de hovering con perturbaciones a los 47.2y 50.8 segundos aproximadamente. En este se observa en laprimera subfig. la actitud del quadrotor en todos sus ejes, luegola salida del control del SAS y por ultimo la del CAS. Se

43 44 45 46 47 48 49 50 51 52 53(5

0

5

10

15

20

25

Att

itude [

deg]

phi

theta

psi

43 44 45 46 47 48 49 50 51 52 53(1

(0.5

0

0.5

1

SA

S o

utp

ut

Roll

Pitch

Yaw

43 44 45 46 47 48 49 50 51 52 53(15

(10

(5

0

5

t[s]

CA

S o

utp

ut

Roll

Pitch

Yaw

Figura 7. Telemtrıa de un vuelo en hovering con perturbaciones. Se uti-lizo CAS+SAS en los ejes de pitch y roll y solo SAS en el eje de yaw

observa que ante la ausencia de perturbaciones, el sistema decontrol de actitud CAS logra mantener los ejes de pitch y rollen un rango de ±2◦. Tambien es posible observar que el eje deyaw al solo tener SAS tiene una pequena deriva causada porla acumulacion de velocidad angular muy pequena pero queigual no afecta el desempeno del vuelo. Luego al momento delas perturbaciones (golpes desde abajo de la aeronave en unade sus patas) el controlador CAS actua en sentido contrario ala perturbacion corrigiendo esta en menos de 1 segundo.

Tambien se pudo comprobar que durante el vuelo y alutilizar el control colectivo en modo manual, el piloto lograestabilizar la altura en un valor del 55 % que fue el punto detrabajo elegido para las linealizaciones.

VI. CONCLUSIONES

Se comprobo con exito a lo largo del desarrollo del trabajoque es posible utilizar un modelo simple desacoplado por ejespara estudiar el comportamiento de aeronaves del tipo quadro-tor sin mayores complicaciones. Los resultados obtenidos enlas pruebas de vuelo se corresponden fehacientemente con losmodelos matematicos y las simulaciones realizadas. Ademasse comprobo que es posible utilizar controladores simples deltipo PID para hacer un control aparentemente complejo y queel sistema de cascada CAS-SAS resulta altamente efectivo paraestudiar el problema de forma progresiva.

Como trabajo futuro se encontraron una gran variedad desituaciones a resolver durante el desarrollo del mismo comoser:

Control automatico de altura usando un sensor ba-rometrico para grandes rangos de altura o un sensorde distancia ultrasonico para aterrizajes y despeguesautomaticos o vuelo rasante.Compensacion del control colectivo en funcion del pitcho roll para evitar descender cuando se trasladaDeterminacion de un modelo de mas complejidad paracasos donde la aeronave se aleja del hovering ya sea porgrandes angulos de ataque o bien grandes velocidadesde desplazamiento.un estudio detallado en como maximizar la accion decontrol de cada controlador que ahora se encuentralimitada a que la suma de todos no supere el 100 %.Es posible hacer controladores con maximos y mınimosvariables en funcion del estado del quadrotor.

REFERENCIAS

[1] Aerospace controls laboratory - mit. ”http://acl.mit.edu/projects/.[2] Grasp - general robotics, automation, sensing and perception laboratory,

upenn university. ”https://www.grasp.upenn.edu/”.[3] W.B. Heard. Rigid Body Mechanics. Physics textbook. Wiley, 2008.[4] J.G. Leishman. Principles of Helicopter Aerodynamics. Cambridge

Aerospace Series. Cambridge University Press, 2006.[5] M.A. Johnson and M.H. Moradi. PID Control: New Identification and

Design Methods. Springer, 2010.[6] R.P.G. Collinson. Introduction to Avionics Systems. SpringerLink :

Bucher. Springer London, Limited, 2011.[7] http://github.com/akharsa/qpid.[8] H. G. Phakatkar. The theory of machines and mechanisms. 1. Nirali

Prakashan, 1987.


80

Embedded System to Monitoring and Control Irrigation System in Real Time - Integro

Bruno Muswieck², Rafael Vieira, Ronaldo Laguna

Research & Development Dept. Eletroeste Tecnologia & Automação¹

Uruguaiana, Brazil [email protected]

Frederico Soares¹, Jonathan Behrens¹

Electrical Engineering Federal University of Pampa²

Alegrete, Brazil [email protected]

Abstract — The present paper proposes a new tool for

farmers to manage their irrigation system. This tool, Integro, is

an embedded system developed for the rural application needs.

The Irrigation System is based on many Pump System which is

located far from the farmhouse. The Integro brings the

monitoring and control of the Irrigation System to the farmhouse

through a Wireless System Network (WSN). Besides, the device

provides automation, security and protection for the users and

system. The rural application imposes severe problems in any

electronic equipment connected to the power line, like lightning

and overvoltage, as shown in the results section. The paper

presents the main characteristics, important requirements,

methodology used in the development, hardware and firmware

architecture and results of the field tests and the first phase of

commercialization.

Keywords — Embedded System; Irrigation; Real Time;

Monitoring; Security; Automation; Electric Protection;

Telemetry; Wireless System Network; Agriculture; Pump

System; Irrigation System.

I. INTRODUCTION

The rice has played a strategic role both in the economic and social. Cultivated and consumed in all continents, is distinguished by the production and cultivation area. It has been grown about 150 million hectares and it has been produced about 590 million tons each year worldwide, which more than 75% use some irrigation system (IS) [1]. According to the Food and Agriculture Organization (FAO), Latin America is the second largest producer and the third largest consumer of rice in the world [2].

In the last two decades, several studies aimed at improving the rice production processes have been developed, mainly in the aspect of environmental impact and energy efficiency. However, the themes of remote automation and security of these systems have been poorly addressed in these studies.

In large farms, one of the greatest difficulties encountered by producers was a large distance between the farmhouse and pumping stations (PS). To perform any operation, identify gaps and read some variables, the operator needs to be inside of the PS control room, which can often become dangerous due to lack of technical knowledge or any equipment failure. Moreover, due to the high cost of equipment and the distance,

the PS becomes vulnerable to theft.

In summary, the main problems caused by the PS distance are:

• Lack of automation and protection;

• Lack of security against theft;

• Lack of constant monitoring of the electrical variables;

• Difficulty of identifying system failures;

• In case of failure, the reestablishment of the system becomes slower and can impair the production.

Aiming to minimize these problems, we developed a solution that combines remote automation, electrical protection, telemetry and security against theft in a single device: the Integro

®1. The Integro is an electronic device that aims to achieve the integration of all components of the IS. It allows monitoring and control all the IS variables directly from the farmhouse with a simple interface and wireless communication, eliminating the problems caused by distance from the PS.

This paper presents the methodologies used to develop the Integro, along with the main results of the application. In Chapter II the system is presented. The philosophies of automation and protection are seen in Chapter III. The fault history and the question of safety are addressed in Chapters IV and V. The levels of Integro communication system are presented in Chapter VI. Finally, the results are presented on Chapter VII and the conclusion section.

II. THE INTEGRO

A. The System

The main objective of the Integro system is the integration of control, monitoring and security in a single device. In order to fulfill this requirement, the system has one Integro installed at each PS that forms the IS. This Integro is called Integro Pumping System (IPS). It is responsible for controlling, monitoring and security of the PS. But beyond local control, the system still has distance control. This is possible because of the Integro which is installed at the farmhouse. This Integro is called Main Integro (MI) and it is responsible for bringing together the control and monitoring of all Integros installed on

¹ Integro: Integration + Agriculture


81

the network. Figure 1 explains the whole idea of the Integro in the IS.

Fig. 1: Integro in Irrigation System.

The MI is the central part of the network. It provides real

time information, status, control and monitoring of all the IPS. The wireless network (WN) is based on radio transceivers that establish the channel for exchange data between the Integros. The maximum range between two Integro is 8 km as tests indicate. But even if this distance exceeds the radius of 8 km, it can be increased using directional antennas with higher gains or array of antennas.

The MI consists of four electronic boards, a stationary battery, to ensure the operation when a power failure occurs, a siren which is triggered when an IPS has the alarm triggered, an omnidirectional antenna, a transformer and two ceramic fuses.

Furthermore, the IPS is where most of the automation occurs. For this, some additional features are required in relation to MI. In order to get the motor drive control, to monitor the lack of any phase in the system and check the security sensors, the IPS has one board additional compared to the MI. This board is dedicated especially to reach the above objective. For that, it is connected to the motor drive (normal or variable frequency inverter), to the three-phase power line and security sensors (magnetic sensor and/or vibration). In addition, the IPS has also an electrical transducer which performs the measurement of electrical values and records them in its memory. These values are accessed by MI and informed to the user in real time. The IPS has also a siren, a stationary battery, a directional antenna, a transformer and two ceramic fuses.

The place where Integro stays, the rural area, has serious problems on the transmission lines, quality of the energy, loss of power, storms and lightning. The energy of the farm is delivered by long transmission lines, and then voltage swing is normal when the irrigation of the farms is working. Also, the transmission lines sometimes do not have the necessary maintenance that they should have. In stormy weather, strong winds knock old poles down which cut the power of the farms, as a result the farmers can spend even a week without power. Furthermore lightning in farms cause serious problems because of the open terrain and the transmission lines are really susceptible for lightning strikes that will transfer the energy to all the equipment connected to the power line. In

addition, we know that every farm has already had damaged equipment that are connected to the power line. So all these problems of power supply have been taken into consideration during the design phase which led us to PB and to protect other boards.

Finally, Integro is a strong equipment and it has great autonomy, designed to withstand the difficulties imposed by the application in rural areas. Its external structure is impact-resistant, protecting the electronics against the ingress of dust, water jets in angles up to 60º from the vertical and complete protection against contact. Its interface buttons are resistant and able to withstand mechanical stresses of higher intensities. The Integro can be considered as a tool that facilitates the farmer's life, increasing the safety and reliability of his IS.

B. Development

Today the development is looking for ways to shorten the time to market of the products and Agile methods are helping developers teams to achieve this. The development of the Integro uses some Agile methods and others not Agile because the authors believe that each team should use the methods that most fit for the team itself.

The bottom-up and top-down approach are used. First, the system requirements are determined, top-down. Second, the system was spread in small modules enabling the team working in parallel at the same time or in different modules. The modules are divided in tasks, each one is identified by the subject, priority, team member, initial and final date and complexity. After the module is ready it is integrated to the system, following the process on Figure 2 (a).

The same principle is used for hardware and firmware (HaF), Figure 2 (b) and (c) respectively. For the hardware board requirements are determined, the tasks are established, and when the electronic circuit cannot be reused from previous project, it is simulated and or prototyped, so when the module is finished one board is manufactured for validation, in the end if the board passes for the previous stages, the final board is achieved. The firmware follows similar methodology, but during the tasks and validation, definitions of the tasks are created, so it can be spread and change the task phase. After the module is done, it is integrated to the main firmware.

Fig. 2: Development: (a) HaF; (b) Hardware; (c) Firmware.


82

The division of the system in separate board shows other advantages, for hardware, it will accelerate the maintenance and reduce the cost of replacement of the boards. For firmware, it will split the processing power and development as well, once that the necessary boards have its own microcontroller (uC). The hardware part is compost:

• Main Board (MB): general control of the system, which takes care of the user interface, WS, real-time clock (RTC), memory, acquire information from other boards and system actions.

• Expander Board (EB): the input and outputs of the system. The inputs have AC, DC and 3-phase channels. The output relays acts in the controlled system.

• Protection Board (PB): provides AC energy for the power management board which consists in different types of protection against overvoltage and lighting [3].

• Power management Board (PmB): controls the energy of the system. It measures and charges the backup battery, selects the energy source (mains AC or battery), checks the system fuse in PB and provides status information for the MB.

• Electrical Transducer (ET): this product provides for the system the electrical variables. The MB is responsible to acquire this information.

• mRadio: this product provides the wireless communication for the system and the MB builds the wireless network through it.

The MB, EB and PmB have their own uC. The use of three uC enable the system to be more flexible and divide more tasks for the development team and decrease the processing in the uCs. On the same idea, the specific hardware could be built and tested faster. On the field, this method enabled the Integro to have an easier maintenance, because only some tests are needed to find the problem and replace the damaged board.

The firmware are programming in C language. Libraries were created for each module and one firmware for each board that has its own uC. These modules enable the team to develop individual libraries and the final step for merge all in the final program. But even in this method a plan must be done when the individual libraries were built, they need to have global variables or return of functions to exchange information between them for controlling the modules, as it is shown in Figure 3. As the MB has several tasks to do, the program must be in real time but instead of using a real time operation system (RTOS), all the firmware functions do not block the program or the tasks that need to spend time waiting for another response e.g. radio response, it will not remain in this loop response and it will go to the next task and after return [4][5] to complete the loop response. Some tasks that have higher priority can block others through the global variables shared between them. In this way, Integro can perform the necessary tasks running at 8 MHz.

Fig. 3: Libraries Data Communication

III. AUTOMATION AND PROTECTION

The reliability of the IS depends, fundamentally, on a good strategy of automation and electrical protective equipment. In conventional systems, many components (various manufacturers) may be used to accomplish the automation and ensure protection of the electrical system. This diversity increases the possibility of failures and defects hindering the diagnostic and maintenance equipment.

In conventional systems, automation is achieved by timing relays, which are configured to ensure that the system does not operate at peak time², and also when there is returning water in the pipes that the motor won't starts, preventing any mechanical component is damaged. The protection of electrical equipment intended to mitigate the consequences of possible surges, short-circuit or overcurrent. The origin of the problems can be external: lightning, failures in transmission lines or human errors, or internal: equipment failure or poor quality of drivers.

The Integro add automation to the control and monitoring of the irrigation and has numerous special features that make it a reliable and secure. The IPS was developed with redundant logical to the motor driver. An example is the confirmation of the execution of the motor on/off command, verifying an AC input, relay and current measurement [6]. Moreover, the Integro still has two main types of control: Automatic or Manual. In this two types of control there are: time of the returning water (time relay) and time for power cycling, which consists of a time after the power line returns. However, unlike the manual mode, the automatic mode controls the peak hours, preventing the engine from starting on time where there is higher power consumption, and also when the power utility charges a higher price of energy. In addition to the automation performed, Integro also makes the electrical protection of the IS. This electrical protection is extremely important because its purpose is, among other things, prevent equipment damage. Below some protection items that Integro owns and its operations:

• Phase Loss: Identifies when there is a loss of phase through an input AC where EB is connected in 3-phase supply. The Integro generates a fault that stops the motor and does not allow it to be switched on again until the 3-phases became normal.

• Control of High and Low Voltage (Relay of minimum and maximum voltage): Identifies when the three-phase voltage is too low or too high using electrical measurements that are provided through the ET and also taking into account the values of High Voltage and Low Voltage that are preconfigured in the Integro.

² Peak time: time chosen by the power utility, based on three hours, within exception of Saturday, Sunday and holidays, when happens peak of power consumption. This definition is done based on the power utility curve. On the peak time the energy costs are higher than the non peak time costs. On this way, its normal to shutdown the irrigation system on the peak time [7].


83

Thus when the values are out of the range, a fault is generated and motor will starts again when the voltage came back to the range.

• Control Overcurrent (Thermal Relay): Indicates the occurrence of motor overload. In order to identify overcurrent, Integro uses the readings of electrical values held by ET. Thus, when an overload is identified, a time is set according to the level of the current, taking into account the nominal motor current. A time is generated to cooling down the motor before turn on again the motor.

• Control attempts to restart the motor in automatic mode: Protects the system with respect to restart the engine several times after the occurrence of a failure. After stopping the engine, 3 times because of the failure, the Integro block the motor drive, forcing the user to check the problem.

• Prevent starting the motor when the water is coming back (Relay Time): Whenever the motor is shut down, either by failures, control peak hours, or even by a user command, there is a time that the motor can’t be restarted. This is time for the return of the water that is in the pipeline. Furthermore, as Integro has a battery, even in the event of a power failure, this time continue to count. This ensures the farmer that the engine will shut down only the time required for return of water, thereby avoiding the waste of time.

• Energy payback time: Controls the waiting time necessary to stabilize energy when the energy returns. Generally when the energy returns occurs voltage fluctuations and this could cause damage to electrical equipment. To solve this, the Integro has a timer that is reset whenever there is a return of energy. After spending that time, the motor is allowed to start.

All these shields serve to decrease the incidence of problems related to electrical equipment damage that composes the IS. This also reduces the time and expenses for maintenance and repairing the damaged equipment and also helps to diagnose the origin of the problems. Furthermore, the user can access these failures through the MI at farmhouse.

IV. FAULT HISTORY

When failures occur in a PS, the time that the failure occurs is not known, even the order of occurrence and the main reason of the failure. This hinders the ability to diagnose the problem more quickly and also let it difficult to know whether the failure was mechanical or human nature. In consideration of this, Integro has a history of faults, alarms, and RTC, telling the operator the date, time and the order in which they occurred. This history is divided into categories of faults and alarms. The MI, for example, has a history of alarms related to security, hardware failures, and problems in RTC. In the case of the IPS, it has failures of the PS including electrical faults and problems with the peak hours and the MI categories. In addition, MI has the facility to be able to access

the fault history of other IPSs, then, the operator does not need to go to the place where the PS is.

V. SECURITY

A PS is often a target of theft, because it has high value equipment such as: motors, transformers and large amounts of copper. Furthermore, because the distance between the PS and the farmhouse, a human security scheme can be very complicated, expensive and inefficient.

To prevent the PS violation a magnetic sensors are used at the main door. To protect the external equipment (transformer and copper cables) a vibration sensor is used, which this sensor was fully developed by the R & D sector of Eletroeste. It is based on the accelerometer in MEMS technology and its sensitivity to vibration can be adjusted for different types of applications.

Even when the PS is out of power, the security system continues to monitor the sensors Integro through batteries. If the communication with the farmhouse is interrupted or because of a broken antenna or the radio or IPS shutdown, the security system operates. The firmware Integro also possess logical that prevent system crashes, thus increasing their reliability.

The Integro has two user levels, i.e. two passwords, one that provides access to the most basic functions, such as on/off motor, on/off alarm, and another that allows you to configure more advanced system features. In this way you can prevent people from access and change the device settings and if a user without knowledge of the password tries to access it, after 3 failed passwords Integro will trigger the alarm.

VI. COMMUNICATIONS

A. Telemetry

The Integro has a WN that enables remote monitoring and control of the IS. The Telemetry provides quick action of the operator in case of failures or other contingencies of the IS, while it still allows all transactions in the system be made directly from the farmhouse. Furthermore, the cost of fuel, used in shifts, is reduced.

The communication between the PS and the farmhouse is done by radio frequency (RF) through the mRadio. The mRadio is a device designed exclusively to meet the characteristics of the application and market (target price). The information is sent only after being encapsulated in a robust and highly reliable proprietary protocol.

B. Board Communication

On Chapter II the boards were described, which the boards work based on their own tasks and they need to exchange information between them, Figure 4 shows the board network. The MB has the main control of Integro, so all the information from other boards must be known by MB. But to allow this, more than one physical and protocol layers are needed as can be seen on Figure 5.


84

Fig. 4: Diagram Board Communication.

(a) (b)

Fig. 5: (a) Physical Layers. (b) Protocol Layers.

The physical layer, Figure 5(a), starts by the boards

communication, where data are exchanged between the boards. Next layer the MB obtains the data from the electric transductor. Following, through the Integro I/O, the control and monitor of the motor driver is done. For last, the WN layer connects the MI to other IPSs, enabling the MI monitor and control the IPSs.

The protocol layer, Figure 5(b), starts by analog and digital circuits to pass voltage level and status. Next layer is the I2C protocol used to connect the MB, I2C master, to its RTC, EB and PM, all I2C slaves. After that, the Modbus protocol is used by MB to obtaining data from electric transductor. Finally, the MI communicates to other IPSs using a proprietary protocol developed by Eletroeste.

C. User Interface

One of the main project requirements was to present a simple user interface and on the same time robust. This justifies mainly on the type of work done on farms, brute workforce, and the fact of the users still do not know how to work with electronic equipments, the interface can be seen in Figure 6.

Most of time the farm owners are not the Integro user, normally it is used by the farm manager. When Integro is used on the rice harvest, the manager has the possibility to obtain fast response on the IS and he has more time to perform other tasks. Another point is the users' security, once the Integro is

the one that controls the motor driver, any dangerous problem that happens, like contactor or capacitor explosion, the user will be safe and he will not be injured. In Figure 7 is presented the IPS connected to Motor Drive.

Fig. 6: User Interface.

Fig. 7: IPS connected on Motor Drive.

VII. RESULTS

As mentioned in the previous sections, in cases of failures, the Integro allows faster operator response without going to the PS. Besides, during the test period it was possible to determine improvement for the farmer in terms of precise and fast diagnostic of failures (power line, PS or Integro itself). These failures generate Integro alarms enabling reduction of the time to reestablish the system. Another point is the precision of the failures that lead the operator to coordinate the maintenance team with important information about the state of installation and in the types of failure that result the call. Within this information, the maintenance team can forecast the necessary procedures for the maintenance before going to the farm.

The harvest 2012/2013 lead to at least two real results:

• The Integro security system worked in the field. Robbers tried to steal the electric equipments on the PS. But when they entered in the motor driver house, they were caught by surprise from the Integro and its siren starts to ring. On a despair action, they tried to turn off the Integro, but due to Integro strength, they did not succeed, then they left the place. In this situation the Integro protects the farmer against a loss of U$ 18000 in equipments and paying the Integro investment in less than one harvest.


85

• The Integro get better automation. The Variable Frequency Driver (VFD) was controlling the peak time and it was found a failure on the VFD’s software and hardware. This failure generates random pulses that turn off the VFD and due to the mechanical installation, when the motor is turned off, it is necessary to wait 40 minutes to turn it on. Overwhelming this problem, the Integro was configured to control the motor and in this situation the farmer has not had any problems of unexpected stops.

The economical side of the Integro when considered a farm that the PS is 5 km far from the farmhouse and the roads have no good accessibility to the PS.

The harvest last around 100 days and it is estimate that the PS is visited at least once per day to be certain it is working properly. Around this situation it is possible to calculate the costs of an operator with three different vehicles. The table I shows the estimate fuel cost during the harvest and the risks that the operator is exposed to. For these costs the following information is taken in account:

TABLE I. ESTIMATED COSTS WITH FUEL DURING THE HARVEST

Type Cost Risk

Car US$ 150 • Roads in bad conditions; • Bad weather; • Direct contact with energized

equipments.

Motorcycle US$ 60

Tractor US$ 260

• Gas equal to US$ 1.45/liter and Diesel equal to US$ 1.03/liter.

• Consumption: 10 km/l of gas for car, 30 km/l gas for motorcycle and 6 l/h of diesel for tractor.

• The costs of vehicle maintenance are not used in this calculus.

With the Integro these costs and the risks can be reduced to zero. Besides the response becoming fast to execute an operation and guarantee the users’ security, the economy for the farmer can be up to US$ 260 for one harvest.

The Integro statistics are divided in two steps: prototype time, installed on three locations and commercial time (harvest 2012/2013), installed in three locations.

In the prototype time six Integros were installed as three MI and three IPS and in the commercial time more eight Integros were installed as three MI and five IPS. The table II presents the relation of damaged boards and theirs main causes:

TABLE II. STATISTICS OF DAMAGED BOARDS AND MAIN CAUSES

The statistics show that the main case of the damages was lightning. Some actions that we have taken to increase the equipment reliable were: to reduce the protection earth resistance and increase the surge discharge capacity of PB. Another point is that the fuses and PB present the higher failure rate, to reinforce the severe problem imposed by rural application.

CONCLUSIONS

We have faced to through some difficulties like any other embedded system on its firsts time on the field. But the great difficulty was the Integro connection to the power line, because of the complications that the application imposes, lightning and severe voltage oscillations. Nowadays Integro have been installed in several configurations and motor drivers. It has shown a flexible and easily adapted equipment. We can affirm that Integro has reached the initial requirements to be a generic system to control the IS.

The beginning of Integro was in 2005. Since 2009 Integro prototypes have been working and they are being improved. Until the beginning of the 2012/2013 harvest, Integro had 13000 hours of tests in the field and in 2012/2013 harvest it was put on the market. Since then 13 equipments have been in the field and they have been improving the IS of the farms, reducing costs, such as working hours and fuel, as a result starting a new type of management harvest.

We will connect the Integro to the Internet in the future. We have already thought about the hardware for the internet connection which will communicate to a dedicate Server. Then the farmers will have a data logger of their IS never seen before. Secondly, we will make a connection to the VFD to be able to have all the control of it. Then we will improve the distance of WN implementing the repeater option of the protocol. Finally connect a flow meter to Integro in order to provide the flow and volume of water used by the IS.

REFERENCES [1] Empresa Brasileira de Pesquisas Agropecuárias - EMBRAPA.

Importância econômica, agrícula e alimentar do arroz, 2010. Avaliable at <http://www.cpact.embrapa.br/publicacoes/ catalogo/tipo/sistemas/arroz/cap01>. Acess on 08/03/2013.

[2] Food and Agriculture Organization - FAO. International Rice Commission - Plant Production and Protect Division, 2013. Avaliable at <http://www.fao.org/agriculture/crops/core-themes/theme/treaties/irc/en/>. Acess on 08/03/2013.

[3] R. B. Standler, "Protection of Electronic Circuits from Overvoltages", 1sr ed., Dover Publications, Inc, 2002.

[4] A. C. Shaw, "Real-Time Systems and Software", 1st ed., John Wiley & Sons, InC., 2001.

[5] R. Williams, "Real-Time Systems Development", 1st ed., Butterworth-Heinemann and Elsevier, 2006.

[6] C. M. Franchi, "Acionamentos Elétricos", 1st ed., Editora Érica Ltda, 2007.

[7] Agência Nacional de Energia Elétrica - ANEEL. Biblioteca Virtual - Glossário de Termos Técnicos, 2012. Avaliable at <http://www.aneel.gov.br/>. Acess on 08/03/2013

Boards Trouble – Prototype time Trouble – Commercial Time

Lightning Overvoltage Others Lightning Overvoltage Others

MB 1 - 1 1 - 1 EB - - 1 - - 1 PmB 1 - 1 1 1 - PB 5 2 1 1 3 - LCD - - 1 1 - 1 mRadio 1 - 1 1 - -


86

Real-Time Image Processing System Based on

Android Embedded Operating System

Andres Felipe Barrero Arce

Faculty of Technology

Distrital University Francisco José

de Caldas

Bogotá, Colombia

[email protected]

Edwar Jacinto Gómez



de Caldas

Bogotá, Colombia

[email protected]

Fredy Hernán Martínez Sarmiento



de Caldas

Bogotá, Colombia

[email protected]

Abstract — Technological advancement has made that the

image processing reaches a critical role in many applications,

from the astronomical field, robotics and computer vision, to the

field of entertainment. As the smartphone industry grows

rapidly, smartphone applications are becoming more oriented to

these specialized niches. In this paper the performance of high

level programming is analyzed with respect to image processing.

Five image processing filters are applied to different images in

soft real-time using a development platform running on an

Android OS. The efficiencies are compared with respect to the

quality and performance of the filters. The results show the

ability of the embedded system and the programming with high-

level tools to solve problems in real time.

Keywords— Android; embedded system; images; real-time

processing.

I. INTRODUCTION

he set of techniques and processes used to discover or to highlight information in an image using as main tool a

digital system is known as digital image processing [1]. This concept can be extended if it is focused on new technologies, which use embedded systems, and the clearest examples are the smartphones and tablets. Real-time imaging systems typically process a stream of digital images, analyze the images and then control some part of the system based on the results of the analysis.

Considering this, digital image processing has a great relationship with digital signal processing, knowing that the latter is the general way of processing any type of signal, and being images, one of them. This is particularly important in control applications [2], [3].

With this information, the idea of performing digital processing of images with an embedded system based on the ARM11 microprocessor is formulated, processor that is used by the development system Real6410. Unlike a commercial smartphone, the development system includes several input and output ports that allow us to interact with the card. The Android operating system was selected due to its versatility and compatibility with these types of electronic devices [4]. This operating system controls a mobile device just as Mac OS, Windows or Linux control a desktop computer or laptop [4],

and most importantly, it is an open platform, which contributes to the easy development of applications of different types. The interest is to develop a simple application, through the implementation of five basic filters, which allow to observe the real-time processing capacity of the embedded system.

II. ANDROID AND EMBEDDED SYSTEMS

An embedded system is a computerized electronic circuit that is designed to perform a specific task [5]. The embedded programming allows to develop instructions for microcontrollers that perform specific functions, which makes the tedious tasks more simple and practical. Therefore, these systems are present in almost all the objects that surround us such as cell phones, pocket planners (Palm), the fuel injection system, a camera, etc.

With embedded systems, 10 years ago we could ask if it was necessary to use an operating system in an embedded system. Today, with the development of these systems we do not need to ask the same, now the question is, what operating system do I choose? and which of them optimizes the system that I will develop? On the market can be found operating systems for embedded systems among which are OS/2 (eComStation), Windows CE, Windows Embedded Automotive, OSEK, FreeBSD, Android, Symbian, etc.

Each of these systems are found in various equipment like ATMs, washing machines, microwaves and other. For our specific purpose, the most practical and best resources is Android [6], since this system is still a small Linux distribution.

Android is a source of software for mobile devices that includes an operating system, middleware and key applications. The Software Development Kit for Android (SDK) provides the tools and Application Programming Interfaces (APIs) necessary to begin developing applications on the Android platform using the Java programming language [6]. Android is able to manage all the resources of a mobile device to be used in an optimal way [7], comfortable and seamless, so that users can maintain communication without problem using the hardware resources it provides. The Fig. 1 illustrates layered each components that are part of the internal architecture of Android [6].

T


87

Fig. 1. Different layers of the Android OS architecture [6]

In its architecture, the base consists of a Linux kernel, which is used for basic services with which account the mobile device [8] as memory management, security, process management, etc. Following to the kernel, Android has two layers; an Android Runtime provides most of the functionality available in the core libraries of the Java programming language, and the libraries used by various components of the Android system, written in language C/C++, where you can find libraries like SQLite, handling graphics libraries for 2D (SGL) and 3D.

The next layer is the application structure where Android allows an open development platform for any developer with the ability to create rich and innovative application taking advantage of the device hardware, access information and run background services. Behind the applications are a set of services and systems which are [6]: 1. Views, 2. Content Providers, 3. Resource Manager, 4. Notification Manager and 5. Activity Manager. In the top layer are the applications which are included in the cell phone and include e-mail client, calendar program, SMS, maps, browser, etc.

III. IMAGE PROCESSING

Today, the digital processing of images is a very specific area of research in computer systems. The goals to be achieved are [1]:

a) Improving the quality of information contained in an image so that this information can be interpreted by humans.

b) The processing of data in a scenario through an autonomous perception machine.

If we recapitulate the reasons for these ideas, we must remember why we want to perform some processing of this kind. Formerly and for a long time, manipulate an image digitally was relatively a luxury that only a small group of specialists could have, because having access to computers that did this was quite complicated, and only were in laboratory

equipment [9]. Now, with the combination of powerful desktop machines and specialized software, is fairly easy to perform these tasks. Other important thing is to scan an image is quite simple with acquisition tools as a scanner or digital camera.

With these great advances, applications are becoming bigger and better, leading to increasingly develop more and better processing algorithms that can be quite complicated at first, but with a good implementation is usually pretty easy. Typical applications include mapping, medicine, robotics, advertising, among others.

Before processing any image, the first step is to scan it, and this basically consists of an optical system and the digitizer, by which the visual image is converted into electrical signals to be processed [10]. Already digitized, images can be sorted by size, color palette or dimension (2D and 3D images).

In this paper are referenced 2D images, which are square or rectangular images, whose pixels (x,y) represent square regions. The columns are represented by the y-coordinate and the x-coordinate representing the rows. The pixel (0,0) is located in the upper left corner of the image [9]. A digital image of MxN pixels is a function [10]:

(1)

When an image is scanned, the sensor sends a value within a range. This value can be either a single value (gray scale) or a vector with three pixel values (RGB) corresponding to the intensity of red (R), green (G) and blue (B). This scale has a range combining discrete and get all visible colors. The grayscale images with only 2 colors: white and black (0 and 1, respectively), are called binary images. This color quantization process is called quantization.

Fig. 2. Quantification in grayscale [7]


88

IV. DESIGN AND DEVELOPMENT

In this section, the hardware used, the application design and the development process undertaken within the application is clearly illustrated.

A. Hardware

For the design of the application, the development board Real6410 of CoreWind (Fig. 3) was used. The platform was chosen given its availability, however, it is intended to develop a software for any hardware with Android OS. Other platforms that are being evaluated for use in autonomous robots include the Samsumg Galaxy Ace and Zopo ZP900 smartphones.

This card is designed with Core6410 processor, which integrates a microcontroller Samsung S3C6410 (ARM11) 667 MHz, has 256MB of SDRAM, 1GB Nand Flash memory, RTC, audio processor (DSP) and network. The card supports Linux 2.6.28 operating system, Android 2.1 and Windows CE 6.0, with all relevant drivers, which makes this card ideal for applications related to communications and multimedia [11].

Fig. 3. Development board Real6410 (ARM11, 256 MB mDDR SDRAM, 1 GB Nand Flash, Android 2.1) [9]

The S3C6410X is a 16/32-bit RISC microprocessor, which is designed to provide efficiency at low cost, low power consumption, high performance applications and solutions for mobile phones. The development board also includes hardware accelerators for high-performance tasks such as video processing, audio processing and 2D graphics.

B. Design

For efficient design of the application, two working criteria were defined: source of the image and interface design. For the first criterion, to capture the images in two ways was determined: (1) choose the image to be processed directly from the development system's memory, choosing it from the gallery, and (2) capture the image using a camera connected to the development system. Both options are required in other research projects of the group (robotics).

Regarding the design of the GUI, it had in mind considerations of friendly interaction and functionality. The analysis looked at modes of operation which covered in different ways capture and processing the image functions. For example, in the initial screen, buttons to obtain the image with

the corresponding drawings of camera and gallery were placed, simplifying the most of user interaction.

Fig. 4. Block diagram of the internal structure of the development system Real6410.

The GUI design was developed in DroidDraw, an open source WYSIWYG User Interface (UI) editor for Android, from which the basic structures for the design of all the graphical environment was generated, which is then link up with the processing code in Eclipse, another editor, a multi-language software development environment, in this case for the development of Java code.

The GUI was implemented in Eclipse with XML, and Java was used to implement the functionality and the filters for the images (Fig. 6).

C. Image processing

Once the image to be processed is acquired, the next step is to apply a certain filter to modify it. Filter is called the process by which a given signal is changed (in this case, each pixel of the image) such that the amplitudes of the components (RGB) are eliminated or changed [9]. The filters are also used to restore a signal when the signal has been distorted in some way.

Given this definition, some basic filters to the selected images were applied. In geometric identification processes in images, one of the first modifications made to the images is its conversion to grayscale. This is the first filter implemented for evaluation, and for this the equation of luminescence was used [10]:

Y = (0.299*R + 0.587*G + 0.114*B) (2)

Where R, G, and B are the values of each pixel and Y is the new filtered image.

The second filter chosen allows to visualize each RBG components of the image. This transformation is also very useful in identification processes. The calculation is much


89

simpler, it is only necessary adjust to 0 the unwanted components of the image.

The third filter is color inversion. In this case it is to transform each pixel color in its inverse. RGB channels can contain values from 0-255, where 0 is the darkest value, and the value 255 the lighter or illuminated [10]. Therefore, an inversion to each pixel must be done, so each lit pixel is dark and vice versa. For this, what is done is subtract 255 to each pixel value as follows:

R = 255 – R (3)

G = 255 – G (4)

B = 255 – B (5)

Where R, G, and B are the values of each pixel [9].

The fourth filter selected is called "Blur", because the blurring or smoothing applied to the image. It is actually an averaging of values, and is used in addition to soften and blur the image to remove noise that contains the image. Its implementation consists in generating a mask or "kernel" [9] for each pixel, in order to change its value. In the particular case of this filter, each pixel is divided by 9, making a slight blurring in the image.

The last filter chosen is called Sobel-Prewitt filter. The most important function of this filter is to find the edges in the image depending on the direction or position. In the implementation of this filter, the edges of both the x-axis as the y-axis were found [10].

Sobel-Prewitt filter is based on the gradient of the pixels of the image (Fig. 5). Analyzing the behavior of the gradient can be detected edges according to the spatial derivatives of the image. These derivatives are calculated by convolution operators. Convolution is a sweep applied without altering the two operands, in this case the kernel (now in the form of a matrix) and the original image [9]. The result of this swept or interaction will be the filtered image.

The kernel used in matrix form on the x-axis is:

-3 0 -3

-10 0 10

-3 0 3

And in the y-axis is:

-3 -10 -3

0 0 0

3 10 3

In these matrices the row or column with 0's is responsible for dividing the image. By calculating the convolution, the result defines the location of the edges.

Fig. 5. Sobel-Prewitt filter example.

These filters were implemented entirely in Java, without the use of libraries for image processing. This feature allows defining the implementation of the tool as soft real-time, under the limits that confers a high level language like Java. It also allows differentiate it from other existing applications to image processing.

V. RESULTS

The initiation of the application and selection of the filter looks like this:

Fig. 6. First application screen with filter selection options.

To evaluate the result of the grayscale filter, inversion filter and separation of components of the image, the test image shown in Fig. 7 was used. This image was designed with colors that are part of each component. Furthermore, the combination of these colors produce white, i.e. pixels with value 255. The dimensions of this image are 305 pixels wide and 321 pixels tall and is in JPEG format.


90

Fig. 7. First test image.

The result of applying the gray scale filter to the image in Fig. 7 is shown in Fig. 8.

Fig. 8. Output generated by the gray scale filter

Fig. 8 shows the transformed image. The image shows a single hue with visually identifiable content. From the user's perspective, it is very difficult to detect delays caused by image processing, since the response is almost immediate. Response times are measured in the laboratory between 0.2 and 0.3 s, even when the system is subjected to parallel operations in the background.

Fig. 9 shows the result with the inversion filter. The figure shows the inverted colors as expected of the filter. In particular, is observed as white becomes black. As with the grey scale filter not seen delays in the running time, and the average processing time measured in laboratory is maintained in the range of 0.2 to 0.3 s.

Fig. 10 shows the result with the separation of components filter. The figure shows how each component is isolated, by putting the other pixels in black. Also, as with the previous filters, it is difficult for the user to identify delays in the running time. The average time in laboratory is the same.

Fig. 9. Output generated by the inversion filter

Fig. 10. Output generated by the separation of components filter

Finally, to evaluate the result of Blur and Sobel-Prewitt filters a second test image was used (Fig. 11). The dimensions of this image are 400 pixels wide and 282 pixels tall and is in JPEG format.

Fig. 11. Second test image

Fig. 12 shows the result with the Blur filter. The figure shows a new image softened and blurred. In this case, the system had a few seconds delay, 1 to 1.3 s when run individually, and 3 s when there are other heavy tasks in the background.

Fig. 13 shows the result with the Sobel-Prewitt filter. The figure shows a new image in which edges have been detected, and the image was somewhat softened. As in the previous case,


91

the system had a few seconds delay (1 to 3 seconds) depending on the tasks in the background.

Fig. 12. Output generated by the Blur filter

Fig. 13. Output generated by the Sobel-Prewitt filter

In the laboratory several tests were performed, both with images stored in memory as directly captured by the camera. The tests included pictures of different sizes. In general terms, the grayscale, inversion and separation of components filters have no delays identifiable by the user (0.2 to 0.3 s), while the Blur and Sobel-Prewitt filters presented delays according to the image size and load applied to the system (1 to 3 s).

The application was also evaluated on a Samsumg Galaxy Ace smartphone (Qualcomm MSM7227, 800 MHz, ARM 11). Under similar conditions, a reduction in delay times of around

20% was observed. The shorter times are attributed to the increased capacity of the processor.

VI. CONCLUSION

In this paper a simple application with the intention to evaluate the ability of the Android OS for performing image processing in real time was developed. A program capable of applying a total of five filters to images previously stored in the system memory or captured by a digital camera was created. The selected filters are of interest because of their potential use in visual identification for autonomous robots. The great contribution of this research lies in demonstrating the possible use of the system for analyzing images in soft real-time without the need for additional libraries, such as OpenCV, reducing hardware requirements and the overall execution time. The next step in this research is to estimate the exact requirements of processing according to the size of the image to define criteria for use in real applications of real-time identification.

ACKNOWLEDGEMENTS

We wish to thank to the Laboratory of Electronics, Faculty of Technology, of the Distrital University Francisco José de Caldas for the advice regarding the management of the hardware used, and to Eng. Emmanuel Castillejos Villatoro, Optomecatronica Master, Center for Research in Optics (CIO) of the city of Leon, Guanajuato, Mexico for the advice with regard to the processing of images with Java.

REFERENCES

[1] Burger, W. and Burge, M. "Digital Image Processing: An Algorithmic Introduction using Java", 1st ed., Springer, ISBN 978-1846283796, 2008.

[2] Karungaru, S., Sugizaki, M. and Fukumi, M., "Biped robot walking control using image processing", ICCAS-SICE 2009, Fukuoka, pp. 4020-4024, 2009.

[3] Zeng, X., Zhao, G., Wang, Y., Wang, C.,and Wang, J., "Research on the Elevator Door Control System Based on the Image Processing Technology", 2010 International Conference on Electrical and Control Engineering (ICECE 2010), China, pp.1781-1784, 2010.

[4] Shanker, A., and Lal, S., "Android porting concepts," 2011 3rd International Conference on Electronics Computer Technology (ICECT), vol.5, pp.129-133, 2011.

[5] Galeano, G., “Programación de Sistemas Embebidos en C” 1ra ed. Editorial Alfaomega, 2009.

[6] Khomh, F., Hao Yuan, Ying Zou, “Adapting Linux for mobile platforms: An empirical study of Android,” 28th IEEE International Conference on Software Maintenance (ICSM), pp. 629-632, 2012.

[7] Polanco, M.; Taibo, B.; & Luis, J., "Android" El Sistema Operativo De Google Para Dispositivos Móviles”. Revista Negotium, 7, 79-96., 2011.

[8] Nagata, K.; Yamaguchi, S.; Ogawa, H., "A Power Saving Method with Consideration of Performance in Android Terminals," Ubiquitous Intelligence & Computing and 9th International Conference on Autonomic & Trusted Computing (UIC/ATC), pp.578-585, 2012.

[9] Burger, Wilhelm.; Burge, M., “Digital Image Processing An Algorithmic Introduction Using Java” 1ra ed. Editorial Springer, 2008.

[10] Gonzalez, R.; Woods, R., “Digital Image Processing” 3ra ed. Editorial Pearson, 2007.

[11] CoreWind, Real6410 Hardware Development manual, Ver. 4.0 (2011-1-23).


92

Microcontrolled based traffic monitoring system

Alberto Fernández1, Juan Chacón2, José Chacón3, Johan Carvajal4

Department of Electronics Engineering Costa Rica Institute of Technology

Cartago, Costa Rica [email protected]; [email protected]; [email protected]; [email protected]

Abstract— This paper presents the design and implementation of a traffic monitoring system, capable of gathering important information about vehicle traffic such as the number of cars that travel on the study road, car speed, the number of axles, time and date of the event for every car. The project was developed because of the lack of information about traffic circulation on the roads of Costa Rica and other Latin-American countries. For instance, the data obtained from the system can be used to know the traffic impact on a road network, allowing the prediction of future malfunction on the road and/or congestion events.

Keywords— monitoring traffic; microcontroller; data acquisition; FAT32; sensors technology; embedded system; host; device.

I. INTRODUCTION

Developed countries have developed technologies to create databases regarding road traffic behavior, allowing them to make decisions on road infrastructure projects such as new road construction, traffic signals installation and road congestion analysis. For this reason, we designed a traffic monitoring system to determine the number of vehicles circulating on a road, their speed and number of axles. Based on this information, it is possible to classify the traffic that travels on the road being analyzed. In addition, the system can determine congestion hours of the road because it records the date and time of the event.

Actually on the market there are different options on systems similar to the proposed such as those that use cameras and advanced data processing algorithms. Also available are technologies through the use of piezoelectric, inductive and valves sensors. The principal difference of these alternatives with regard to our system is that these technologies are used in fixed form due to its complexity of its installation, while our system is portable because it is used to perform studies on roads for a maximum time of 24 hours.

II. DESING SYSTEM

A. Block Diagram of the System

The system basically consists of 4 operation blocks. The first stage consists of the detection of the vehicle circulating

on the road; the second refers to the detection of the vehicle axles to determine the speed and quantity of axles, both stages use the sensors that will be further described. The third stage corresponds to a voltage coupling block between the sensors output voltages and the digital inputs of the fourth block on the processing system.

The Fig. 1 shows the block diagram of the project, it illustrates each of the system operation blocks.

FIGURE 1. THE BLOCK DIAGRAM OF THE SYSTEM

Processing module is the most relevant because it

processes the data and controls the USB communication as host and device.

The system has two modes of operation, mode of real time and data storage. If the user doesn't connect the computer, the system stores the data on a USB memory. Otherwise the user can get the data in real time or download the stored information. The two operating modes need the USB ports of embedded system. In addition, the sensors are connected to the processing unit using the general purpose ports (GPIO).

B. Sensors Technology

The system needs a sensor to detect the presence of a vehicle and two sensors to detect its axles. These sensors are in the Fig. 2. All sensors are commercialized by the company Banner Engineering.


93

Vehicle detection sensor is the sensor M-GAGE S18M. It detects big metallic objects, such as vehicles and trucks. The sensor works by means of magnetic distortion field generated by the appearance of a ferromagnetic material.

The S18M can detect changes in the ambient magnetic field

in all directions because the detection zone is three-dimension “x”, “y”, “z”, which allows the detection of vehicles within a radius of adjustable approximation. Also, the sensor was designed to minimize the effects of temperature swings and destabilizing magnetic fields.

FIGURE 2. SENSOR TECHNOLOGY USED IN THE PROJECT

The QM42 sensors are used to detect the axels with retro

reflective technology. They send a beam of infrared light of 880 nm (not visible). The infrared beam is constantly sent, if it detects a shaft this returns to the receiver located in the same package. The following table illustrates the specification sensors used [9].

TABLE I. SPECIFICATIONS SENSORS USED

Specification M-GAGE S18M QM42

Supply Voltage 10 - 30 Vdc 10 - 30 Vdc

Sensing Technology 6 levels until 3m

Output Response time 20 ms 1 ms

Operating Conditions -40° to +70° -40° to +70°

C. Sensors Location

Installation Diagram of the sensors in the road and a sketch about detection zones are shown in Fig 3. M-GAGE S18M sensor is built-in in the pavement, because it needs to be under the vehicle at the time of the detection. While sensors retro reflective QM42 are placed beside the road because these sensors need to be at the same level of the vehicle axles [9].

For obtaining the speed of a vehicle, we determine the travel time of its axis between two retro reflective sensors, with a defined distance between both of 0.6m.

FIGURE 3. INSTALLATION DIAGRAM AND SKETCH ABOUT DETECTION ZONES

D. Embedded System

In order to process the data and manage the system operation we used the embedded platform PIC32 microchip starter kit because of the platform high performance. The platform uses a PIC32MX795F512L microcontroller; therefore it works at a frequency of 80 MHz and utilizes an architecture 32-bit with 512 KB flash memory and 128 KB SRAM. Also, it has a GPIO unit (SPI, USART, I2C, CAM and USB ports) and RTCC [7]. The Fig.4 shows the functional block diagram of the microcontroller that is required in the system implementation.

FIGURE 4. MICROCONTROLLER BLOCKS USED IN THE IMPLEMENTATION


94

With the configuration of the RTCC module, the system gets the date and time of each event, so that it is required a 32.798 KHz quartz crystal for the implementation. Additionally, to the interface connection between the platform and sensors we used the Starter Kit I/O Expansion Board.

E. Voltages coupling circuit

We converted the output voltage of the sensor to the input voltage of the I/O ports of the embedded platform in the range of 0V-3.3V. Those circuits are described in the Fig. 5.

FIGURE 5. CIRCUITS ABOUT THE VOLTAGES COUPLING

III. IMPLEMENTATION

A. Programming of the firmware microcontroller

We programed each functional blocks of the microcontroller required by the system, including 2 USB Host and Device ports for communicating with the USB memory (Storage) and the computer.

To define the behavior of the microcontroller as Host or

Device, we used two buttons of the development platform for choosing the operation mode. Therefore in host mode, the microcontroller controls the sensors‟ logic and also stores the data processed by the system on a USB memory with FAT32 format. In this case, first the microcontroller detects the presence of a mass storage device (MSD), after it creates a file with .txt extension in the USB memory.

On the other hand, in device mode the microcontroller

closes the file with .txt extension and detects the computer connection. The user accesses that connection by using the USB connector Type Micro-AB for USB device connectivity. If the user disconnects the computer from the system, the microcontroller automatically sets the mode operation as Host. The communication protocol used in the Host mode was the Mass Storage Device (MSD), and for the mode Device was the Human Interface Device (HID). For programming operating modes we use the example "USB Dual Role - MSD host HID device" from "Microchip Application Libraries."

Also we configured the RTCC module for getting the date and time of the event. Therefore to calculate the transit time of

the vehicle between the retro reflective sensors were using the TIMER 1.

FIGURE 6. FLOW DIAGRAM ABOUT THE PRINCIPAL EXECUTION.

Initially, in the flow diagram shown, the bits

microcontroller configuration is established, as well as the initialization of the global and local variables. Variables Sw3 and Sw2 represent the button state of the embedded system. If the user presses the second button (Sw2), the system starts the USB Host mode. If the user presses the third button (Sw3), the system changes to USB Device mode.

The Fig. 7 shows the flow diagram for the logic sensor sub routine, which defines the behavior of the system according to the sensors state. This logic allows the system to count the number of axles and to estimate the vehicle speed.

FIGURE 7. FLOW DIAGRAM ABOUT THE SUBPROCESS SENSOR


95

B. Data visualization

The visualization software was developed using a high level tool. This software allows the user to explore all the results more clearly and using filters that help visualizing the order and the overall understanding of the data collected. The user can observe statistics of the traffic flow, the final number of cars that transit the road on a specific period of time, the average speed and a classification of the cars that pass over the system. Also this app allows to see what is happening in the system in real time, and also, the user can observe previous results stored on a flash memory.

FIGURE 8. VISUALIZATION INTERFACE

C. Prototype

A package for the prototype system was designed for the circuit and development board protection. The following figure shows the prototype of the system, and also it displays the interface for the sensors connection.

FIGURE 9. IMAGES OF THE SYSTEM PROTOTYPE

IV. PERFORMANCE

In order to check the performance of Vehicle Monitoring System, different tests were performed on the country's highway and roads on the Costa Rica Institute of Technology campus.

Through the TIMER 1 implementation on the embedded board, the system accuracy is adjusted in such a way it can detect vehicles with a minimum speed of 2 km/h and a

maximum of 210 km/h, this range is acceptable for vehicular traffic conditions in Costa Rica.

It should be mentioned that the reliability of the speed

detection by the system is given by the responsiveness of the sensors used (QM42 and M-GAGE S18M). Table 2 shows the performance of the sensors used, thus allowing defining the detection range of each technology.

TABLE 2. PERFORMANCE OF SENSOR TECHNOLOGY

Sensor Detection Distance (m) Output Voltage (V)

M-GAGE S18M

0,80 1,02

0,90 9,86

1,20 9,86

1,30 1,45

QM42

0,30 9,58

1 9,65

2 9,32

3 1,32

About the obtained detection distances in Table 2, it is

possible to deduce that by using the M-GAGE S18M sensor with a sensitivity level 5, allows the detection of a vehicle at a distance of approximately 90 cm from the sensor, which gives enough time to the algorithm to start the counting process and estimated speeds, as well as counting axles through QM42 sensors.

The system was compared to manual counting method, in order to define the percentage error in the counting function of vehicles. We obtained a 15% error due to the ability to detect the retro reflective sensors, considering that these sensors are located at the axis level.

Also, we test our system in a 24 hours experiment on a

major highway in our country, with high traffic; the data obtained is shown in the fig. 10. Is important to say that the highway was two routes, and every route had a breadth of approximately 4 m.

The information gathered shows the flow of traffic demonstrating the high traffic of vehicles on the road being analyzed. Using the number of axles it was possible to classify the traffic on the road by using the characteristics of the vehicle fleet in our country. Thus, defining the classification according to auto light, small truck, bus and large truck and trailers.

Finally, the average speed of the cars was 41.37 km / h and the total number of cars detected by the system was 4773 in the 24 hour test.


96

FIGURE 10. EXPERIMENTAL RESULTS OF THE 24-HOUR TEST

V. SUMMARY AND CONCLUSIONS

Through the application of this study, a system capable of determining the presence of vehicles on roads, speed, number of axles, time and date was developed. This system was design using the PIC32 microcontroller incorporated in the development board PIC32 Starter Kit. A sensor of magnetic field distortion to determine the presence of a vehicle on the road is used for the system design. This sensor responds to disturbance by ferrite materials. Furthermore, the axis count was determined by using retro reflective sensors pointing in the direction of the wheels of vehicles. We defined the detection range of speeds between 2 km/h-210 km/h and an error rate in detecting events by 15%.

The power supply section for the system was conditioned

by creating a power source capable of generating the required voltages from the national grid (120 VAC).

Finally, an interface was programmed using high-level

computational tool Visual C # 2010 with the aim of showing the information obtained from the system in a clear and orderly way.

The implemented system allows giving solution to national problems about the lack of information of vehicular traffic on

the roads. Using the information obtained from the system it is possible to analyze potential points of congestion, assess the burden of traffic and create a statistical database of vehicular traffic of Costa Rica for eventual studies.

In the future work, we might evaluate the replacement of retro reflective sensors for a more reliable technology in relation with the infrared detection, due to the error rate in the detection of the sensors used in this project.

Also we might define a platform with an embedded ARM processor in order to process the data obtained from the sensors and load them using 3G technologies to a server, to fully visualize the data in real time. The work team might consider the implementation of photovoltaic system self-sufficient to energize the electronic devices and thus not rely on the national grid.

REFERENCES [1] Di Jasio Lucio. Programming 32-bit Microcontrollers in C: Exploring

the PIC32. California: Newnes, 2010, pp 81-162.

[2] Ferguson Jeff, Patterson Brian and Bares Jason. Programing in C##. Madrid: Editorial Anaya, 2010, pp 102-199.

[3] V. Anita. AASHTO Guidelines for Traffic Data Programs. Florida, 2009, pp 21-63.

[4] R. Erickson. Fundamentals of Power Electronics, Second edition, U.S.A.: Kluwer Academic Publisher, 2004, pp 205-272.

[5] I.K.E Purnama. “Real time vehicle counter system for Intelligent Transportation System”. IEEEexplore.

[6] Microchip. Microchip Libraries for Applications. Avalaible: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en547784.

[7] Microchip. PIC32 microcontroller documentation. Avalaible: http://www.microchip.com/pagehandler/en-us/family/32bit/.

[8] National Semiconducter. LM317 datasheet. Avalaible:

http://www.datasheetcatalog.org/datasheet/nationalsemiconductor/DS009063.PDF.

[9] Banner. Information about the sensors M-GAGE S18M and QM42.Avalaible: http://www.bannerengineering.com/en-US/.

[10] Nallig Leal, Esmeidel Leal and John Branch. “Traffic surveillance systems base on image segmentation techniques”. Available: http://www2.unalmed.edu.co/~pruebasminas/index.php?option=com_docman&task=doc_view&gid=1742&tmpl=component&format=raw&Itemid=285.


97

Modernización, simulación e implementación en una computadora robusta, de un sistema de medición

angular a partir de un sensor sincrónico

Ing. Edgardo Comas, Ing. Daniel Pastafiglia, Cristian Bruña, Ing. Adrián Stacul, Sergio Saluzzi, Mauricio Burgos Laboratorio de Técnicas Digitales � Departamento de Electrónica Aplicada

CITEDEF � Instituto de Investigaciones Científicas y Técnicas para la Defensa Villa Martelli, Buenos Aires, Argentina

{ecomas, dpastafiglia, cbruna, astacul, ssaluzzi, mburgos}@citedef.gob.ar

Abstract� Se describe brevemente una implementación de un

preciso sistema de medición angular utilizando un sensor

sincrónico (en idioma inglés, synchro), y se muestra el uso de computadoras robustas compactas, que alojan un modelo matemático y realiza el procesamiento de señales del sistema.

Keywords� PC/104; synchro; sensor sincrónico; modelado; procesamiento de señales.

I. INTRODUCCIÓN

Los sensores sincrónicos (en inglés, synchros, resolvers) existen desde hace 40 años y son parte de muchos sistemas servo-electromecánicos y sistemas de posicionamiento angulares. Sin embargo, en la última década, en conjunto con una electrónica apropiada, los synchros, resolvers y encoders incrementales forman el corazón de los sistemas de medición digital de ángulo y de sistemas de posicionamiento, y se ha determinado que en términos de fiabilidad y costos, son insuperables que cualquier otro método.

Mientras que los encoders son sensores de posición relativa, los synchros y los resolvers son transductores de ángulo absoluto, proporcionando señales que permiten dicha detección de ángulo. Además, eliminan el ruido en modo común, por lo tanto son utilizados comúnmente en ambientes ruidosos.

La PC/104 es un factor de forma popular estándar para módulos de computadoras pequeños, generalmente este formato se utiliza en sistemas de control industrial o vehículos.

El éxito del PC/104 se debe a que se ha convertido en el formato de computadora industrial más extendido desde su origen en 1987, con un crecimiento exponencial de uso en dicho ámbito desde entonces hasta el presente.

Su versatilidad radica en las amplias posibilidades que ofrece a los integradores de sistemas para añadir electrónica de entradas-salidas, buses de campo, puertos adicionales, etc., apilando tarjetas sobre el robusto conector PC/104.

Su evolución ha llevado a la creación de estándares adicionales como PC/104+, PCI104 y PCI-104 Express.

El sistema de procesamiento se realizó en una computadora embebida con el formato PC/104 de la marca Advantech, y una placa adquisidora multifunción de la misma firma, a fin de realizar la conversión analógica a digital que está diseñada para aplicaciones específicas, como captura de datos o sistemas de control industrial.

Fig. 1. Vista de computadora de grado industrial con formato PC/104

En dicha computadora se alojó un modelo de MATLAB® y SIMULINK® que está compuesto de un bloque adquisidor de datos, un bloque de transformación de Scott, un bloque de generación de una señal senoidal (la cual se utiliza, una vez amplificada, para alimentar al sensor), un bloque de detección y filtrado (similar a un receptor AM) y finalmente un bloque convertidor de datos al formato requerido para la aplicación específica.

En este caso particular el desarrollo descrito tuvo como leit-motiv la provisión de información de acimut de antena de un radar, entregando para ello en su salida unas series de pulsos denominados ACP y ARP que permiten inferir dicha magnitud.

El ACP (Acimuth Change Pulse) es un tren de pulsos, donde el intervalo entre éstos es un ángulo fijo. Comúnmente la cantidad de dichos pulsos ACP es de 2048, 4096 o 8192, y cada una de estas cantidades equivale a 360º.


98

El ARP (Acimuth Reset Pulse) es un pulso de reseteo que se produce en un punto de referencia. Por lo tanto, el ángulo del radar se deduce contando el número de pulsos ACP desde el último pulso de ARP registrado.

El objetivo del proyecto concluye al obtener una medición angular en 12 bits de resolución (de 0 a 360 grados con una grado de error en la medición menor al 0,03%) y ajustable a la cantidad de bits y protocolo que se requiera para otros proyectos (como puede ser, 16 bits en paralelo) con solo variar unos pocos parámetros en la solución embebida, es decir, que este sistema es personalizable según requerimientos del sistema en donde se aloje.

II. CARACTERIZACIÓN DE UN SYNCHRO

A. ¿Cómo funciona un sensor sincrónico?

El synchro es un transductor, el cual puede ser conectado para obtener una medición angular, un cambio de ángulo o una posición de un sistema. El synchro se asemeja a un motor de corriente continua, posee un rotor con uno o varios devanados capaces de girar en un estator fijo. Existe una señal de referencia (entre R1 y R2, Fig.3) que produce señales proporcionales, en amplitud y fase, al ángulo de rotación del eje y con la misma frecuencia que la señal de referencia (análogamente a una señal de amplitud modulada, AM). Dicha señal luego se procesa a través de un modelo matemático y un filtro digital que representan digitalmente a un transformador de Scott-T para obtener dos señales, una cosenoidal y otra senoidal (a diferencia de los resolvers que entregan estas señales directamente) para en un último paso calcular el ángulo del eje mecánico del dispositivo.

Fig. 2. Vista de un synchro, su esquema y señales que éste entrega

Para obtener el valor de la medida específica de ángulo es necesario convertir estas señales de una forma analógica o digitalmente (como se ha hecho en el presente desarrollo)..

Fig. 3. Esquema de bobinados de un synchro y señales asociadas

En la Fig. 3 se visualiza que como consecuencia de la excitación aplicada sobre los devanados R1 y R2, se generan tensiones inducidas presentes en los bornes de los devanados fijos S1, S2 y S3, obteniéndose la señal modulada desfasada

120º en su modulante variando dicha modulante su período en función de la velocidad de giro, o la posición del eje mecánico del synchro.

B. Evaluación experimental

Para dicha caracterización se realizó el conexionado detallado en el diagrama de la Fig. 4. Los resultados de dichas evaluaciones realizadas con un osciloscopio y una plaqueta de adquisición PCI de la firma Advantech y ejecutando MATLAB® y SIMULINK® se muestran en Fig. 5 y 6, respectivamente. Finalmente, las señales del synchro pasan a través de una conexión de resistencias en topología estrella para obtener una tensión adecuada.

Fig. 4. Diagrama del conexionado para la caracterización de un synchro

Fig. 5. Figura que muestra varias tomas del trigger externo, cada una estos pulsos representa una vuelta entera de giro del eje del synchro


99

Fig. 6. Adquisición de señales de un synchro y un trigger externo acotando su tiempo y amplitud

III. IMPLEMENTACIÓN DE UNA CONEXIÓN SCOTT-T

Existe un dispositivo llamado transformador de Scott-T, o conexión Scott-T, el cual a partir de las tres señales desfasadas, produce a su salida dos señales, una del tipo senoidal y otra del tipo de cosenoidal. Este transformador se puede implementar por medio de bobinados conectados en una forma particular, o también se puede realizar mediante una configuración con amplificadores operacionales, pero sea cual fuere su implementación responde a una ecuación matemática cuya aproximación se tiene en la Fig. 7.

Fig. 7. Símbolo del Synchro, transformador de Scott-T y configuración con operacionales de Scott-T

En la Fig. 8 se muestra el modelo representado en SIMULINK® con el agregado de bloques de suma, resta y ganancia que representan a la ecuación aproximada de la conexión tipo Scott-T. En la Fig. 9, en colores amarillo y magenta, se muestran las señales senoidal y cosenoidal de la conexión Scott-T y su cálculo final de la posición relativa del synchro determinada por la señal en celeste mediante el cálculo del arco-tangente del cociente de las mencionadas señales armónicas.

Fig. 8. Implementación del la ecuación aproximada de la conexión Scott-T en SIMULINK®

Fig. 9. Señales obtenidas con la implementación de la conexión Scott-T

IV. IMPLEMENTACIÓN DEL SISTEMA

Luego de una exitosa prueba de un primer prototipo se realizó el siguiente diagrama para una implementación final.

La Fig. 10 muestra el prototipo final del sistema, y se dará una breve explicación de los bloques que intervienen en el procesamiento de las señales.

Fig. 10. Esquema del prototipo final

atan

T rigonometri c

Funct ion

120

s+120

T ransfer Fcn3

120

s+120

T ransfer Fcn2

120

s+120

T ransfer Fcn1

120

s+120

Transfer Fcn

Scope2

Scope1

Scope

Relay1

Rel ay

1.154

Gain1

0.5

Gai n

Divide

Anal og

Input

Analog Input3Adv antech

PCI-1710 [auto]

Anal og

Input

Analog Input2Adv antech

PCI-1710 [auto]

Anal og

Input

Analog Input1Adv ant ech

PCI-1710 [auto]

Anal og

Input

Analog InputAdv ant ech

PCI-1710 [auto]


100

A. Synchro

Se construyó un sistema simple con el fin de utilizar el mismo synchro y generar un pulso con un interruptor para la generación de una marca de referencia (por ejemplo, para emular el Ship Heading Mark de una antena de radar primario de un buque).

B. Estapa de alimentación � Señal de referencia del synchro

La PC/104 entrega una señal cuadrada de 400Hz y luego, para transformarla en una senoidal, pasa a través de un filtro pasa-bajos analógico.

Esta señal es amplificada para así excitar un transformador y este proveer la alimentación adecuada de 115v/400Hz al synchro.

C. Procesamiento de señales

Las señales son procesadas por una placa de adquisición (PCM-3718H de la firma Advantech) montada en un puerto PCI104 de la PC/104, y luego de que éstas sean tratadas por un modelo realizado bajo el entorno MATLAB® y SIMULINK®, se extraen por un puerto digital en una codificación de 12 bits, donde 0 grados sexagesimales se traducen como 000 hexadecimales y los 360 grados sexagesimales corresponden a FFF hexadecimales. Dicha señal es conveniente aislarla utilizando opto-acopladores para prevenir algún posible daño a alguna placa de adquisición que se utilice, y debe respetar el protocolo que dicho adquisidor o sistema requiera.

D. Simulación y procesamiento en tiempo real

Se realizó el modelo final que se muestra a continuación, que contiene, además, una corrección de las ecuaciones aproximadas de la conexión Scott-T, a fin de obtener la precisión requerida.

Fig. 11. Modelo matemático en Simulink a fin de adquirir señales de un synchro model in SIMULINK®

a) Circuito Scott: Consiste en una implementación digital del circuito Scott-T donde ingresan las tres señales moduladas en amplitud en función de la velocidad/posición con una portadora de 400Hz, obteniéndose dos señales armónicas con misma portadora, modulante y amplitud pero desfasadas 90º entre sí (seno, coseno).

b) Bloques pasa-banda: Bloque que realiza la función de un filtro pasa banda de tipo IIR Butterworth, de banda de paso entre frecuencias de 350Hz y 450Hz, con el propósito de eliminar el ruido y limitar la velocidad del synchro a 50 vueltas por segundo. En el caso puntual bajo estudio, el tiempo promedio estimado en dar una vuelta de antena, o sea del synchro, ya que éste esta ligado a la antena sin reducción alguna, sería de alrededor 5 segundos.

c) Bloques de demodulación: Se genera una señal senoidal de 400Hz para demodular las señales a la salida de los filtros, las mismas se las vuelve a ingresar a través de filtros pasabajos para obtener las señales demoduladas, un seno y coseno, cuyos argumentos son las posiciones angulares instantáneas referidas a un cero de posición.

d) Bloque atan2: Este bloque realiza un cálculo entre las dos señales seno y coseno que ingresan a éste, y se obtiene la posición angular instantánea. Los valores que ingresan al bloque deben tomar valores entre �ʌ y ʌ en grados radianes que luego son escalados y acomodados a fin de obtener una salida entre 0° y 360°.

e) Etapa de ajuste de cero de referencia: Para esta etapa se utiliza un bloque de memoria el cual es combinado con bloques de lógica de conmutación, y, ante una señal de disparo almacena el ángulo instantáneo. El bloque de memoria en todo momento resta su valor almacenado al valor instantáneo calculado, de esta forma estableciendo un cero relativo al momento de la señal de disparo. Para evitar disparos consecutivos por rebote del sensor se utiliza una banda de guarda para la adquisición del valor instantáneo de la posición angular.

V. CONCLUSIONES

Se pudo caracterizar el comportamiento del synchro y evaluar su principio de funcionamiento.

La señal de 400Hz correspondiente a una salida digital de la PC/104 el filtro pasa-bajos, resultó estable, sin anomalías ni deformaciones.

Se comprobó también el buen funcionamiento de la puesta de referencia a cero grados.

Como última prueba de puesta en marcha, se conectó un motor de tensión continua con un control de velocidad constante en baja velocidad, con el fin de simular la rotación de una antena de radar, y se acopló el eje mecánico del synchro. Luego, se adquirió una suficiente cantidad de muestras corroborando la integridad de datos, la ausencia de falsos pulsos y de deformaciones en la señal o de ruidos que la alteren significativamente.

El objetivo del proyecto se alcanzó con éxito al obtenerse una medición angular de 12 bits de resolución y un error menor al 0,03%. La gran ventaja de utilizar modelos matemáticos embebidos en computadoras compactas reposa en la flexibilidad, pudiendo por ejemplo en el caso descrito ajustar la cantidad de bits y protocolo de salida con solo cambiar ciertos parámetros.


101

REFERENCIAS

[1] Kamen, Edward y Heck, Bonnie, Fundamentos de señales y sistemas usando la Web y MATLAB. México: Pearson Educación, 2008.

[2] Oppenheim, Alan y Schafer, Ronald, Tratamiento de señales en tiempo discreto. Madrid: Prentice Hall Iberia, 2000.

[3] Chen,Wai-Kai, Passive and active filters. Canada: Wiley, 1936.

[4] Armentano R., Fochesatto J. y Risk M, Análisis de señales y sistemas. Argentina: Rocamora, 1997.

[5] Mariani, Amadeo, Fundamentos de MATLAB y SIMULINK. Argentina: Universidad Tecnológica Nacional, 2008.


102

Multi-Client Application for Electric Arc Furnaces, using

Compact RIO and FPGA

Ing. Manfredi Gustavo Ariel Techint Tenaris Siderca

Campana - Buenos Aires (Argentina) Email [email protected]

Mg. Ing. Héctor Risso Instituto Universitario Aeronáutico

Córdoba Capital - Córdoba (Argentina) Email: [email protected]

Abstract — This paper presents a solution design and

implementation of a multi-client application as a part

of a system for electric arc furnaces (EAF). The same

allows reading voltage, current, pressure, digital

parameters and, depending of the way they control the

movement of electrode essentially making a better use

of electrical energy.

Within this scope, this paper shows the development of

a distributive multi-client platform to monitor the

performance on any PC simultaneously to the control

system, by transferring the operating software and

installation, which is created in Labview and

synthesized in an FPGA, that implement software

algorithms in hardware.

The result is a product installed on any computer that

connects to the embedded controller (Compact RIO)

capable of monitoring and control via an Ethernet

network, providing the user with a graphical human

interface (HMI). Keywords: NI Compact RIO, cRIO, FPGA, Embedded

Systems, HMI, Labview, EAF, GUI.

I. INTRODUCTION

In the control processes that take place in real life is mandatory to meet the design goals, in the case of siderurgical industrial automation like this; those are to better dispersion, to lower power consumption and to optimize costs. But as important, is to know the status of the different variables of the process, and to do it from anywhere in the world, is a factor that distinguishes between common industrial processes, and even more it is, to do all the programming in a single embedded automation device. In the project referred to this work, emerged the need to explore the alternatives which allow connectivity, such as the TCP / IP (Transmission Control Protocol / Internet Protocol) or UDP (User Datagram Protocol) protocols, to provide access to subsystems via HMI and, to manage (at a lower layer of the protocol stack) the underlying hardware platform that runs it, i.e. their modularization.

Fig 1. NI compact RIO � The device that manages the control, command and also support the platform is the embedded NI Compact RIO (Fig.1), which is programed with Labview (acronym for Virtual Instrumentation Laboratory Engineering Workbench), on which there is an FPGA (reconfigurable Field-Programmable Gate Array), free programmable, which allows to run potential combinational logic and high-density concurrent processes fast enough. The ability to reconfigure the FPGA (Xilinx - Virtex V) is the center of the architecture of the embedded system in NI Compact RIO (cRIO) [9]. The objective of the final program, is to use the cRIO for synthesizing control functions, database, HMI, combinational logic and digital processing, creating a Multi-Client system on the same platform that performs the control process of automation, i.e. the same device that performs control loops, real-time calculations, digital processing, resorting the FPGA and embedded systems to synthesize hardware. One challenge that solves is the convergence of different technology systems that require multiple control devices into a single integrating device PAC. (Fig. 2) [13] (Programmable Automation Controller), which communicates using open network protocols such as TCP / IP or Modbus Plus serial ports.


103

Fig. 2 Current control technology to convert PAC Another challenge that successfully resolves the proposed design is the implementation of the solution in Labview, most profoundly, is synthesized in HDL code (acronym for Hardware Description Language), and then allowing via an GUI (acronym for Graphical User Interface) his use for human technical operators inside the factory in a user friendly way. (Fig 3). The control software is transportable in its client version to any PC and allows constant monitoring of furnace control system remotely, including all calculations, functions in time or frequency diagram analysis. The scope of the project, require that this should be done under strict considerations and stringent quality requirements, schedules and costs, clearly specified.

Fig. 3 Compact RIO GUI connection over Ethernet

II. DEVELOPMENT AND APPLICATION MODULE

EMBEDDED USING LABVIEW On the basis of software, it was used for the development “Labview”, proprietary software from National Instrument (NI), which has the advantage of easy programming, simple hardware configuration and high external acquisition speed [1]. After selecting the platform, the remaining hardware and software components were developed involving: • Design of the hardware platform according to the

requirements of the national steel and siderurgical industry. • Definition and choice of communication protocol for multi-remote application, in this case TCP / IP. • Design of Software Platform programmed in Labview 2009, creating the modes “Master” and “Client or user”. • Commissioning and performance testing in Steel Refining Furnaces.

a) General Architecture

Fig. 2 shows the general architecture of the application running on the system which applies the multi-client embedded platform. Over the platform “cRIO-9014” is embedded the software done in Labview, and then synthesized into VHDL code. (Fig.5, 9). The code that includes the logical and mathematical operation for controlling, is the same used for performing a multiclient comunication, this presents a state for the art technology for the steel making industry.

b) Synthesis of Code

During the synthesis process, the code data is obtained from the cRIO (Fig. 5, 6), indicating that the conversion from a Labview code interpreted by the FPGA code is being carried out, this process has different length time, which depends on the complexity of the code developed.

Fig 5. Data Summary


104

Fig 6. Processes running Compilation

Digital processing techniques have been introduced using FPGA in a wide range. It is always competent to complete all the processes and analyze measurement task by using Labview graphical programming ideas, data flow and execution, [5] which simplifies the process.

c) Application Front View

The Fig. 7 shows only the front end view of the application. The system shows everything that happens in the embedded controller, control actions, settings, digital inputs, and analog outputs of the same type or, RMS signals, FFT, THD.

Fig. 7. Panel Frontal

d) Development of multi-client architecture

To make the application work as multi-client is necessary to manage each of the users (clients) dynamically, as each client connects there is a consequent consumption of memory and computational resources which must be managed to deliver bandwidth, the bandwidth generated by client should be able to be returned to the system once the user disconnects, operating dynamically all the time. The system is designed to give extreme robustness, reliability and energy efficiency. It is believe that a system based on FPGA hardware can be synthesized and achieve temporal precision measurements of the critical component of 25 ns [12].

In turn, there should only be one person running as an administrator (or master) that controls the regulatory system calibration, the reference master must always be connected to flow parameters configuration, if it is off, as it would a client anywhere in the world, that user will only see what happens in the electrode regulation system, but it can not change the control parameters e.g. PID setpoint or constants Ki, Kp, Kd. Fig. 8 show the system that takes care of adding user connections based on external requirements, which are detected by multiplexing listening port and correspondingly, then when the user disconnects the connection closes, returning the memory and the bands requested. As the Compact RIO is based on FPGA architecture, algorithms can be implemented in embedded software instead of hardware, which also provides a benefit of synchronization and temporal adjustment compared with common processor [6]. Furthermore, the multi-client system is based on quick decisions and concurrent multitasking typical of FPGA, whose only limitation is the inability to work in floating point [10].

Fig 8. Dynamic allocation of users


105

Fig 9. General Architecture Control System

e) Control

Being the cRIO an FPGA architecture, the algorithms can be implemented in embedded software, which provides also a benefit of timing and seasonal adjustment compared with common processor logic [6],[10]. The trasductors used for obtaining a fraction of the real voltage and current are unique and hand made by specialist form the factory, with those is made the insertion in the cRIO acquisition system. Regulating the electrode positioning is achieved using phase divided by PID control; following parameters expressed in the equation (Ec.1).

)()()()(0

tedt

dKddeKteKtMV

t

ip � ++= ττ (1)

The regulation system should be understood as a system intended to improve mainly the "current leakage" that is produced by a lack of response of the system, the hydraulic movement of the electrodes, by waves steel bath liquid, line noise, or by whatever material enters the steel bath near the control element and/or their own limitations as latency constructive transducers, and consequently improve other related variables.

IV. VALIDATION AND VERIFICATION The validation and verification (V & V) design requires special considerations. At verification level every unitarily particular interface is reviewed, voltage levels, currents, harmonic distortion, dispersion of current value, ignition time, active, reactive and apparent power, and so on, which are stringent and constitute the success or failure of the system.

For testing at unit level the receiving commands, the same excitations were simulated with different impulses types, and changed both digital (on / off) and analog waveform (amplitude, frequency and phase) by a brand HP function generator model 3312A and Texas Instrument digital Simulator. Subsequently, it was followed with the integration with the real system to verify the data collection from the launcher, verifying the objectives were completed. Also it was tested the software with maximum settling on Windows 2000 onward as portable installer from a USB flash drive, with good results since all waveforms were identically and only resolution of the monitor problems were encountered. Field tests were conducted, testing the control system and simultaneous monitoring from steelworks and engineering management, both being several hundred meters away from each other. Test results were documented and included in the documentation of the system, as a result user manual. Integration with and industrial PC is also solved with a verification criteria because the final product is delivered on with a panel-type Touch screen PC with Windows embedded owns by NI, and was also checked the seamless connectivity between the embedded platform under development and the simulator / real control steelmaking plant. Integrating some final details, such as having immediate value memory consumption has been scheduled for a later stage of the project and has not been completed at the time of making this publication.

V. PROJECT SUMMARY The total duration of the project involved about 8 months of work from the definition of system-level requirements, to the conception of a deliverable item, which this paper is a part off. The approach meets all stages of a cycle iterative live stage type, including requirements, design, construction, testing stages, hardware and software integration and validation.

VI. CONCLUSIONS

This work reflects the creation of a multi-client platform embedded, as part of the development of an improved control system for control an electric arc furnace (EAF) for steel casting.


106

This type of development appeals to the simplicity of Labview programming environment to create a user interface. The development process is supported in software engineering practices [7] established cycle such as requirements, design stages, establishing baseline configuration and inspections confirming the usefulness of these techniques in the development of embedded systems of this complexity . The hypothesis is confirmed regarding the relative advantages of the selected platform in compare of development based on functionally equivalent conventional architectures. These advantages are in areas such as integration capabilities of hardware and software as an integrated solution and the possibility of flexible firmware update, which transforms into a modular structure developed, tolerant to changing requirements. An advantage of the design was, developed in a friendly programming environment based on Labview language structures, which allowed the technology to address a learning curve modest compared to what would have been necessary to achieve the application directly to VHDL without previous systetization in Labview. Also, the systetization of several hardware components such as conditioners, actuators, analog and digital acquisitions under one manufacturer (NI), eliminates incompatibilities, delivering results in a considerable reduction in size compared to applications with electrical and control panel separately, with a logical consequence of reducing errors, and increasing the ease of detection thereof.

Fig. 12. Normal current dispersion

Fig. 13. Improved current dispersion Following the implementation of the PAC based on FPGA embedded instead of the conventional control system based on PLC (acronym for Programmable Logic Controller ) was obtained an improved of the current dispersion (Fig. 12 and 13), leading a power savings of approximately 15%, improving therefore the ignition time. Studies were conducted with the system owner level 2 "Phwindows" from Tenaris Siderca [14]. The availability of large numbers of examples, application notes and manufacturer's manuals provided a blueprint for this development. Future work will lead to the integration of the control system engineering with model based predictive control (MBPC) using Matlab (short for Matrix Laboratory, "Matrix Laboratory”) and update the embedded software of each module according to requirements for each subsystem and digital / analog (PID, acquirer, etc) integrated. The final integration is undated, as it is expected a new financial year of the company to assign hours and diagramming an itinerary.

REFERENCES

[1] Image Processing Based on Seamless Integration Technology Between Lab VIEW and MATLAB - 2010 International Conference on Information, Networking and Automation (ICINA). Modeling and Control of an Electric Arc Furnace -Radu B�lan, Vistrian M�tie�, Olimpiu Hancu, Sergiu Stan, L�pu�an Ciprian

[2] Mechatronics Department, Faculty of Mechanic

[3] Available www.ni.com/compactrio/esa [4] Available www.ni.com/labview/esa [5] Alex See, "Utilizing Labview for data

acquisition and analysis for a 13 weeks undergraduate course", American Soc.Eng. Edu.Annual Conference Proceedings, (2004), session no.2220.


107

[6] Design of Compact RIO-Based acquisition System Tao Lin. Yongxing Xie, Jing Tan Dept. of Controling Naval Aeronautical ands Astronautical University.

[7] Metodologías Ágiles en el Desarrollo de Software José H. Canós, Patricio Letelier y Mª Carmen Penadés DSIC -Universidad Politécnica de Valencia.

[8] "Distributed Application Architecture". Sun Microsystem. Retrieved 2009-06-16.

[9] Li Meng, Jin Shijun, “Design and implementation of strain acquisition system based on Compact RIO,” Research and Development, vol. 26, no. 3, pp.29-31, 55, 2007.

[10] Carroll Dase, Jeannie Sullivan falcon, Brain Maccleery, “Motorcycle Control Prototyping Using an FPGA-Based Embedded Control System,” IEEE Control Systems Magazine, pp.17-21, Oct. 2006.

[11] Real-Time Control of Active Ankle Foot Orthosis. H.S, V.I.George Department of Electronics & Communication Manipal Institute of Technology, Manipal University Manipal, India

[12] National Instruments [online]. c2010 [cit. 2010- 03-14]. FPGAs - Under the Hood. Desde link de Internet www: http://zone.ni.com/devzone/cda/tut/p/id/6983.

[13] Desarrollo de SCADAs con conectividad a PLCs y PAC. Gustavo Valdes. Technical Marketing Engenier NI México Academic Days 2010.

[14] Tenaris Siderca es una empresa metalúrgica dependiente del Grupo argentino Techint.


108

��ABC�CD�BCD�E�FC��

��AB�CD�EDBAAD

��AB�C�DEF��CA�C�D�E�C�E��A��D�EA��EE��D�A��A��D��E�D��E�CD�

�C�ECD�� AB� � B�CBC � D � EF � ��FB��CD�� A��

��C�C�� F � �F�� D � �C�� A��B� � �E � �ED � ��

��C�CD� � F � �F�EC� � � � �� !��"C� � D�C��CD� � �C�C � ��

��A��A�FB��CD�� #$% � ��B&'%( � EB��)CD�* � �E�C � �C�

C��E�BABE�C�D�EF��A��A�FB��CD��+��D�,��B*��B�FD��C��

E�EC�� D� �� D�C��C� �F � � �EF � ��C�C ��E � �E��

A��CD��C�C�D�A-C�C��E�BABE�C*��B�CF�!��D��C��C�C��E�

��B�� AEA��F � .��D� � C � �E � �C � C��E�BABE�C � D� � �+� � ��

�E�CDC* � � � �C��)C��F � �� C � ��C � C��EF�� AC�� C�C�

��/��D��CF�C��0��C��EF��DE��D�-C�D"C�*�

A��B��*�A�FBCD��D��E��*��CF��D�EF��E��$12,3 �

.��BC��CF�C��C�CD��FEFAC��AE�C�0��BC�C��

D��C��F�/�*�A��A0�AE��D��B��D�EF�B��*��

�CED�CB�D��C�A��EF�ACA��F��*�BC�C��D��C��E��4�D��4C�

��AE�C�� F � � � AC�� D � ��C�C� � D��ABC�FB � EF�

��A��A�FB��CD��

��B�A��B��C��B��AE��CD�E�FC��

�� B�� A

!"��A��A��A�#��DA��A$%��A&��A�D�A'�D��(E��A��A%��A��AE��)�A��A��*A#��EAC��DAE�A��AA��E�+�A�D� A ��E�� A ��'E�� A '��D A �� A ��E�� A '��C�E��A��D��D�DAC��DAEA��A&��A�EA��'D��DA��(�AEE��AAC(DA�� A CD�'E�)� A ��D A CD�D A ��E�D A �� A CF��D A ��,-C�E A ��A�� A% A ��A,��E A��E A'�D*�C�D A�� ACD�� A��A$%�A��A()DACD��DA&��A'��A��A'�D��(E�A��C��A��AE��)�A�A*A��A��A�D�DA'�D��C.�AE�A��)�A&��A'��A��AE��)��

��(��D A A &�� A �E A ��'D��D A C�� A CD� A ��A��C�DCD��DE�D�� A��ACD�#�A'�� A'D�A&�/A�DA��)� AEA'�D��D� A ��E A $%� A '�D�� A ��C�� A �EA��C�DCD��DE�D�A��AE��)�A��A%A��'��AA��A'��A�� A &�� A ��(��-�D� A '�� A &�� A �E A '�D��D� A ��E A $%�A'D�� A ED� A ��D� A CD�DC��D� A &�� A �� A '�D��D� A ��A��C�DCD��DE�D�� A ��)��D A (�� A E A 'D��(�E�� A ��A��C��A��C��ACD�A�EA.��0��AEDAC�EA'��AEE��AA�1D�A��(E��A�D(��A�EA��D�A'D�A�)��'EDA��(��DAA��A�EACD�,��C�F�A��AE�A��A*A�E��

%A�DE�C�F�AA��A'�D(E��A��A�EA��1DA��A��A2�$�A'D�A3D,�0��4A��E��DA��A��A��C�DCD��DE�D��A��A,��0��A��A�)�C��5 A �� A �E A ��D A ��C�DCD��DE�D� A &�� A 'D�� A �EA��'D��D�A��A&��A�EA'�D��D�A��C��(��5A��A'�D��A&��A��A2��E�D�4A�)�C��5�A

�� A �� A�D�D A�E A'�D�� A��E A$%� A&�� A��C'��E�DA��DA��EA,��0��A��EA��C�DCD��DE�D��A'��/��DE�AA/��ACD��DE� A E A �)�C�C�F� A ��EE�� A ��DA

CD�'D��D�A��5��CD�A��A�EA.��0��A��A�"��AE�#�A��D�A��A�EA'�D��A��EA$%��A$D�AD��A'��A��CA��A��)�5A�EA.��0�� A �� A ,D�� A ��C�� A ��D A A ��/� A ��E A ,��0�� A ��EA��C�DCD��DE�D��A�EAC�5EA��(�/�A��A��C��5A��ACD�,��A*A��E�+� A �E A .��0�� A �� A ,D�� A CD��C�� A ��D A ��D�� A ��ACD�,��C�F� A &�� A ��-� A �E A ��DEED A �� A �� A ��(��A'�D��A��C��A�EA,��0��A��EA��C�DCD��DE�D��

�� !3��$�� A�!%A3�3B!6�

$�A��C��(��AE�AC'�A��A.��0��7�D,�0��A&��A'D��A�EA��'D��D�A��A��C��AAEA��A8�A!�A�EEA��A'��A��A&��A�D(�� A �E A ��D A ��C�DCD��DE�D� A ��E A $%� A 9�' A ��A.��0�� A CD� A �� A ��C�DCD��DE�D� A ��6: A �� A �)�C�� A ��A��0�� A&�� A2��E4 A �� A�� A�$�A;�� ACD� A�� A�� A��A��CC�D��A��3�A��A<(��A!��A�$�A'D�A�D�,0��A��A�EA&��A�)�C��5A�EA'�D��A&��A�EA'�D��D�A��EA$%�A��C��(��5A*ACD�'�E�5A'�A��C.A�&��C��

��A8��&��C��A��EA��

3� AD(�� A �� A E A�� A8 A&��A�E A'�D�� A��E A��DA&��A2CD��D4A��DA��EA�$�A'D�A3D,�0��A��A�D�DA&��A�D�A��CC�F�ACD�A�EA.��0��A��ACD��DE�A'D�A��C.DA�$��A��A��)A��A��A�D��EDA��A&��A�EA2��E�D�4A��EA�$��A��(�/�A��E��AA()DA��EAC��D�A�F��ED�A&��A�EA��DA'��A��E�+��A'D�A�)��'ED=

� B��ACD�A(��A��A��'DA��A8��

� !��ACD�,��(E��ACD�DACD��D��A��A'�E�D��

� !��ACD�,��(E��ACD�DA��CD��

� 6��)D A �� A �� A (�� A �3><? A CD� A '�D�DCDED A E�(�� A DA6D�(��A�3��ADA�B�A@?A�

� %�C��A��A��A�EF��CA��ACD��A9BCDB��:

� %�C��A��A��A��E��

� !�C��A��A�E��A��E��


109

��A��DA��A��D�A�F��ED�A��AC��D�A��D�A&��A��5�A�'��D�A��A�EA�$�A'D�A3D,0�� A��A�D�DA&��A'��A��ACC��D� A �� A E A 'E�CC�F� A ��E A ��D A '� A 'D��A��)�ED�A,5C�E��

� A CD��C�F� A �� A ��C��(� A �E A ��'D��D A�� A ED�A(ED&��A'�D'��D�A��AEA��AD�A!�A�EEA��AD(��A&��A�EA��C�DCD��DE�D�A��E�+�DA9%$�888>@8A:A'D��ACD��C��A��A��D�� A ,E�. A 3$� A 9�B>?��B>8�C3�@DA: A �� A E A C�E A ��AE�C�� A �E A CF��D A ��E A '�D�� A CD�'�E�D A '� A EA�&��C��A��EA�$�A'D�A3D,��

��AD��A��A(ED&��A��EA��'D��D�

��C.DA'�D��A��A��C��(�A��AEA��D��A��A��A$�A��E�+��D A �� A '��D A ��E A �3DED A ��D A A EA2'�D��C�F�4 A ��E A $%�� A % A #��C A ��B A ��EA��C�DCD��DE�D��A��E�+�A'�AEA'�D��C�F��A��ACD�'��A�� A �E A ,��C�D��D A ��E A $%�� A CD�D A �� A (�� A �3><?A�� A E A CD��"�F� A �� A �� A �� A '� A ��C.D A ,��A93�F?8FG@EA:� A $D� A D��D A E�D� A �E A ��'D��D A C�� A CD� A >A�� A ��E�� A &�� A �D'D�� A .�� A D<H� A * A �� A ��A�EF��C A �� A CD�� A C'+ A �� A �� A �� A B A A DB�� A 3�A��1�D�A�D�A��D��A��A��A$%�AED�AC�E��A��A��,��C��A'D�A�EA��'DA��A�E��A&��A'D��=

� 6D��EDA2�4=AEA3E��AA��E/A>BBHC8�

� 6D��EDA2B4=AEA3E��AAB��CA>BBHC8�

��E��A��AEA��AEA��AD(��A�EA,��A��EA�&��'DA�� A�D��A&��A��C�� A �� A ��,C�� A�� A ��CD��"�F�ACD�A�EA�"��D�A��A(D��

��AE��A��EA��'D��D�

�� !6�%��A�!A�$�

%A'��A,��EA��EA,��0��A��A��A$%��A�EA�$�A'D�A3D,�0��ACD��A��A��'��A��CC�D��A��A��(E��A��A��'DA��3��A%A�&��C��A�E��A'�A��E��A,��AEA��A��A��C�DCD��DE�D� A �� A < A (�� A $��8<�>GDB� A %� A C�C��-��C�A'��C�'E��A��A��A��C�DCD��DE�D�A�D�AE�A��A@>A=

� G>I(*��A��A��D��A��A'�D��

� >I(*��A��A��D��A��6�

� ��&��C��A;��

� 3�� A �� A ��CC�D�� A ��3� A CD� A E��D� A �� A FBA��CC�D��

��(��DAA&��A�E A,��0��A��(-A��E� AEA�&��C��A*A�)�C�� A E� A ��CC�D�� A �� A E A �� A �� A D'�F A 'D� A ��A��C�DCD��DE�D�A��(��DAAEA()AC��A��A��CC�D��A*A��D�A&��A'D��

!EA��DA��C�DCD��DE�D�A��EA$%��A�EA%$�888>A'D��A<I(*�� A �� A ��D�� A ��6� A �� A ED� A C�E�� A �� A ��D�A>I(*��A'�A��E�+�ACD�DA��D��A��6A��EA�$�A��E�D�AB�(�/�A��A��D� A8I(*�� A'�A�E A(�,,�� A��AEA��B�A��)��DAED�A��AEI(*��AE�(��A'�A&��A�EACD�'�E�D�AED�A��E�C�A��A.�'�A��CJ�A��C�

!E A ��! A �� A �� A $%�� A CD�D A �� A �"'E�C�5 A�5� A ��E��ACD�'�E�5A��A'�D��A'�A�EA��C�DCD��DE�D�A$��8<�>GDBA*A��5A�EA�C.��DA2�.�"4A��DAAEA��D��A,E�.A&��A'D�� A �E A ��'D��D� A�� AEE- A �E A ��E�D� A�� A�$�A E��5 A E�A��CC�D��A&��A��(�A�)�C�� A��'��DAE�A��CC�D��A��A��D��A��C�D��A��DA��EA'�D��A��A�EA��CDA��AED�A>I(*��A��D�A'�A�EA,��

�(�A��C�A&��A�DA��ACD'��AE�A��CC�D��A��AEA��D��A ,E�.AA��6�A* A&��A�E A'�D��A'��A �� A��A��1DA��AG>I(*�� A* A�E A%$�888>A�DEDA'D�� A<I(*�� A��A��6�A��A�D�DA&��AE�A��CC�D��A&��A��(��A�)�C��A��A��AE�*��DA��A�D�DA��C��C�EA��AEA��D��A,E�.A3$��A%A��EDC��A��EA'��DA3$�A��E�+�DA��AD>6.+�AEDA&��A'�D��A��A��EDC��AC�'�(E�A'�AEA�)�C�C�F�A��AE�A��CC�D��AD(��D A �� A 2��C�DCD��DE�D� A �&��E��4 A A ��A$��8<�>GDBACD��DAA?BI.+�A

!�AEA��A>A��AD(��AEA��C��A��AEA��D��A,E�.A3$��AEAC�EA��5ACD�'��A'D�ADB><A'5��A��ADG>A(*��AC�A�� A% A '��C�F� A �� A �� A �� A C�� A �� A �E A�D��D A��A��C��(��AEA��D��A*A&��A��A��C��(�A��AA'5��A'��DA'�AEAE�C��A�"��A��A�D�DA2��C��C�E4A��A�D��A��AE��AED�A(*��A��DA��5�A��AD��DA��ACD��AEA��F�A'D�A'5��A*A/��A�� A �E A�D�D A��E�+�D A'� A E�� A E� A ��CC�D�� A &�� A ��(��A�)�C��

!� A ED� A ��C�DCD��DE�D�� A $��8<� A E A �*D�- A �� A E�A��CC�D��A��A��A��1DA��ADA(*��A�"��DAE��A&��A'D��A>�A$�ACD��AEA��A��AED�A��D�AE�-�D��A��A��CEFAC�ADA(*��A��A��D�A8A(*��A��A�.�CJ��A�EAC�EA��ACD�'��A��E�+��DAEAD'��C�F�AK��A��AED�A�D�A(*��A��A��D�� A!� A �E A C�D A �� A &�� A �E A�.�CJ�� A�D A CD��'D�� A ��A��E�+�5�A.��A?A��D�A��AEAE�C��


110

��A>�!��C��A��AEA��D��A�B>?��B>8��

3�A.(E�5AACD��C�F�A��AEA��D��A��6A��'D��(E�A��A�EA'�D��A��EA$%��A�D�DA��A��C�D�FA��D��AEA�&��C��A��E�A��&��A>I(*��A��A��D��A��6�A'D�AED A&�� A �� A ��D� A>I(*�� A�� A E A��D�� A ��E A%$�888>ACD�DAAEA��6A'�D'�A��EA�$�A��E�D�A!EA$��8<�>GDBA��A��AED�A#E��D�A8D<A(*��A��EA(ED&��A��A>I(*��A��A��D��A��D� A ��'�C�E�� A �� A ED� A C�E�� A �� A CD��DE� A ED�A�F��ED�A��A.��0��A&��A/��A'D��A��AEA,��A?A��AD(��A�EA�'A��A��D��A��6A��EA��C�DCD��DE�D�A��E�D�

��A?�6'A��A��D��A��6A��EA$��8<�>GDB�

A6�C.D�A��A��D�A��D�A��A��D�ACD�AEA��A,��C�D�E��A*A&��A��A��E�+�D�A'D�A�EACD�'�E�D�A��A�AEA��A�EA��(E��A'�A��A�&��C��ACD�DA'D�A�)��'EDAED� A ��D� A �� A ��CC�D��D A ��C�D A �3�"� A ��D�A

��D� A,��D�AC�(��D�A'�A&��A�EA'�D��D�A��AA��'D��C�F�A��D�A&��AE�A'��A��)�AED�A�F��ED�A&��A�E A $%� A ��E�� A A ()D A ��E� A CD�D A 'D� A �)��'ED� A ��ACD��CC�F�A�3><?�ADAEAE�C��A��AEA��A�EF��C�

!� A ��'D�� A ��C� A &�� A E A #��C A ��CC�F� A ��EA'�D��A&��A��C��(�A�EA'�D��D�A��EA$%�ACD�A�EA,��0��A��EA��C�DCD��DE�D�A%$�888>�A��A��E�+A��A��D�A��D�A��'�C�E��A93��:�A$D�A�)��'ED�A�EA�ED�A��AEA��A�EF��CA�� A E�-�D A 'D� A �E A ,��0�� A ��E A��C�DCD��DE�D�� A * A �E A �ED�AD(��DA��A��C��DACD�DA��A2,ED�4A��A�EA(ED&��A��A��D��A��6 A &�� A ��E�+ A �E A '�D�� A ��E A $%�� A �� A ED� A ��D�A��'�C�E��AB"��BA9��D:AAB"��EA9��!3%:�A'D�AEDA&��A��A�EA'�D��A��EA$%��A�DEDA(��AE��A�EACD��DA��A��A��DA��'�C�EA'�AD(��A�EA�ED�A��ACD��A��AEA��A�EF��C=

��

��ABCDE��

!EACD�'�E�D�A��EA$%�A'D��A��AE�(��-A��A�D��A*A��5�A��E�� A��AE�C��7��C�� A��AED�A3��A'D�A��DA��A,��C�D��

!EA��A��AEA��AGA��A�EAC�CEDA��A�)�C�C�F�A��AE�A��CC�D�� A.C��DA�D�� A&��AED�A��D� A��'�C�E��A�D�AEACD��"�F�A��A�EA'�D��A��EA$%�A'�AEA�&��C��A��E��A*A�EA,��0��A��EA��C�DCD��DE�D��A�EAC�EA��C�#ACD�A�EA.��0��

��AG� A%DD'A'��C�'EA��EA,��0��A�A��CC�F�ACD�A�EA'�D��A��EA$%��

!�A�EA'��A(ED&��A��A��A��EAEDD'A'��C�'EA��AD(��AE� A ��C�D�� A A �)�C�� A �� A E A��D�� A ,E�. A 3$�� A ��A�)�C��A��A�DEA��CC�F��A&��A'��A��C��ADA�DACD�AEA��D��A��6A��AEA�&��C��A��E��A*AE��DA��A�)�C��AED� A �� A (ED&�� A &�� A ��E�� A �'�C�D� A �� A .��0��A��)��DA��AED�A��D� A��'�C�E�� A��AEA��D��A��6A��EA$%��A,E�� A�ED��AD(��D��A��C� A'�A&��A�EA'�D��A��EA$%� A '�� A CC�� A A �EED�� A�E A �� A ��C.� A �� A ��A��E��AA�)�C��AD��A��CC�F�AE�-�A��AEA��D��A,E�.�A*A�EAC�CEDA��E��AACD��+��


111

�H� $��L��6��

�D�DA��A��C�D�FA��D��A�EA'�D��A��EA$%�A��A�)�C��5A��A��A��CDA��AG>I(*��A��A��D��A��A'�D��A*A>I(*�� A �� A ��D�� A ��6� A �� A ED� A C�E�� A 8D< A �*�� A �D�A��D� A ��'�C�E�� A 93��: A�� A ED� A C�E�� A �� A 'D��(E�ACC��AAED�A�F��ED�A&��A�EA,��0��A��EA$%�A��E��AA()DA��E�

!��A'�D�� A��C��D A��A��A��(�A�� ACD�'�E�DA'� AEA�&��C�� A��E A$��8<�>GDB� A ED AC�E A �� A ��E�+ A�� A�EACD�'�E�D�A�8<A��A6�C�DC.�'A@GA�A$�A��A&��A�EA��DA��)�A��C��AED�A��D�A��'�C�E��A��A��DEEFA��AE�(��-ACD�A�D��AE�A,��C�D��A&��A'�D��A�EA$%�A*A&��A��A��)� A A �� A �� A ED� A 3�� A !�� A E�(��- A CD�� A �� A �D�A�C.��D�=

� $%��.

� 3*��.

!� A $%��.� A �� A ��,�� A ED� A ��D� A ��'�C�E�� A CD� A ��A��CC�D��A��A��D��ACD�DA'D�A�)��'EDA$��B�A9��DA'�A��)DA��A��:A*A$��B�A9��DA'�A��)DA��A�E��:�A!�A�EA�C.��DA3*��.A��A��,��AED�A'�D�D��'D�A��AE�A,��C�D�� A &�� A �� A CD�'�E�D� A �� A E A E�(��- A 23*��D4A��DEE�� A &�� A �� A ��CE�*� A E A CD�'�E� A �E A '�D�� A ��EA��D�A!�A�EEA��A��,��D�A,��C�D��A'�A�EA��)DA��=

� B��AB�

� B��A8�

� �3><?�

� !��A�EF��C�

� !�CD��

� �3><?ACA6D�(��A��

� �3><?ACA6D�(��A�E��

� �D��D��A��A'�E�D��

% A �&��C�� A 2�&��E��4 A ��E A ��'D��D A '� A �EA��D�A��A��A��AEA��AF=

��AF��&��C��A2��E�4A�D��A��A�)�C��A�EA'�D��A��EA$%��

�� A �E A '��D A �� A �� A ��E A '�D��D� A ��E A $%�� A ��A'�D�� A �� A �)�C�� A ��D A �� A E A �&��C�� A 2��E�4A��C�A��AEA��AF�A!��A�&��C��A��A�&��E��AA��A$��8<�>GDB A �� A C��D A A �� A �� A ��CC�D�� A��D�� A ��A'�D��A*A��D��A��A��(��DAED�A�F��ED�A��A.��0��A&��A��A��)�AA��/�A��AED�A3��A�D�A��,��A��(��DAEA��DA��AE A E�(��- A3*��. A�E A��D A'D��5 A'�D�� A �E A $%� A��AE��)�A�A*A��)�A�EA.��0��A��EA&��A��'D��A��A��A��'E��

H� �3�A�!A!�B��3AMA3�%��3

�D�DA�DA��AEA��C�F�A��A��A�DC��DA��A�"'E�CC�F�A��EE�A��A�D�AEAE�(��-A3*��.�A��A��5A��A(��A�)��'EDA��ACD�DA��E�+�AE�A��A*A�E��A��A��A$%�A��A�EA'�D��A��AE��)�A��A'�A��D��AEA,C�E��ACD�A&��A�EA.��0��A'��A��)��

!"�� A C��D A �� A �� A �E A ��'D��D� A �D� A �� A �EE�A'D�� A ,��C�D�� A �"�� A 9'� A ED� A CD��D�� A �� A '�E�D� A *A��CD��:� A '��D A E� A C��D A '�� A ��E�+�� A CD�D A ��A��E��A%D�AD��D�A�D�D�A��AE�A��A��AC��A��A,��C�D��A��AEAE�(��-A3*��.

��A<��C��'C�F�A��A��

$�AE��A�EA��DA��A��A��A�DEDA(��ACD�A��E�+�A�EA��DA$��B�A�EAC�EA��A��A��C�A��A��ACD�AED�A��(��D�A��"A9ABAAE�A��DA'D�AC�A��:=

��FC��

��B��

$�A��E�+�AE�A�E��A��A��C��AEA��DA$��B��AEA��C��(��ED�AE�A�E��A��EA$%�A��A�D��,�C�5�=

FC��C!�C�

FC��E��C""�CE

��AN��C��'C�F�A��A�E��AAB��C�

!�A ED� A�)��'ED�A&��ACE� A E A ,C�E�� A��E A��)DA��EA$%�A'�A�EA'�D��D��A3�A��(�A��CD��A&��AEA��C��(��A��A�EA$��B�� A �� A ��5 A ��C��(��D A �� A ��D A �� A ED� A >I(*�� A �� A EA��D��A&��A�EA'�D��D�A��'D��A*A&��AE��DA�EA��0��A��E A $%� A E�� A �� A EE- A �E A �ED� A * A �D��,�C A �E A '�� A ��EA��C�DCD��DE�D�A%$�888>A��#�ACD��'D��A!EA�,�C�DA,��EA��A&��AEA�D��,�C�A�EA$��B��A��A�D��,�CA��A�E��


112

H�� L�� A�!%A$��L��6�ACA��!

!EA��D��DA��A��DEEDA��E�+�DA��AEA��F�A��EA��D��DA!CE�'��AEE��A;�E�D�A@FA�A'�AEAC�EA��A��DEEFA��A$E��A'�D��D A �� A O� A @<A A &�� A '�� A E A !CE�'�� A ��E�+� A �EACD�'�E�D�A��A6�C�DC.�'A�8<A*A�EA'��DA��A��AEA$�A'�A��A�EA'�D��ACD�'�E�DAEA$%��

��A8B� !��D��DA��A'�D��C�F��

!EA'E��A��1�DA'�A�EA!CE�'��A'�D��5AEA!CE�'��A��A�D� A (D�D�� A ��D A '� A CD�,��C�F� A ��E A $%�� A * A D��D A '�A��(�A�EA'�D��A��A�EA��D�ACD�DA��A��CA��AEA��A88�

��A88� �D�D��A�D�,��C�F�A*A$�D��C�F��

!EA(D�F�A��ACD�,��C�F�A'��5A��E�CC�D��A�EA'��DA��A��AEA$�AEA&��A��ACD��C��DA�EA$%��A*A.(�E��A�EA��DA��EA'�D�DCDEDA6D�(��A�D(��A�EA(��A�3><?A)��DACD�A�D�A��ACD�,��C�F��

$D�A#E��D�A�EA(D�F�A��A'�D��C�F�A'��5A��(�A�EA'�D��ACD�'�E�DA��A�EA$%��AEA.C��ACE�CJA'��C��5A��A(��A��A'�D��DACD�DA��AEA��A8D�

��A8D� $�D��DA��A'�D��C�F�A��EA$%��

H�� 3!P�A!%!�B� ��

3�A�"'E�C�5AACD��C�F�AE��D�A�'�C�D�A��EA��1DA��EA��'D��D�A%A,��A��AE��C�F��A��C�A��AEA��A8E�A��A��EA ��'DA30��C.��A@NAA��E�+��DA�EAC��C��DA��DA%6D?F?BC?�BHA@8BAA�EAC�EA'��AE��A�EA$%�A��A��A��DA��A��F�A��ANHAAD?H�A%A��F�A��A�E��A��A?HAE��AEA��A�3><?�A�3DEDA*AA��A��E�D�AE��E A��AE�EH�A�EAC�EA��A��C��A��AE��A�EA��C�DCD��DE�D�A*AEA��D��A�E�.�

��A8E� ��A��AE��C�F��

%�A��A��E��A�D'D��A��A��F�A�5"��A��AD<HA�D��DA��A2��D4AEF��CDA'D�A��C��A��AED�AEHA*A��A2C��D4A'D�A��()DA��A8H�A!�AEA��A8>A��AD(��AEA'�D��CC�F�A'�A��D�� A �� A�� A �E A ��D�D A�?� A .C��D A &�� A EA��A�D'D��A��A��F�A��A��A.��ACD<H�

��A8>� !��A��E�

$� A E� A �E�� A AB��C� A �� A ��E�+F A �E A C��C��D A ��DA6��EBD8A@88AA�EAC�EA'��A��E�A�EAC��C��DA��A'D��C�A��AEA�E��A��EA��C�DCD��DE�D��A!�AEA��A8?A��AD(��A�EAB��CA��E�+�D=A�B8ENC<BBA@8DA�A�EAC�EA��A�EA��)DA��A��ACD��A��A8��

��A8?� 3E��AAB��C�

!EA(��A�3><?A��AEE��FAAC(DA��A�EA��A3�F?8FG�ACD��C��DAAEA��BA��EA��C�DCD��DE�D��A��AEA��A8GA��AD(��A�EACD��"�D��D�

��A8G� ��EE�A��A�3><?�


113

H�� $��B�A��%

�� A�� ACD��+� A�E A��(�)DA��E A$��A��A��E�CC�D�FA��A�(�� A �� A ��E A ��'D A��E A�� A �E A C�E A ��F A �EA��1DA��AEA'EC�A��(��DAAEA��AE��A��EA�(��A��AD'�FA'D�A��(�)�A�D�A'EC�AE�AC�E��A��ACD��C��A��A�D(��AEAD��A��AEA'��A��ACDEDC�D�AE�A��A�E��A��A�3><?A*A,��A��AE��C�F��A��A&��A��AEA'ECA��'��D��A��ACDEDCF A �E A��C�DCD��DE�D�� A �E A �� A�3DED A * A E A��D��A�E�.�

��A8F� $ECA(��A9�+&�:�A'ECA��'��D�A9��C.A��(:A*A�'��D�A'�A��C�DCD��DE�D��

�D�DA��A��A��AEA��A8F�A��5�A��AEA'ECA��'��D��A��A��E�+F A �� A �'��D� A '� A �E A ��C�DCD��DE�D�� A �� A ��A��C'��E�D A A ��$� A !��D A '��5 A ,��D� A C�(�D� A �� A �EA��C�DCD��DE�D�A��A��A&��A��1�A�EA��DA��AE�A'EC��

��A8<� L(��A9�+&�:A*A'�D�D��'DA9��:�

!�AEA�� A8<A��A'��AD(�� A�E A'�D�D��'DA��DEE�DA)��DACD�A�EA�(��A��E�CC�D��D�

�K� ��%�3��!3

%��DA��A��E�+�AE��D�A'�D��A��A�)��'EDA'�A��A$%�� A ��A EE�� AA E ACD�CE��F� A��A&��A A'�� A�� A�DA�� A��A��'D��D A �5'��D A �� A CD� A �� A C'C�� A ��ACD�'E��A'�DA'�ACD��DE�AC��A��A��'E��A&��A�D A ��&�� A �� A '�DC��D A �� A ��EDC�� A * A &�� A �EAE��)�A�A'��AEA'�D��D�A��DE��A'�D(E��A��A��*ACD��DA��'D�

�E�� A �� A E� A ��)� A &�� A 'D��D� A ��C� A �� A ��A��'D��DA�D�AE�A��=

� �)DACD��D�

� �D��DA��'DA��A��DEEDA��EA'�D��

� �5C�EA��DA��EA'�D��

� $�D�DCDED A6D�(�� A CD�D A6�� A * A 3E�� A ED A C�EA'��ACD��C��A��A,D��A��C�ACD�AD��D�A$%��ADA��'D��D�A&��A��)��A�EA��DA'�D�DCDED�

� ��'E�DA��DA��AE��C�F�A8DH7D>H

� 3E��A��A'D��C�ADDBH78�

�!�!�!��3@8A �K$�A2%$�888878D78E78>A$�D��C�A��.��4�A��A>�A��(��DADB88�

@DA ��E�A2�B>?��B>8�A��.��4�AAE>>E�Q��%3;QD7B<�

@EA B�"�A��A23�F?8FG�A��.��4�A3%%38BB��A6*DA8NN?�

@>A 6�C�DC.�'�A2$��8<�D?D?7DGDB7>?D?7>GDBA��.��4�A�3ENGDG�ADBB>�

@?A 6D�(��D�� A 26��3 A D�� A 3��E A %�� A 3'�C�,�C��D� A ��A��'E��D�AL��4�AH8�BD�A��C��(��ADBBG�

@GA 6�C�DC.�'�A26'E(A�8<A�A�D�'�E��A��R�AL��4�A�3ENGDG��ADBB?�

@FA B.�A!CE�'��A�D��D��A.��'=77000��CE�'��D��

@<A !��C A �E*(�� A �� A ��(�E� A 2!CE�'��= A ��E�� A �D��C�ECS�E��*A$E��C��AD��A!��D�4�A��D�AT��E�*A$�D,��D�E�A6�+DADBBG�

@NA ��EA;��A2!E�C��F��CA��A'D��C�4�A$��D�A!��CC�F�A3��A6��A''ADB8CD8D�A1DADBB8�A

@8BA ��D�E A 3��CD��C�D�� A 2%68?F?7%6D?F?7%6D?F?;H A ��.��4�A�3B88>F?�A��D��DADBB>�

@88A 6D�D�DE� A 2�'�D��DE�D�� AB��C A�� A��'��4� A�� A 8 A6��EBDB7��A8NN?�

@8DA �K$�A2�B8ENA3��AB��CA��.��4�ANENFAF?BA8EE?<�A��A>�BAO�E�DADBB>�


114

SENSADO INS/GPS CON MONITOREO EN TIEMPO REAL

Edgardo A. Comas1, Daniel A. Pastafiglia2, Cristian R. Bruña3, Ariel Dalmas Di Giovanni4, Martín E. Morales5, Agustín Dal Lago6, Mauricio Burgos7

División Técnicas Digitales- Departamento de Electrónica Aplicada Instituto de Investigaciones Científicas y Técnicas para la Defensa (CITEDEF).

Villa Martelli, Provincia de Buenos Aires, Argentina. [email protected] , [email protected], [email protected], [email protected],

[email protected], [email protected] ,[email protected]

Abstract� El presente trabajo expone el diseño y desarrollo de

un sistema específico que alberga las aplicaciones de

procesamiento de información de sensores (intraceptivos y

exoceptivos), las correspondientes a la implementación de

mecanización de ecuaciones de navegación, y las aplicaciones

asociadas a las acciones de control de servomecanismos del

vehículo; con un puesto de monitoreo para la evaluación en

tiempo real del comportamiento de la Planta.

Keywords� Adquisición, control, navegación, procesamiento,

sensores.

I. INTRODUCCIÓN

En la actualidad si bien la mayoría de los sistemas electrónicos tienen capacidad de procesamiento digital, en las aplicaciones donde se interactúa con fenómenos naturales, sensado, actuación, etc., son necesarias las interfaces analógicas.

En particular para sistemas de control digital [1] se necesita tener un módulo capaz de adquirir información proveniente de los sensores de la planta, poder procesarla y generar las acciones de control sobre los actuadores.

Similares características son necesarias para trabajar en navegación [2]. De acuerdo con [3] y [4] son necesarias dos formas de medición diferentes a los efectos de la denominada navegación integrada � los sistemas INS/GPS son un ejemplo de ello-, mediante sensores introceptivos (Ej: sensores inerciales) y exoceptivos (Ej: GPS), ambos instrumentos alojados en el móvil bajo análisis.

Para ambos casos se puede desarrollar una misma plataforma o módulo de adquisición, que reúna las características básicas para resolver problemáticas que involucren las áreas de control digital, navegación, instrumentación, entre otras.

A su vez, y como complemento del módulo de adquisición, es de suma utilidad tener un puesto de monitoreo que permita evaluar el comportamiento de la planta y/o móvil bajo ensayo en tiempo real, en forma gráfica, y que incluya el almacenamiento de la información para un post-procesado y estudio de la misma.

En las subsiguientes secciones se describen el diseño y desarrollo del módulo de adquisición, que incluye sensores para navegación, posibilidad de actuación y procesamiento; y además una descripción del puesto de monitoreo implementado, ejemplificando una arquitectura potencial de aplicación del sistema.

II. DESARROLLO

A. Módulo de Adquisición de datos

El módulo fue diseñado con el fin de adquirir, interpretar y procesar la información de distintos sensores, con capacidad de procesamiento de algoritmos de control y parte de los algoritmos de navegación para procesamiento de los mismos en forma distribuida con una unidad base de mayor potencia y precisión de cálculo.

Figura 1. Esquema de interconexión de los módulos funcionales.

Se compone de bloques funcionales interconectados de acuerdo a como se muestra en la Figura 1, entre los que se destacan:

• Microcontrolador de la familia dsPIC33 [7] para un procesamiento más intensivo de datos.


115

• Microcontrolador de la familia PIC32 [8] para adquisición en tiempo real.

• GPS ET-332 [5]: este receptor se comunica por medio de la interfaz serie en el protocolo NMEA 0183. A partir de esta comunicación es posible enviar comandos al receptor GPS para operar en otros modos de funcionamiento o cambiar los parámetros de operación. Además, a los fines de sincronizar la adquisición de datos con otros sistemas de control y supervisión se dispone de la señal de 1 pulso por segundo proveniente del sistema GPS.

• Unidad de Mediciones Inerciales (IMU) ADIS 16400 [6]: esta unidad presenta además de los sensores inerciales (acelerómetro y giróscopo de tres ejes), con un magnetómetro triaxial y un sensor de temperatura. El dispositivo se comunica mediante una interfaz SPI, motivo por el cual también se lo puede configurar pudiendo modificar su frecuencia de muestreo, y realizar su calibración.

• Interfaz para tarjeta de memoria SD.

• I/O: Entradas analógicas, digitales y salidas digitales PWM (Pulse Width Modulation).

El módulo posee un conector DB25 como interfaz hacia el exterior que aloja:

• La entrada de alimentación para él módulo.

• Señales de entrada y salida digitales y analógicas.

También posee un conector SMA que pertenece al módulo GPS para conectar la antena del mismo.

B. Diseño del PCB del Módulo de Adquisición

Para el diseño del circuito impreso se plantearon una serie de restricciones (constraints) inherentes a la aplicación de forma tal de garantizar el correcto funcionamiento y accesibilidad al módulo de adquisición.

• Utilización de dos pines para la entrada de

alimentación del módulo (mayor capacidad de corriente).

• Distancia mínima entre los pines de comunicación SPI.

• Ubicación de ambos microcontroladores en la misma capa que los sensores.

• Ubicación del centro de la terna de referencia de la IMU en el centro de la placa.

• Ubicación de los conectores SMA y DB25 en el borde de la placa para facilitar su acceso, al igual que el zócalo para la memoria SD.

• Los reguladores de tensión dispuestos sobre la placa de forma tal de asegurar un área de disipación mayor a 1� (pulgada) cuadrada.

• Ubicación de todos los circuitos integrados y dispositivos de comunicación SPI en la misma cara.

En la Figura 2 y Figura 3 se muestran las vistas del PCB finalizado.

Figura 2. Vista de la capa superior (Top Layer) del PCB.

Figura 3. Vista de la capa inferior (Bottom layer) del PCB.

C. Unidad de monitoreo o �Puesto tierra�

El denominado �Puesto Tierra� refiere al hardware específico (computadoras de misión crítica, capaces de operar en escenarios adversos, como puede ser el terreno de campaña) y también a las aplicaciones (software) que operan en las mismas con el objeto de recibir la información proveniente del vehículo cuyos parámetros de desplazamiento, inerciales, actitudes y trayectorias desean supervisarse. La función del �Puesto Tierra� contempla la recepción de información de navegación del vehículo, el backup de la misma para reproducción posterior o post-procesamiento, la solución en tiempo real de la cinemática del móvil, y la representación gráfica de dichas soluciones (trayectografías, actitud) o de variables particulares en función del tiempo.


116

III. RESULTADOS Y APLICACIÓN

Se diseñó y desarrolló un módulo de adquisición que reúne las siguientes características:

• Integración de un GPS ET-332 (Sensor exoceptivo).

• Integración de una IMU ADIS16400 (Sensores intraceptivos).

• Capacidad de almacenamiento de datos en tarjeta SD instalable por medio de zócalo correspondiente.

• Entradas analógicas, digitales y salidas digitales PWM.

• Capacidad de incorporación de otro sensor compatible con NMEA 0183, como por ejemplo un compás electrónico.

• Tamaño de la placa: 10 cm x 10 cm.

• IMU ubicada con su referencia centrada en el centro de la placa.

Se muestra en la Figura 4 una vista del módulo terminado.

Figura 4. Vista de la placa terminada del módulo de adquisición.

El módulo de adquisición instalable en un vehículo, junto al denominado �Puesto Tierra�, conforman una arquitectura como la ejemplificada en la Figura 5.

En la misma, la aplicación para monitoreo identifica la

información de sensores inerciales (acelerómetros y giróscopos) y de referencia exoceptiva (ej. GPS), las procesa y almacena en una Base de Datos para reproducción ulterior de la navegación del vehículo, y efectúa los cálculos inherentes a la navegación misma en �tiempo real�; esto es, resuelve algorítmicamente las ecuaciones dinámicas del movimiento, para finalmente transferir el resultado de dicho procesamiento al subproceso graficador de la cinemática del vehículo, donde por ejemplo puede observarse la �actitud� u orientación del mismo respecto a ternas de referencia, como se muestra en la Figura 6.

Como se indicó, esta aplicación también tiene como

característica la posibilidad de conexión a un sistema gestor de base de datos para post-procesamiento de la información

adquirida. En este caso se ha creado la base de datos manejada desde el DBMS provisto por MySQL-Oracle, y la aplicación homónima efectúa las transacciones correspondientes para resguardo de la información base de navegación.

Figura 5. Arquitectura del sistema completo.

Figura 6. Visualización de actitud y posición del vehículo en �Puesto Tierra�.

IV. CONCLUSIÓN

Se instrumentó un sistema de medición para navegación con capacidad de ejercer acciones de control, destinado a vehículos no tripulados, con interfaces que permiten montar una comunicación bidireccional desde y hacia un puesto de monitoreo y control en tiempo real para su seguimiento y evaluación. El mismo podrá ser aplicado a diferentes sistemas para su evaluación. Esta solución se podrá implementar en conjunto con cargas telemétricas para sistemas de control, navegación, guiado, etc. aplicados a sistemas de medición de alto rendimiento y sistemas de navegación de vehículos no tripulados.

REFERENCIAS [1] Katsuhiko Ogata, �Sistemas de Control en Tiempo Discreto�, 2da.

Edición, Pearson Educación.

[2] Bernard Etkin y Lloyd Duff Reid, �Dynamics of Flights- Stability and Control�, 3er Edición, John Wiley and Sons Inc.

[3] Martín España, �Fundamentos de la Navegación Integrada�, 2010, AADECA.

[4] Myron Kayton y Walter R. Fried �Avionics Navigation Systems�, 2da Edición, John Wiley and Sons Inc

[5] Globalsat ET-332:


117

http://www.globalsat.com.tw/products-page.php?menu=2&gs_en_product_id=4&gs_en_product_cnt_id=44&img_id=110&product_cnt_folder=3

[6] Analog Devices ADIS16400:

http://www.analog.com/static/imported-files/data_sheets/ADIS16400_16405.pdf

[7] Microchip Technology Inc. dsPic33:

http://ww1.microchip.com/downloads/en/DeviceDoc/70286C.pdf

[8] Microchip Technology Inc. PIC32MX:

http://ww1.microchip.com/downloads/en/DeviceDoc/61156G.pdf


118

Sistema de adquisición de datos y control en tiempo real para bancos de ensayos de motores

Ignacio Maffei, Orlando Micolini

Laboratorio de Arquitectura de Computadoras Facultad de Ciencias Exactas, Fisicas y Naturales

Universidad Nacional de Cordoba Córdoba, Argentina

[email protected], [email protected]

Resumen— En este trabajo se describe el desarrollo de un sistema de adquisición de datos y control para bancos de ensayos de motores de combustión interna, del cual podemos destacar las siguientes características: bajo costo y tiempo de desarrollo, robusto, escalable y reconfigurable para distintos tipos de ensayos de motores (eléctricos o de combustión).

Dicho sistema está conformado por dos subsistemas que funcionan en conjunto.

El primer subsistema es un módulo de adquisición de datos y control, cuyo núcleo es un microcontrolador Cortex M4 (32 bit), el cual ejecuta un sistema operativo en tiempo real (MQX) para realizar la adquisición, el control, y el envío y recepción de datos al siguiente subsistema.

El segundo subsistema tiene como responsabilidad la configuración, control y comunicación con el primer subsistema, como así también la visualización, corrección y almacenamiento de datos, y la generación de señales para el control de los dispositivos actuadores conectados primer subsistema. Este subsistema puede ser recompilado para distintas arquitecturas y sistemas operativos, debido a que fue desarrollado con la herramienta QT Designer.

Palabras claves— Sistema de adquisición de datos; Sistemas

Embebidos; Freescale; MQX rtos; Cortex M4;.

I. INTRODUCION

A. Descripcion General

Los bancos de ensayos de motores son utilizados para el estudio experimental de motores eléctricos y de combustión interna, permitiendo determinar sus curvas características para su investigación, optimización y mejora.

Actualmente existe mucha información general sobre los bancos de ensayos de motores. Sin embargo la información específica para desarrollar un sistema de adquisición de datos y control para un banco de ensayos de motores es escasa y genérica, puesto que esta pertenece al ámbito de empresas privadas. En esta publicación se presentan los requerimientos e implementaciones para desarrollar un sistema de este tipo, en base a información brindada por expertos de distintas áreas de ingeniería.

La arquitectura general del sistema se divide en 5 etapas: software de usuario, módulo de adquisición de datos y control, hardware de acondicionamiento de señales eléctricas, sistema a medir y actuadores.

En este informe se muestran las arquitecturas utilizadas para el desarrollo de un módulo de adquisición de datos y control (Punto IV) y el software de adquisición (Punto V).

B. Objetivo general y especifico

El objetivo general es analizar, diseñar e implementar un sistema de adquisición de datos y control reconfigurable para distintos tipos de bancos de ensayos de motores.

El objetivo específico es utilizar el sistema desarrollado para aplicarlo a un caso particular, como lo es un banco de ensayo de motores de combustión interna. Para esto se requiere desarrollar:

Un módulo que permita: la digitalización y filtrado de las señales emitidas por los sensores del banco, el control del sistema a medir a través de actuadores y la comunicación con otros subsistemas.

Un sistema capaz de interactuar con el módulo de adquisición para enviar y recibir datos, almacenarlos y visualizarlos en tiempo real mediante diferentes gráficas y curvas.

II. REQUERIMIENTOS DE USUARIO

Los siguientes requerimientos generales fueron obtenidos en base a entrevistas a expertos, operarios y fabricantes de bancos de ensayos para motores de combustión interna:

1) Medir las siguientes magnitudes físicas: Presión de aceite del motor y dinamómetro. Temperatura de agua del motor y dinamómetro. Velocidad del motor (RPM). Torque ejercido por el motor. Condiciones atmosféricas (temperatura, humedad y

presión de la sala). 2) Realizar el muestreo de datos de dos formas:

Continuo: tomar muestras automáticamente, pudiendo configurarse el tiempo de muestreo.

Por puntos: tomar muestras solo cuando el operador presiona un botón.

3) Calcular la potencia del motor ensayado 4) Cumplir con la Norma SAE J1349, la cual establece un

método estándar para la corrección de la potencia y torque medido. [1]

5) Compensar la inercia de las partes mecánicas (motor y freno) mediante un Factor de Inercia del sistema con el cual se debe corregir el torque y potencia medidos.


119

6) Controlar la cupla que ejerce el dinamómetro de corrientes parásitas al motor desde un software de usuario.

7) Controlar el acelerador del motor a ensayar desde un software de usuario.

8) Almacenar los valores medidos en forma de tabla en un archivo.

9) Mostrar en pantalla y generar un archivo de resumen del ensayo realizado con los siguientes datos: Valores mínimos y máximos medidos (corregidos y sin

corregir). Factor de corrección atmosférico y factor de inercia. Fecha, hora, nombre y duración del ensayo. Cantidad de muestras tomadas. Rango de rpm del ensayo (solo en caso de muestreo

continuo). 10) Generar los distintos tipos de gráficos (torque vs rpm,

potencia vs rpm, etc.). 11) Generar alertas visuales y sonoras cuando los valores

medidos excedan ciertos límites configurables.

En la Tabla 1 se muestran los requerimientos específicos para un banco de ensayos de motores de combustión interna, el cual se va a implementar en el Laboratorio de Ensayo de Motores de la FCEFyN de la UNC.

Requerimientos de adquisición

Magnitudes físicas

Valor máximo Resolución Bits

requeridos Período

muestreo

Velocidad motor

6000 rpm 10 rpm - 100 ms

Fuerza motor

150 kg 100 g 11 bits 100 ms

Temperatura motor

150 ºC 1 ºC 8 bits 1 s

Temperatura dinamómetro


Presión de aceite del

motor 7 bar 0,5 bar 4 bits 1 s

Humedad ambiente

100% 5% 5 bits 15 s

Temperatura ambiente


Presión atmosférica

115 kPA 10 kPA 4 bits 15 s

Requerimientos de control

Acelerador Control del acelerador a través de un accionador. Por

ejemplo un servomotor controlado por una señal digital PWM

Freno Control del freno dinamométrico a través de una

corriente analógica de referencia. Por ejemplo un salida analógica de 0 a 3 V

Tabla 1: Requerimientos específicos

Las magnitudes de humedad ambiente, temperatura ambiente y presión atmosférica son requeridas para la corrección de potencia y torque. Para más información ver norma SAE J1349 [1].

III. ARQUITECTURA GENERAL DEL SISTEMA

En la Figura 1 se muestra un diagrama en bloques del flujo de datos y control del sistema y las interrelaciones entre sus componentes.

Etapa 1 Sistema a medir

Etapa 2Conversión analógica

Etapa 3Conversión digital

Etapa 4Usuario

Etapa 5: Control

Banco de

ensayo

Módulo de

adquisición de

datos y control

Señales

digitales

Dispositivos de

control

Sensado y

adaptación

Magnitud

física

Señales

eléctricasSoftware

de usuario

Señales

analógicas/digitales

Magnitud

física

Figura 1: Arquitectura general

En la Etapa 1, el sistema a medir genera las distintas magnitudes físicas, por ejemplo: fuerza, calor, campo magnético, etc. Estas magnitudes son capturadas y convertidas a señales eléctricas mediante un transductor en la Etapa 2. Luego en esta misma etapa se acondicionan las señales eléctricas según los rangos de tensiones aceptados en la entrada de la Etapa 3.

En la Etapa 3 se encuentra el módulo de adquisición de datos y control, el cual tiene las siguientes responsabilidades:

Convertir las señales eléctricas o analógicas a señales digitales.

Enviar las muestras digitalizadas a la Etapa 4. Recibir señales de control desde la etapa 4 Controlar el sistema a medir (Etapa 1) generando las

señales analógicas o digitales requeridas por los dispositivos de la Etapa 5.

Calculo de las señales de control a partir de las señales adquiridas para enviárselas a la etapa 5.

Filtrar ruido electromagnético de las señales eléctricas.

En la Etapa 4 se encuentra el software de usuario, el cual tiene las siguientes responsabilidades:

Recibir las señales digitales enviadas desde la etapa 3. Brindar una interfaz de usuario que permita la calibración

o conversión de los datos enviados por los transductores. Mostrar, graficar, almacenar y tabular datos. Brindar una interfaz de control del módulo de adquisición

para los usuarios del sistema. Alertar sobre anomalías en el sistema a medir.

En la Etapa 5 se encuentran los dispositivos requeridos para el control del sistema a medir, los cuales reciben las señales de control calculadas en la etapa 3. Estas señales analógicas o digitales son reacondicionadas o convertidas a magnitudes físicas.

En los siguientes puntos se detallara la arquitectura para el módulo de adquisición de datos y control comprendido en la Etapa 4 y para el software de usuario de la Etapa 5.


120

IV. ARQUITECTURA DEL MÓDULO DE ADQUISICIÓN DE

DATOS Y CONTROL

De acuerdo a los requerimientos expuestos en la Tabla 1 se desprenden las especificaciones mínimas que el kit de desarrollo debe cumplir para la implementación del módulo de adquisición de datos y control. Estas son:

Velocidad de conversión mínima: 100 samples/seg. 12 bits de resolución del módulo ADC. 12 bits de resolución del DAC. 7 entradas analógicas (Sensores). 1 Salida analógica (control dinamómetro). Módulo de PWM (control acelerador) 4 I/O digitales.

Un kit de desarrollo que cumple satisfactoriamente estas condiciones, y a un bajo costo, es el Freescale Kinetis Kwikstik k40 [2]. El mismo dispone de un microcontrolador ARM Cortex M4, un SO de tiempo real y una amplia gama de módulos programables.

En la Figura 2 se muestra la arquitectura propuesta para el módulo de adquisición de datos y control para un banco de ensayos de motores de combustión interna.

Figura 2: Arquitectura del módulo de adquisición

Actuadores: dispositivos que controlan el sistema a través de señales digitales o analógicas enviadas por el módulo de adquisición de datos.

Transductores: dispositivos que convierten las distintas magnitudes físicas a medir en señales eléctricas.

Módulos para la adquisición de datos (Apartado IV.A): hardware programable, administrado y gestionado por procesos que hacen uso del scheduler del sistema operativo y las interrupciones, para llevar a cabo las tareas de adquisición de datos.

Módulos para el control (Apartado IV.B): igual que en el punto anterior, pero los procesos ahora acondiciona y envían señales de control a los actuadores.

Módulo de comunicación USB (Apartado IV.C): interfaz de comunicación en entre el software de usuario y el módulo de adquisición de datos.

SO MQX-Rrtos (Apartado IV.D): software embebido encargado de controlar todos los procesos del sistema haciendo uso de un planificador (scheduler) de tareas.

Teniendo en cuenta que este sistema estará ubicado en un ambiente altamente ruidoso, como lo es una sala de ensayos de motores, en la cual el ruido electromagnético es generado principalmente por los componentes eléctricos del motor a explosión (bujías, distribuidor, alternador, sistema de arranque, etc.) será necesario diseñar e implementar un filtro (Apartado IV.E) que elimine todo el ruido y acondicionen las señales proveniente de los sensores.

A. Implementaciones para la adquisición de datos

Para implementar los requerimientos de adquisición de datos son necesarios los siguientes módulos:

1) Módulo para la digitalización

El kit de desarrollo dispone de dos módulos de conversión Analógico-Digital. Ambos conversores pueden ser configurados para obtener las siguientes características:

Resolución de 16 bits. Tensión de referencia de 3 voltios. Tensión mínima detectada de 45,8 µV (3/216). Tiempo de muestro de hasta 72 microsegundos por

muestra.

La nota de aplicación AN4373 de Freescale [3] recomienda implementar un filtro analógico tipo “T” en las entradas de los módulos ADC como se muestra en Figura 3.

Figura 3: Filtro anti aliasing

Este filtro evitara el aliasing entre dos muestras de distinto canal cuando se utiliza el mismos módulo ADC para varios canales.

Con esta implementación se obtuvo un resolución libre de ruido de 14 bit y un tiempo de muestro mínimo de 140 microsegundos por muestra. Para lo cual se hicieron diversas pruebas, como ser: mediciones con la entrada del ADC con una batería y a masa, reemplazo de la celda de carga por un sistema estático, cambio de la tensión de referencia, entre otras.

2) Módulo para el cálculo de las RPM del motor

Generalmente, los dinamómetros disponen de una corona dentada de 60 dientes para el sensor de RPM del motor, por lo cual el módulo de adquisición deberá contar 60 pulsos externos por cada vuelta del motor. El diseño está basado en dos


121

contadores, uno para contar los 60 pulsos externos (contador A) y otro para contar el periodo (contador B) como se muestra en la Figura 4.

Figura 4: Contadores para el módulo el cálculo de RPM

Si se conoce la frecuencia del contador B, el tiempo es calculado como:

La inversa de este tiempo nos permite conocer la frecuencia de los 60 pulsos externos y así calcular las RPM del motor. El error del módulo de RPM estará dado por ±1 pulso del contador B, por lo cual los criterios a tener en cuenta para la elección de la frecuencia son:

Frecuencia del contador B: a mayor frecuencia, menor error, por lo que usaremos la mayor frecuencia que el módulo Flex Timer lo permita (48 Mhz).

Velocidad máxima del motor: a medida que aumentan las RPM del motor, el error del contador B es más significativo, por lo que se debe buscar un equilibrio entre la cantidad de dientes y la velocidad máxima y mínima a medir.

Los contadores del módulo Flex Timers de la placa seleccionada fueron utilizados para medir el tiempo entre dos eventos con una gran precisión. El contador B se configuro con una frecuencia de 48 Mhz y 32 bit para obtener la base de tiempo, mientras que el contador A se configuro con 16 bit para el conteo externo de las RPM. Se realizaron mediciones validadas entre 1 y 25 mil RPM.

3) Módulo para marcas de tiempo

El módulo RTC es utilizado para conocer el tiempo transcurrido desde que se inició un ensayo hasta su finalización. Dicho módulo dispone de una estructura de datos que es consultada para conocer los segundos, minutos, horas y días desde que el módulo ha sido iniciado.

B. Implementaciones para el control del sistema

Para implementar los requerimientos de control son necesarios los siguientes módulos:

1) Módulos de I/O digitales

Los módulos GPIO, de la placa seleccionada, permiten configurar hasta 16 entradas y salidas digitales. Las entradas digitales pueden ser configuradas en modo de interrupción por flancos de subida o de bajada y son utilizadas con múltiples propósitos para el sistema de control. Por ejemplo, una entrada fue configurada como una interrupción NMI de máxima prioridad para asegurar la respuesta a las contingencias del

sistema de control, cuando este deja de funcionar inesperadamente.

2) Módulo para el control del dinamómetro

El dirver utilizado para controlar un dinámetro por corriente de Foucault requiere una señal de entrada analógica de referencia. Al variar esta tensión analógica de referencia, el diámetro aplica mayor o menor cupla sobre el motor a ensayar.

El módulo DAC (12 bit) convertir las señales de control enviadas desde del software de usuario, en forma digital, a una señal analógica de referencia para el driver del dinamómetro.

3) Módulo para el control del acelerador

En uno de los módulos de FlexTimer se configuró una salida digital como un modulador por ancho de pulso (PWM), para controlar el driver de un servomotor. De esta forma es posible controla la posición del acelerador.

C. Módulo para la comunicación USB

La placa de desarrollo seleccionada provee el driver necesario para controlar el puerto USB a través de una comunicación serial virtual (Virtual Com), el cual fue empleado para comunicar nuestro módulo de adquisición con el software de usuario. En caso que se requiera otro tipo de comunicación, se deberá desarrollar un device driver para el sistema operativo correspondiente y desarrollar el controlador del módulo USB del el kit de desarrollo.

D. Sistema operativo MQX-Rtos

La utilización de un sistema operativo nos facilitara el desarrollo del módulo de adquisición de datos y control, ya que nos posibilita:

Disponer de un completo scheduler para la administración de interrupciones y tareas en tiempo real.

Utilizar drivers disponibles en el RTOS. Simplificar las tareas de verificación y validación. Soportar multi-hilo con sincronización. Portabilidad del código a otras CPUs. Tener resuelto el manejo de recursos. Agregar prestaciones sin afectar funciones de mayor

prioridad.

Tanto los módulos de adquisición como los módulos de control requieren ser administrados a través de tareas (periódicas o aperiódicas) y/o múltiples interrupciones, por lo cual se requiere determinar el scheduler a utilizar en el sistema operativo.

En la figura 5 se observa el tiempo límite, dado por los requerimientos, para el envío de información al software de usuario; lo cual limita que todas las tareas deben ser realizadas antes de los 100 ms.

Figura 5: Tareas del SO-MQX


122

Teniendo en cuenta que suma de los tiempos de todas las tareas que el sistema debe realizar es mucho menor al tiempo requerido para el envío de información al software de usuario, el scheduler del SO-MQX puede ser configuraron con una planificación con prioridades fijas con desalojo. Esto es, las tareas de mayor prioridad interrumpen a las tareas de menor prioridad, cuando esta termina se continua la ejecución según la prioridad de las tarea

En Tabla 2 se muestra una lista de las interrupciones y tareas que han sido configuradas en el scheduler del sistema operativo:

Prioridad Módulo Acciones

Máxima Inicialización Inicialización del SO, no existen ninguna tarea hasta que no finalice la inicialización del sistema.

1 Entrada NMI Lleva el sistema a un estado de reseteo.

2 Watchdog

Chequea el correcto funcionamiento del sistema mediante el refresco continuo de variables, en caso de no tener refresco se lleva el sistema el estado de reseteo.

3 USB:

Recepción de datos

Cambiar el estado del sistema a través de solicitudes enviadas por el usuario. Por ejemplo módulo PWM , DAC, etc.

4 FlexTimer: Contador de

pulsos

Módulo de conteo de pulsos entre dos o más flancos de subida para el módulo de RPM.

5

ADC: Conversones

para cada canal

Módulo encargado de iniciar conversiones para cada canal y almacenar datos en variables. Al final de un ciclo de conversión (muestra de cada canal) se inicia el proceso de filtrado.

6

Tarea Principal:

recolectar y enviar datos

Recolectar y enviar datos a la computadora. Luego reiniciar el proceso de conversión ADC.

Tabla 2: Tareas SO-MQX

Existen módulos que no requieren ser una tarea, ya que funcionan de forma autónoma, como es el caso del módulo contador de pulsos, el módulo RTC, etc.

E. Filtro digital de respuesta finita (FIR)

Puesto que es necesario eliminar el ruido electromagnético que existen en el ambiente que opera el sistema, es requerida la implementación un filtro pasa bajo. En base a los requerimientos este tiene una respuesta máxima de 30 hz.

Existen dos alternativas: un filtro de respuesta infinita (IRR) o un filtro de respuestita finita (FIR). Ambos filtros pueden ser utilizados para eliminar ruido electromagnético.Sin embargo se decidió implementar un FIR en vez de un IRR, debido a que los IIR poseen una respuesta de fase no lineal, mientras que los filtros FIR pueden lograr una respuesta de fase lineal. Este cambio de fase introduciría errores cuando las señales se usan en sistemas realimentados.

El filtro FIR fue diseñado con la herramienta FDAtools de Matlab con las siguientes características:

FIR pasa bajo con frecuencia de corte (Fc) de 30 hz Atenuación 10 db en la frecuencia de corte Frecuencia de muestreo (Fm) de 1 Khz.

Para la implementación del filtro FIR se utilizaron las librerías que provee Freescale [4].

V. SOFTWARE DE ADQUISICIÓN DE DATOS Y CONTROL

El software de usuario fue desarrollado con la herramienta QT-Designer. Esta herramienta permite migrar el software a distintas arquitectura y sistemas operativos de forma muy sencilla.

A. Arquitectura del software de usuario

Para el desarrollo del software de usuario de la etapa 4 de la arquitectura general del sistema (punto III), se observaron tres dimensiones necesarias:

En primer lugar, se requiere mantener la independencia entre el módulo que toma las muestras y la presentación de los resultados.

En segundo lugar, la presentación visual debe ser realizada por un módulo de visualización.

En tercer lugar, se requiere de un algoritmo para el control y para la toma decisiones.

Estos criterios simplifican el diseño y el mantenimiento del software de usuario. Un patrón que cumple con estas características es el Modelo Vista Controlador (MVC) [5]. Este modelo es un patrón de diseño basado en la separación de la aplicación interactiva en 3 capas bien definidas: procesamiento, salida y entrada. Para esto, utiliza las siguientes abstracciones:

Modelo: encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada.

Vista: muestra la información al usuario. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador.

Controlador: reciben las entradas, usualmente como eventos que codifican los movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc. Los eventos son traducidos a solicitudes de servicio ("service requests") para el módelo o la vista.

La Figura 6 muestra una representación del MVC, teniendo en cuenta la interacción entre sus componentes.

Etapa 4: Modelo Vista Controlador (MVC)

CONTROLADOR

MODELO

VISTA4

5

1

3

2

Observer: IGU

Observer: IA

Figura 6: Modelo Vista Controlador


123

El componente Vista contiene dos observers, la interfaz gráfica de usuario (IGU) y la interfaz de adquisición (IA). La interfaz de usuario captura las peticiones de usuario, mientras que la interfaz de adquisición captura las peticiones del módulo de adquisición de datos. En ambos casos se envía una solicitud al componente Controlador (1) para modificar el estado de las variables del Modelo. Luego, el componente Controlador verificara si es correcta la petición de la Vista y procederá a cambiar el estado del Modelo (2), finalmente el Controlador cambiara el contenido de la Vista (3).

El Modelo también dispone de mecanismos para notificar los cambios realizados (4-5), de modo que la Vista pueda obtener el estado del Modelo (5) y trabajar con los datos que este dispone, por ejemplo datos ingresados por el usuario, datos enviados por el módulo de adquisición, archivos, etc.

B. Desarrollo del software de usuario

Teniendo en cuenta que se debe controlar un sistema de tiempo real, fue requerido un lenguaje de programación eficiente en cuanto a uso de recursos, memoria y velocidad de ejecución. Para determinar estas características se tomó como referencia un artículo publicado en el sitio de internet debian.org [6], donde se realiza un análisis comparativo sobre el rendimiento de programas escritos en diferentes lenguajes de programación. Luego, basándonos en estos benchmarks, se confecciono una tabla comparativa (Tabla 3).

Java C++

Uso del CPU Alto Bajo

Uso de memoria Alto Bajo

Tamaño del programa Bajo Medio

Portabilidad Alta Media

Velocidad de ejecución * Lento* Rápido*

Conocimientos sobre el lenguaje Medio Medio

*Dependiente del programa a ejecutar

Tabla 3: comparativa java vs C++

En resumen, podemos decir que C++ es el lenguaje que mejor cumple con los requerimientos para este proyecto, ya que es más eficiente en el uso de memoria, consumo de procesador y tiempo de ejecución (en la mayoría de los casos).

VI. SOFTWARE DE USUARIO

En la Figura 6 se muestra la pantalla principal del software de usuario desarrollado para este proyecto.

Figura 7: software de usuario

El software de usuario dispone de 10 display reconfigurables para las muestras del ensayo, un tacómetro analógico/digital, alarmas programables, gráficas del ensayo, accionadores para controlar el banco, almacenamiento de datos en tablas y archivos, ensayos automáticos programables, tablas para la calibración de sensores, etc.

En el link de la referencia [7] se puede ver un video para un ensayo automático de un motor Brushless.

VII. CONCLUSION

En el desarrollo de sistemas complejos es dificultoso integrar software, hardware, sistemas de control y sensores; por lo cual es necesario elegir cuidadosamente el ciclo de vida para el desarrollo, los framework y las plataformas de hardware adecuadas. El presente trabajo es un caso de éxito de estas elecciones y puede ser tomado como modelo de desarrollo para sistemas similares. Además al momento de desarrollar un sistema de este tipo es fundamental tener el acceso a los expertos en las distintas áreas específicas del desarrollo para evitar largos y costos procesos de investigación en la obtención de los requerimientos del sistema.

Gracias a las características modulares de la solución planteada, tanto del software como el hardware, la flexibilidad obtenida permite ajustar el sistema a una amplia gama de configuraciones distintas según los requerimientos del banco de ensayo y el motor a ensayar.

AGRADECIMIENTOS

Los autores quieren expresar su agradecimiento a: Ing. Juan F. Giro, Ing. Mario Spinoza, Sr. Maximiliano Vázquez, Sr. Michael Watson y Sra. Fabiana de Watson. Quienes nos han brindado la información necesaria para poder documentar los requerimientos del sistema de adquisición y control de un banco de ensayo de motores de combustión interna.

REFERENCIAS

[1]. Vazquez, M. (2011). Medición de potencia de motores. Universidad Tecnológica Nacional facultad regional Córdoba.

[2]. Freescale Kwikstik-k40: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KWIKSTIK-K40

[3]. AN4373 Cookbook for SAR ADC Measurements: http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4373.pdf

[4]. Using CMSIS-DSP Algorithms with MQX: http://www.freescale.com/files/microcontrollers/doc/app_note/AN4489.pdf

[5]. Modelo Vista Controlador (MVC) http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

[6]. Comparación Java vs C++: http://benchmarksgame.alioth.debian.org/u32/java.php

[7]. Software de usuario: http://www.youtube.com/maffeiignacio


124

Sistema inalámbrico de microestaciones meteorológicas para aplicaciones agropecuarias

Presentación general del sistema

Brengi, Diego1; Canziani, Monica1; Gomez, Rodrigo1; Gwirc, Sergio1; Lupi Oreste1; Moltoni, Andrés2; Nassipián, Veronica1; Slawiski Javier1; Zaradnik, Ignacio1

1Laboratorio de Inteligencia Ambiental, Departamento de Ingeniería e Investigación Tecnológica Universidad Nacional de la Matanza. Buenos Aires, Argentina.

2Laboratorio de Electrónica, Instituto de Ingeniería Rural, Centro de Investigación de Agroindustria, Instituto Nacional de Tecnología Agropecuaria. Castelar, Buenos Aires., Argentina.

[email protected]

Abstract—Las exigencias para la exportación y el consumo de alimentos de origen agropecuario requieren de un mayor control de los procesos de producción desde su inicio, donde las variables climáticas son las que determinan las características finales del producto. Para aumentar la competitividad de las empresas productoras, se requiere cada vez mas monitorear las condiciones micro-climáticas de cada una de las áreas ganaderas de la finca o superficie cultivada. El proyecto responde a la necesidad de monitorear los distintos parámetros “agro-meteorológicos” como ser temperatura de aire, tierra y las hojas, radiación solar, presión atmosférica, humedad, etc. Este monitoreo requiere de sensores y dispositivos de bajo costo, con múltiples opciones de alimentación e inalámbricos para facilitar su instalación y mantenimiento. Se presenta el diseño y desarrollo de un sistema inalámbrico de microestaciones de este tipo para el monitoreo de los parámetros agro-meteorológicos claves para controlar y asegurar la calidad y trazabilidad de la producción. En el trabajo se incluye la definición de características del dispositivo, la selección de componentes, la implementación del hardware y firmware asociado. Se hace referencia también, a los otros elementos del sistema así como a la aplicación agropecuaria que se utilizara como testigo del sistema.

Keywords- microestación, denominación de origen, criadero de pollos, transceiver, microcontrolador, paneles solares, Builder.

I. INTRODUCCIÓN

En los últimos años se viene manifestando un aumento del consumo de alimentos de origen agrícola, el cual se aprecia en las exportaciones de los denominados productos primarios y productos de manufacturas de origen agropecuario [1][2]. Así mismo, las exigencias del mercado de alimentos, están vinculadas de forma creciente con la pureza, la autenticidad y la sostenibilidad de los alimentos, ya que aún con la crisis, los consumidores siguen optando por alimentos con alto valor agregado [3].

Para poder lograr cualquier tipo de Certificación y o “Denominación de Origen” es condición “sine qua non” contar con su trazabilidad.

Esto requiere de un mayor control de los procesos de producción desde su origen, esto es en el campo donde las variables climáticas son, en gran medida, las que determinan las características finales del producto.

Por lo tanto, la necesidad de monitorear los distintos parámetros “agro-meteorológicos”, a fin de asegurar la calidad del producto y la obtención de las posteriores certificaciones y/o denominaciones, requiere de sensores y dispositivos de bajo costo y que soporten las condiciones de uso y ambientales habituales en este medio. Además que contemplen la necesidad de eliminar cableados en el área de laboreo, que dificultan la instalación y la continuidad de los resultados.

II. APLICACIÓN AGROPECUARIA

A. Selección de la aplicación

Si bien el proyecto planteado busca servir en forma general para cualquier aplicación agropecuaria, desde una aplicación de agricultura como ser el cultivo de olivos [4], hasta una aplicación de ganadería como ser el engorde vacuno [5], a fin de poder hacer pruebas sobre el hardware, firmware y software desarrollado se seleccionó la aplicación de un criadero de pollos.

Este tema tiene varios puntos interesantes, entre los que se pueden citar, el aumento en el consumo de carne de pollo, del orden del 40%, que el nivel de las exportación de la misma en los últimos años [6], se ha convertido en una de las principales exportaciones de la Argentina [2] y la moderna unidad de investigación avícola que se plantea construir en el INTA de Concepción del Uruguay, la cual tiene como objetivo el asegurar una alta excelencia en investigación, extensión, capacitación y servicios de diagnósticos que permitan a las empresas acreditar la calidad de los productos comercializados


125

en Argentina y en los países a donde llegan las exportaciones [7].

B. Parámetros de la aplicación

Para determinar los parámetros mas importantes a medir se analizó la información disponible sobre el manejo de pollos de engorde [8][9][10]. En estos se observa que existe una gran cantidad de parámetros que afectan al desarrollo de los pollos, los cuales se detallan a continuación:

Temperatura del agua.

Presión y flujo del agua.

Temperatura del interior y el exterior del galpón.

Humedad ambiente.

Temperatura y humedad de la cama.

Velocidad del aire.

Concentración de gases.

Presiones barométricas (interna del galpón y externa).

Temperatura exterior.

Niveles de iluminación.

Para esta aplicación se seleccionaron, la temperatura y humedad ambiente, los niveles de iluminación, la concentración de gases y la velocidad del aire. Todos ellos de gran incidencia en la productividad tal como los demuestran, los trabajos que se citan en [11-16].

III. SISTEMA INALAMBRICO DE M ICROESTACIONES

A. Descripción general

El sistema está formado por cuatro partes: la microestación, de la cual se puede ver el diagrama en bloques en la figura 1; la estación colectora de datos; el servidor de datos, y el software de gestión.

En nuestra aplicación testigo, criadero de pollos, varias microestaciones son distribuidas en un galpón, midiendo los parámetros necesarios en cada punto. Las mismas permanecen en un modo de ahorro de energía la mayor parte del tiempo, lo que permite un reducido consumo. Dado un intervalo de tiempo previamente configurado, el cual depende de la aplicación en particular, la microestación sale de este modo y efectúa la medición de sus sensores. La información de cada microestación se transmite en forma inalámbrica a la estación colectora. Esta realiza un análisis local de los datos, pudiendo activar algún tipo de alarma, y luego reenvía los datos a un servidor conectado a internet. El software de gestión se conecta al servidor, del cual obtiene los datos para trabajar. A través de este se puede evaluar la evolución de los distintos parámetros de nuestra aplicación, configurar alarmas, generar informes y otras tantas funciones.

Para ofrecer mayor flexibilidad al sistema, la microestación está formada por dos placas, una que pretende ser estándar para todas las aplicaciones agropecuarias y una particular para cada una de las aplicaciones. La placa estándar incluye el

transceiver, el microcontrolador, la fuente de alimentación y los sensores más comunes. La particular incluye los sensores específicos de cada aplicación y las etapas necesarias para adaptar las señales de estos y enviarla a la placa estándar. En nuestro caso los sensores especiales son el de velocidad de viento y los de gases.

Figura 1. Diagrama en bloques.

B. Selección de Sensores

Para esta selección, además de las especificaciones técnicas, se tuvieron en cuenta los siguientes factores: disponibilidad en el mercado local y la disponibilidad en venta por catalogo (tipo Digikey, Farnell, Newark, RS), costo, montaje y tipo de interfaz.

Temperatura ambiente. Se selecciono el modelo AT30TS75 o ATS30TS75x de la firma ATMEL, el cual posee encapsulado SOIC 8, registros no volátiles, EEPROM de hasta 8K, precisión en nuestro rango de 0,5°C, salida digital I2C [17]. Si bien en esta aplicación el sensor no se utiliza, ya que el sensor de humedad ambiente que se presenta a continuación incluye el de temperatura, en aplicaciones donde la medición de la humedad no es necesaria reducirá los costos integrar este en lugar del sensor combinado.

Humedad ambiente. Se eligió el modelo Si7005-B de la firma Silabs, el cual no sólo mide la humedad relativa sino también la temperatura, posee encapsulado QFN de 4x4mm, precisión en nuestro rango de +- 4,5% RH y 0,5°C, y salida digital I2C [18].

Luz ambiente. Se optó por el modelo SFH 7773 de la firma OSRAM. La selección del mismo se debió básicamente al costo y a que posee un salida digital I2C [19].

Concentración de gases. Luego de analizar la aplicación se determino que los principales gases a medir son el Dióxido de Carbono (CO2) y el Amoniaco (NH3). En función de esto se seleccionaron en modulo CDM4160 para la medición de CO2 y el modulo EM2444 para la medición de NH3, ambos de la firma Figaro [20][21].

Velocidad del aire. Para la medición de este parámetro se utiliza un puente Wheatstone con termistores. En dos de sus ramas se colocan los


126

mismos, una rama expuesta al viento y la otra totalmente aislada de este.

C. Fuente de Alimentación

Si bien la aplicación sobre la cual el sistema será utilizado determina fuertemente las disponibilidades de suministrar energía al sistema, el diseño de la fuente de alimentación se analizó y desarrolló teniendo en cuenta distintas posibilidades, las cuales se detallan a continuación:

Alimentación a través de paneles solares.

Alimentación por medio de baterías.

Alimentación a través de la red eléctrica.

Para lograr dicho cometido la fuente a utilizar debía tener un circuito de carga y alimentación capaz de alimentar el sistema de telemetría y al mismo tiempo efectuar la carga de una batería de Li-Ion. Adicionalmente el circuito de carga debía poseer la capacidad de ser conectado a la red eléctrica para efectuar una carga rápida de la batería.

Para aplicar la primera de las posibilidades enumeradas, se ubicaron localmente paneles solares que se adaptaran a nuestras necesidades, y se seleccionaron los ST04-XI [22].

Estos paneles entregan alrededor de 5 V a circuito abierto y 100 mA en cortocircuito, y la potencia máxima es de 0.25W (3.9 V / 64 mA) en condiciones de luz solar (1000 W/m2) con dimensiones de 60mm x 60mm x 2mm.

Para cumplir con las necesidades de tensión y corriente de carga, se utilizaron cuatro paneles solares conectados en configuración serie/paralelo. Lográndose una corriente de salida máxima de 90 mA.

La inclusión de una batería recargable en el sistema de alimentación hace que la microestación tenga total independencia de cableados para la alimentación.

Para los ensayos del circuito de alimentación se empleo una batería de litio estándar de telefonía celular, la cual tiene las siguientes características

Tensión: 3,7 [V];

Corriente: 1500 [mAh];

Potencia: 5,6 [Wh].

Para el circuito de carga y alimentación. Se analizaron distintas alternativas las cuales se resumen en la tabla 1.

Fabricante Modelo Imax [A] VCCmin[V] VCCmax[V]

ON Semiconductor NCP1852 1,8 3,6 7

Microchip MCP73833 1,2 3,75 7

Maxim MAX8903A 2 4,15 16

Texas Instruments BQ24071 2 4,36 16

Tabla 1. Soluciones de fuentes.

De las cuatro opciones de la tabla, las dos primeras tienen un reducido rango de tensión de entrada. Si bien los chips de

Maxim y de Texas Instruments son equivalentes desde el punto de vista de los parámetros eléctricos, el BQ24071 permite implementar un circuito más reducido, ya que no requiere el uso de ningún inductor, mientras que si lo requiere el MAX8903A de Maxim, motivo por el cual se utilizo el de Texas Instruments [23].

De esta forma se logro que el sistema pueda trabajar a través de paneles solares y/o baterías. En caso de ser conectado a la red eléctrica, dicha conexión se realiza a través de una fuente AC/DC que entrega una tensión de salida continua de 12V, rango el cual es tolerado por el BQ24071.

D. Enlace inalámbrico

Dado que la intención del proyecto es el desarrollo de una solución genérica y de bajo costo, aplicada en este caso a criadero de pollos, se decidió que la etapa de transmisión inalámbrica de la microestación debía ser diseñada y desarrollada, desde el principio y no emplear uno de módulos disponibles en el mercado, tal como se hace en muchos trabajos donde el foco es la aplicación [24-27] y no una solución genérica como esta.

Luego de analizar las posibilidades accesibles localmente se eligieron dos circuitos integrados de ATMEL, los transceivers AT86RF212 y AT86RF231/2. La elección se fundamenta principalmente en que ambos chip son pin a pin compatibles y con ellos se puede implementar tanto un transceptor en las bandas “SubGhz” (AT86RF212) o en 2.4Ghz (AT86RF23x) [28][29]. Esto permite que el resultado sea empleado en un amplio abanico de aplicaciones, simplemente montando en el circuito los componentes adecuados. Puntualmente para nuestra aplicación, se empleara el AT86RF23x, ya que el alcance no es un parámetro critico.

Estos mismos transceivers se encuentran integrados en módulos más complejos disponibles en el mercado, los módulos Zigbit ATZB-24-B0/A2 y ATZB-900-B0 [30][31]. Dichos módulos no solo integra uno de estos transceivers, sino que también un microcontrolador ATMEGA1281 y todos los componentes necesarios para el funcionamiento del sistema, inclusive en algunos casos la antena. Esto permite el desarrollo del firmware en forma paralela al diseño del hardware. La figura 2 muestra una imagen de la placa desarrollada con estos módulos para el desarrollo del firmware, mientras se diseña la placa del microsensor.

Figura 2. Placa con modulo Zigbit de ATMEL basado en AT86RF23x y ATMEGA1281.

E. Microcontrolador

El microcontrolador seleccionado fue el ATMEGA1281, ya que es integrado en los módulos Zigbit [30][31]; ATMEL


127

ofrece un stack ZigBee Pro tanto para los módulos de 2.4GHz como para los SubGHz, lo que permite aumentar el alcance de la red inalámbrica más allá del que tiene los módulos; posee múltiples tipos de interfaces seriales (I2C, SPI, UART), y entradas analógicas (ADC) [32]. Estas dos últimas características le permite una buena interacción con los sensores seleccionados.

IV. ESTACIÓN COLECTORA

Para la estación colectora de los datos se selecciono un microcontrolador de 32 bits de ATMEL, el ATSAM3X [33]. La elección de este se apoya en cantidad y tipo de interfases de comunicación que posee, USB, SPI, I2C, Ethernet y UART.

Par el desarrollo del firmware se empleo el kit de evaluación del microcontrolador seleccionado [34], junto al cual se integraron una de las placas con modulo Zigbit y un modem GSM/GPRS. En la figura 3 se puede ver una imagen del kit empleado.

Los datos son recibidos por la placa con modulo Zigbit y enviados al microcontrolador central a través de una interfaz serial, el cual los retransmite a un servidor en internet a través del modem GSM/GPRS o a través de una conexión Ethernet.

Figura 3. Kits de desarrollo de ATSAM3X.

V. FIRMWARE DE LOS MICROSENSORES

El firmware de la microestación se basa en el stack Zigbee Pro que ofrece ATMEL, el BitCloud. El mismo es ofrecido para varias de sus plataformas, la empleada por nosotros es “BitCloud SDK for ZigBit/ZigBit Amp/ZigBit 900 modules and RCBs”.

En una red Zigbee un dispositivo puede tener tres tipos de funcionalidades: Coordinador, Router o End Device. Dicha funcionalidad se configura simplemente por uno comando “define” en la estructura del stack [35]. Tal como mencionamos antes el alcance no es crítico en nuestra aplicación, sin embargo la vida útil de la batería tiene mayor relevancia. Con esto en mente la red está formada por un coordinador, el cual se encuentra ubicado en la estación colectora y las microestaciones que implementan la funcionalidad de End Device, las cuales estarán “durmiendo” y se “despertarán” cada un intervalo de tiempo y transmitirán los parámetros de sus sensores.

El firmware del microcontrolador de las microestaciones implementa además las siguientes rutinas: lectura y escritura de la interfaz I2C, para la configuración y adquisición de los valores de los sensores colocados ella; lectura de las entradas analógicas, donde están conectados los sensores de velocidad de aire y concentración de gas, y el manejo de los pines de entrada y salida.

Para el desarrollo de este firmware se tomo como base el firmware de la aplicación Wireless Sensor Network (WSNDemo) provista por ATMEL dentro del BitCloud.

VI. FIRMWARE DE LA ESTACIÓN COLECTORA

Una vez realizada la inicialización del microcontrolador, es decir puertos, interfaces, oscilador, watchdog, etc., el dispositivo permanece en un ciclo infinito en el cual chequea si ingresa algún dato y monitorea la conexión GSM/GPRS o Ethernet según la que se haya configurado. El chequeo del ingreso de los datos y el monitoreo de la conexión se realizaran por el llamado a dos subrutinas en el programa principal, dentro de las cuales se implementa una máquina de estado para cada una de estas funciones.

Si comienzan a ingresar datos, la máquina de estado que monitorea estos verifica si tienen el encabezado correcto, si lo tienen comienza a almacenarlos hasta que llega el caracter de fin de datos. Una vez recibido el dato completo se informa la recepción del dato a través de la puesta en “1” de una bandera. Si la conexión no está disponible, el dato es almacenado en memoria no volátil hasta que esté disponible una conexión.

Los datos recibidos pueden ser enviados a un servidor propio en el cual se ejecuta un software de base de datos, o puede ser un servidor de correo, como ser Yahoo o Gmail, donde los datos son almacenados como correos electrónicos. Un ejemplo de esto último es lo planteado en “Diseño e Implementación de sistema Embebido para Telemetrizar Estaciones Limnimétricas”[36].

La máquina de estado que se encarga de la conexión GSM/GPRS o Ethernet hace que el dispositivo siempre tenga una dirección IP asignada. Una vez que los datos son recibidos y la bandera de recepción es puesta en “1”, la máquina de estado abre un puerto TCP en el servidor remoto que se haya configurado, el cual puede ser propio o de correo electrónico.

La elección de un socket TCP se fundamenta en que este protocolo es orientado a la conexión a diferencia de UDP, el que implicaría la implementación de una rutina de confirmación de datos. Además TCP es la base del protocolo SMTP, el cual se debe implementar para el envío de correos electrónicos contemplados en esta aplicación, como se detalló arriba.

Una vez abierto el puerto TCP, si el servidor es propietario, se transmiten los datos, cerrando el puerto luego de esto, poniendo la bandera en “0” y volviendo al estado de espera. Si el servidor del cual se abre un puerto es un servidor de correo electrónico se debe implementar el protocolo SMTP, el cual incluye una codificación Base 64 para el envío del usuario y la contraseña de la cuenta. Todas estas tareas son


128

desarrolladas en la máquina de estado encargada de la conexión GSM/GPRS.

El entorno de trabajo para este firmware es el ATMEL Studio 6, entorno de desarrollo propietario de ATMEL el cual trabaja por defecto con un compilador GCC y además incluye el ATMEL Software Framework, conjunto de librerías que agilizan el desarrollo del firmware.

VII. SOFTWARE

El software de gestión provee conectividad con cualquiera de los servidores detallados en el párrafo anterior, registro de datos y permite la elaboración de estadísticas históricas de los establecimientos. La información se puede discriminar por microestación y particularmente por cada sensor. En líneas generales, el software permite visualizar sobre un mapa la ubicación geográfica de los establecimientos que se están monitoreando, figura 4, y ver su estado general.

Figura 4. Pantalla principal.

Permite realizar incorporación de nuevos establecimientos, microestaciones de trabajo y/o sensores en cualquier momento, figura 5.

Figura 5. Ingreso de nuevos elementos.

Adicionalmente, se muestra la tendencia de las variables de manera simple de comprender, pudiendo realizar comparaciones entre distintas estaciones ó sensores, o bien contrastar valores esperados/planificados contra valores reales

obtenidos. Estos informes se pueden realizar de manera histórica, como se mencionó, o por periodos, figura 6.

Figura 6. Histórico de variables.

El software de gestión se desarrollo utilizando las herramientas de Google Maps para la ubicación geográfica y el Builder C++ como software de programación.

VIII. CONCLUSIONES

Por tratarse de un proyecto aún en desarrollo las conclusiones que se detallan a continuación son parciales.

Se ha logrado desarrollar una plataforma de amplias funcionalidades para el monitoreo y la trazabilidad de parámetros microclimáticos en aplicaciones agropecuarias. La flexibilidad obtenida con la configuración de dos placas en la microestación permite la implementación de distintos tipos de ellas, logrando tener un hardware estándar y no estar desarrollando todo desde cero en cada nueva de aplicación.

El software de gestión presenta una interfaz amigable e intuitiva que facilita al usuario la interpretación de los datos. Se prevé para concluir el desarrollo del software de gestión la posibilidad de mostrar cada sensor en tiempo real de manera amigable mostrando estados instantáneos.

Finalizado el proyecto actual se planean como siguientes pasos en esta línea de investigación la utilización del sistema en otras aplicaciones agropecuarias, lo que implicara el estudio de estas y tal vez la implementación de nuevos sensores. El control de dispositivos que actúen sobre el sistema, como ejemplo podemos citar sistemas de ventilación o calefacción en los criaderos de pollos, sistemas de riego en cultivos, etc. Y la suma de inteligencia a la estación colectora, que le permita actuar sobre los sistemas en función de parámetros previamente configurados.

REFERENCIAS

[1] http://www.alimentosargentinos.gov.ar/contenido/sectores/AyB/estadisticas/GR/GR_expo.html

[2] http://faostat.fao.org/site/342/default.aspx

[3] Observatorio Virtual Agroindustrial N°6 Diciembre 2011.

[4] Implementación y análisis de diferentes modos de control automático de un sistema de riego por goteo en olivos. 40JAIIO - CAI 2011 - ISSN: 1852-4850


129

[5] Desarrollo de una calculadora nutricional de engorde vacuno para el apoyo de la docencia investigación y la extensión. 39JAIIO - CAI 2010 - ISSN:1852-4850

[6] http://www.cronista.com/negocios/Mas-pollo-en-la-mesa-de-los-argentinoscrecio-40-el-consumo-en-seis-aos-20120716-0022.html

[7] http://www.proyeccionagroindustrial.com/index.php/home/1-noticias/1186-moderna-unidad-de-investigacion-avicola

[8] COBB Guia de manejo del pollo de engorde. 2008. cobb-vantress.com

[9] ROSS Enviromental management in the broiler house. 2010.

[10] Arbor Acres Broiler management guide. 2009.

[11] Efecto de la temperatura y la humedad relativa en los parámetros productivos y la transferencia de calor en pollos de engorde. Rev Col Cienc Pec 2007; 20:288-303.

[12] El efecto del medio ambiente sobre la presencia del síndrome ascítico en el pollo de engorda. Arce MJ, López CC, Ávila GE. Vet Mex 1998; 29.

[13] Measuring ventilation using carbon dioxide balances: Evolution of CO2 production from litter in two broiler cycles. IX International Livestock Environment Symposium, 2012. Paper Num: ILES12-0503.

[14] Mapping Thermal Environment Inside Broiler Barns for the Diagnosis of Cold Stress at Bird Initial Growing Stage. IX International Livestock Environment Symposium, 2012. Paper Num: ILES 12-0694.

[15] Different Light Intensity On The Behavior And Welfare Of Commercial Broiler Chicks. IX International Livestock Environment Symposium, 2012. Paper Num: ILES12-1766.

[16] Performance and Preference of Broiler Chickens under Different Light Sources. IX International Livestock Environment Symposium, 2012. Paper Num: ILES12-1847.

[17] http://www.atmel.com/products/Other/digital_temperature_sensors/digital_temperature_solutions.aspx

[18] http://www.silabs.com/products/sensors/humidity-sensors/Pages/si7005.aspx

[19] http://catalog.osram-os.com/catalogue/catalogue.do?act=showBookmark&favOid=000000010003ac1809c9003a

[20] http://www.figaro.co.jp/en/data/pdf/20091110153854_38.pdf

[21] http://www.figaro.co.jp/en/data/pdf/20130226105448_39.pdf

[22] http://www.gmelectronica.com.ar/catalogo/pag81.html

[23] http://www.ti.com/product/bq24071

[24] Red de sensores para monitoreo costero de temperatura utilizando dispositivos analogicos-digitales reconfigurables. Congreso de Microelectrónica Aplicada 2010.

[25] Arquitectura de un nodo sensor para aplicaciones de supervision ambiental. Implementacion de un nodo prototipo reconfigurable. Congreso de Microelectrónica Aplicada 2011.

[26] Sistema inalámbrico de monitoreo de temperaturas para seguimiento de cadena de frío en la industria frigorífica. Congreso de Microelectronica Aplicada 2011.

[27] Equipo portátil y autónomo para registro de presión sangínea intradiaria. Congreso Argentino de Sistemas Embebidos 2012.

[28] http://www.atmel.com/devices/at86rf212.aspx

[29] http://www.atmel.com/devices/AT86RF233.aspx

[30] http://www.atmel.com/tools/ZIGBIT2_4GHZMODULEWITHBALANCEDRFOUTPUT.aspx

[31] http://www.atmel.com/tools/ZIGBIT900MHZMODULEWITHBALANCEDRFOUTPUT.aspx

[32] http://www.atmel.com/devices/atmega1281.aspx

[33] http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx

[34] http://www.atmel.com/tools/SAM3X-EK.aspx

[35] Atmel AVR2050: Atmel BitCloud Developer Guide.

[36] Implementación de sistema Embebido para Telemetrizar Estaciones Limnimétricas. Congreso Argentino de Sistemas Embebidos 2012.


130

Smart wireless sensor for industrial machinery health monitoring

Rodrigo José Carbajales GAEN – Bariloche Atomic Center – CNEA

Balseiro Institute. UNCuyo San Carlos de Bariloche, Río Negro, Argentina

[email protected]

Martín René Vilugrón GAEN – Bariloche Atomic Center – CNEA

San Carlos de Bariloche, Río Negro, Argentina [email protected]

Abstract—This paper presents a low-cost solution for

improving structural health monitoring in industrial machine s using an smart wireless sensor. Based on measuring vibration with the sensor placed in different places such as on housing, on pipes, even rotating shafts, the proposed system calculates the spectrum from machinery to show changes in normal operation. Implementation of the Real-Valued FFT algorithm in TinyOs inside the ultra-low power module is developed.

Keywords—Smart Wireless Sensor, Industrial Machinery Health Monitoring, Real-Valued FFT Algorithm, Tinyos.

I. INTRODUCTION

In general, there are three instances when machinery maintenance tasks are required, when they break down, when scheduled (preventive) or when they are about to fail (predictive) [1].

In the first approach there is no preventive maintenance tasks, in the second, tasks are established periodically and both maintenance and inspection require the shutdown of the machine for any work to be done. In predictive maintenance, monitoring the trending and analysis of the performance parameters detect and identify developing problems before failure and extensive damage can occur. In early detection of the problem a shutdown for repair can be scheduled conveniently, saving time, money and damage to the machine.

Advances in wireless technology and embedded processing have made wireless systems an appealing solution for predictive monitoring. By removing the wires, hard to reach places can be instrumented with a variety of sensors, also this can be done in rotating and moving parts. Devices can be attached to the equipment to measure misalignment of couplings, bearing and gears, unbalance of rotating components, deterioration of rolling-element bearing, gear wear, rubbing, resonance, etc. to detect problems before they do any damage.

For example, in [2] on-shaft vibration measurement method using wireless transmission of the vibration signals has been proposed as a concept for the future condition monitoring system.

The smart sensor measures vibration in a period of time with a selectable resolution and process the Real-Valued FFT

algorithm. The aim of applying this algorithm is to calculate the spectrum directly in the sensor and quickly identify the source of the trouble and take corrective action depending of main vibrating frequencies.

Also it is important for example to measure modal frequencies for not having motors rotating at the same frequency of the system. If rotating frequency is equal to modal frequency, resonance can destroy part of the installation.

The smart sensor could be a part of a Wireless Sensor Network (WSN) where different sensors cooperate to distribute the information to a collection system.

II. DESIGN AND IMPLEMENTATION OF A WIRELESS SENSING

A. SMART SENSOR PLATFORM

The smart Platform sensor used in this research is the Zolertia Z1 [8] (Fig. 1). The Z1 is built with Texas Instruments‟s ultra-low power processor MSP430x family (Msp430F2617) [10]. The onboard memory of the Z1 is limited, correct sampling rate and data acquisition values are important. It has only 8KB of integrated RAM and 92KB of flash RAM.

The Z1 is equipped with two on board digital sensors, accelerometer and temperature, communicated through I2C (Inter-Integrated Circuit: a two-line serial data bus that supports multiple data channels).

Fig. 1. Zolertia Z1 platform.


131

TABLE I. ZOLERTIA Z1 MAIN FEATURES

16-bit Ultra-Low-Power MCU 92KB flash, 8KB RAM 2.4 GHz RF Transceiver IEEE 802.15.4 & 6LowPAN ready

3-Axis Digital Accelerometer Configurable to ±2/4/8/16 g, events interrupts

Low Power Digital Temp. Sensor ±0.5°C accuracy Multiple Power Options USB powered, 2xAA/AAA, coin cell

52-pin Expansion Connector ADCs, DACs, SPI, I2C, UARTs, interrupts, USB

2 Antenna Options Embedded ceramic or U.FL external adapter

Price 3xZ1 kit 299 €

Z1 platform is attractive because, as it is shown in Table I,

it is low-power and has multiple power options (e.g. USB, 2 AA/AAA, coin cell or LI-ion batteries).

The radio transceiver is CC2420 [11] compatible with IEEE 802.15.4 [7] It has 2 antenna options (embedded ceramic or external antenna) which make it compact and easy to place in shafts or small places. Two different sensors are embedded, temperature TMP102 [13] and accelerometer ADXL345 [12] shown ahead.

It works with TinyOS [9] that is the open-source operating system used specially designed for wireless sensor network in UC Berkeley. TinyOS [3] is independent from hardware and makes focus in low power devices.

B. Accelerometer ADXL345

The accelerometer provided with the Z1 is an Analog Devices ADXL345. Fig. 2 shows a functional block diagram. It is small, thin, low-power, 3-axis accelerometer with high resolution (13-bit) measurement up to ±16 g. Digital output data is formatted as 16-bit two‟s complement and is accessible through I2C digital interface. Its high resolution (3.9 mg/LSB) enables measurement of inclination changes less than 1.0°.

Main specifications are presented in table II. The accelerometer is user configurable; in this case, it was configured to work with an output data rate 800 Hz with a consumption of 140 µA and configured to work in the range of ±2g, 10 bits resolution.

Fig. 2. ADXL345 Functional Block Diagram

TABLE II. ADXL345 MAIN SPECIFICATIONS

Parameter Value

Axes 3 Measurement Range ±2, ±4, ±8, ±16 g

Resolution 10, 11, 12, 13 bits Max. Bandwidth 1600Hz

Power supply 2 to 3.6V Noise density, x - y axes and z axis 0.75 - 1.1 LSB rms

C. Real Valued FFT algorithm

Fast Fourier Transform (FFT) is a fast algorithm to perform frequency analysis of discrete signal [4]. An algorithm computing the Discrete Fourier Transform (DFT) requires, to compute N complex values, N2 arithmetical operations, N2 complex multiplications and N2-N complex additions. Direct computation of the DFT is inefficient primarily because it does not exploit the symmetry and periodicity properties.

The classic FFT algorithm takes N (usually a power of 2, otherwise padding is necessary) complex values as input, reshuffles the input array by bit reversing, computes the result by employing a divide-and-conquer strategy. This algorithm requires N log(N) arithmetical operations, (N/2) log2(N) complex multiplications and N log(N) complex.

The classic FFT is memory inefficient when dealing with real value input, since it wastes memory to store the imaginary part which is initially set to zero. Real-Valued algorithms [5] solve this problem and reduce the memory requirement by a factor of two by exploiting the symmetry properties of the Fourier Transform.

The algorithm is implemented in TinyOS [6]. It takes N values from the accelerometer with a frequency sample of fs. Then the algorithm makes decimation in time to reorder the data. Finally a vector already stored in memory with the value of twiddle factors with the trigonometric constant coefficients that are multiplied by the data.

III. CURRENT STATUS

A. Framework Integration

The program implemented in Z1 measures the accelerometer with a maximum rate of 1 ms and measuring 1024 points per period in 1 Hz resolution.

fs=1kHz, N=1024, f=1Hz

After one second of measurement of 1024 values from the accelerometer, implementation of FFT algorithm takes place, finally the information processed inside Z1 with real and imaginary value of the spectrum is sent through the radio directly to the collecting system.

The collecting system comprises another Z1 connected to a computer via serial communication thought the USB connector to be stored or visualized. The information is sent point to point to the collecting system but the wireless smart sensor could be part of a WSN in a mesh topology.


132

TABLE III. DIFFERENTS TIME SAMPLE AND RESOLUTION

Sample Time (ms)

Sample Frequency (Hz)

BW (Hz) Points Resolution (Hz)

1 1000 512 1024 1 2 500 250 1024 2 10 100 50 1024 10

The program takes 1 second to measure 1024 points data from the accelerometer and takes 0.24 seconds to process the real-valued FFT algorithm. The spectrum is sent wireless in 5 seconds.

Maximum time sample reached with Z1 in TinyOS is 1ms. A better resolution can be reached by sacrificing the maximum bandwidth, increasing the time sample as seen in Table III.

B. Results

A measurement of vibration was taken in a pipe attached in a side to a pump with a motor at the end and in the other side a heat exchanger (Fig. 3). The sensor is fastened to the pipe where it has the maximum vibration. In Fig. 4 the raw data from the accelerometer is shown.

To measure the Real-Valued FFT algorithm performance in Z1, it was compared to a FFT algorithm implemented in Matlab. In Fig. 55 both spectrum are shown.

A comparison of both FFT algorithms is shown in Fig. 66. Taking Matlab FFT as reference the difference is d = 0.026±0.074% demonstrating that the Real-Valued Algorithm is acceptable.

C. Future work

A program modification can be expected in the future, implementing an algorithm for detecting the principal frequencies. With this value detect when there is a deviation in amplitude or in frequency. For example, implementation of a Zoom FFT algorithm to have a better resolution where is desirable.

Fig. 3. Sensor attached to the pipe

0 0.2 0.4 0.6 0.8 1-2

-1.5

-1

-0.5

0

0.5

1

1.5

2Raw data from Accelerometer y(t)

Time (seg)

y(t)

(g

)

Fig. 4 Accelerometer data.

An alarm can be sent just when changes take place, also a coded alarm will inform the type of problem the machine is having. So a diagnostic and probable solution will be informed directly from the sensor to schedule reparation in advance.

IV. CONCLUSION

Smart wireless sensor node provides an easy to install platform to collect the data required for example to measure vibration. As the raw data from the accelerometer is not completely useful, implementation of a Real FFT algorithm for a pre processing data to obtain the spectrum of the vibration is desirable. This ability can be used to automate monitoring and damage detection in an economical manner.

A 1024-points Real-Valued FFT algorithm is implemented in TinyOS to measure with a maximum sampling time of 1ms (sampling rate 1 kHz) in 240ms.

0 100 200 300 400 5000

10

20

30

40

50Single-Sided Amplitude Spectrum of y(t) from Z1 and Matlab

Frequency (Hz)

|Y(f

)| Z

1

Z1Matlab

Fig. 5. Both spectrums, from Matlab and from Z1


133

0 100 200 300 400 5000

0.05

0.1

0.15

0.2

0.25

0.3

Difference between both FFT algorithms

Frequency (Hz)

Dif

fere

nce

%

Fig. 6. Porcental difference between FFT algorithms

The Real Value FFT algorithm implemented inside the Z1 is compared to the one realized with the raw data from the accelerometer in Matlab. Taking the second one as the reference value, the difference between them is below 0.3%.

The wireless sensors can be part of a WSN making a reduction in the amount of information sent to the network where many sensors coexist. This is a network data reduction and also a reduction in the sensor consumption. Also they are important to measure where wires cannot be used, such as rotating shafts at machines in operation.

V. REFERENCES

[1] S.Rao, “Mechanical vibrations” (5th edition), Pearson Education, 2011

[2] F. Phillipp, J. Martinez, M. Glesner, and A. Arkkio. “A SmartWireless Sensor for the Diagnosis of Broken Bars in Induction Motors” 2012 13th Biennial Baltic Electronics Conference. Estonia, 2012.

[3] P. Levis, “TinyOS programming”, http://csl.stanford.edu/pal/pubs/tinyos-programming.pdf.

[4] J. Proakis, D. Manolakis “Digital signal processing” Pearson Prentice Hall, 2007

[5] H. Sorensen, D. Jones, M. Heideman, C. Burrus "Real-valued fast Fourier transform algorithms," IEEE Transactions on Acoustics, Speech and Signal Processing, vol.35,pp.849-863, 1987.

[6] N. Xu, “Implementation of Data Compression and FFT on TinyOS” Embedded Networks Laboratory, Computer Science Dept. USC. Los Angeles

[7] IEEE Standard 802.15.4-2003: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs), May 2003.

[8] Z1 datasheet, http://zolertia.sourceforge.net/wiki/images/e/e8/Z1_RevC_Datasheet.pdf

[9] TinyOs official website, http://www.tinyos.net

[10] MSP430F2617 datasheet: http://www.ti.com/lit/er/slaz033j/slaz033j.pdf.

[11] CC2420 datasheet: http://www.mtl.mit.edu/Courses/6.111/labkit/datasheets/CC2420.pdf.

[12] ADXL345 datasheet: http://www.analog.com/static/imported-files/data_sheets/ADXL345.pdf

[13] TMP102 datasheet: http://www.ti.com/lit/ds/symlink/tmp102.pdf.


134

��A�B�C�DC�AE�B��F�F��C��FB��FB��

DC��AFB��

��A�B��CDE��FA��CF��F��FA��F�D��A�B��D�A��ED��

[email protected]; [email protected]; [email protected]; [email protected]; [email protected](*); [email protected](*);

Instituto de Investigaciones Antisísmicas, * Laboratorio Electrónica Digital,

Facultad de Ingeniería, Universidad Nacional de San Juan

�

��E��F�F��E��F��ED��E��D�E��D��E�D�F�D��F�D�F��E�� D��F��

�� EDE��!F��F�"�DED�D��F��E�F�� "��FE�� E��E��E� ��DE�D��FE� D�� F��EA�

"��F�!F��F��E��F��E��D��E��!��D��F��F�F�D�F��#�"��F�E!D�D�

�E��E� �F��E� �� D�� F��$C%A� �� D�F� ��D�F� �� &E�D�� #� �� !F� D�F�&!�D�F� F� �F�'E� ��

!��!��C�(�)*C��

��EDE��!F�E��F�F��F��!D��F��+��D�EA��!��B,C-+��.-�

�� /��E�F�� C�� F�D�F� ��F�F� �� D��D�� D!��E�� F� �F� "�� E�� F� E��E��E� ��

D�� F��C)0A�01B�#�F�F��D�F��C��F�D�F��FE��F��!��2+345��D�� F��01B�

#��678��)294-:-4-��D�� F��F�F��D�F��

��E��F��E��D��E��E��E��E�E��F�!F��F��E��!�!�DF�C7��

C��D!��!��F�D�� F��$C%�1�-��!��E�;07�#�B7BA�'E�F�<��D!F��!D��F��=��>�E��

F��F�'E��E�D��D��F��

C�� D!��!��F� D�� F�� D�F� ��D�F� �� &E�D��A� <�D�� E��FD�E� �� E� "�� D��

��!F��'�D��E�!�#�D��E��C��F��F��E��E�F�D�� F��FF��F��F�E!DED��F��E�

��E��F�F��A��D�F��F��F��'��D�F��F��F��ED��A�F��F��E�F�D��!��F��

C��D!��!��F�D�� F��D�F�&!�D�F��!��!��C�(�)*CA��F��F��F��F��F�E!DED��E�

�F��E��D��E�F��E��D��!��


135

“Brújula Electrónica” Bernis, Ariel; Turconi, Diego; Tantignone, Hugo; Zaradnik, Ignacio.

[email protected]; [email protected]; [email protected] Cátedra de Tecnología Electrónica, DIIT, UNLaM. Buenos Aires, Argentina.

Una Brújula es un instrumento que sirve para orientarnos sobre la superficie terrestre. La orientación se suele realizar por una aguja imantada que señala el Norte magnético. Pero este método tiene algunos inconvenientes, el Norte magnético no es el mismo en todas partes del planeta, no coincide con el Norte geográfico y para que la medición sea exacta el instrumento debe estar en paralelo con la superficie terrestre. Estos inconvenientes pueden ser solucionados con una brújula electrónica. La misma puede ser empleada en muchas aplicaciones: navegación aérea, marítima y terrestre [1]; dispositivos de asistencia al peatón [2]; sistemas de asistencia de manejo y seguimiento vehicular [3][4], y robótica [5][6]. El trabajo presentado es el diseño de una brújula electrónica utilizando dispositivos MEMS, para ser empleada en futuras aplicaciones de robótica. El desarrollo se realizó con un magnetómetro y un acelerómetro, éste último para realizar la corrección en la magnitud medida por el primero. Ambos dispositivos integrados en la placa de evaluación ATAVRSBIN1 [7]. La lógica fue implementada en un microcontrolador de 8 bits, el ATMEGA64. El desarrollo se completa con un display gráfico de 128x64 puntos. Finalizado el desarrollo se realizaron pruebas comparativas con respecto a la placa del Reference Desing de una brújula electrónica de la empresa Silabs [8]. Los resultados obtenidos fueron similares, sin embargo se observó una mayor variación en la medición en presencia de campos magnéticos fuertes en nuestro dispositivo.

[1]The role of compassing in telematics. Mark Amundson, Telematics Update, Issue 24. [2]Design of a Wireless Assisted Pedestrian Dead Reckoning System—The NavMote Experience. IEEE Transactions on instrumentation and measurement, Vol. 54, No. 6, 2005. [3]An Inexpensive and Accurate Absolute Position Sensor for Driving Assistance. IEEE Transactions on instrumentation and measurement, Vol. 57, No. 4, 2008. [4]An Adaptive Fault-Tolerant Multisensor Navigation Strategy for Automated Vehicles. IEEE Transactions on vehicular technology, Vol. 59, No. 6, 2010. [5]Diseño e implementación de un sistema de control embebido de control modern: Una experiencia práctica. CASE 2012, ISBN 978-987-9374-82-5. [6]Nessie II Autonomous Underwater Vehicle. Student Autonomous Underwater Competition - Europe (SAUC-E), 2010. [7]http://www.atmel.com/Images/doc8354.pdf [8] Silicon Labs F350-COMPASS-RD


136

“Control de una red domótica ZigBee a través de un servidor webembebido en un microcontrolador”

Guillermo Emilio Mandagaran; Luciano Vergagni; Juan Carlos Bonadero;Pablo Daniel Agüero; Alejandro José Uriz

Laboratorio de ComunicacionesFacultad de Ingeniería

Universidad Nacional de Mar del PlataMar del Plata, Argentina

Email: [email protected], [email protected]

Hoy en día, la domótica se convirtió en uno de los pilares de la evolución tecnológica en pos delbeneficio de las personas. La tendencia es transformar los hogares en unidades funcionales a losintereses y las necesidades de sus habitantes. En un sistema domótico en el cual los datos viajan demanera inalámbrica, la flexibilidad del mismo se ve incrementada. El protocolo ZigBee fue diseñadopara ser usado en sistemas de este tipo y está destinado al envío y recepción de información usada parael control y gestión de sensores y actuadores en una red domótica, con una baja tasa de transferenciay de manera confiable y segura.

Este artículo presenta el desarrollo de una interfaz de comunicación que relaciona una red ZigBeecon el protocolo Ethernet, el cual posibilita la operación de la misma usando el conjunto de proto-colos TCP/IP. El desafío planteado prevé la construcción de una red de domótica ZigBee operada através de un servidor web embebido en un microcontrolador. La red contiene sensores y actuadores,y mediante el servidor web resulta posible obtener lecturas de esos sensores (p. ej. temperatura deun recinto) y encender o apagar dichos actuadores (por ejemplo, calefacción), entre otras cosas. Elsistema desarrollado ofrece a las personas una forma accesible e intuitiva para manejar el hogar demanera local o remota mediante la integración de nuevas tecnologías, como los teléfonos inteligentes.A partir de la selección de componentes apropiados se consiguió brindar a los hogares una mayorfuncionalidad.


137

“Aplicación domótica empleando LaunchPad MSP430: Experiencia en formación investigativa”

Hortua Tamayo Santiago; Ruge Ruge Ilber Universidad de Cundinamarca

En el desarrollo del Simposio Argentino de Sistemas Embebidos realizado en Buenos Aires en el mes Agosto de 2012, la Universidad de Cundinamarca Colombia fue beneficiaria del Programa de Equipamiento para Universidades al recibir la donación de 10 kits LaunchPad MS430 de Texas Instruments. Con la asesoría del Ing. Gerardo Sager profesor titular de la Facultad de Ingeniería UNLP la Universidad de Cundinamarca inicia la gestión de conformación del Semillero en Sistemas Embebidos. El área de aplicación que se abordó para iniciar este proceso fue la Domótica, como una alternativa de optimización en el uso energético. El presente trabajo realizado en el Semillero de Investigación consiste en un modelo a escala del sistema de control de luminosidad, empleando como plataforma de control el LaunchPad y cumpliendo con los siguientes parámetros: La luminosidad de la habitación se activa proporcionalmente a la intensidad de luz ambiente, realizado por medio de una fotocelda.

La prioridad será iluminar el habitáculo con luz natural, realizado por medio de cortinas gobernadas por motores, garantizando así el ahorro energético.

El encendido o apagado de la luz dentro de la habitación se realiza evaluando la presencia del usuario, para ello se utiliza un sensor de movimiento Passive Infra Red estándar.

El propósito soportado con todos los resultados del semillero de investigación será el aportar en la actualización curricular de los núcleos temáticos de circuitos digitales en la Universidad.


138

�NODO DE COMUNICACIONES M2M

MULTIACCESO�Conectividad en Red para Equipos con Interfaz Serie RS-232/485

Emiliano Prato1 ; Raúl Bruña2

Universidad de Buenos AiresFacultad de Ingeniería

Seminario de Sistemas [email protected] , [email protected]

Actualmente existe una gran variedad de equipos de uso industrial o científico en servicio cuya única interfaz de datos es del tipo serial RS-232 o similar, y que por razoneseconómicas o simplemente por robustez y fiabilidad probadas, no poseen intención de reemplazo en el corto o mediano plazo por parte de sus propietarios, sean éstos de empresas privadas u organismos públicos. En algunos casos se trata de equipos originalmente diseñados para ser operados en sitio por personal especializado que establezca una conexión local mediante un terminal de mano (handheld) o computadora portátil para lectura de datos, o quizás que estén pensados para trasladar dentro del ámbito fabril o industrial información de ciertas magnitudes del proceso productivo a un centro de control pero siempre dentro de la misma planta.

Se plantea el desarrollo de un nodo de comunicaciones destinado a la gestión remota de estos equipos, brindando a los mismos capacidad de conexión LAN/WAN y con las ventajas propias de la jerarquización en red. Como característica distintiva, el nodo posee capacidad de selección automática de la red de acceso disponible, pudiendo brindar conectividad GPRS, WiFi o Ethernet, minimizando la posibilidad de pérdida de vínculo entre extremos remotos.

A nivel hardware se implementa en una plataforma basada en LPC1769 que gestiona convenientemente cada uno de los módulos de comunicación empleados (Motorola G/W 24 externos, IEEE 802.3 interno), mientras que a nivel software embebido se programan tareasespecíficas en un sistema operativo de tiempo real con la robustez que brinda FreeRTOS para el microcontrolador mencionado.


139

- 1 -

"Sistema de dinero virtual" Gadea A.; Kovalsky N.; Maroli G.; Sankowicz J.

Universidad Tecnológica Nacional Facultad Regional Buenos Aires [email protected]

[email protected] [email protected] [email protected]

Este proyecto consta de un dispositivo que realiza la lectura de un código de barras incorporado en una pulsera. Este código tiene asociado un determinado saldo, cargado previamente por un operador. Una vez cargado el sado el usuario podrá realizar la compra de diversos productos sin la necesidad de realizar el pago con efectivo. Este sistema está pensado para ser instalado en diversos comercios, donde se realizaran múltiples transacciones tales como hoteles, cruceros, bares. El proyecto se realizó con un micro-controlador con arquitectura de 8 bits de la familia 8051 de silabs (C8051F020), montado sobre un kit de desarrollo de la cátedra de Informática II de la carrera de Ingeniería electrónica. De dicho kit se hizo uso del display LCD, teclado matricial, y además se desarrollaron drivers para la utilización de modúlo Wi Fi y un lector de código de barras, los cuales se explican a continuación. Para la interfaz con el lector de código de barras, el firmware realiza una verificación de validez del código a partir de su longitud, luego realiza la conversión del scancode al carácter ASCII, e indica la validez de la pulsera. La comunicación Wi-Fi se realizó con un módulo WI-FLY RN-XV, el cual se conecta a través del puerto serie. El módulo actúa como emulador serie transmitiendo los datos entre el micro y el servidor mediante protocolo TCP/IP. La configuración de la conexión del módulo a la red, y al servidor, se hizo a través de una funcionalidad de conexión Ad-Hoc.


140

��ABC��

DAEF��E��

��A�BC


141


142

Compilación e Instalación de Linux Embebido con Yocto para Placa de Desarrollo Intel

Agustín Martino, Facundo Solano, Francisco Guillermo Gutierrez, Juan Eduardo Picco Centro Universitario de Desarrollo en Automación y Robótica

Universidad Tecnológica Nacional – Facultad Regional Córdoba Córdoba, Argentina

[email protected] - [email protected]

Resumen— El presente artículo busca servir como punto de partida para la compilación de Linux embebido en una placa de desarrollo basada en un microprocesador Intel Atom. Se destacan pasos comunes a seguir en cualquier desarrollo, utilizando las herramientas que el Proyecto Yocto provee. Estas herramientas permiten desde la creación de un sistema operativo personalizado, hasta el desarrollo de aplicaciones para cualquier arquitectura de hardware.

Palabras Clave— Linux, Embebido, Intel, Atom, Yocto

I. INTRODUCCIÓN

La utilización de sistemas operativos en aplicaciones embebidas ha crecido aceleradamente en los últimos años. Esto se debe entre otras cuestiones, al actual avance en microcontroladores, y al abaratamiento y popularización de los microprocesadores “system on a chip” (SoC) que permiten implementar sistemas complejos a bajo costo. Utilizar un sistema operativo asegura la portabilidad de las aplicaciones desarrolladas y permite trabajar con un nivel de abstracción más elevado, independizándose de las características del hardware. Uno de los sistemas operativos más comúnmente utilizados en este contexto es Linux. Entre sus ventajas se encuentran la utilización de componentes de software de alta calidad, muy extendidos y ampliamente probados como son el kernel de Linux, y las herramientas desarrolladas por el proyecto GNU, la enorme compatibilidad de hardware, la absoluta flexibilidad para adaptarlo a cualquier aplicación, sin costos extras y su continua actualización. Existen varias alternativas comerciales para Linux embebido, cada una con sus propias herramientas y entornos de desarrollo, por lo general orientadas en ofrecer facilidad de uso y tiempos de desarrollo cortos. Por otro lado existen alternativas libres como el Proyecto Yocto[1], que a pesar de ofrecer un tiempo de aprendizaje mucho mayor, permite una vez dominadas sus herramientas, controlar a fondo todos los aspectos del desarrollo y así generar proyectos sin limitaciones ni costos adicionales.

II. PLACA DE DESARROLLO

La placa de desarrollo utilizada en el presente trabajo es la Inforce SYS9402 [2] (ver Fig. 1). Esta plataforma consiste en una placa base que proporciona conectores y soporte a una placa con factor de forma Qseven, la Inforce IFC9402, que a su

vez está basada en un procesador Intel Atom E640 conformando lo que se conoce como system on a chip (SoC). La plataforma está orientada al desarrollo de aplicaciones embebidas de bajo consumo. Además, este microprocesador SoC, incluye un acelerador de gráficos 3D, controladores de memoria, y puertos de expansión.

A. Características

• Procesador Intel Atom E640, 1GHz. • Intel® Platform Controller Hub EG20T • 512 MB RAM DDR2 800Mhz. • Incluye interfaces USB, PCIe, SDIO, SDVO, RS-232,

Gigabit Ethernet. • Dos puertos SATA 2.0 3Gb/s. • Controlador de audio Intel High Definition Audio. • Salida de video VGA y posibilidad de conectar

pantallas LVDS, permitiendo operación simultánea con dos displays.

• 14 pines GPIO (General Purpose I/O). • Alimentación 12V - 1.5A.

B. Arquitectura

En una arquitectura tradicional de PC, el microprocesador es acompañado por un chipset o circuito integrado auxiliar que sirve de enlace entre éste y el resto de los componentes de la placa base.

Figura 1. Placa De Desarrollo Inforce SYS9402


143

El chipset históricamente fue dividido en dos integrados, el northbridge o puente norte que funcionaba como enlace entre el microprocesador, la memoria y los puertos PCI y AGP; y el southbridge o puente sur que permitía la conexión con el resto de los periféricos. No obstante, la arquitectura utilizada por la serie de microprocesadores Intel Atom E6xx solo posee un circuito integrado auxiliar denominado platform controller hub (EG20T) [3]. En este esquema el procesador se encarga de la mayoría de las funciones de un puente norte, administrando el acceso a la memoria RAM, el puerto PCI express y la memoria flash SPI mientras que el platform controller hub se hace cargo del resto de las funciones de un puente norte además de las propias de un puente sur administrando los discos SATA, los puertos USB, el puerto serie y las entradas y salidas estándar.

La conexión entre el microprocesador y el platform controller hub EG20T se realiza mediante una interfaz PCI express estándar.

C. Qseven

Qseven es el factor de forma implementado por la plataforma IFC9402, es un estándar que define las características físicas de la placa base de una PC. Está orientado a sistemas de tamaño y consumo reducido, basados en arquitecturas x86 o ARM. El tamaño de la placa es de 70mm x 70mm incluyendo un conector de 230 pines que mapea todas las líneas de señales y alimentación al resto de la placa base. Todas las especificaciones técnicas así como los esquemas de un módulo Qseven se encuentran en la página oficial del estándar [4].

D. Encendido e Inicialización

El programa de inicio de la placa se carga desde una memoria flash SPI de 2Mb que se encuentra en el módulo IFC9402. La plataforma soporta los siguientes BIOS o bootloaders: BIOS Phoenix, Intel BLDK e Intel BLDK2. La placa por defecto no posee BIOS sino que viene con un bootloader desarrollado en BLDK (bootloader development kit), suministrado por el fabricante. BLDK [5] es un entorno de desarrollo de Intel que permite la creación de firmware personalizado de inicialización para plataformas basadas en productos de Intel. Los bootloaders desarrollados con este kit cumplen con los estándares UEFI. UEFI (Unified EFI) [6] es una fundación creada por Intel para promover EFI. Esta última es una interfaz que hace de puente o comunica el firmware base de una computadora con el sistema operativo en sí. Se desarrolló con el fin de reemplazar al BIOS, que ha quedado obsoleto debido a sus muchas limitaciones. El mecanismo de inicio implementado por EFI es completamente diferente al utilizado por el BIOS. Para poder iniciar un sistema operativo es necesario contar con algún gestor de arranque que soporte EFI. Para sistemas operativos basados en GNU-Linux, dos de las opciones más comunes son ELILO o GRUB2.

III. YOCTO

Yocto es un proyecto de colaboración de código abierto, enfocado en el desarrollo de Linux Embebido. Provee herramientas, ejemplos y métodos para crear sistemas operativos en forma personalizada, orientados a sistemas embebidos en distintas arquitecturas de hardware. El punto de partida de todo desarrollo embebido basado en Linux, es obtener una distribución de este sistema operativo lista para ser corrida en el hardware utilizado, o construir una a partir de código fuente. Debido a que no existe ninguna distribución orientada a la placa de desarrollo Inforce SYS9402, se opta por la creación de una imagen, es decir, un sistema operativo compilado y listo para ser corrido, utilizando los recursos que brinda el Proyecto Yocto. Vale aclarar que cuando se desarrolla software para un sistema embebido, debido a las limitaciones de hardware, el proceso de desarrollo se realiza en un sistema auxiliar conocido como host, el cual corre en una arquitectura diferente para la cual se compila el código final, es por eso que a los compiladores que realizan esta función se los denomina cross-compilers. Al sistema sobre el cual se va a correr el software generado, se lo denomina target. El componente principal del Proyecto Yocto para la creación de una imagen, es la herramienta bitbake [7]. La misma fue desarrollada originalmente en el proyecto OpenEmbebbed [8] y es integrada y mantenida junto al Proyecto Yocto. Esta herramienta facilita la construcción de un programa o conjunto de programas y el manejo de sus dependencias, de forma similar a la famosa herramienta make, pero a diferencia de ésta, no utiliza un simple archivo makefile sino que se basa en una serie de archivos que se engloban bajo el nombre de metadata. Entre estos archivos se encuentran las recetas o recipes, que consisten en un set de instrucciones que bitbake ejecuta para construir un determinado paquete. También se engloban dentro de esta categoría los archivos de configuración (.conf), que se utilizan para definir variables que afectan a un proceso de construcción. Utilizando bitbake se pueden desarrollar, construir, y debuguear imágenes completas de Linux personalizado. Además se pueden desarrollar aplicaciones que corran luego sobre el sistema operativo implementado en el target.

IV. CONSTRUCCIÓN DE LA IMAGEN

El primer paso para comenzar con la construcción del sistema es asegurarse de tener instalados todos los paquetes de software necesarios para trabajar con Yocto en el host, que en este caso, utiliza la versión 17 de Fedora [9] como sistema operativo. La lista de paquetes puede obtenerse de la documentación disponible en el sitio web de Yocto [10]. Para instalarlos basta con ejecutar el gestor de paquetes ya que pueden obtenerse directamente de los repositorios de sistema. Luego se procede a descargar Poky, que es un conjunto de herramientas del Proyecto Yocto necesarias para la construcción de Linux embebido (incluye bitbake). Este paquete se descarga desde la página web de Yocto o mediante un repositorio git, lo que permite obtener la última versión ya


144

que ésta es una herramienta para manejo de versiones y gestión de código fuente muy usada para el desarrollo de proyectos de código libre. Para copiar Poky desde el repositorio git, (con esta herramienta instalada) se debe ingresar a la terminal, ubicarse en la carpeta en donde se quiere guardar el paquete y ejecutar la siguiente línea: $ gitclonegit: //git.yoctoproject.org/poky.git A continuación se debe crear una carpeta en donde se van a ubicar los archivos generados en el proceso de construcción del sistema operativo, denominada en este caso YOCTO_BUILD. Para poder construir la imagen del sistema operativo es necesario contar con información sobre el target y su arquitectura. Para ello se debe descargar o construir lo que se denomina BSP (base support package). Un BSP es un conjunto de archivos (metadata) que define como interactuar con un dispositivo en particular o una plataforma de hardware. Incluye información sobre las características del dispositivo target, junto con la configuración del kernel o núcleo del sistema operativo y los drivers requeridos. El Proyecto Yocto permite la creación y modificación de un BSP, información sobre este aspecto se encuentra disponible en la documentación del proyecto [11]. Sin embargo, no siempre es necesario proceder de esta manera debido a que se disponen de varios BSP ya creados, orientados a dispositivos populares, que se pueden descargar desde el sitio web del proyecto [12] o mediante repositorios git. Para la plataforma Inforce SYS9402 se debe utiliza el BSP SYS94xx. Este BSP no se encuentra listado en la sección de descargas del sitio web de Yocto por lo que debe descargarse desde los repositorios git. Lo más importante de este BSP es que posee soporte EFI, indispensable para poder bootear la imagen generada. Es necesario obtener la carpeta completa con todos los BSP de Intel, que en este caso, luego se almacena dentro de la carpeta creada anteriormente para los archivos generados (YOCTO_BUILD). Para esto hay que ubicarse desde la terminal en dicha carpeta, y escribir el siguiente comando: $ gitclonegit: //git.yoctoproject.org/meta-intel Este comando copia, todos los BSP de Intel disponibles en el repositorio git. La información común para todas las plataformas de Intel se encuentra en el directorio raíz/meta-intel y la información referida a las distintas plataformas en particular en subcarpetas. De estas subcarpetas se va a utilizar /meta-sys94xx que contiene al BSP para la plataforma Inforce SYS9402. Una vez descargados estos archivos, se procede a generar el entorno para la construcción del proyecto YOCTO. Esto se realiza mediante un comando que inicializa el sistema de construcción y le indica al sistema la carpeta donde se van a guardar los archivos de construcción. Para hacerlo desde la terminal, hay que ubicarse en la carpeta donde fue guardado

Poky y luego ejecutar oe-init-build-env, esto se realiza de la siguiente forma: $ sourcepoky/oe-init-build-env YOCTO_BUILD Se le indica al comando como parámetro la carpeta en donde se van a guardar los resultados del proceso de construcción. Se supone que la carpeta YOCTO_BUILD se encuentra en la misma carpeta donde se descargó Poky, de otra forma se debe especificar la ruta completa de esta carpeta. El comando de inicialización genera dentro de la carpeta YOCTO_BUILD una carpeta conf que contiene dos archivos de configuración, local.conf y bblayers.conf. El archivo local.conf contiene las configuraciones básicas del proceso de construcción. La mayoría de las líneas se encuentran comentadas ofreciendo una configuración estándar, sin embargo, deben ser modificadas de acuerdo al target elegido y al host que se está utilizando. Dentro del archivo bblayers.conf se debe indicar la ruta de los BSP que se van a utilizar, en este caso se debe indicar la ruta de la carpeta meta-intel y de la carpeta meta-sys940x. Desde la misma terminal se llama al sistema de construcción bitbake. Es importante destacar que el comando de inicialización del entorno de construcción debe ejecutarse siempre antes de poder utilizar bitbake, si los archivos de configuración ya se encuentran definidos no son modificados. El sistema constructor bitbake puede generar distintos tipos de imágenes, para satisfacer requerimientos particulares de cada sistema y aplicación. Se pueden utilizar tipos de imágenes predefinidas o generar una imagen personalizada. De esta forma se pueden elegir paquetes de software para incluir en la imagen, distintos tipos de herramientas, elegir el gestor de paquetes que va a utilizar la distribución, la interfaz gráfica, las librerías, entre otras cosas. $ bitbake <nombre_imágen> Con este comando se comienza la construcción de un tipo de imagen predefinida, utilizando la configuración actual y el BSP seleccionado. Cada imagen predefinida esta descripta en una receta de alto nivel que le indica a bitbake los pasos a realizar para su construcción. Se eligió el tipo de imagen core-image-base que es una distribución de solo consola, es decir, sin interfaz gráfica pero con la mayoría de las herramientas comunes GNU, para ello se utiliza el siguiente comando. $ bitbake -k core-image-base La opción –k se incluye para que el proceso de construcción que se está ejecutando continúe a pesar de que aparezcan errores. Durante la construcción de la imagen se descargan múltiples archivos de Internet, es importante entonces que el host se encuentre en todo momento conectado a la red. Una vez finalizado el proceso se puede encontrar la imagen lista para ser ejecutada en el target dentro de YOCTO_BUILD/tmp/deploy/images. El contenido de esta


145

imagen .iso se copia en una unidad USB, la cual se va a utilizar para arrancar el sistema.

V. CARGA DEL SISTEMA OPERATIVO

Una vez instalada la imagen en la unidad USB, se conecta la placa Inforce SYS9402 al host por medio de un cable serie NULL-MODEM. En el host se configura una conexión serie usando hyperterminal a 115200bps, 8N1, sin control por hardware. Posteriormente se conecta el cable de alimentación a la placa y se la enciende. El sistema inicia como consola EFI y por defecto intenta arrancar desde el disco rígido. Se debe presionar cualquier tecla para cancelar la operación y salir de la consola. Al salir de la consola se ingresa a un menú de selección de arranque dentro del cual se debe escoger “BOOT from USB”, lo que ejecuta el cargador de arranque GRUB instalado en el disco extraíble USB junto con la imagen generada. Finalizado el proceso de arranque del sistema operativo, se le conecta a la placa un teclado y un monitor y ya se puede utilizar el sistema de forma independiente del host. El usuario administrador es root, y por defecto no posee contraseña.

VI. DESARROLLO DE APLICACIONES

Otra de las características del proyecto es el kit de herramientas para el desarrollo de aplicaciones (aplication development toolkit) [13]. Este conjunto de herramientas provee una plataforma para el desarrollo de aplicaciones embebidas, formada por el cross-toolchain, el sistema de archivos, la herramienta de integración al IDE Eclipse y un emulador para poder probar las aplicaciones sin tener que cargarlas en el target. El cross-toolchain es el conjunto de herramientas orientadas a la arquitectura específica del target para el cual se desarrolla, consiste en un compilador, un enlazador y un debugger. El sistema de archivos también es específico de la arquitectura y contiene todos los archivos de cabecera y librerías para que la aplicación desarrollada pueda ser ejecutada en el target. El instalador de este kit de herramientas se descarga desde el sitio web del Proyecto Yocto, o pueden conseguirse las mismas de forma individual. Lo más recomendable es instalar el plug-in de Yocto para el IDE Eclipse, lo que permite obtener un entorno único desde donde desarrollar software, compilarlo para cualquier tipo de hardware, emularlo, cargarlo en el target y luego debuguearlo. El plug-in se puede instalar desde la versión 4.2 de Eclipse en el submenú Install New Software al cual se accede desde el menú Help, los pasos para configurarlo se pueden obtener en [10]. Por último, la aplicación desarrollada se puede compilar junto con la imagen del sistema operativo, de forma que se cargue en el target junto con la misma o puede ser suministrada utilizando un dispositivo de almacenamiento USB. La placa de desarrollo Inforce SYS9402 posee un procesador Intel Atom, por lo que la arquitectura que utiliza es idéntica a la de una PC de escritorio. El kit de desarrollo de aplicaciones se utiliza integrado al IDE Eclipse pero su uso no es estrictamente

necesario, ya que no es indispensable utilizar compilación cruzada para este caso particular.

VII. ANÁLISIS DE LA IMAGEN OBTENIDA

La imagen final generada posee un tamaño de 86Mb y el proceso total de compilación, que incluye la descarga de código fuente desde internet, tomó un tiempo aproximado de cinco horas, habiendo utilizado un host con procesador dual core y 2Gb de memoria RAM. El tiempo total de arranque del sistema es de 40 segundos, desde que reconoce la imagen en el disco extraíble USB, hasta el inicio de sesión. Una vez iniciada la sesión como root se puede navegar por las distintas carpetas del sistema de archivos de la misma forma que en la terminal de cualquier distribución de Linux. Además muchas de las utilidades comunes a cualquier sistema basado en Linux se encuentran implementadas a través de BusyBox [14]. BusyBox es una aplicación que provee herramientas comunes en un solo binario, que puede ser invocado de diferentes maneras. Es por esto que se pueden ejecutar comandos como ps, grep o chmod, de la misma forma que en cualquier terminal. Anteriormente, se mencionó junto con las características de la placa Inforce SYS9402, que la misma posee 14 pines GPIO, que son entradas/salidas digitales de propósito general. El manejo de estos puertos desde Linux se encuentra bastante estandarizado y se realiza mediante llamadas al sistema (syscalls) que leen o escriben archivos (el manejo de periféricos en Linux es siempre a través de archivos) en la carpeta /sys/class/gpio [15]. Esta carpeta sin embargo, no existe en la imagen generada por Yocto, debido a que el controlador para el manejo de los puertos GPIO no se encuentra implementado. Este inconveniente implica que para poder usar estos puertos sea necesario agregar el soporte para estos puertos al BSP utilizado. Por último, para analizar el rendimiento de este sistema, se realizaron una serie de benchmarks a fin de comparar el comportamiento del sistema operativo generado con Yocto respecto a otra distribución de Linux embebido. UnixBench [16] es una colección de benchmarks destinados a evaluar el desempeño de sistemas tipo Unix en varios aspectos. Se sometió al sistema a una serie de estos tests, y se comparó los resultados, con los obtenidos en la misma placa utilizando el sistema operativo instalado por defecto por el fabricante, Timesys 11 basado en Fedora [17]. El desempeño del sistema generado con Yocto fue ligeramente superior en todas las pruebas realizadas. El resultado del test Whetstone, una de las primeras y más difundidas pruebas de rendimiento [18] se muestra en la Fig. 2, donde se comparan las MWIPS (millones de operaciones whetstone por segundo) de ambos sistemas. Los resultados de otros tres benchmarks (Dhrystone, Pipe Throughput y System Call Overhead) se muestran en la Fig. 3 donde se observa que el puntaje obtenido por Yocto supera por poco al de Timesys 11. Para más información sobre que se evalúa en cada test, se debe consultar [16].


146

VIII. CONCLUSIONES

Se logró generar e implementar un sistema operativo personalizado basado en Linux que corre perfectamente en la placa de desarrollo. Se obtuvo un punto de comienzo para cualquier posible desarrollo partiendo casi desde cero, a la vez que se adquirió familiaridad con el desarrollo utilizando Linux. Se observó que el rendimiento del sistema no es inferior respecto al que se distribuye con la placa aunque posee algunas falencias como la falta de soporte para GPIO.

REFERENCIAS [1] The Yocto Project, “About the Yocto Project” [en línea], disponible en:

https://www.yoctoproject.org/about. Abril 2013.

[2] Inforce Computing – SYS94XX Development Platforms [en línea] disponible en: http://inforcecomputing.com/product/9400series.html. Marzo 2013.

[3] Intel Corporation – Intel Platform Controller Hub EG20T Datasheet [en línea], disponible en: http://www.intel.com/content/dam/www/public/

us/en/documents/datasheets/platform-controller-hub-eg20t-datasheet.pdf. Abril 2013.

[4] Qseven Standard, Qseven Specification Revision 2.0 [en línea], disponible en: http://www.qseven-standard.org/. Junio 2013.

[5] Intel Corporation - Intel Boot Loader Development Kit [en línea], disponible en: http://www.intel.com/content/www/us/en/intelligent-systems/intel-boot-loader-development-kit/intel-bldk-initialization-firmware-development-solutions-toolkit.html. Abril 2013

[6] UEFI, “About UEFI” [en línea], disponible en: http://www.uefi.org/about. Abril 2013

[7] R. Purdie, “Bitbake” in Yocto Project Reference Manual [en línea], disponible en: http://www.yoctoproject.org/docs/1.4/ref-manual/ref-manual.html, Sec 6, Abril 2013

[8] Open Embedded, “About Open Embebbed” [en línea], disponible en: http://www.openembedded.org. Abril 2013

[9] Fedora Project, “About Fedora” [en línea], disponible en: http://fedoraproject.org/es/about-fedora, Junio 2013.

[10] S.Rifenbark, “Yocto Project Development Manual” [en línea], The Yocto Project, disponible en: http://www.yoctoproject.org/docs/current/ dev-manual/dev-manual.html. Abril 2013.

[11] T. Zanussi, R. Purdie, “Yocto Project Board Support Package Developer’s Guide” [en línea], The Yocto Project, disponible en: http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html. Abril 2013

[12] The Yocto Project, “Downloads” [en línea], disponible en: https://www.yoctoproject.org/downloads. Abril 2013

[13] J. Zhang, “Yocto Project Application Developer’s Guide” [en línea], disponible en: http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html. Abril 2013.

[14] G. Sally, “BusyBox”, in Pro Linux Embedded Systems, Ed. Apress, 2010, p. 293.

[15] The Linux Kernel Organization, “GPIO Interfaces” [en línea], disponible en: https://www.kernel.org/doc/Documentation/gpio.txt, Junio 2013.

[16] Unix Bench, “Unix Bench Project Information” [en línea], disponible en: https://code.google.com/p/byte-unixbench/. Junio 2013.

[17] Timesys, “About Timesys” [en línea], disponible en: http://www.timesys.com/company. Junio 2013.

[18] B. Bramer, “System Benchmarks” [en línea], DeMontfort University, UK, disponible en :http://www.cse.dmu.ac.uk/~bb/Teaching/ ComputerSystems/SystemBenchmarks/BenchMarks.html. Junio 2013.

Figura 3: Resultados de otros benchmarks realizados.

Figura 2: Resultados del test Whetstone


147

Reverse-Engineering a Closed-Box Hardware andSoftware Linux Embedded System

Rafael Zurita, Rodolfo del Castillo, Miriam Lechner, Eduardo Grosclaude

Departamento Ingenierıa de Computadoras - Facultad de InformaticaUniversidad Nacional del Comahue

{rafa,rdc,mtl,oso}@fi.uncoma.edu.ar

Abstract— Linux embedded systems are often found in closed-box products. The present work documents the process by whichsuch a closed-box, off-the-shelf product, has been analysed tostudy how it is built, how it is powered by Linux, and how itssoftware can be updated or modified to adapt the device to otherusages. The final result, after the described procedure is applied,is a generic, embedded Linux development board, suitable for ar-bitrary purposes. Our practical experiments targeted an Encore1

ENTC-1000 product marketed as a thin client device for remotedesktops.

I. INTRODUCTION

Dozens of embedded devices such as toasters, mobilephones, refrigerators, vacuum cleaners, TV decoders, clocks,home network routers, game consoles, are used in daily life.Most of these, unlike domestic PCs, are bound to perform asingle function. This single function makes them qualify asembedded systems [1].

However, these household items are no longer as simpleas they were once. Some years ago, most of these deviceswere just mechanical and electrical artifacts. Today’s appli-ances integrate electronic circuits, sensors, microcontrollers,microprocessors, and are capable to perform a sophisticatedset of functions.

Such complexity comes along with the need to have thedevice run an operating system, as several functions need tobe concurrently managed. Vendors opt for Linux in many casesdue to low cost and easy customization [2], [3].

In our region, acquisition of embedded Linux systems forresearch or development is a complex and expensive prospect.If we were to build, say, a sophisticated robotic device, thenour best strategy would be reusing as many parts as possiblefrom other previous work, and choosing off-the-shelf, ready-made hardware and software components to be repurposed.

Many embedded devices are available in our regionalmarket for study or customization. Most of them come with therequired hardware to run an embedded Linux system, althoughthis is rarely indicated. Typical devices capable to run a Linuxsystem are TP-Link home routers or Google Android-equippedmobile phones [3], [4].

Related works have investigated reverse engineering forrepurposing appliances in the regional market, for example, the

1All brands and product names may be trademarks of their respectiveholders.

Nintendo Game Boy, Zaurus SL-5000 and Chumby devices,as described in [5], [6], [7].

We chose the Encore ENTC-1000 embedded system forthis experience as it met the capabilities and availabilityexpectations. To our knowledge, this device has not beenstudied for adapting to arbitrary purposes.

The ENTC-1000 embedded system is a proprietary productof Encore Electronics Inc. [8], working as a remote desktopterminal supporting RDP (Remote Desktop Protocol) and XWindow System protocols. Commercial brochures and prod-uct documentation provide minimal specs, i.e. the deviceis marketed as a Linux 2.4 embedded system2. However,there is no additional documentation about architecture orsoftware internals. Encore Electronics Inc. does not providethe source code for the installed software, nor any compilingand installing instructions as required by the GNU GeneralPublic License Linux is released under [9].

As the ENTC-1000 device is a modern embedded system,available for purchase in our country (Argentina), understand-ing its architecture and behavior is of interest to our Depart-ment. The goal of this paper is to document the process bywhich the Encore ENTC-1000 has been studied and modified.As a result of our work, we have reused the embedded Linuxdevice to provide the following functionalities :

• Print server for USB printers without networkingcapability.

• DHCP server for small internal subnets at the Univer-sity.

• Brain for a research robot, tied to a microcontrollerand a set of sensors.

• Embedded Linux system for learning and experimen-tation.

• DNS server in a lab network.

II. LEGAL BACKGROUND

When repurposing a closed-box hardware and softwaresystem, the knowledge we need about its internals can beobtained either by having complete written documentation ofthe target device, or by directly experimenting with it. Thisexperimentation is called reverse engineering, and this is themethod we used for this case study.

2This kernel version was released in 2001.


148

Figure 1. Encore ENTC-1000 board

As reverse engineering happens to be illegal in somecountries, a question is raised about the legal status of ourprocedure. In our particular case, the goal in using reverseengineering is exactly to reuse the hardware for a different pur-pose. This goal matches the terms in the act Ley Argentina N◦

24.240 de Defensa del Consumidor, which does not resctrictthis action provided the product has been purchased legally.

III. ARCHITECTURE OF AN EMBEDDED LINUX SYSTEM

A. Hardware Architecture

We must know first the hardware architecture in orderto understand the behavior of an embedded Linux device.In a modern embedded system, the main component is amicrocontroller or microprocessor (CPU). Nowadays, manysystems integrate a system-on-a-chip (SOC) device containingthe CPU and most of an embedded system’s components, in asingle chip [10].

We also need to know about other components existing inthe system. After the CPU, the most important components arememory modules (RAM and Flash types) and communicationmodules (such as serial or USB). These devices, togetherwith the CPU, give an overview to what the boot process oroperational regime of the system will be like.

In practice, the architecture of an embedded system can beknown by detaching the circuit board from the enclosing case.This enables us to visually inspect and list the main systemcomponents. Most of the time, from this listing we can get theneeded ID of components or chips so as to reach their publicdocumentation, i.e., data sheets, programming manuals, etc.

As we disassembled the ENTC-1000 (see Figure 1),we identified a Cirrus Logic EP3907A SOC as the maincomponent. This chip contains an ARM920T main processorrunning at 200 MHz. The board also holds two 32 MBSamsung SDRAM memory modules and one 16 MB IntelFlash embedded module.

Although Encore does not publish technical documentationabout this board and its software, Cirrus Logic does. Detaileddocumentation of the Cirrus Logic 3907 SOC can be found onthe Cirrus Logic web site [11]. Cirrus Logic also distributesprogramming software and Linux source code for experimen-tation. Our search was completed by finding documentationfor evaluation boards published by Cirrus Logic. These designpapers are very useful to firms employing Cirrus Logic’s SOC,as they can take them as a reference design for their owndevelopments.

B. Software architecture

On the software side, the architecture typically consists ofthree essential components:

• A bootloader for an embedded system, usually DasU-Boot [12].

• A Linux kernel, or, when the system lacks a memorymanagement unit (MMU), a µClinux) kernel [13],[14].

• A minimalistic filesystem containing, at the very least,a C library (usually uClibc or eglibc) and a Busyboxshell [15]. Busybox is a small executable programoptimized for embedded systems. Busybox is capableof performing roughly the same work as many basicUnix utilities like ls, cp, etc.

Usually a fourth software component set is found in thesystem. These are the vendor’s own applications and hardwaredrivers. Vendors’ applications are seldom of interest for ourresearch; however, drivers are of prime importance. If closedsource drivers are present in the system, then the work ofpreparing an embedded Linux system supporting the wholehardware will be utterly difficult, due to the lack of accessto source code. In our experience with ENTC-1000 we didnot find any closed source drivers, so this issue is beyond thescope of this article.

At this stage, we prepared two complete replacement em-bedded Linux systems: Angstrom (using OpenEmbedded) andemDebian. The documentation for preparing embedded Linuxsystems is broadly and publicly available [16], [17], [18], andthere are also dozens of Linux distributions or developmentenvironments for embedded systems. Even when the processof preparing a embedded Linux system targeted to a specificdevice is not straightforward, these development tools help onreducing complexity of the task. Some of these projects areOpenWrt, Buildroot or OpenEmbedded [19], [20], [21].

Once we know how to build (i.e. compile, configure) andoperate the software components for the target architecture, wemust determine how the original firmware can be modified.

IV. SOFTWARE ACCESS

A. Serial interface

There are several ways to access an embedded Linuxsystem. The most usual way is through a serial console. InLinux systems, the serial console allows to look at the kernelerror messages and to interact with the boot manager.


149

Most embedded systems have a UART (Universal Asyn-chronous Receiver-Transmitter) controller, which is usedmainly for debugging and development, but is also usedby Linux as a default serial console. The UART translatesinformation in parallel form, coming from the system bus, todata in serial form, so as to be transmitted through differentports. In embedded systems, usually the UART controller ispart of the SOC, so that, even when there is no exposedconnector in the board, the controller is there.

During our work with ENTC-1000, the pins of the UARTwere not identified or labeled, but present. We identifiedseveral ground (GND) and voltage (VCC) pins by means of amultimeter. Then, using the GND pin and multimeter, the restof the exposed pins in the board were tested to try to identifytransmission (TX) and reception (RX) candidate lines.

To establish which pins we had found were the right UARTlines, we connected an RS-232 level converter to them, andthen to a PC. We finally used the minicom communicationsprogram to obtain some visual information and confirm, usingthe Cirrus EP9307 Boot process, the correct UART lines. Thisprocess is further explained in section “Communication withthe CPU”.

B. Taking control

Once we knew the software components, we conductedaccess tests to the original system, at least at three levels inthe architecture :

• Through TCP/IP connections, as soon as the originalfirmware is operating;

• by connecting to the boot manager;

• by accessing the Boot ROM software.

We first tried to get root access though TCP/IP but wewere unable to find a service we could exploit to that end. Forthe boot manager, we seek to access the minimal commandinterpreter offered by some boot managers. This was alsounsuccessful because the boot manager does not accept inputover the serial line. We therefore went on deeper in thearchitecture, trying to reach for operating stages earlier to theexecution of the boot manager.

Using the available hardware architecture and program-ming documentation, we analyzed the hardware reset processand the way the ENTC-1000 internal CPU begins executinginstructions.

Communication with the CPU

As stated in the documentation at hand, Cirrus LogicEP9307 SOC has a Boot ROM memory which supports takingthe UART as a program source to initialize the processor.The boot process is as follows: the ARM920t CPU begins theexecution of code at address 0. The SOC honors the “HardwareConfiguration” controls to select the device that appears ataddress 0. We found a switch labeled “boot mode select” onthe ENTC-1000 board, with which we experimented to selectBoot ROM.

Once started, the code in the Boot ROM enters a modecalled “serial download” which allows us to send some code

bytes to be executed by the CPU. The serial download per-forms the following steps:

1) Initialize UART1 to 9600 baud, 8 bits, no parity, 1stop bit

2) Output a “<” character over the serial connection3) Read 2048 characters from UART1

• If our serial peer does not send 2048 bytes,go on with boot process using internal Flashmemory

• If the serial peer sent 2048 bytes, store themin a internal buffer, output “>” through theserial link to indicate a successful read

4) Turn on green LED5) Jump to the start of the internal Boot Buffer

After several reset tests, the minicom communication pro-gram on the PC got the “<” character. This confirmed thatour understanding of the system was correct this far: the wiredconnections between PC and board were functional, and theBoot ROM code was being executed. After that, we were ableto download a specific program as the first code to be executedby the ARM core.

We took a small sample program in ARM assemblylanguage from Cirrus Logic as a start. Once assembled, theresulting object version for this program was smaller than2048 bytes. By incrementally modifying the program source3,we were able to discover the missing information about thearchitecture.

We were mainly interested in the addresses where thesoftware components (bootloader, Linux kernel and the rootfile system) could be found inside the Flash memory. Hence,when executed, our program looks for the physical addressesof the internal Flash memory. To do so, the program readsconsecutive memory locations, starting from the physical ad-dress 0x60000000, looking for the string “CRUS”. We chosethe 0x60000000 address based on possible values listed onthe SOC documentation. The “CRUS” token is defined as thekeyword for the CPU to identify the boot address when probingdifferent addresses for booting code.

We loaded our small probe program through the serialdownload feature of the Boot ROM process. The “CRUS” to-ken was found in the Flash memory at the address 0x60001000.As the CPU, during the boot process, will try to execute anycode written after that memory location, it was a good placeto locate the bootloader component software.

Our last goal during this stage was to find the last validphysical address for RAM memory. After modifying our probeprogram to do some a few trial and error tests, the programfound that limit, and we modified the U-Boot bootloader RAMsettings accordingly.

C. Booting an Alternative Linux Embedded System

Knowing how to execute a small program after a hardwarereset event, and having the RAM and Flash addresses, we wereready to deploy an alternative Linux embedded system overthe device. Our first step to accomplish this was to prepare a

3While taking into account the size restrictions imposed by the serialdownloader feature of the Boot ROM code.


150

bootloader and Linux kernel to be sent into RAM through theserial line.

We chose U-Boot as bootloader, built using the instructionsfound for the Sim.One board [22], but configured for thisparticular device.

When looking for a suitable current kernel, we tried to findfor existing support for devices using the same chip. We foundthe configuration for EDB9307A, which is a developmentboard produced by Cirrus Logic. When we built a kernel withthis configuration and ran it, it did not boot on once. But, afterwe modified the SDRAM base address configuration option,we were pleasantly surprised that it not only booted on the firsttry, but also that it supported all the peripherals of the ENTC-1000. This suggests that Encore simply copied the referencedesign without introducing any major changes.

When bootloader and kernel Linux were ready, we success-fully transfered and executed the bootloader, and were loggedinto its minimal -but powerful enough- command line. How-ever, we still had to decide how to layout out software withinthe Flash, which would then replace the original firmware.

Using U-Boot’s TFTP4 utilities and networking capability,we transferred the Linux 3.1.1 kernel built5 to a particularaddress in RAM. Now the two main pieces of software(bootloader and kernel) required to boot a system were readyin RAM.

The next step was to copy RAM content over the Flash.For this we used a copy (cp.b) command available on the U-Boot command line, the physical RAM addresses where U-Boot and the Linux kernel were loaded, and the start addressfor Flash memory (found when probing for the “CRUS” tokenas described in the previous section).

Finally, it is worth mentioning that we modified the U-Bootconfiguration in Flash so as to load and boot automaticallyfrom the address where the Linux kernel was saved on Flash.The Linux kernel we built was prepared to load the root filesystem (the last remaining major piece of software needed fora functional system) from a USB storage device. As a resultof this process, we modified the Encore ENTC-1000 firmware,thus offering at least two new interesting features:

• A modern and customizable bootloader, accesiblethrough a serial line.

• An updated Linux kernel, prepared to boot differentLinux operating systems from a USB port.

These functions lead us to a wide range of options to reusethe Encore ENTC-1000 device. From here we are ready to startour programming tests based on Linux embedded systems,without being required to go through the troublesome processdescribed above. The new device is just boot-and-use.

V. CONCLUSIONS AND FUTURE WORK

We used reverse engineering in order to understand thearchitecture, functioning and programming of a modern Linuxembedded system.

4Trivial File Transfer Protocol5Latest available at the time the article was written is 3.8.8, original was

2.4

Our knowledge has been increased through the experienceand documentation process itself. The resulting system allowsfor academic experimentation based on embedded Linux,running on a commercial embedded hardware which can berepurposed for specific needs.

We chose the Encore ENTC-1000 embedded system forthis experience as it met our expectations about device costand capabilities. However, at first sight, our chances to be ableto research and reuse the system were not clear.

As a result of our experience, we have been able tounderstand its internal functioning, and moreover, the devicehas been reused to provide the following functionalities in aproduction environment:

• Print server for USB printers without networkingcapability.

• DHCP server for small internal subnets at the Univer-sity.

• Brain for a research robot, tied to a microcontrollerand a set of sensors.

• Embedded Linux system for learning and experimen-tation.

• DNS server in a lab network.

As future work, we consider the fact that there may bestill some time ahead until the acquisition of specializedhardware for embedded systems can be made affordable topublic educational institutions. Until that moment can bereached, we aim to build standardized guidelines requiredfor a methodology allowing the reuse of commercial Linuxembedded systems. Even when such hardware is available fordevelopment, reverse engineering experience on commercialLinux embedded systems can be thought as a method toencourage learning about the architecture and functioning ofembedded systems.

The source code links and the documentation forthe software upgrade process explained can be obtained athttp://labti.fi.uncoma.edu.ar/trac/wiki/HackingEncore.

REFERENCES

[1] S. Heath, Embedded Systems Design, Second Edition. Newnes, 2002.ISBN-13: 978-0750655460

[2] Electrolux Brazil, The Electrolux Infinity I-Kitchen refrigerator. http://group.electrolux.com/en/linux-community-touched-by-the-touchscreen-on-electrolux-fridge-8873/

[3] Google, Android Devices. http://www.android.com/devices/[4] TP-LINK, 3g/4g Home Routers. http://www.tp-link.com/en/products/

?categoryid=202[5] C. I. C. Camargo, Metodologia Para la Transferencia Tecnologica en

la Industria Electronica Basada en Software Libre y Hardware Copyleft.Proceedings of the Congreso Argentino de Sistemas Embebidos 2012Libro de Trabajos, pages 111-116. 2012. ISBN: 978-987-9375-82-5

[6] C. Camargo, Implementacion de Sistemas Digitales Comple-jos Utilizando Sistemas Embebidos. Proceedings of XI Work-shop de Iberchip. http://www.iberchip.net/iberchip2005/articles/62/62--ccamargo-iberchip 05.pdf. 0.5em minus 0.4em2005. ISBN 959-261-105-X

[7] C. A. Perez Quintero, Automatizacion de un puente grua a escala,mediante una plataforma embebida la cual soporta multiprogramacion.Proceedings of XII Taller IBERCHIP, 2006. http://www.iberchip.net/iberchip2006/ponencias/119.pdf


151

[8] Encore Electronics Inc, Encore Thin Client ENTC-1000. http://www.encore-usa.com/ar/cat/Thin-Client/Encore-Thin-Client

[9] Free Software Foundation, GNU General Public License. http://www.gnu.org/licenses/gpl.html

[10] S.B. Furber, ARM System-on-chip Architecture, Second Edition.Addison-Wesley Professional, 2000. ISBN: 8131708403

[11] Cirrus Logic, EP93xx User’s Guide. http://www.cirrus.com/en/pubs/manual/EP93xx Users Guide UM1.pdf

[12] Denx, U-Boot bootloader. http://www.denx.de/wiki/U-Boot/[13] Linux Kernel, Linux Kernel Archives. http://www.kernel.org/[14] uClinux, Embedded Linux/Microcontroller. http://www.uclinux.org[15] Busybox Project, The Swiss Army Knife of Embedded Linux. http:

//www.busybox.net/[16] C. Hallinan, Embedded Linux Primer: A Practical Real-World Ap-

proach, Second Edition. Prentice Hall (2010)[17] J. Masters, Building Embedded Linux Systems, Second Edition.

O’Reilly Media; (August 22, 2008) ISBN-13: 978-0596529680[18] Free Electrons, Public materials for embedded Linux developers. http:

//free-electrons.com/docs/[19] OpenWrt Project, OpenWrt Linux distribution for embedded devices.

http://openwrt.org[20] OpenEmbedded Project, OpenEmbedded is a build framework for

embedded Linux. http://www.openembedded.org[21] Buildroot Project, Making Embedded Linux Easy. http://buildroot.

uclibc.org/[22] Sim.One, The Simplemachines Sim.One Single-Board Computer. http:

//code.google.com/p/sim1/


152

��ABC��

DAEF��E��

��

�

�ABCD�E�D�CF�


153


154

Fig. 1. (Left) Tipical HiL Test Bench (Right) SiL/Hil Test Bench.

Proposal for the design of a System Integration Laboratory for the new generation of avionics

systems

Damián H. Primo1 2, Pablo N. Solivellas1 2, Hernán Ponso1 2, Manuel Amor1 2, Gustavo M. Rodriguez1 2, Ariel Cararo1 2

1Aeronautics Technologies R&D Centre Argentine Air Force, Ministry of Defense.

Ruta Nacional 158, Las Higueras, Argentina. [email protected]

2Real Time Systems Research Group National University of Río Cuarto

Ruta Nacional 36 Km. 601, Río Cuarto, Argentina. [email protected]

Abstract—The avionics systems, especially flight management and control system, are some of the most critical element of any aircraft. Before final installation, the developed avionics systems have to be fully tested in an integrated Lab, known as SIL (System Integration Laboratory) in order to validate its successful integration and to prove the OFP (Operational Flight Program) tests as an integrated avionics suite. Nowdays, tests conducted at a System Integration Laboratory are required for aircraft development programs or for avionics systems upgrade programs. It is logical therefore, to develop a suitable simulation environment in which the avionics systems can be tested. It is desirable for the system to be easy to adapt to different environments, cost effective and representative of the aircraft being simulated. This paper shows the proposal design for a Software-in-the-loop System Integration Laboratory with partitioned architecture, flexible LRU design and integrated virtual protocol for testing the software of an avionics system aircrafts showing interesting performance about adaptability, cost, fault tolerance and certification effort.

Keywords—System Integration Laboratory; Software in the Loop; Avionics.

I. INTRODUCTION

Most aircraft upgrade programs include upgrading the avionics system to an integrated system to fulfill the increased operational and functional requirements, so designing an avionics system as an integrated suite has become a dominant trend. Nowadays, the FAA (Argentine Air Force) is leading an upgrading program of its avionics systems. This includes several research & development projects, among them, the design of new aircraft avionics system prototypes. The FAA has the capacity of corrective and predictive maintenance of the OFP (Operational Flight Program) of different avionics systems, for correcting fails and making better improvements. Due to the complexity of the systems, making upgrades or improvements in a Federated Avionics architecture implies time, complexity and higher economic costs.

However, as avionics systems become more complex and advanced, conducting validation and verification activities of the systems prior to aircraft level tests became common sense

for system development. These activities are normally done in test facilities, which are called as SIL (System Integration Laboratory) or avionics test bench, which assist in the identification and elimination of problems in the hardware or software of the developed system. By making the simulation environment realistic and extensive it is possible to simulate a wide range of scenarios, and the more scenarios capable of being simulated the more valuable the testing can be performed. The combination of a capable simulation system and well-structured test plans provides the capability to test all elements of the system from the highest level to the lowest. Defense companies have realized the importance of System Integration Lab and its role in the success of a vehicle or avionics system program, therefore, the SIL has become a required component of any serious defense program [1].

When talking about SIL, we can think in a Hardware-in-the-loop simulation, Software-in-the-loop simulation, or both together known as HiL/SiL co-simulation. When performing HiL simulation, the developed system runs on a real hardware environment. On the other hand, SiL testing offers the advantage of flexibility and expensive hardware equipment would not be required, making the test bench to be cost effective.

As in this project we are developing a new MC (Mission Computer) prototype, this paper covers the requirements for the development and design of a Software-in-the-loop System Integration Laboratory to test this prototype. The core of the SIL is a flight engine which solves the aircraft dynamic model equations. The SIL also consists of software simulation of all LRU (Line Replaceable Unit) required to recreate real data traffic to be send over the MIL-STD-1553 data bus [2] to the


155

Fig. 2. A generic avionics system block diagram.

developed MC, as navigation data, steering calculations, communications and GPS, and the visual instruments in order to recreate a real cockpit view, e.g. UFCP (Up Front Control Panel), MFD (Multi Function Display), CP (Control Panel), MMI (Main Machine Interface) interfaces. We propose a flexible and cost effective design which can be adapted to different avionics systems requiring only minimal changes.

II. THE AIRCRAFT AVIONICS SYSTEMS

At the present, the OFP of the FAA aircrafts is embedded in a central computer, called MC and it communicates via standard data bus serial protocol to other elements in the avionics system.

A generic combat aircraft avionics system [3] is composed by the following subsystems:

Navigation: it is the primary and most critical system of the aircraft. It includes all subsystems that acquire and process information on the attitude of aircraft.

Communication: It contains all the subsystems for the aircraft-aircraft and aircraft-ground communications.

MMI: It refers to all the subsystems that allow the pilot to interact with aircraft systems.

The LRUs of a generic avionics system are listed in Table 1. In general, these LRUs are connected by using the MIL-STD-1553B bus. Communications are controlled by the MC which acts as the bus controller of the system [4]. The system block diagram is shown in Figure 2.

Subsystem Equipments

Communication/ Identification

VHF-FM Intercomm

IFF

U/VHF-AM

Navigation Radar ALT GPS/INS

VOR/ILS ADF

MMI MFD 1/ MFD 2 UFCP

SHUD HOTAS

Table 1. List of LRU in a generic avionics system.

The main functions to be performed by a generic avionics system are the following:

Cockpit & Mission Management

Flight & Navigation Management

Communication and Identification

System Management & Maintenance

Aircraft Systems Monitoring

Mission Preparation and Debriefing.

III. MAIN REQUIREMENTS FOR THE SYSTEM INTEGRATION

LABORATORY

The aim is to replicate the behavior of a system in a simulator, so that the set of inputs and outputs relationships are identical for both the system and its simulation model. In other words, if a specific set of inputs to the system produce a particular set of outputs, the same inputs would generate identical outputs in the simulation. Therefore, the main objective of the SIL is to provide the MC with a simulated environment where the OFP testing activities can be done as if the aircraft were in a real flight condition. As we propose a Software-in-the-loop test bench, one SC (Software Component) has to be developed for each LRU present in the avionics system, and its behavior has to be as equal as possible to the real hardware behavior. All navigation and communication subsystems, e.g. EGI (Embedded GPS & Inertial Navigation), ADC (Air Data Computer), VOR (VHF Omnidirectional Radio), ILS (Instrument Landing System), ADF (Automatic Direction Finder), have to be simulated. Also all MMI controls have to be emulated, like the UFCP, MFD, and different Control Panels to handle digital I/O.

A. SIL Architecture

The proposed SIL architecture is made up of three major components, as illustrated in the Fig. 3. The first component called FSE (Flight Simulation Engine) is a computer that will hold the software which solves the aircraft dynamic equation and will work together with FlightGear1 to recreate the real flight conditions. The second component called LRU Computer is the computer where all simulated SCs will run. The third and last component is the new Mission Computer prototype, which is the device that is going to be tested.

1 Most FlightGear Flight Simulator (often shortened to FlightGear or FGFS) is a free, open source multi-platform flight simulator developed by the FlightGear project since 1997.


156

Fig. 3. SIL Components architecture.

Fig. 4. Data generation and data processing.

B. Data Generation & Data Handling

Almost all data required by the MC, excluding the steering calculation and mission database, shall be generated and simulated by the flight simulation software. This data consists on all navigation and communication data, like the calibrated airspeed, mach number, altitude, altitude trend from sensors such as pitot-static, gyroscopes, GPS, accelerometers, and also navigation parameters such as ground speed, azimuth, roll, pitch, yaw, magnetic heading, latitude, longitude, wind direction and velocity, etc. This data shall be generated by FlightGear and sent to each LRU SC (Fig. 4) which will process the data and retransmit it to the MC according to the 1553B protocol. The transmission rate must be at least equal to the maximum rate of all required parameters, for example pitch and roll parameters are some of the most critical navigation parameters and require a transmission rate of 200 Hz.

All this parameters generated and transmitted by FlightGear are the parameters that cannot be simulated because they are obtained from sensors, like airspeed, pitot-static, etc. Just to ensure that all critical parameters will be delivered at the correct rate, all parameters are sent at the highest rate. This way, the SCs are responsible for managing and processing all received data.

C. Comunications and Interfaces Requirement

MIL-STD-1553b is the standard protocol of the most generic avionics system. In order to integrate both, the data bus and the simulated environment, the LRU computer shall have a PCI card supporting the 1553B protocol, but due to the dual redundancy of the bus, the 1553 card has to support both 0 & 1 channel, in order to communicate efficiently with the different components which uses different channels, e.g. EGI transmit data on both channels, but left and right MFD uses only one channel each. So, this card shall be responsible for receiving data messages transmitted from the MC to each SC, and for transmitting data messages from each SC to the MC. To do this, it has to be capable of being configured and running as a Multiple Remote Terminal, to emulate each RT (Remote Terminal) of the avionics system. For this purpose, the card provided us with embedded software which can be programmed to simulate all RT, and all Sub Addresses.

Upon the reception of a new message, the 1553b card shall retransmit it to the correspondent LRU SC.

For communications between the simulated LRU, we developed a virtualized version of the MIL-STD-1553b

protocol called Virtual 1553, or V1553. In this way, communications between the SCs are carried out in the same way as if they were using the real MIL-STD-1553b protocol.

This implies the need to develop a SC that, on one hand, have the ability to communicate with the MC through MIL-STD-1553b protocol using the PCI card to send data from the LRU‟s, while on the other hand, this component should retransmit all data received from the MC using the V1553 protocol to the simulated LRU‟s.

It is important to note that some simulated LRU‟s require data that should come from analog and digital sensors that cannot be simulated, as mentioned in Section III.B. It is for this reason that such LRU„s should receive these data through UDP packets from the FSE computer.

Why using V1553 and UDP protocol? MIL-STD-1553b cards are by no means inexpensive. Cards range in price from around a U$S 1,000 to over U$S10,000, depending upon the manufacturer, system interface, and capabilities of the card. It is obvious that in order to use a real 1553 data bus in a development or simulation environment a 1553 cable network must be designed and implemented and expensive cards must be purchased. For these environments, it would be ideal if, rather than creating a 1553b cable network, existing communications infrastructure (for example, Ethernet networks) could be utilized. Also, rather than purchasing expensive 1553b cards, commodity hardware (for example, NIC cards) could be employed instead. From a system design and development perspective, what matters most is what messages get transmitted on the data bus and when those messages are transmitted. The details of how those messages actually get transmitted, so long as they are reliably transmitted, are not as important. A good amount of system development, testing, and simulation can be accomplished as long as the bits get to the right place at the right time in the right format.


157

Fig. 5. Communications and interfaces between software components.

Although UDP protocol provides an unreliable service and datagrams may arrive out of order, appear duplicated or go missing without notice, the system will be connected through a private local area network, with short distances between connected devices, thus it is considered to be a secure channel and bit error probability is considered to be extremely low, by not saying zero. Furthermore, as critical data are sent at high transmission rate, losing one datagram should not be a problem, as the new information is coming immediately after.

As it can be seen in Fig. 5, a RS-422 serial data interface exists between the MC and the LRU computer. This is because not all SCs make use of the 1553 protocol, but some of them, like the UFCP, require this type of connection. This interface is provided by the PCI card too. The way in which the data shall be transmitted must be defined in the Interface Requirements Document.

In Fig. 5 is also possible to observe that the LRU computer will use a hypervisor that allows hosting multiple virtual machines. Thus, each virtual machine is responsible of hosting one simulated LRU.

Why using a Hypervisor? First of all, a hypervisor is a software technology used in virtualization, which allows several operating systems to run side-by-side on a given piece of hardware. Unlike conventional virtual-computing programs, a hypervisor runs directly on the target hardware‟s “bare-metal” instead of as a program in another operating system. This allows both the guest Operating Systems and the hypervisor to perform all tasks much more efficiently. A hypervisor offers many benefits. As each LRU runs on a dedicated VM, this provides greater stability to the system because if a failure occurs in the LRU and this failure affects the operating system, such failure would not affect the remaining LRUs of the system. Secondly, this architecture

provides a high scalability because as many LRU as necessary can be added to the system as. And last but no less important, the cost of hardware acquisition and maintenance is reduced since it is centralized on a single server.

The Control Panel SC that can be seen in Fig. 6, controls all digital and analog input/output, in order to simulate all discrete signaling present in the avionics system, e.g. landing gear up or down condition or weight on wheel2 sensor signal.

This SC shall be connected to the VME backplane rack in order to interact correctly with the Mission Computer.

IV. REAL-TIME REQUIREMENTS

Basically, real-time systems are classified into two categories: hard real-time and soft real-time. The main criterion behind this classification is the degree of tolerance of missing deadlines3. However, in soft real-time systems, there is a certain degree of tolerance for missing deadlines depending on the application of interest.

In the proposed SIL, each SC has to be capable of receiving data from the V1553 bus, operate this data, convert the output into the correct message format, according to the 1553b protocol, and send the new formatted data over the V1553 Bus. Since BC tasks are handled by the MC, which is separated from the V1553 environment; a SC to manage and replicate all data traffic between real and virtual 1553 buses must be used. This particular SC uses a buffer where all command, data and status words are stored and used upon requests from the MC.

2 Most aircraft utilizes some type of WOW (Weight On Wheels) sensor or switch that activates when the aircraft in on the ground. 3 Deadline is a narrow field of time, or particular point in time, by which a task must be accomplished.


158

Fig. 6. SIL navigation system block diagram.

Fig. 7. Layout of SIL.

A soft real-time behavior can be achieved over the proposed hypervisor infrastructure by improving two aspects of the VMM (Virtual Machine Monitor) scheduler, managing scheduling latency as a first-class resource, and managing shared caches [5].

V. FLIGHT, MMI AND INSTRUMENTS PANEL DISPLAY

A realistic panel shall be designed through graphical simulation in order to build a simulated cockpit view, cockpit panels and other control panels by selection predefined controls (Push button, Switch, Monitor, Led, Label, Text Injection, Selector, Knob, etc). The simulated flight shall be displayed in an ergonomic view, through three monitor which will show the Flight World Simulation, and the HUD (Head Up Display). Also the MMI interfaces, like the MDF or HDD, UFCP and related control panels shall be allocated at the bottom of the flight visualization.

VI. THE A IRCRAFT DYNAMIC SIMULATION

The aircraft Dynamic model must be developed in JSBSim framework. JSBSim is an open source, multi-platform, flight dynamics model (FDM) framework written in the C++ programming language. It is designed to support simulation modeling of arbitrary aerospace craft without the need for specific compiled and linked program code. Instead, it relies on a relatively simple model specification written in an extensible

markup language (XML) format. That is, specific aircraft would be defined in data files, and no new program code would be required to model any arbitrary aircraft.

JSBSim was conceived in 1996 as a batch simulation application aimed at modeling flight dynamics and control for aircraft. It was accepted that such a tool could be useful in an academic setting as a freely available aid in aircraft design and controls courses. In 1998, the author began working with the FlightGear project, and was integrated with FlightGear in 1999. Today is the default flight model.

JSBSim retains the capability to run in a batch mode. The volunteer development team has grown over the years, and vigorous development continues. Since it is provided and developed under the GNU General Public License, it is available for use in other simulation projects with few restrictions [6].

The set of models that comprise the JSBSim framework includes:

Aerodynamics.

Propulsion.

Flight Control.

The aerodynamic, flight control, propulsion, and ground reaction models all feature a manager class that loads model information from a file, creates and maintains a list of objects, and cyclically executes each object in the list.

Additional characteristics of such a framework include:

Employs object-oriented design principles.

Complies across common platforms and compilers.

Readily available as an open source application.

Is self-documenting

VII. LRU SIMULATIONS

In a simulated generic avionics system, the basic LRUs to be simulated in order to test the correct operation of the MC are MFD, UFCP, ADC, EGI and DTS.

In order to implement and improve the flexibility of the proposed design, the communication module of each LRU within the data bus (real or virtual) is defined by a configuration file in XML format responsible for determining the proper messaging of each LRU with the remaining system components. This allows every SC to be adapted to different testing, design and development scenarios.

A. Head Down Display and Up Front Control Panel

The HDD and the UFCP software components are graphic applications that let to the pilot read and write information from and to aircraft systems. They look like a real HDD and UFCP. The UFCP has to communicate through a RS-422 interface with the Mission Computer.


159

B. Air Data Computer

In the real world, it is an aircraft equipment that provides the system with some flight parameters such as calibrated airspeed, mach number , altitude, input data from sensors such the pitot-static. In the SIL System, the ADC SC will simulate the real aircraft ADC and it has to provide to MC the barometric altitude and barometric pressure for navigation activities. It shall send information to the MC via the 1553b data bus.

C. Data Transfer System

It is a graphic application that shall allow the tester to make a FP (Flight Path) and load it into the MC. The DTS SC shall also let the tester to input the waypoints in the FP, and for each waypoint, the waypoint number, the waypoint name, the waypoint type and the waypoint position (latitude and longitude).

D. Embedded GPS and Inertial Navigation

In the real world, it is aircraft equipment that provides the system with all flight parameter through its sensors: the GPS for global position and accelerometers for inertial movements in six free degrees. In the SIL System, the EGI SC has to simulate the real EGI and it has to work together with the FSE to give all navigation and attitude information.

VIII. IMPLEMENTATION

Currently, the System Integration Laboratory is in the process of implementation. Most of the implementation work was carried out on the LRU computer containing the SC's and the FSE computer containing the simulation engine (Figure 4). Both, hardware and software used are COTS and Open Source.

The characteristics of the server used for the FSE computer are:

Microprocessor: Intel i7 2600 3.4Ghz

Motherboard: ASUS P8P67

Ram: 8 GB DDR3

Disk: 500 GB

Video: GIGABYTE ATI Radeon HD 6850 - 1GB

and the server used for the LRU computer:

Microprocessor: Intel i7 2600 3.4Ghz

Motherboard: ASUS P8P67

Ram: 16GB DDR3

Disk: 1 TB

Video 1: XFX ATI Radeon HD 6870 - 1GB

Video 2: ASUS GFORCE GT430 - 1GB

PCI: Systran MIL-STD-1553B Dual-Channel PCI Board

In the case of the FSE computer, was installed Flightgear V2.10 running on Debian Wheezy using JSBSim as a dynamic

model to recreate actual flight conditions. In the LRU computer was installed XEN hypervisor v4.1.2 running on Ubuntu Server 12.10. XEN is a Type-1 hypervisor that runs bare-metal over the installed operating system. The decision to use XEN Hypervisor is based mainly on three aspects:

1. Cost. While proprietary solutions such as VMware are very expensive and restrictive, XEN Hypervisor is free and Open Source.

2. The "PCI Passthrough" functionality to assign a MIL-STD-1553B PCI card to a virtual machine.

3. The "VGA Passthrough" functionality to assign video output to a virtual machine.

PCI passthrough is a technology that allows giving control of physical devices to guest operating systems. Thus, it is possible to use PCI passthrough to assign a PCI device (NIC, disk controller, USB controller, firewire controller, soundcard, etc) to a guest virtual machine, giving it full and direct access to the PCI device. Similarly, VGA passthroug allows assigning control of a video card to a virtual machine.

Currently, the hypervisor has 5 virtual machines running the following configurations:

1. BC-VM: Running Ubuntu Server 12.10 without graphical environment with 512 Mb of RAM and 10Gb disk. This VM contains a SC which is responsible for carrying out the functions of Virtual-1553 BC. In particular, it has an MIL-STD-1553B PCI card assigned, that is used as a communication interface between the SIL and the MC.

2. DTS-VM: Running Ubuntu Server 12.10 without graphical environment with 512 Mb of RAM and 10Gb disk. This VM contains an SC that is responsible for carrying out the functions of DTS.

3. EGI-VM: Running Ubuntu Server 12.10 without graphical environment with 512 Mb of RAM and 10Gb disk. This VM contains an SC that is responsible for carrying out the functions of EGI.

4. ADC-VM: Running Ubuntu Server 12.10 without graphical environment with 512 Mb of RAM and 10Gb disk. This VM contains an SC that is responsible for carrying out the functions of ADC.

5. CockpitView-VM: Running Ubuntu Server 12.10 with graphical environment, 2048 Mb of ram and 50GB disk. This VM contains three SC's. One offers the cockpit view while the other two correspond to HDD and HDD2 SC‟s. Furthermore, the VM has an assigned video card using VGA Passthrough enabling the video output to a monitor.

The LRU are, in themselves, very expensive components because its design meets manufacturing aeronautical standards. Only one of them exceeds all the costs involved in SIL architecture. Also, it should be mentioned that for test purposes of OFP, a simulated environment can provide the entire necessary stimulus. Furthermore, although aeronautical systems maintainability of technology is higher than in


160

traditional engineering cases, there are issues such as obsolescence and component degradation with use, which directly affect the cost of keeping the bank operational and increase the danger that it becomes out of service.

IX. CONCLUSIONS

The recent role of simulation, to support engineering design, is increasingly important. Computers are used in the design, validation and assessment of prototype systems, providing insight into the performance and behavior of a system in the early phase of development. By providing a system integration laboratory, where the simulated aircraft subsystems closely matches the real aircraft subsystems, the system designer can install, integrate and evaluate the MC aircraft Avionics System in the simulator.

The greatest advantage offered by the proposed design lies in four main points. First, the implementation costs are noticeably reduced as specific hardware can be replaced with commodity hardware. A specific hardware such as a HDD has a cost of thousands of dollars while the proposed SIL require only 10% or less of that cost to its full implementation. Secondly because both the design and the implementation lie in the easy configuration of the different software components to be applied to several systems, the proposed architecture is extremely flexible to adapt to different scenarios. And finally, due to the modularity proposal for the SIL, where software components run in virtual machines, which are hosted on separate partitions on a hypervisor, gives to the SIL two advantages: its fault tolerance because the failures are not propagated to the rest of the system and the easy certification process to international standards because if it is necessary to add or modify an LRU, it is not necessary to certify the complete system.

X. FUTURE WORK

Both the MC and LRUs that make up the avionics system are components with strict time constraints. For the purposes of that the SIL faithfully simulate the operating environment of MC, it is desirable that the XEN partitioned architecture proposal meets real-time requirements [5] for each of the software components contained therein. Exploration of this area would contribute not only in matters of testing of the MC but also a possible Instructional Flight Simulator. Moreover, the virtualization of the different protocols used in avionics systems (AFDX, ARINC 429, etc.) is an interesting challenge to achieve because the SIL would give full versatility to handle different configurations encountered in each particular case of an avionics system.

ACKNOWLEDGMENT

The authors thank CITeA's (Research & Development of Aeronautical Technologies Center - Argentine Air Force) members and GSTR's (Real-Time System Group - National University of Rio Cuarto) members for their feedback on earlier version of this work.

This work is partially funded by the PIDDEF 31/11 Project dependent on the Research & Development Program for the Defense of the Ministry of Defense and by the PPI 18/B215 Project dependent on Science & Technical Secretary of the National University of Rio Cuarto.

REFERENCES [1] S. Demers, P. Gopalakrishnan, L. Kant. “A Generic Solution to Software-

in-the-Loop” Military Communications Conference, 2007. MILCOM 2007. IEEE, pp. 1-6, 29-31 Oct. 2007.

[2] USA Department of Defense, Military Standard 1553B, Aircraft Internal Time Division Command/Response Multiplex Data Bus, 12 Feb. 1980.

[3] M. C. Kim, W. Seop Oh, J. H. Lee, J. B. Yim, Y. D. Koo, "Development of a System Integration Laboratory for aircraft avionics systems," Digital Avionics Systems Conference, 2008. DASC 2008. IEEE/AIAA 27th, vol., no., pp.5.A.1-1,5.A.1-11, 26-30 Oct. 2008 doi: 10.1109/DASC.2008.4702841.

[4] D. Primo, A. Grop, “Desarrollo de sistemas embebidos para simulación de componentes de aviónica con MIL-STD-1553 y migración a banco SIL.”, XIV Reuniòn de Trabajo en Procesamiento de la Información y Control 2011 (RPIC2011), pp. 941-946, 2011.

[5] M. Lee, A. S. Krishnakumar, P. Krishnakumar, P. Krishnan, N. Singh, S. Yajnik, “Supporting Soft Real-Time Tasks in the Xen Hypervisor”, VEE‟10, March 17-19, 2010, Pittsburgh, Pennsylvania, USA. ACM 978-1-60558-910-7/10/03.

[6] J. S. Berndt, “JSBSim: An Open Source Flight Dynamics Model in C++”, IAA Modeling and Simulation Technologies Conference and Exhibit,16 - 19 August 2004, Providence, Rhode Island.


161

��

�

��ABCD��E��F�A��E�E��C�A��CB��A�A��

��C��E��A�CA��C�C��D�CBA��F�A�E��F��C��

�F�C�A�A��CB��

��A��B�CC�D�E�F��

��

��A��A��A��A��A�� !�B��A�B��"��#��A��EFA�E��AC��B��FA��C��B�A��AC��B��

�

��ABC��D�DE�F��C��C��E��D�CD��D��D��FD��C�C�F��C��D��E��D��D��D��C��DE��CDE�D��

��E� F�� CE�FC��D��E��C��E��C��D�D��F��C�E� ��E�C�E�F�� D��D�� CDE��!�"DED��F�DE�D�� F��

��EC��C#��C�E��D��D�FC#��D�C�E�D�D��C��D��E��D��F��DE�� F��FD��D��E��ED�� F��CDE�D��

��D��FD�!�A��$F�C��D�%��C��E�DF��%��DF��D��C��DF��E��DF��CDE�D!�&��FC��C�E��D�

�C��D��CE�F��C��DE��D��F��FD��D��C��DE��D��C��C��D��D��D��E��C�FD��F��C�E�

��D��FC�C��C�ED��DFC�CE��C�E��DF��FD!�AF��%D�C��D�D��D��%��D��C��FD�DE��E��D��E��F�C��E��

�D� �DE��D�� CE�F��C�� DE� DF� D��E�� 'AAA� ()*!+,!-�� E� E�� D�� F�� E��C�C�E� �D� A."� ��

�D��D��C��F��EC��D��D��CDE��F��F!�&�D��D��D�FC#��F��D��F��C�E��D�F��D�!�

�


162

��A�B��CDDAEEA�F��C�F��C��A�C��C��F��D��A

�A��A��C��CE��D��C�� !�"

��A�BCDE�F��CC�E

��C��A�B��B��B��

�!�BC��C��F��CB"��

#$��%��C��&��A��'�$(�FF(�A��

��)��*+C��,��E��!��!*��,��E

��CC��*��+,��,�BE

��B��*-B�,�C�,��,�B

!�C��*��,��C�,��,�B

��C��B��B��-��C��!�B��!�B��"��-��C��

��B��!B��B��,�F�C��BD��.��/�C��C��

��!B��"��C��,�#��B��C��+��,�F��

��C��CB��/��!B��C��BB��C��BB��!�B��BE�CB��C�BE�

��B��!B��B��C��+��!�B��0��!��!�B�B��0��!��

B��C��C��C�,�#C��B��+��1��B�� 2��

��BB��B��+�B�3�B��-�B�3�B��!��C��C�B��CB��"��B��

��/��B��C��0��C��!BC��'FFF�456,78,9E�-B��B��

��B��B��,��C��CB��C��+��CB��0��

!B��C��-C3�B��BB��!B��C�1!B�B��/��:;2,

��-B��"��!B��C��!�B��!��B��-��C��0��!��B��

1��2,�F��B��"��B��!B��B�C��

!B��C��.��!�B��CB��!B��B��1-B��CB�E�

��B��+��E��C�B��B��C��!B��CB�2,�F��C��

��C��C��B��CB��(B��!�B��!�B�B�

��C��C��C��!��,��CB��-B��"�

��C��B�E��C��C�B-��3��E�!��!�B�B��

��C��C��B��C��0��B��!�C��B��

'�C�B��C,�F��C��C��C��C��!�B��"��0��C�B��B��

��B��B��+��E�!�B��B�!��B��+��+��C��

��!��!E��!�B��C��B��CB��B��!��D-��!B-��

��C��"��B,�#��C��!�B��"��!�B��C��/��-B��

��E��C��+��B�C��!B��C,�F�C��C��

!�B��C�B��C�B��-��!�B��B��B��C��

��,�F��C��!B��!�B��<!�B��C��0��C��

7=��E��E��F�C��"��F<!�B��C��(�B!��B��

A��'��C�C�C��$��D��(�B!��B��1'�$(2,


163

“Transmisión de Datos de Sensores de Aceleración Mediante Bluetooth y su Análisis en PC”

Mg. Cristian Sisterna; Navas Gabriel

Universidad Nacional de San Juan

Facultad de Ingeniería

Instituto de Investigaciones Antisísmicas

La investigación basa el estudio e implementación del protocolo bluetooth para la transmisión inalámbrica de datos provenientes de sensores de aceleración, para su visualización y análisis en PC.

El proyecto, en un contexto de estudios sismoresistentes del instituto I.D.I.A (U.N.S.J F.I.), implementa el uso de acelerómetros en redes con tecnología bluetooth. Esto, facilita la conexión de los sensores en las estructuras a analizar y evita problemas de captación de ruidos electromagnéticos en tendido de cables.

Para el desarrollo del proyecto utiliza el CC2540 Mini Development Kit de Texas Instrument. Este contiene un periférico y una central que se conecta a la pc vía USB. Ambos contienen el microcontrolador CC2540, que tiene un módulo de transmisión de Bluetooth integrado, además el periférico cuenta con un acelerómetro. La central cuenta con el microcontrolador y un conector USB.

En la primera etapa, se ha estudiado y descripto el estándar IEEE802.15.1. Posteriormente se ha trabajado el código C++ para comprender la implementación del protocolo en un microcontrolador.

En los últimos avances se ha logrado recibir datos del acelerómetro desde el periférico hacia la central y visualizarlos en la PC mediante el software provisto por Texas. Posteriormente se realizara un software específico que el instituto utilizará para los ensayos. El poster mostrara como trabaja el protocolo bluetooth y su implementación con microcontroladores en redes.


164

��ABC��

DAEF��E��

��


165


166

1

Abstract—En este trabajo se describe la implementación de un sistema de control para la locomoción de un robot hexápodo autónomo cuyo movimiento está basado en la marcha de un escarabajo pinacate, para esto es necesario realizar un análisis de movimiento del insecto para poder obtener la gráfica de la trayectoria de cada par de patas, así como la secuencia que existe entre cada una de ellas para su posterior implementación en la marcha del robot. Las extremidades del robot cuentan con tres grados de libertad cada una y se mueven por medio de servomotores. El hexápodo es capaz de avanzar hacia adelante, girar a la izquierda y a la derecha. El sistema de control para los 18 actuadores ha sido implementado en un dispositivo FPGA XC3S1200E de Xilinx, el cual está incluido dentro de la tarjeta Nexys 2, todos los bloques del sistema han sido desarrollados en lenguaje VHDL. Palabras clave— FPGA, hexápodo, robot móvil, análisis de marcha, VHDL.

I. INTRODUCCIÓN.

El sistema de locomoción con patas siempre ha sido de interés para el desarrollo de robots móviles, campo de interés de la biónica, debido a la versatilidad que ofrecen en comparación con los robots con ruedas [1,6-9]. Este tipo de locomoción permite la movilidad sobre diversas superficies incluyendo terrenos muy accidentados.

Existen diversas configuraciones para los robots con extremidades, incluyendo bípedos, cuadrúpedos, hexápodos y octópodos, sin embargo, la configuración hexápoda es la que confiere un mayor balance entre estabilidad y velocidad de desplazamiento a la hora de la marcha [2].

Las primeras investigaciones referentes a la locomoción con patas, estaban enfocadas a la observación, comprensión y modelado matemático de los parámetros de la marcha de organismos de la naturaleza [3]. Para el caso de los robots hexápodos el organismo a analizar fueron los insectos, algunos

-A. Anzueto. Laboratorio de Biomecánica, Academia de Biónica, UPIITA- IPN. Av. Instituto Politécnico Nacional No. 2580, Colonia Barrio la Laguna Ticomán, G.A. Madero C.P. 07340, México, D.F. E-mail: [email protected]. -A. Avila. Laboratorio de Biomecánica, Academia de Biónica, UPIITA-IPN. Av. Instituto Politécnico Nacional No. 2580, Colonia Barrio la Laguna Ticomán, G.A. Madero C.P. 07340, México, D.F. E-mail: [email protected] -J. Quiroz. Laboratorio de Biomecánica, Academia de Biónica, UPIITA- IPN. Av. Instituto Politécnico Nacional No. 2580, Colonia Barrio la Laguna Ticomán, G.A. Madero C.P. 07340, México, D.F. E-mail: [email protected].

ejemplos de robots basados en insectos son TUM (Pfeiffer and Weidemann, 1991) y Tarry (Frik et al., 1999).

El presente trabajo está organizado de la siguiente manera: en el apartado II se presentan los análisis realizados al escarabajo pinacate, en el apartado III se describe de manera general el modelado cinemático para el robot hexápodo, a partir de lo anterior se presenta el desarrollo de una simulación en MATLAB en el apartado IV, en donde son programadas todas las relaciones matemáticas descritas anteriormente. En el apartado V se explica la forma en la cual se realizó la implementación del sistema de control para la marcha del robot hexápodo dentro de un dispositivo FPGA. Por último en los apartados VI y VII se presentan resultados y conclusiones.

El sistema de control descrito en este trabajo permite el desplazamiento en línea recta del robot hexápodo, sin embargo, el mismo sistema de locomoción puede ser utilizado para la realización de otras trayectorias; este sistema de control trabaja de manera conjunta con un sistema de visión artificial, el cual establece la dirección de desplazamiento.

II. ANÁLISIS DEL INSECTO.

El modelo biológico que se eligió pertenece al orden de los coleópteros (escarabajos) debido a que son un tipo de insecto que se caracterizan por su alto grado de estabilidad.

Los escarabajos poseen un cuerpo dividido en tres secciones: Cabeza, Tórax y Abdomen. Sus tres pares de patas completamente articulados se encuentran colocadas a cada lado del tórax de forma simétrica. Las patas se componen de cinco partes: coxa, trocánter, fémur, tibia y tarso, figura 1, las partes principales que permiten la marcha del insecto son básicamente la coxa, el fémur y la tibia.

Fig. 1. Anatomía de la pata de un insecto.

En la marcha de los hexápodos se identifican dos estados: la fase de suspensión de las patas y la fase de apoyo o soporte. Investigaciones [2,8] muestran que la velocidad Vn de un hexápodo, siendo n el número total de patas, depende de la longitud de paso Ls, el ciclo de tiempo T, y la relación entre el tiempo de suspensión y el tiempo de soporte, く.

Control de la marcha de un robot hexápodo autónomo implementado en un FPGA.

Álvaro Anzueto, Andrea Avila y Job Quiroz1


167

2

紅噺痛濡脹 (1)

Donde: 建鎚┺ 鶏結堅件剣穴剣穴結健欠血欠嫌結穴結嫌剣喧剣堅建結劇┺ 系件潔健剣穴結健欠喧欠建欠

La ecuación que expresa la velocidad del cuerpo del hexápodo en términos de los parámetros antes descritos es:

撃津噺挑濡脹噺挑濡脹貸痛濡岾怠貸庭庭峇 (2)

A la secuencia con la que se alterna el movimiento de cada

una de las patas se le denomina modo de marcha. En los insectos se presentan distintos modos de marcha, sin embargo, los principales son el trípode y el modo pata por pata, figura 2.

En el modo trípode el cuerpo del hexápodo siempre es soportado por tres de sus patas durante la caminata, dichas patas siempre forman un triangulo sobre el piso asegurando la estabilidad del cuerpo, figura 3, este modo de marcha es el más común en los insectos. En el modo pata por pata el movimiento se presenta de una pata a la vez, este modo de marcha es el más lento de todos pero a su vez es el más estable.

Fig. 2. Esquema de los dos modos de marcha.

Fig. 3. Polígono de estabilidad.

Con el fin de analizar la marcha del insecto, se realizaron

algunas capturas de video desde una vista lateral y superior, figura 4, a partir de dichos videos se obtuvieron diversos fotogramas. La parte de la pata que se analizó fue el punto final de la tibia de la cual se obtuvieron las gráficas de la trayectoria seguida, en la figura 5(a) se muestra la trayectoria seguida por la pata 1 durante la fase de suspensión, en la figura 5(b) se muestra un polinomio de aproximación obtenido a partir de la trayectoria obtenida de los frames.

Fig. 4. Análisis de la tibia.

Fig. 5. Trayectoria del punto final de la tibia del insecto.

Otro de los aspectos que se pudieron observar del

escarabajo fue la forma en la cual están orientadas cada una de las patas con respecto al cuerpo cuando este se encuentra en reposo, figura 6. En está figura también se puede apreciar como el par de patas traseras del insecto es considerablemente más largo que el par central y delantero.

Fig. 6. Numeración y ángulos de las patas del insecto.

III. MODELADO DEL ROBOT HEXÁPODO.

La estructura mecánica del robot hexápodo discutido a lo

largo de este trabajo es el modelo Phoenix de la empresa Lynxmotion [4], figura 7. Cabe mencionar, que si bien la estructura mecánica está inspirada en la morfología de

190 200 210 220 230 240 250 2600

2

4

6

8

10

12

14

16

18Trayectoria obtenida de los frames

Pixeles en x

Pix

eles

en

z

0 2 4 6 8 10 12-0.2

0

0.2

0.4

0.6

0.8

1

1.2

1.4

Z

X

Trayectoria deseada

(a)

(b)


168

3

insectos y busca cierto grado de verosimilitud biológica, su diseño no pretende emular la biomecánica más allá de las funcionalidades necesarias para el robot.

El modelo Phoenix cuenta con seis extremidades distribuidas de manera rectangular, con tres grados de libertad cada una, los cuales tienen similitud con la coxa, el fémur y la tibia de la pata de un insecto. El robot cuenta con 18 servomotores en total, tres por cada extremidad, las medidas generales del robot se presentan en la tabla I.

Fig. 7. Robot hexápodo Phoenix.

TABLA I. Características de la estructura mecánica.

Especificaciones estructura mecánica.

Altura (Cuerpo) 5.08 cm

Altura (incluyendo patas) Hasta 13.33 cm

Ancho (Cuerpo) 43.18 cm

Largo (Cuerpo) 19.05

Peso sin baterías. 1.36 kg

Distancia al piso. Hasta 13.97 cm

Como se mencionó anteriormente el par de patas traseras

del escarabajo tiene una longitud mayor al del par central y delantero, debido a esto se tuvo que modificar la estructura mecánica del robot, cambiando el par de extremidades traseras por unas más largas, de tal forma que se mantuviera una mayor relación entre la geometría del insecto y la del robot.

A partir de las características físicas de la estructura mecánica se obtuvo el modelo cinemático del robot hexápodo, en el cual cada extremidad se le considera como un manipulador de 3 GDL montado sobre una superficie móvil. Se define en cada una de dichas extremidades un sistema de coordenadas local para posicionar su efector final y además existe un sistema de coordenadas sobre el centro del cuerpo del robot al cual están referenciados los sistemas de las extremidades. Así mismo se considera un sistema global fijo en el piso para poder referenciar el cuerpo, como se muestra en la figura 8.

Fig. 8. Modelo de la extremidad del robot y sistema de referencia global sobre

el cuerpo del robot.

El modelo cinemático está compuesto por el conjunto de ecuaciones para la cinemática directa e inversa de las extremidades del robot, estas ecuaciones están referenciadas al sistema del cuerpo del robot y al sistema global. Este modelo es utilizado en la simulación realizada, en la cual se hace uso de la cinemática directa para realizar el dibujo de la animación y la cinemática inversa para determinar la posición angular de cada una de las secciones de las extremidades de tal forma que el efector final realice un seguimiento de trayectoria.

IV. SIMULACIÓN DE LA MARCHA DEL HEXÁPODO. Una vez realizados los análisis al insecto y del modelo

cinemático del robot, se procedió a realizar una simulación en MATLAB en la cual se reflejaran los diversos aspectos obtenidos en dichos análisis.

El conjunto de ecuaciones pertenecientes al modelo cinemático del robot fueron programados en MATLAB, para que dicho software realizara el cálculo de cada uno de los ángulos de las extremidades del hexápodo en cada instante de tiempo. Estos ángulos son utilizados para realizar una animación así como para obtener las curvas de comportamiento de los ángulos.

En la simulación realizada es posible seleccionar los dos tipos de modos de marcha anteriormente descritos, el modo trípode y el modo pata por pata. La trayectoria seguida por las extremidades es la misma para ambos modos, pues lo único que cambia es la secuencia en la cual comienzan el movimiento. La figura 9 muestra una vista de la simulación mientras está en funcionamiento.

Fig. 9. Simulación de la marcha del robot hexápodo.

En la figura 10 se presentan las gráficas obtenidas de la simulación del modo de marcha trípode para las coordenadas de la extremidad del hexápodo en el espacio, en las primeras dos gráficas se observa el comportamiento de x y de z a lo largo el tiempo para la extremidad 1 y 2, es posible observar que ambas curvas tienen un comportamiento periódico.

La curva para la coordenada x tiene un comportamiento creciente en la primera mitad del periodo, esto es debido a que el efector final de la extremidad se desplaza hacia el frente. En la segunda parte del ciclo, x tiene un comportamiento decreciente, lo cual no significa que la extremidad está

-10

0

10

20

30

-20

-10

0

10

200

5

10

X

85

Y

Z


169

4

retrocediendo, sino que es el cuerpo, y con esto el sistema de coordenadas del mismo, el que esta desplazándose hacia adelante.

Fig. 10. Gráficas para las coordenadas espaciales.

Por otro lado la curva de la coordenada z presenta dos fases: la fase de suspensión y la fase de soporte. En la primera fase, correspondiente a la primera mitad del periodo, z tiene un comportamiento de ascenso y descenso, realizando un seguimiento de trayectoria de las curvas obtenidas del análisis al insecto. En la segunda fase, correspondiente a la segunda parte del ciclo, z se mantiene con un valor constante de cero, es decir, la extremidad se mantiene pegada al piso.

Otro aspecto que es importante recalcar para las primeras dos gráficas es el desfasamiento que existe entre las curvas para la extremidad 1 y 2, debido a que mientras una se encuentra en el aire la otra se mantiene pegada al piso.

La trayectoria de la figura 5(b) nuevamente se muestra en la tercer gráfica de la figura 10, con la diferencia de que en esta última se incluye el retorno al punto inicial de la trayectoria.

A continuación se presentan las gráficas obtenidas para el comportamiento de los ángulos en cada articulación para la extremidad 1, figura 11.

Fig. 11. Ángulos de las articulaciones para la primera extremidad

Los valores mostrados en las gráficas de la figura 11 corresponden a los ángulos de las articulaciones de la primera extremidad. Es posible observar que estas curvas son periódicas y su periodo, que corresponde a un ciclo de marcha, está compuesto por 24 muestras. La simulación genera entonces seis arreglos compuestos por 24 elementos, en donde cada elemento contiene el valor de los tres ángulos de la extremidad, figura 12.

Muestra 1 Angulo Coxa Angulo Fémur Angulo Tibia


… … … …


Fig. 12. Ejemplo del arreglo de 24 muestras.

Este arreglo será cargado posteriormente al sistema de control embebido.

V. IMPLEMENTACIÓN DEL CONTROL DEL ROBOT.

Todos los bloques del sistema digital de la marcha del hexápodo han sido programados utilizando el lenguaje descriptivo de hardware VHDL, haciendo uso del IDE de Xilinx, ISE 12.4.

Para la implementación de la marcha del robot se desarrolló un bloque de control individual para cada una de las extremidades, dicho bloque sería el encargado de generar tres señales de PWM para cada uno de los tres servomotores. A este bloque de control es necesario cargar el arreglo resultante de la simulación realizada, dicha arreglo consta de 24 muestras las cuales serán traducidas en los PWM correspondientes de un ciclo de marcha.

En la figura 13 se muestra el bloque de control de una extremidad, en el cual se aprecian los puertos de entrada y de salida.

Fig. 13. Bloque de control de la extremidad 1.

Los datos almacenados en el arreglo tienen un valor de

ángulo que va de 0° a 180°. Este valor deberá de ser convertido en una señal cuadrada de PWM, con un periodo de 20 ms y con tiempo en alto desde 0.6 ms (0°) hasta 2.4 ms (180°), el proceso anterior se realiza dentro de un bloque interno, la configuración interna del bloque de control para cada extremidad luce como en la figura 14.

0 20 40 60 80 100 120-1

0

1

2

t

x

X en función del tiempo (pata 1 y 2)

Pata 1

Pata 2

0 20 40 60 80 100 1200

1

t

z

Z en función del tiempo (pata 1 y 2)

Pata 1

Pata 2

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 20

0.5

1

X vs Z (pata 1)

x

z

0 20 40 60 80 100 120 1400

10

20

30

Theta1 en función del tiempo (pata 1)

t

The

ta1

0 20 40 60 80 100 120 14040

60

80


t

The

ta2

0 20 40 60 80 100 120 140110

120

130

140


t

The

ta3


170

5

Fig. 14. Configuración interna del bloque de control de una extremidad. En la figura 14 se puede apreciar que existen tres bloques

para la generación de las señales de PWM, los cuales funcionan de una manera independiente, esta es una de las ventajas que brinda la utilización de dispositivos FPGA.

Para acceder a cada uno de los datos del arreglo interno al bloque se hace uso de un apuntador el cual incrementa su valor a una frecuencia de 25 Hz, es decir, se recorren las 24 muestras en un tiempo determinado por:

劇噺態替態泰噺ど┻ひは (3)

Una vez que se han terminado todas las muestras, el

bloque resetea el valor del apuntador para volver a comenzar la lectura de los elementos del arreglo, esto ocurre gracias a que la marcha del robot hexápodo es periódica tal como lo muestran las gráficas obtenidas en la simulación.

El bloque de control de la extremidad anteriormente descrito forma parte del sistema de control de todo el robot, en el cual se incluyen seis de estos bloques. El programa principal tiene la función de integrar dichos componentes, de habilitar el funcionamiento de cada bloque y de seleccionar el modo de marcha a realizar. Un panorama del programa principal se muestra en la figura 15.

Fig. 15. Sistema de control para las seis extremidades del robot.

En la figura 15 únicamente se muestran los bloques de

control para las dos primeras extremidades, sin embargo son seis los bloques que forman parte del programa principal.

VI. RESULTADOS.

A partir del desarrollo de la simulación y del vínculo de esta con el sistema de control embebido del robot hexápodo, se determinaron los valores para los parámetros de marcha del robot de tal forma que se mantuviera la estabilidad y se observara un movimiento continuo del robot, tabla II.

TABLA II. Parámetros de marcha del robot.

Parámetro Valor Altura del cuerpo del robot

con respecto al piso. 10.5 cm

Distancia del punto final de la extremidad al cuerpo del

robot.

Par Delantero

Par Central

Par trasero

3.8 cm 4.5 cm 6.2 cm Longitud de paso 5.7 cm

Altura de paso. Par Delantero

Par Central

Par trasero

3 cm 3.9 cm 2.5 cm Estos parámetros son los mismos para ambos modos de

marcha, en los cuales únicamente cambia la sincronización entre cada una de las extremidades.

Las medidas descritas en la Tabla II presentan cierta escala con las medidas del insecto, sin embargo, en algunos casos se tuvo que modificar la escala para poder adaptarnos a las propiedades físicas del robot, es decir, para la determinación de los parámetros de marcha fue necesario tomar en cuenta los resultados del análisis de marcha del insecto y la geometría de la estructura mecánica.

La velocidad máxima alcanzada por el robot fue de 12 cm/s en modo trípode y de 2.5 cm/s en modo de marcha pata por pata. A partir de estos valores de velocidad se pudo corroborar la relación descrita en (2) para cada modo de marcha.

En el desarrollo de la simulación fue necesario tomar en cuenta el hecho de que cada par de patas del escarabajo se mueve de una forma distinta, si bien la longitud de cada paso es la misma en cada par, no lo es la forma de la curva ni su altura máxima.

Tal como se describió en el capítulo IV, la simulación realiza los cálculos necesarios para que el hexápodo se desplace de manera recta y se generan las tablas necesarias para cada una de las extremidades del robot.

Uno de los objetivos para el robot es poder girar hacia la izquierda y hacia la derecha, para estos casos se deben realizar dos distintas simulaciones. En la primera se establece una longitud de paso de 5.7 cm y las tablas de datos generadas se almacenan en el bloque de las extremidades de un lado. En la segunda simulación se establece una longitud de 6.7 cm y los datos generados se almacenan en los bloques de las extremidades contrarias, esta diferencia de la longitud de paso genera un giro hacia la derecha o izquierda por parte del cuerpo del robot.


171

6

Fig. 16. Giro hacia la izquierda del robot hexápodo.

VII. CONCLUSIONES.

A lo largo de este trabajo se presentaron las diversas etapas para el diseño de un sistema de control de la marcha de un robot hexápodo, partiendo desde el análisis de un sistema biológico hasta la implementación en un dispositivo FPGA, utilizando lenguaje descriptivo de Hardware (VHDL).

El análisis del escarabajo pinacate ha facilitado la puesta en marcha del robot hexápodo, puesto que se pudieron observar las trayectorias que seguían cada una de sus patas y la secuencia con la que se movían las mismas, de esta manera el desarrollo del sistema de control parte de las características observadas de un organismo vivo.

El modelo matemático definido en (2) tuvo una gran importancia en la implementación de la marcha del robot, debido a que este modelo expresa la relación existente entre el movimiento de cada una de las extremidades del robot y el cuerpo del mismo. Es a partir de esta ecuación y del modelo cinemático del robot que se pudieron obtener las curvas para el control de cada extremidad.

El uso de un dispositivo FPGA para el control del robot hexápodo brinda diversas ventajas puesto que permite la realización de diversos procesos de manera concurrente, por lo cual la sincronización del movimiento de las extremidades disminuye su complejidad.

En el presente trabajo únicamente se abordó el tema referente a la locomoción en línea recta, sin embargo, este sistema de control trabaja de manera conjunta con un sistema de visión artificial mediante el cual se establece una dirección de desplazamiento, de tal forma que se realice un seguimiento de objetos [9].

VIII. REFERENCIAS.

[1] Faculty of Electrical Engineering, Automatics, Computer Science and

Electronics, Department of Automatics, AGH University of Science and Technlogy, “Walking robot modelling aspects,” Septiembre 2012 [Online] Available: http://rie2010.stuba.sk/pdf/32.pdf

[2] R. Woering, “Simulating the „first steps‟ of a walking hexapod robot,” M.S. thesis, Technische Universiteit Eindhoven, Eindhoven, Netherlands, 2011.

[3] P. G. de Santos, E. Garcia and J. Estremera, “Quadrupedal Locomotion: An introduction to the control of Four-legged robots,” Ed. Springer-Verlag London, 2006. ISBN-13: 9781846283062

[4] Lynxmotion. Último acceso: 19 de abril de 2013.

http://www.lynxmotion.com/

[5] K. Waldron and R. McGhee. “The adaptive suspension vehicle,” IEEE Control Systems Magazine, vol.6, no. 6, pp. 7-12, December 1986.

[6] M. Ramírez, F.D. Sánchez, “Control servo-visual para un robot hexápodo autónomo implementado en un FPGA”, Tesis, Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas, IPN, Distrito Federal, México, 2011.

[7] S. Singh, “Prototipo de un emulador del sistema de locomoción de la

hormiga, Hexabot”, Tesis, Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas, IPN, Distrito Federal, México, 2011.

[8] A. Vargas, L. Ramírez, “Robot hexápodo de mecatrónica, HEX-3M”,

Tesis, Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas, IPN, Distrito Federal, México, 2006.

[9] A. Avila, J. Quiroz, “Control de un robot hexápodo autónomo inspirado

en el modo de marcha del escarabajo histeridae implementando visión artificial”, Tesis en desarrollo, Unidad Profesional Interdisciplinaria en Ingeniería y Tecnologías Avanzadas, IPN, Distrito Federal, México, 2013.

[10] GITS Informática. Último acceso: 22 de abril de 2013. http://www.gitsinformatica.com/bionica.html


172

Sistema de control distribuido para una maquinacaminante de 6 patas

Joaquın de Andres y Martinez de ArenasaFacultad de Ingenierıa

Universidad de Buenos AiresCiudad Autonoma de Buenos Aires, Argentina


Mauricio AnigsteinFacultad de Ingenierıa

Universidad de Buenos AiresCiudad Autonoma de Buenos Aires, Argentina


Resumen—En este trabajo se presenta el desarrollo de unaplataforma robotica movil de 6 grados de libertad controladapor un sistema distribuido. La plataforma adquiere su movilidadgracias a 6 miembros articulados, de 3 grados de libertad cadauno, coordinados por un procesador central que utiliza unsistema operativo Linux embebido. El control de los actuadoreses independiente para cada miembro y es llevado a cabo por mi-crocontroladores dedicados. Se presentaran tambien los distintosproblemas que deben solucionarse para que la plataforma sedesplace y como fue implementada la solucion para estas tareas.

I. INTRODUCCION

El estudio de los robots caminantes cobra importancia enla decada del 60 (habıa quedado relegado inicialmente porquese suponıa que era un sistema de locomocion inferior y porla complejidad del control). Los trabajos de Bekker ([1], [2])mostraron que los robots con patas son superiores a los robotsmoviles con ruedas en su relacion carga/potencia consumida,en su capacidad de moverse en terrenos adversos, y no menosimportante: son mas ecologicos porque no destruyen el terrenoa su paso (solo dejan huellas discretas).

Bekker amplio la investigacion de maquinas con multiplespatas que origino una variedad de trabajos en el area ([3], [4],[5], [6], [7], [8], [9], [10], [11]).

Una rama particular e importante de la robotica movil conpatas es el estudio de los modos de caminar. Los primerosen usar una matematica para este estudio fueron Tomovic yKarplus ([12]) y se basaron en los trabajos de Muybridge ([13],[14]) quien, mediante secuencias de fotos, identifico los modosde caminar de distintos cuadrupedos y bıpedos. Hildebrand([15]) introdujo algunos conceptos y metodos importantes, quefueron extendidos posteriormente por McGhee ([16]). Estamatematica permitio la clasificacion de los distintos modosde caminar y el estudio de estabilidad de los mismos, yen 1988 Waldron y Song, en su libro Machines that walk([17]), la utilizan para el diseno del controlador de un vehıculocaminante de 6 patas asegurando la estabilidad estatica delmismo.

La robotica movil con patas tiene los mismos problemas dela robotica clasica o industrial con el agregado de que el robotno esta solidamente adherido al suelo sino que, al contrario,esta libre. Esta libertad trae problemas de estabilidad que debenser tenidos en cuenta en el planeamiento del movimiento.

El robot que se estudiara adquiere su movilidad gracias amiembros articulados que le permiten desplazar su entorno

de trabajo en el espacio. El planeamiento no se reduce alcalculo cinematico del robot sino que implica varias decisionesanteriores que definan cual es la posicion deseada para elcuerpo y los miembros. En parte estas decisiones estan atadasa la solucion del problema de estabilidad.

Existen varios modos de caminar o gaits que son lassecuencias de posiciones del cuerpo y los miembros quepermitiran que el robot camine. Cada uno de estos modosdefine cuales son las patas, y cuales las posiciones de apoyo delos pies, que soportaran al cuerpo a lo largo del movimiento.

A partir de la morfologıa del robot y los distintos puntospor los cuales tiene que pasar el centro de gravedad del cuerpo,se debe hacer un planeamiento de la trayectoria del cuerpo. Sehara este calculo cinematico tratando al cuerpo y las patasapoyadas como un robot paralelo ([18]). Las patas que seencuentren levantadas del piso deberan adelantarse para serusadas en la siguiente translacion del cuerpo. En este casocada pata sera tratada como un robot serie haciendo el calculocinematico del efector final, el pie.

El sistema de generacion de angulos que utiliza los trespasos antes nombrados (generacion de gait, generacion detrayectoria para el cuerpo y las patas en traslacion y calculodel problema inverso) fue programado en Python para hacerlas pruebas de los calculos y la posterior implementacion deun robot real.

Se presentara el sistema embebido que da soporte algenerador de angulos y al controlador del robot, ası como elhardware distribuido encargado del control del robot.

II. SOFTWARE DE CONTROL, MONITOREO Y SIMULACION

El programa fue pensado de forma que fuese el mismocodigo tanto en la etapa de desarrollo de los algoritmos ytesteo de los mismo, como en el controlador del robot real.Para esto se armo de forma modular y con tareas distribuidas,como se muestra en el diagrama en bloques de la figura 1.

Se eligio este esquema distribuido para poder inicialmentetrabajar en una PC simulando el robot en el entorno OpenGLpasando despues al robot real. La comunicacion entre procesosse hace por medio de sockets de red que permiten visualizaren el entorno 3D corriendo en una PC los calculos hechos enel robot.

La distribucion mas comun para la ejecucion de estosbloques es donde los graficadores se ejecutan en una PC y


173

Modelo Cinematico Modelo Grafico

S

E

R

V

I

D

O

R

CLIENTE

CLIENTE

CLIENTE

Distribuidor

de

angulos

Graficadorde

curvas

GraficadorOpenGL

Sistema

generador

de

angulos

Figura 1. Diagrama en bloques del software de control.

el sistema de generacion de angulos junto al distribuidor deangulos se ejecutan en el sistema embebido del robot.

A continuacion se explicaran los bloques mas importantes.

II-A. Modelo Cinematico

El robot esta definido por su modelo cinematico quecontiene la informacion morfologica y las funciones necesariaspara el calculo cinematico. Para este trabajo se desarrollarondos modelos distintos, uno para el robot hexapod de 3 GDL(traslacion en los ejes X e Y , y rotacion en el eje Z), y otropara el robot hexapod de 6 GDL (traslacion y rotacion en lostres ejes). Los grados de libertad del robot y los problemas deredundancia fueron tratados en un trabajo anterior ([19]).

Los modelos cinematicos estan estructurados dentro declases. La clase del modelo tiene como atributos las medidasy parametros del robot. Siempre pensando en una solucionmodular y estructurada los miembros fueron definidos consu propio modelo cinematico y metodos correspondientes,tratandolos como robots serie independientes.

El metodo mas importante de estas clases es el que resuelveel problema inverso del robot que busca los angulos necesariosen los actuadores para llegar a una posicion y orientaciondefinidas. Este metodo se apoya en el mismo metodo dela clase que define el modelo cinematico de los miembros.Esta solucion permite probar la cinematica mas sencilla delos miembros para despues implementar la solucion del robotsegun se muestra en el diagrama de flujo de la figura 4.

II-B. Generador de angulos

El esquema del generador de angulos se muestra en lafigura 2. La generacion de angulos parte del planeamiento dela trayectoria, generando el gait para cada tramo proyectado.Para cada paso de los distintos gaits se calcula la trayectoria

cartesiana y posteriormente se resuelve el problema inverso delrobot. A continuacion se explica cada uno de estos procesos.

Planeamiento

Generador de Tripod Gait

Generador de Wave Gait

Generador de Crab Gait

Generador de trayectoriacartesiana

Calculo del problema

Sistema de entrga

planeamientoTripod gait

Cola de

Wave gait Crab gait

Gait

cartesianatrayectoria

inversoproblema

Cola de Cola deplaneamiento planeamiento

Cola deprocedimiento

delplaneamiento

Cola de

Cola de

inverso

Cola del

de angulos

Figura 2. Esquema de threads y colas del generador de angulos.

Cada uno de los procesos corre en un thread independienteque utiliza la informacion de la cola que lo precede.

1) Planeamiento: Dados los puntos inicial y final en laterna mundo se generan los movimientos intermedios que deberealizar el robot. Estos movimientos se definen como el puntoinicial, el punto final y el modo de caminar con el que debeejecutarse. Para conseguir que los puntos planeados se calculenen el orden correcto, por los distintos threads, se ideo unsistema de colas en el cual el thread de planeamiento ingresaun punto en la cola de uno de los gaits y espera a que elthread correspondiente a ese modo de caminar devuelva elmismo punto por una cola de procedimiento. Recien en esemomento el thread de planeamiento agregara un punto nuevoen las colas de los modos de caminar.

2) Generador de gait: Cuando alguna de las colas de gaittiene un punto, el thread correspondiente lo toma y comienzala generacion de pasos. Estos se generan de forma cıclica porel thread en cada iteracion. El calculo devendra en una listade puntos intermedios por los cuales debe pasar el cuerpo yla forma en que debe pararse el robot entre estos puntos.

En el diagrama de flujo de la figura 3 se ve el algoritmo degeneracion de estados de un wave gait segun el β ([17]) delmovimiento. Este parametro indica la porcion del tiempo totalde un paso en que cada pata permanece en fase de soporte delcuerpo. El tiempo t se incrementa en cada llamada del threadde cero a T , el perıodo del movimiento. En forma cıclica se


174

Calculo estado miembroi

tinicio−soporte = |φiT |T

tinicio−soporte ≤ t <

tfin−soporte = |φiT + βT |T

Estado = soporte

tfin−soporte ≤ t <

Estado = transferencia

tinicio−soporteSi

No

Estado

< tfin−soporte

tinicio−soporte tfin−soporte

No

No

SiSi

Figura 3. Diagrama de flujo de la generacion de estados

calculan todos los pasos intermedios (posicion del cuerpo ylos apoyos) hasta generar el ultimo paso, que llega al puntodeseado.

3) Generador de trayectorias cartesianas: Cuando el ge-nerador de gaits genera dos o mas puntos el generador detrayectorias cartesianas los toma y, dependiendo del tipo degait, genera los puntos intermedios del movimiento. En elcaso particular de gaits de movimiento lineal se calcula unatrayectoria lineal para el cuerpo y una trayectoria de traslacionpara las patas que no estan en soporte.

4) Calculo del problema inverso: Teniendo la orientaciony la posicion deseada para el cuerpo, y las posiciones dondeestan apoyadas las patas relativas al mundo, se calculalaposicion de apoyo relativa al cuerpo. Con este dato y el dela posicion de sujecion de la pata relativa al cuerpo se llamaa la resolucion del problema inverso de la pata (figura 4).

Posicion del cuerpo

Orientacion del cuerpo

Posicion de apoyo de las patas

Caculo problema inversorobot paralelo

Calculo de la posicion

relativa del apoyo a la base

Posicion relativa de los apoyos

a la base de cada miembro

Calculo del problema inversodel cada uno de los miembros

Angulos de todas las

articulaciones

Figura 4. Diagrama de flujo del calculo del problema inverso.

5) Distribuidor de angulos: Una vez calculados los angulosel distribuidor se encarga de enviarlos a cada uno de losclientes que esten conectados. Los clientes podran ser elgraficador OpenGL o la plataforma robotica.

II-C. Controlador principal

Con la idea de correr el mismo software tanto en una PCcomo en el controlador del robot se eligio un dispositivo quepermita la ejecucion de codigo python. Se utilizo una placaBeagleboard con un sistema operativo GNU/Linux. Esta placatiene un microcontrolador OMAP3530 de Texas Instruments([20]) con las caracterısticas necesarias para poder instalarLinux.

El sistema esta formado por:

Bootloaders con la configuracion de los pines nece-sarios para la placa.

Kernel Linux con soporte para la placa, comunicacionI2C y manejo de GPIO.

File System base con python y librerıas matematicasnecesarias para ejecutar el controlador.

1) Bootloader: El booteo de la placa implica 3 aplicacionesdistintas (figura 6).

xloader

ROMCODE

uBootBootloader de

primer nivel

Bootloader de

primer nivel

Kernel

Aplicaciones de usuario

Figura 6. Etapas del booteo de la placa.

La aplicacion de booteo de bajo nivel se llamaROMCODE, que es un segmento de codigo ya grabado en laROM del microcontrolador omap3530 que se encarga de hacerlas inicializaciones primordiales. Entre estas se encuentra elinicio de los perifericos y de la SRAM. Una vez inicializadobusca entre los dispositivos de booteo (Serial, NAND, eMMC,SD y USB) una imagen valida del bootloader de primer nivel.

El bootloader de primer nivel es el x-loader. Estelo otorga la misma empresa que fabrica el chip (TexasInstruments) y es una version reducida del bootloader DasUBoot. Este es el encargado de setear los multiplexores de lospines, inicializar los clocks y la memoria SDRAM cargandoen esta el bootloader de segundo nivel.


175

Adaptador

Controlador

maestro

Servo Motor

Power System

Controlador Controladordistribuido distribuido

Servo Motor

Servo Motor

Servo Motor

Senalde

sincronismo

de niveles

Bus de

comunicacion

Comunicacion

inalambrica

Controladordistribuido

Servo Motor

Servo Motor

Servo Motor

Controlador

distribuido

Servo Motor

Servo Motor

Servo Motor

Controladordistribuido

Servo Motor

Controlador

distribuido

Servo Motor

Servo Motor

Servo Motor

Servo Motor

Servo Motor

Servo Motor

Servo Motor

Figura 5. Diagrama en bloques del hardware

El bootloader de segundo nivel queda a eleccion delusuario. Este es el encargado de terminar de inicializar losperifericos del microcontrolador y cargar el kernel en lamemoria SDRAM.

En este caso se utilizo una version completa de UBootcross compilada desde el codigo fuente para poder configurarlos pines del microcontrolador como entrada/salida.

2) Kernel Linux: El kernel es el encargado de la interaccionde las aplicaciones en espacio de usuario y el hardware.Utilizando las llamadas a sistema las aplicaciones de espaciode usuario puede hacer uso de los perifericos y de los distintosrecursos del hardware.

Se utilizo un kernel 2.6.32 con los parches especiales paraomap3 y beagleboard. Para este proyecto fue necesario crosscompilar el kernel desde su codigo fuente para agregar elsoporte de comunicacion I2C, manejo de GPIO y dongle wifi.

Para poder acceder desde espacio de usuario al dispositivoI2C se utilizo el modulo i2c-dev que crea una interfaz deusuario dentro del file system virtual del kernel, sysfs. Seescribio una biblioteca en python que maneja estos archivospara enviar informacion a traves de la interfaz I2C de la placa.

El modulo de control de GPIO permite, tambien desde userspace a traves de sysfs, controlar el modo de los pines y lalectura o escritura de los mismos.

3) Root filesystem: Para completar la instalacion del SOse armo un root filesystem con las herramientas basicas,Python, la librerıa matematica Numpy y herramientas para la

configuracion de red. Para esta tarea se utilizo el entorno decross compilacion OpenEmbedded.

II-D. Control de cada miembro

Los angulos calculados por el controlador principal sondistribuidos a los distintos miembros por el modulo distribuidorde angulos mediante el bus I2C. Cada pata tiene una direccionen el bus y recibe 3 comandos de seteo de angulo.

Los controladores ditribuıdos, programados en C utilizandola librerıa AVR-libc y el compilador gcc, ejecutan un firmwareque en su lazo principal parsea los comandos de I2C parala configuracion de los angulos maximo y mınimo de cadaarticulacion y el angulo deseado. El duty cicle de los PWM secalcula en base a estos 3 parametros.

Los PWMs son generados utilizando un unico timer delmicrocontrolado de la siguiente manera:

Los PWM se generan de forma cıclica cada 13 del perıodo

total del PWM utilizando una maquina de estados que decidecual es el siguiente y configura una interrupcion por compara-cion del timer con el duty cicle calculado.

III. PLATAFORMA ELECTRONICA

El sistema de control del robot esta formado por uncontrolador principal y 6 controladores distribuidos en cadauna de las patas, como se muestra en la figura 7.

Los controladores distribuidos se conectan al principal pormedio de un BUS y se utiliza una senal de sincronismo parala coordinacion de movimientos.


176

T = 20ms

13T

13T

13T

PWM-1

PWM-2

PWM-3

Figura 7. Diagrama en bloques del hardware

III-A. Controlador principal

Para el controlador principal se eligio la placa BeagleBoard(rev. C4) comercializada por beagleboard.org ([21]). Esta pla-ca, entre muchas otras, utiliza el microcontrolador OMAP3530en conjunto con otros integrados para brindar al usuario unequipo con las capacidades de una netbook pequena pero debajo consumo y bajo costo.

Las caracterısticas principales de la placa son:

Microprocesador OMAP3530

256MB de memoria NAND

256MB de memoria SDRAM

Bahıa para memorias SD/MMC

USB OTG

USB Host

Integrado de manejo de potencia TPS65950

La caracterıstica mas importante por la que se utilizo estaplaca es por el microprocesador que utiliza. El OMAP3530 dela empresa Texas Instruments tiene como core un Cortex A8de la empresa ARM ([22]) de 720MHz con unidad de manejode memoria (MMU). Esta caracterıstica le permite ejecutar unsistema operativo Linux.

La tension de logica de la placa es de 1,8 V. Parapoder conectar con dispositivos de mayor tension se utilizo elintegrado TXS0108 de Texas Instruments.

III-B. Controladores distribuidos

Para el control de posicion de cada pata se utiliza unmicrocontrolador de 8 bits. Cualquier modelo que pudiesegenerar 3 PWM de 50Hz y comunicarse por I2C era utilpara la aplicacion. Se eligio el ATMega88 de la familia AVR,fabricado por la empresa ATMEL, en su formato TQFP de32 pines. La decision fue basada principalmente en que sumodulo interno de comunicacion I2C permite la utilizacion deinterrupciones para la transmision de datos.

El microcontrolador se utiliza como slave I2C. Por estainterfaz recibe los comandos que configuran los angulos decada articulacion y, junto a una senal de sincronismos accesiblepor una interrupcion externa, se hace efectivo el seteo de estosangulos.

III-C. Bus de comunicacion

La comunicacion elegida es una comunicacion serial sin-cronica. El procesador central tiene el rol de master y cadauno de los miembros es un slave dentro de un BUS I2C. Cadamiembro se configura en la programacion con una direccionunica que lo identifica en el BUS.

Controlador

Principal

VccBUS

Miembro1

Miembro3

Miembro5

Miembro2

Miembro4

Miembro6

Rpu

SDA SCL

Figura 8. Conexion de los miembros y el controlador principal en el BUS.

IV. CONCLUSIONES

El sistema distribuido permitio llevar a cabo el desarrollode forma modular haciendo pruebas unitarias incrementales.La interconexion entre procesos con sockets de red permi-tio probar los modulos de generacion de angulos y distribucionen el sistema embebido de forma independiente haciendo eldesarrollo mas sencillo.

El prototipo de robot construido sigue los movimientosimulados en la interfaz OpenGL (figura 10). El prototipomecatronico se puede ver en la figura (9).

REFERENCIAS

[1] M. G. Bekker, Off-the-road locomotion: Research and development interramechanics. University of Michigan Press (Ann Arbor), 1960.

[2] Bekker, Introduction to terrain-vehicle systems. University of MichiganPress, 1 Mar. 1969.

[3] R. Mosher, “A versatile walking truck,” Proceedings of the Transporta-tion Engineering Conference. London: Institution of Civil Engineers.,1968.

[4] W. Cox, “Big Muskie,” News in Engineering, Ohio State University,pp. 25–27, 1970.

[5] U. Mocci and Patternella, “Experiments with Six-Legged WalkingMachines with Fixed Gait,” Report 2-12, Institute of Automation, RomeUniversity, 1972.

[6] Gurfinkel, “A system for Controlling the Extremities of ArtificialWalking Apparatus,” Report No 5, General and Molecular PhysicsSeries, Physio-Technical Institut, Moscow, 1974.

[7] Buckett J.R., “Design of an On-Board Electronic Joint System for aHexapod Vehicle,” Master’s thesis, The Ohio State University, Colum-bus, Ohio, 1977.


177

Figura 9. Prototipo mecatronico

[8] S. Hirose and Umetani, “The Basic motion Regulation System forQuadruped Walking Machine,” ASME Paper 80-DET-34, Design En-gineering Technical Conference, Los Angeles, 1980.

[9] T. Brown, “Dynamic Study of Four-Bar Linkage Walking MachineLeg,” Master’s thesis, The Ohio State University, Columbus, Ohio,1982.

[10] M. Raibert and Sutherland, “Machines That Walk,” Scientific American,vol. 248, no. 2, pp. 44–53, 1983.

[11] M. Russell, “Odex 1: The First Functionoid,” Robotics Age, vol. 5,no. 5, pp. 12–18, 1983.

[12] R. Tomovic and Karplus, “Land Locomotion Simulation and Con-trol,” Proceedings Thirds International Analogue Computation Meeting,Opatija, Yugoslavia, pp. 385–390.

[13] E. Muybridge, Animals in motion. Chapman and Hall, 1899.[14] ——, The Human Figure in Motion. Dover Publications, Inc., 1901.[15] M. Hildebrand, “Simetric Gaits of Horses,” Science, vol. 150, pp. 701–

708, 1967.[16] R. McGhee and A. Frank, “On the stability properties of quadruped

creeping gaits,” 1968.[17] S.-M. Song and K. J. Waldron, Machines That Walk: The Adaptive

Suspension Vehicle. The MIT Press, 1988.[18] L.-W. Tsai, Robot Analysis: The Mechanics of Serial and Parallel

Manipulators. Wiley-Interscience, 1999.[19] J. de Andres y Martinez de Arenasa and M. Anigstein, “Sobre la

redundancia en la actuacion y los grados de libertad de una maquinacaminante,” RPIC 2011.

[20] “Texas Instruments.” [Online]. Available: http://www.ti.com[21] “BeagleBoard.org.” [Online]. Available: http://beagleboard.org

Figura 10. Simulador

[22] “ARM.” [Online]. Available: http://www.arm.com


178

“Clasificador inteligente de objetos con visión artificial utilizando un brazo articulado”

Fernández Diego; Ibarra Alexis Gabriel Facultad de Ciencias Exactas, Naturales y Agrimensura

Universidad Nacional del Nordeste Corrientes, Argentina

En este proyecto se implementó un sistema clasificador de objetos, en donde se utilizó

la visión artificial para la detección de las posiciones y las características de los objetos, para que luego puedan ser manipulados por un brazo robot.

Se desarrolló una plataforma de visión artificial, la cual consiste en una cámara webcam como sistema de captura, una pc para el procesamiento de imágenes, y un brazo robot como sistema dinámico. El brazo robot es controlado por la plataforma de hardware Arduino UNO. El procesamiento consiste en la aplicación de algoritmos y transformaciones de las imágenes de forma de obtener la información necesaria para manipular el sistema dinámico y realizar la tarea asignada. Para ello se utilizó la librería de visión artificial OpenCV, especialmente sus funciones Histograms, Contours, Moments, ConvexHull, ConvexDefects, Meanshift y Camshift, con los cuales se implementaron principalmente los siguientes algoritmos de reconocimiento de ciertas características de los objetos en imágenes (color y tamaño) y seguimiento de objetos en una secuencia de imágenes.

Para lograr flexibilidad, portabilidad y la posibilidad de realizar futuras mejoras al software se desarrolló íntegramente con herramientas libres y de código abierto (lenguaje de programación Python, PyQt y PyQt4 Designer para la interfaz gráfica).

Se realizaron pruebas de posicionamiento del brazo logrando un error máximo relativo de 0,087 (8,7 %). A su vez se probó el algoritmo de detección de objetos en donde las posiciones detectadas contuvieron menos del 8% de error, por lo que el funcionamiento del algoritmo resultó muy aceptable.

Adicionalmente se desarrolló una aplicación que permite, utilizando el mismo hardware y a través de la captura de los movimientos de la mano del usuario, el control del brazo robot. Para ello se desarrolló un algoritmo capaz de detectar la posición de la mano del usuario en las 3 dimensiones.


179

“Force-Feedback Manipulator Based on the Delta Robot”H. Lasevitch, L. Lisboa, N. R. Bedin Neto, A. T. Salton and J. V. Flores

Group of Automation and Control SystemsPontifical University of Rio Grande do Sul

Av. Ipiranga, 6681, 90619-900 Porto Alegre - RS. Brazil

This article describes the development and design of prototype of a haptic device. Some conceptsof haptics and force feedback are presented, then it explains the mechanical structure, based on theDelta Robot and the hardware and software used in the design of the prototype. It also approachesa solution to the forward kinematics problem required to estimate the position of the end-effector.Finally results are shown in order to validate the prototype. The goal is to demonstrate the potentialof haptics technology, highlighting the importance of this technique on the interaction of the humanwith the machine, facilitating situations where it is required from the user good skills to deal withhigh precision equipments.


180

��ABC��

DAEF��E��

��


181


182

PAPER CASE 2013, APRIL 2013 1

Diseno, Implementacion y Validacion de unabiblioteca de algoritmos de control para sistemas

embebidosJ. Ezequiel Esposito∗, Ariel Lutenberg†

∗[email protected], †[email protected].∗Laboratorio de Sistemas Embebidos (FI-UBA), Buenos Aires, Argentina. †Laboratorio de Sistemas Embebidos

(FI-UBA), Buenos Aires, Argentina.

Abstract—El objetivo principal de este trabajo es disenar,implementar y validar una biblioteca de algoritmos de controlpara ser utilizada en un RTCS. Los sistemas dinamicos modernosestan compuestos por diversos procesos que necesitan ser contro-lador para cumplir con los requerimientos de la aplicacion. Paracumplir con dichos requerimientos, es habitual que se utilicensistemas embebidos que deben ejecutar diferentes algoritmos decontrol de manera concurrente y a la vez deben ejecutar otrastareas como atender protocolos de comunicacion, administrarinterfaces graficas de usuario, etc. La biblioteca desarrolladaen esta tesis atiende en forma autonoma las tareas asociadasa los algoritmos de control, de modo que el programadorpueda concentrar sus esfuerzos en las otras tareas de diseno delsistema embebido. La misma administra de manera eficiente losdiferentes controladores instanciados. Los resultados presentados,demuestran que la biblioteca puede ser efectivamente portada aun microcontrolador economico como el LPC1769 Cortex-M3 ydesarrollar en el mismo un excelente desempeno general.

Keywords—Embedded Systems, Digital Control, RTCS, RTOS,OOP

I. MOTIVACION Y PRESENTACION DEL PROBLEMA

Se presenta el diseno e implementacion de una bibliotecade algoritmos de control para sistemas embebidos. Se pre-tende que la misma sea una solucion completa para sistemasdinamicos que requieren ser administrados mediante multipleslazos de control [1]. El principal objetivo de este trabajo esaportar una biblioteca de codigo que permita implementarsistemas de control complejos a partir de utilizar un sistemaembebido de pequeno tamano, bajo consumo de energıa y bajocosto.

En la actualidad, tanto en el ambito academico como enel industrial, existen una gran variedad de sistemas dinamicosque requieren utilizar lazos de control para cumplir con losdiferentes requisitos de las aplicaciones. Las herramientasdisponibles para implementar dichos lazos de control suelenser costosas, poco adaptables a las necesidades de la aplicacione incluso inviables en muchas aplicaciones modernas que re-quieren soluciones de baja potencia, bajo peso y bajo volumen(e.g. quadrotores). Entre las soluciones existentes podemosmencionar [5]:• Paquetes de software sobre sistemas operativos comer-

ciales: Se puede mencionar como ejemplo al software

Matlab, que combinado con un hardware de adquisicionde datos puede ser utilizado para implementar contro-ladores de sistemas dinamicos. Las principales desven-tajas que presenta son que requieren de una computa-dora voluminosa con gran poder de procesamiento paraejecutar el sistema de control y que es una solucioncostosa. La principal ventaja que presenta la soluciones la gran cantidad de recursos matematicos disponiblespara implementar estrategias de control avanzadas.

• Hardware propietario: Se puede mencionar como ejem-plo a los Controladores Logicos Programables (PLCs).Son dispositivos electronicos, ampliamente utilizados enla industria para implementar sistemas de control. Lasprincipales desventajas que tienen es que son solucionespoco flexibles y difıciles de utilizar en escenarios dondese requieren algoritmos complejos de control. La princi-pal ventaja que tienen es que son dispositivos robustoscon una larga trayectoria en el mercado industrial.

Ambas soluciones mencionadas son caras y realmente invi-ables en una gran variedad de aplicaciones modernas. Por estemotivo, en la actualidad, muchos sistemas de control estansiendo directamente implementados sobre sistemas embebidosde bajo costo, consumo, peso y volumen. La desventaja quetiene este tipo de soluciones es el tiempo de desarrollo quese debe invertir en implementar el algoritmo de controlador.Por este motivo, se propone en este trabajo disenar e imple-mentar una biblioteca de algoritmos de control para sistemasembebidos que permita rapidamente implementar sistemas decontrol, y a su vez, permita utilizar todas las ventajas de losmicrocontroladores modernos.

De la gran variedad de tecnicas de control que existen en laactualidad, en este trabajo se decide desarrollar una versiondel controlador PID (proportional integrative derivative) yuna version del controlador predictivo DMC (Dynamic MatrixController) [3]. La primera estrategia de control es elegidapor su simplicidad tanto a nivel teorico como a nivel deimplementacion (consume pocos recursos de memoria y detiempo) y por los buenos resultados que se consiguen en lapractica en sistemas dinamicos simples. La segunda estrategiade control es elegida por tratarse de un algoritmo de controlde caracterısticas opuestas al PID (consume muchos recursosde memoria y de tiempo), por tratarse de un controlador


183


predictivo extensible a sistemas MIMO que optimiza unafuncion de costos cuadratica para determinar las acciones decontrol y tambien por el desafıo academico que representala problematica de adaptar un algoritmo de elevado costocomputacional en un sistema embebido de bajos recursos.

En este artıculo, se presenta la implementacion de la bib-lioteca, detallando en particular, las tecnicas utilizadas paragenerar un sistema flexible, escalable e independiente delhardware y del RTOS utilizado. Finalmente se presentan losresultados obtenidos al portar la biblioteca en el microcon-trolador LPC1769 del fabricante NXP con tecnologıa ARMCortex-M3 en conjunto con el Sistema Operativo de TiempoReal FreeRTOS.

II. SOLUCION PROPUESTA

Dada la gran evolucion que tuvieron los sistemas embebidosen la ultima decada, en particular los microcontroladores, enla actualidad es posible generar soluciones en el formato debiblioteca de codigo portables a diferentes plataformas dedesarrollo. En este trabajo, se presenta como solucion a laproblematica de implementar sistemas de control digital, unabiblioteca de codigo para sistemas embebidos. La misma esdenominada libRTCS y esta especialmente disenada para quese pueda implementar facilmente en un microcontrolador unSistema de Control de Tiempo Real (RTCS). Los RTCS, engeneral, son utilizados para controlar sistemas dinamicos queestan compuestos por muchos subprocesos. Cada subprocesorequiere de un lazo de control independiente, lo que resulta enun escenario con diferentes algoritmos de control ejecutandosede manera concurrente. Para lograr administrar las tareasconcurrentes de manera exitosa, los RTCS utilizan RTOS [2][4].

Los requisitos que debe cumplir la libRTCS son los sigu-ientes:

• La libRTCS debe ser independiente de la plataforma demicrocontrolador utilizado.

• La libRTCS debe ser independiente del RTOS utilizado.• La libRTCS debe incluir diferentes algoritmos de con-

trol.• La libRTCS debe poder instanciar y ejecutar algoritmos

de control de manera concurrente.• La libRTCS debe incluir al menos un test de schedula-

bility, para determinar si el conjunto de controladoresinstanciado es o no administrable.

• La libRTCS debe ser flexible y escalable, es decir, debeser posible agregarle nuevas estrategias de control sinmodificar la estructura de codigo existente.

En la Seccion III se presenta el diseno general de la libRTCSy luego en la Seccion IV se detalla la implementacion de losmodulos principales de la misma.

III. DISENO

La libRTCS esta disenada con el objetivo de que posea lassiguientes caracterısticas fundamentales:

• Flexibilidad: Disponer de una biblioteca de codigo es-tructurada de manera tal que sea flexible y pueda serfacilmente ampliada.

• Escalabilidad: Tener la posibilidad de incorporar nuevosalgoritmos de control digital a la libRTCS sin tener quemodificar el codigo existente.

• Portabilidad: Poder portar facilmente la biblioteca adiferentes microcontroladores y a diferentes RTOS.

• Usabilidad: Poder utilizar la biblioteca en diferentesescenarios de control, garantizando el cumplimiento delas restricciones temporales impuestas al sistema global.

Por un lado, es fundamental que la caracterıstica de flexibil-idad sea buscada desde los inicios del diseno de la libRTCS.Para conseguir esta caracterıstica se realiza un diseno modular.Por otro lado, la escalabilidad se consigue utilizando cor-rectamente diferentes conceptos y tecnicas de ProgramacionOrientada a Objetos (OOP). Se pretende poder incorporar ala biblioteca nuevos algoritmos de control digital sin tenerque modificar el codigo existente. La portabilidad se consiguea partir de incorporar un modulo que permita abstraer elhardware especıfico, conocido bajo el nombre de HardwareAbstraction Layer (HAL), y otro modulo que permita abstraerlas llamadas al RTOS. Por ultimo, para que la bibliotecadisponga de buena usabilidad se anade un modulo que puedaadministrar automaticamente las tareas que ejecutan los algo-ritmos de control. Este ultimo modulo se encarga de hacerlas correspondientes llamadas al RTOS para crear las tareasy asignar sus prioridades. Estas ultimas, son asignadas au-tomaticamente a partir de ejecutar un test de schedulabilityque permite determinar si todas las restricciones temporalesimpuestas pueden o no ser cumplidas.

En la Figura 1 se presenta el esquema general de la libRTCS.Se puede observar la estructura modular de la biblioteca,compuesta por un modulo principal y diferentes modulossecundarios que interactuan con el primero.

Fig. 1. Esquema General de la libRTCS


184


A continuacion se hace una breve introduccion al diseno decada modulo y luego en la Seccion IV se presenta la imple-mentacion de cada modulo en el lenguaje de programacionestandar C.

• Modulo principal: Este modulo es el nucleo central dela libRTCS. Su funcion principal es almacenar y admin-istrar una lista con la informacion de todos los contro-ladores instanciados dinamicamente durante la ejecuciondel sistema. Como cada controlador incorporado en lalibRTCS utiliza sus propios tipos de datos, ya que cadauno dispone de diferentes parametros de configuracion,es un requisito fundamental que la lista pueda almacenarinstancias de diferentes tipos de controladores. Es decir,la lista debe ser un contenedor de informacion inde-pendiente del tipo de dato almacenado. En la SeccionIV se explica como se implementa una lista con estascaracterısticas en el lenguaje de programacion estandarC.

• Modulo de interfaces: Este modulo es fundamental paralograr que la libRTCS pueda ser portada facilmente adiferentes microcontroladores y a diferentes RTOS. Porun lado se incluye una capa de abstraccion que le permitea la biblioteca utilizar recursos del microcontroladorindependiente de cual sea este ultimo. Por otro lado seincluye tambien una capa de abstraccion para que la bib-lioteca pueda independizarse del RTOS. Habitualmentelos RTOS incluyen un modulo para administrar memoriadinamica y un modulo para administrar tareas. Mediantela capa de abstraccion para el RTOS, la libRTCS puedeutilizar estos recursos independientemente de cual sea elRTOS particular que se esta utilizando en la aplicacion.

• Modulo de administracion de tareas: La principalfuncion de este modulo es la de utilizar toda la in-formacion disponible en la lista de controladores delmodulo principal para crear en el RTOS todas las tareasnecesarias para ejecutar los correspondientes algoritmosde control. Tambien incorpora la estructura necesariapara soportar diferentes esquemas de scheduling. Porultimo, dispone de los algoritmos que aplican los difer-entes test de schedulability, los cuales permiten deter-minar si un conjunto de tareas puede cumplir o no conlos requerimientos temporales impuestos. Cabe destacarque en este trabajo, se pondra especial enfasis en elesquema de scheduling RMS y sus correspondientes testde schedulability.

• Modulo de controladores: Por ultimo, en este modulo seimplementan concretamente los diferentes algoritmos decontrol digital. La biblioteca libRTCS esta estructuradade manera tal que facilmente se puedan agregar nuevosalgoritmos de control digital. Para lograr esta finalidad,se diseno una interfaz y una estructura de datos comuna todos los algoritmos de control.

IV. MODULOS DE LA BIBLIOTECA

En esta seccion se detalla la implementacion de los modulosque componen a la libRTCS. La misma esta implementada enel lenguaje de programacion estandar C.

A. Modulo principalEl modulo principal es el encargado de almacenar, admin-

istrar y proveer a los modulos secundarios la informacionde todos los controladores instanciados durante la ejecuciondel RTCS. A partir de esta informacion se crean las tareasdel RTOS, que en definitiva, son las encargadas de ejecutarlos algoritmos de control y asegurar que se cumplan con lasrestricciones temporales impuestas.

Como la biblioteca libRTCS incluye diferentes algoritmos decontrol, la informacion que este modulo almacena es variableen funcion del tipo de controlador instanciado. Por este motivo,se debe implementar un contenedor de informacion que seindependiente del tipo de dato que el mismo almacena. Sedecide implementar una lista simplemente enlazada, ya que ala misma se le pueden agregar y quitar elementos en tiempo deejecucion utilizando de manera eficiente la memoria dinamica.

Para poder implementar una lista simplemente enlazada quesea independiente del tipo de dato particular de cada algoritmode control, se necesita que estos ultimos tengan una interfazpublica comun y generica. Pero a su vez, se requiere que cadacontrolador instanciado ejecute su correspondiente algoritmo.En un lenguaje de programacion orientado a objetos estaescalabilidad se consigue utilizando los conceptos de herenciay polimorfismo. Este tipo de lenguajes de programacion in-corporan mecanismos que permiten aplicar estos conceptos demanera nativa al lenguaje. En cambio, un lenguaje de progra-macion estructurado (como lo es el lenguaje de programacionC), no incorpora este tipo de mecanismos de manera nativa. Enla IV-D se explica como se logran implementar los conceptosde herencia y polimorfismo en el lenguaje de programacionC.

B. Modulo de interfacesEl recurso basico que la libRTCS necesita utilizar de un

microcontrolador es un timer con resolucion del orden delmicrosegundo. El mismo es utilizado para medir de maneraprecisa, durante la ejecucion del sistema RTCS, el tiempo deprocesamiento que consumen los algoritmos de control instan-ciados en el peor caso (WCET). Las mediciones del tiempode procesamiento son fundamentales para poder ejecutar loscorrespondientes test de schedulability.

Para lograr independizar a la biblioteca libRTCS de losmicrocontroladores, se utilizan los punteros a funcionesdisponibles en el lenguaje de programacion C. Un punteroa funcion, es una variable que puede almacenar la direccionde memoria de una funcion o procedimiento que tiene elmismo encabezado que el especificado en la declaracion delpuntero. Entonces si se almacena en el puntero la direccion dememoria de una funcion o procedimiento, luego la invocacionse puede realizar desde dicho puntero. Esta herramienta esfundamental para poder escribir codigo flexible y escalable.El modulo de interfaz con los microcontroladores declarados punteros a funciones, uno para iniciar la cuenta de untimer y otro para finalizar la cuenta del mismo. El usuario dela libRTCS configura dichos punteros a funciones, para queapunten a procedimientos ya declarados y definidos (fuera dela libRTCS).


185


Por otro lado, los recursos basicos que necesita utilizar lalibRTCS de un RTOS son:

• Administrador de memoria dinamica• Administrador de tareas• Administrador de tiemposEl administrador de memoria dinamica del RTOS es fun-

damental para que los diferentes controladores puedan serinstanciados y eliminados en tiempo real. Los RTOS moder-nos incluyen la implementacion de las funciones tıpicas demanejo de memoria dinamica: malloc y free. Estas funcionesson ampliamente utilizadas por la libRTCS. Por otro lado,el administrador de tareas del RTOS se utiliza para crear,eliminar y coordinar las tareas que se encargan de ejecutara los controladores instanciados. Por ultimo, el administradorde tiempos permite que cada controlador instanciado se ejecutesegun la frecuencia de lazo especificada.

Al igual que en la interfaz con los microcontroladores,mediante la configuracion de los correspondientes punteros afunciones, el usuario de la biblioteca define los recursos quela misma requiere del RTOS.

C. Modulo de administracion de tareasEl modulo de administracion de tareas utiliza intensiva-

mente los recursos del RTOS a traves del modulo de interfaces.Una vez instanciados todos los controladores que la aplicacionrequiere, este modulo se encarga de crear todas las tareas en elRTOS necesarias para ejecutar dichos controladores. Para esto,el modulo utiliza toda la informacion disponible en la listade controladores invocando las correspondientes funciones yprocedimientos publicos del modulo principal.

Este modulo implementa los diferentes test de schedula-bility. Antes de iniciar al sistema, el usuario de la libRTCSpuede utilizar este modulo para determinar si el conjuntode controladores que instancio puede o no cumplir con losrequerimientos temporales impuestos. En este trabajo se utilizael esquema de scheduling RMS (Rate Monotonic Scheduling).La Ecuacion 1 define el test de schedulability basico para RMS.

U =n∑

i=1

Ci

Ti≤ n

(21/n − 1

)(1)

Donde Ci es el tiempo de procesamiento de la tarea i, Ti

es el perıodo de la tarea i y n es la cantidad total de tareasinstanciadas.

D. Modulo de controladoresEl modulo de controladores tiene una importancia funda-

mental en la libRTCS. Este modulo le permite a la bibliotecaincluir nuevos algoritmos de control sin necesidad de modificarel codigo existente. Darle esta funcionalidad a la libRTCS noresulta trivial, ya que cada algoritmo de control implementa suspropios tipos de datos y sus propios algoritmos. Sin embargo,todos los algoritmos de control tambien tienen en comun deter-minados parametros. Entonces, se tiene un esquema en el cualexisten distintos tipos de objetos con una interfaz basica encomun pero que a su vez el comportamiento particular de cada

tipo de objeto es diferente. Como se menciono anteriormente,en un lenguaje de programacion orientado a objetos este tipode esquema es facil de implementar a partir de utilizar losmecanismos nativos de clases, herencia y polimorfismo. Comola libRTCS esta implementada en el lenguaje de programacionC, estos mecanismos no estan disponibles de manera nativa.En esta seccion se explica como se implementan dichosmecanismos en la biblioteca.

En el Listing 1 se presenta la estructura de dato que definea un controlador generico.

Listing 1. Estructura de datos del controlador genericos t r u c t R T C S g e n e r i c C o n t r o l l e r T y p e C o n t r o l l e r{

vo id (∗ C o n t r o l l e r F i r s t R u n F u n c t i o n ) ( vo i d ∗ ) ;vo id (∗ C o n t r o l l e r R u n F u n c t i o n ) ( vo id ∗ ) ;vo id (∗ C o n t r o l l e r S a v e F u n c t i o n ) ( vo i d ∗ ) ;vo id (∗ C o n t r o l l e r T x F u n c t i o n ) ( f l o a t ∗ , u i n t 3 2 t ) ;vo id (∗ C o n t r o l l e r R x F u n c t i o n ) ( f l o a t ∗ , u i n t 3 2 t ) ;vo id (∗ C o n t r o l l e r W o r s t R u n ) ( vo id ∗ ) ;vo id∗ t a s k I d e n t i f i e r ;u i n t 3 2 t t a s k P r i o r i t y ;u i n t 3 2 t per iodInMS ;u i n t 3 2 t p rocesso rT imeInUS ;vo id∗ d a t a ;

} ;t y p e d e f s t r u c t R T C S g e n e r i c C o n t r o l l e r T y p e C o n t r o l l e r

R T C S g e n e r i c C o n t r o l l e r T C o n t r o l l e r ;

Todos los algoritmos de control que se implementan en labiblioteca tienen en comun la informacion que almacena laestructura de datos RTCS genericController TController. Enesta estructura se declaran dos punteros a funciones. Por unlado, el puntero a funcion ControllerRunFunction almacena ladireccion de memoria de la funcion que ejecuta el algoritmo decontrol. Por otro lado, el puntero a funcion ControllerFirstRun-Function almacena la direccion de memoria de la funcionque ejecuta el algoritmo que realiza todas las operacionesmatematicas del controlador que no requieren ser actualizadasen cada iteracion. Cabe aclarar que esta ultima funcion es muyutil para reducir el tiempo de computo de los algoritmos decontrol. Las funciones mencionadas, reciben como parametroun puntero generico con los datos de la instancia particular decada controlador. Cada controlador particular implementa suspropias funciones respetando la firma de los punteros a funciondel controlador generico. Cuando un nuevo controlador esinstanciado, se agrega dinamicamente a la lista de contro-ladores. De esta manera, se logra abstraer completamente cuales el tipo particular del controlador que se instancio. Cadaelemento de la lista de controladores es representado por uncontrolador generico y los punteros a funciones encapsulan elcomportamiento particular de cada algoritmo de control.

En la Figura 2 se muestra un esquema de la lista decontroladores, en la cual fueron agregados diferentes tipos decontroaldores.

V. RESULTADOS EXPERIMENTALES

En este capıtulo, se presentan los resultados obtenidosal portar la libRTCS al microcontrolador LPC1769 [6] delfabricante NXP con tecnologıa Cortex-M3 del fabricante ARMy al utilizar el sistema operativo de tiempo real FreeRTOS


186


Fig. 2. Lista de controladores

[7]. Para obtener los resultados se construye una plataformade hardware que incluye a dos microcontroladores LPC1769comunicados entre sı mediante una interfaz UART. Medianteesta plataforma de hardware se implementa la tecnica desimulacion Hardware In the Loop (HIL). Esta tecnica, esutiliza para validar el funcionamiento de los algoritmos decontrol implementados en este trabajo (PID y DMC). En unmicrocontrolador se realizar la portacion de la libRTCS y en elotro microcontrolador se ejecutan las ecuaciones de recurrenciaque definen diferentes sistemas dinamicos discretos. A partirde intercambiar las senales de referencia, salida y accionde control entre ambos microcontroaldores, se ejecuta entiempo real el conjunto sistema dinamico - sistema de control.Las senales obtenidas en tiempo real, son comparadas conlas senales obtenidas al simular el mismo conjunto sistemadinamico - sistema de control en tiempo no real en Matlab.

Cabe aclarar, que el algoritmo de control DMC, requiereoperaciones matriciales. Por este motivo se utilizo la bibliotecade recursos matematicos DSPlib desarrollada por el fabricanteARM. La ventaja fundamental que tiene este biblioteca derecursos matematicos es que si se utiliza un procesador Cortex-M4 todas las operaciones en punto flotante son resueltas poruna FPU. En este trabajo se utiliza un procesador Cortex-M3 que no incluye una FPU. Por este motivo, todas lasoperaciones en punto flotante son simuladas por software.

En la Figura 3 se presentan los resultados obtenidos al con-trolar un sistema dinamico con el algoritmo PID. Cabe aclararque la ecuacion de recurrencia que define al sistema dinamicono resulta relevante para los resultados que se desean mostraren este trabajo. A la izquierda se observan los resultadosobtenidos al realizar la simulacion en tiempo no real en Matlaby a la derecha los resultados obtenidos al ejecutar el algoritmode control en tiempo real en el LPC1769. En esta figura, segrafican en simultaneo la referencia, la salida obtenida sincontrolador y la salida obtenida con controlador. En la misma,

no se pueden observar diferencias apreciables en las formasde las senales. Cabe resaltar, que el eje horizontal del graficoubicado a la izquierda es en funcion del numero de muestras,mientras que el eje horizontal del grafico ubicado a la derechaes en funcion del tiempo. Esta es una diferencia fundamentalentre los dos graficos y para lograrla, cada muestra obtenidaen el LPC1769 es marcada con un valor temporal absoluto apartir de utilizar un timer del LPC1769.

Fig. 3. Comparacion de senales en Matlab y senales en el LPC1769

En la Figura 4, se puede observar a la izquierda el tiempode computo del algorimo PID y a la derecha el tiempo deprocesamiento del mismo. Cabe aclarar que el tiempo deprocesamiento es el tiempo que tarda el algoritmo en ejecutarsey el tiempo de computo es el tiempo entre la conversionanalogica digital (ADC de la salida y la referencia) y laconversion digital analogica (DAC de la accion de control).

Fig. 4. Tiempo de computo y de procesamiento del PID en el LPC1769

Cabe resaltar que tanto en la Figura 3 como en la Figura 4,el tipo de dato utilizado es para representar numeros reales esfloat. Este tipo de dato utiliza 4bytes para representar numerosreales. Las simulaciones realizadas fueron repetidas para elPID con tipo de dato double (8bytes).

Es importante destacar, que las simulaciones tambien fueronrepetidas para el algoritmo de control DMC. Tampoco se obser-varon diferencias apreciables entre la simulacion realizada enMatlab y la ejecucion realizada en tiempo real en el LPC1769.


187


En la Figura 5, se puede observar a la izquierda el tiempode computo del algorimo DMC y a la derecha el tiempo deprocesamiento del mismo.

Fig. 5. Tiempo de computo y de procesamiento del DMC en el LPC1769

Por otro lado, se obtuvieron las frecuencias maximas a lasque pueden ejecutarse los algoritmos de control implementadosen este trabajo (utilizando un procesador Cortex-M3). Lasmaximas frecuencias se obtuvieron a partir de medir, enejecucion, los tiempos de computo de los diferentes algoritmosde control. A partir de los tiempos de computo medidos yutilizando la regla practica definida en la Ecuacion 2 se puedencalcular las maximas frecuencias de ejecucion de los diferentesalgoritmos de control.

fmax =1

20τ(2)

Donde τ es el tiempo de computo.En la Tabla I se presentan las maximas frecuencias obtenidas

para los algoritmos de control.

Controlador Procesamiento Computo fmax

PID float 9us 28us 1.8KHzPID double 16us 55us 910HzDMC SISO 880us 900us 56HzN = 50P = 10M = 5

DMC SISO 1980us 2000us 25HzN = 80P = 15M = 5

TABLE I. MAXIMAS FRECUENCIAS DE LOS ALGORITMOS DECONTROL EN EL LPC1769

Por ultimo, en la Tabla II se presenta la memoria deprograma y de variables utilizada por la libRTCS ası comotambien la memoria dinamica consumida por los diferentesalgoritmos de control.

VI. CONCLUSION Y TRABAJO FUTURO

Como conclusion, se pueden mencionar los principalesaportes de este trabajo:

Parametro ValorMemoria de programa 4.5Kbytes

Memoria de programa libre 480KbytesEn uso: libRTCS + FreeRTOS + CMSIS

Memoria de variables libre 37KbytesEn uso: libRTCS + FreeRTOS + CMSIS

Memoria dinamica PID float 120bytesMemoria dinamica PID double 188bytes

Memoria dinamica DMC SISO float 284bytesMemoria dinamica buffers internos 3680bytes(N = 50, P = 10,M = 5)

Memoria dinamica DMC SISO float 284bytesMemoria dinamica buffers internos 7160bytes(N = 80, P = 15,M = 5)

TABLE II. CONSUMOS DE MEMORIA DE LA LIBRTCS

1) Disenar, implementar y validar una biblioteca de algo-ritmos de control para sistemas embebidos que puedeser utilizada tanto en el ambito academico como en elambito industrial.

2) Portar la biblioteca de algoritmos de control al micro-controlador LPC1769 con procesador Cortex-M3. Estatecnologıa es utilizada en muchos sistemas embebidosactuales. Poner a disposicion de los desarrolladores desistemas embebidos una biblioteca como la libRTCS esun aporte importante.

Cabe resaltar, que en la busqueda bibliografica y de mercadorealizada, no se encontro ninguna solucion disponible concaracterısticas similares a las de esta biblioteca de codigo.Por otro lado, tambien se quiere resaltar, que los resultadosobtenidos en el microcontrolador LPC1769 con procesadorCortex-M3superaron ampliamente las expectativas.

Como trabajo futuro, se puede mencionar:• Portar la libRTCS a un procesador con FPU, como el

Cortex-M4, y comprar los resultados obtenidos con losde este trabajo.

• Implementar en la libRTCS el modulo de abstraccion dela biblioteca de recursos matematicos.

• Incluir en la libRTCS nuevos algoritmos de control,como por ejemplo: LQR, LQG, LPV etc.

• Aplicar la libRTCS a plataformas reales, como puede serun quadrotor.

• Ampliar los esquemas de scheduling y los test deschedulability que incluye la libRTCS.

REFERENCES

[1] Alan V. Oppenheim, Alan S. Willsky Signals and Systems Prentice Hall[2] Karl J. Astrom, Bjorn Wittenmark Computer Controlled Systems. Theory

and Design Prentice Hall 1997[3] Eduardo F. Camacho, Carlos Bordons Model Predictive Control Springer

1999[4] B. Wittenmark, Karl J. Astrom, Karl E. Arzen Computer Control: An

Overview IFAC PROFESSIONAL BRIEF. Department of AutomaticControl, Lund Institute of Technology

[5] Karl-Erik Arzen, Bo Bernhardsson Integrated Control and SchedulingDepartment of Automatic Control, Lund Institute of Technology 1999

[6] LPC17xx User manual, Rev. 2 — 19 August 2010, NXP.[7] Richard Barry, Using the FreeRTOS Real Time Kernel, Version 1.3.0.


188

Implementación de un Kernel de Tiempo Real para Arquitectura ARMv7-M

Pablo Ridolfi1†‡, Santiago Maudet2†, Andrés Di Donato3†, Ariel Lutenberg4‡, Alejandro Furfaro5†, Antonio Gutiérrez6§

[email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]

†Laboratorio de Procesamiento Digital (UTN-FRBA), Buenos Aires, Argentina ‡Laboratorio de Sistemas Embebidos (FI-UBA), Buenos Aires, Argentina

§Facultad de Ingeniería Mecánica y Eléctrica, Universidad de Colima, México

Resumen— La arquitectura ARMv7-M está presente en una

gran variedad de microcontroladores modernos, principalmente implementada en los procesadores Cortex-M3 y Cortex-M4(F), y ha puesto al alcance del programador de sistemas embebidos características de hardware que hasta hace unos años estaban disponibles solamente en microprocesadores de alto rendimiento, orientados a computadoras personales y servidores con gran capacidad de cómputo. Al mismo tiempo, el comportamiento determinístico de esta arquitectura frente a las interrupciones de hardware la convierte en una excelente plataforma para la implementación de un sistema operativo embebido con requerimientos de tiempo real. En este trabajo se presenta un núcleo de sistema operativo (kernel) de tiempo real diseñado para procesadores ARMv7-M que aprovecha las funcionalidades mencionadas, a fin de brindar al diseñador de aplicaciones embebidas servicios de multitarea con niveles de privilegio y protección de memoria. Estos servicios fueron diseñados a fin de sentar las bases para la implementación de un Sistema Operativo de Tiempo Real compatible con el estándar POSIX.

Palabras clave—Real-Time Operating Systems, Embedded Systems, Microcontrollers, ARMv7-M, Cortex-M3, Cortex-M4F , POSIX

I. INTRODUCCIÓN

Actualmente existe una amplia oferta de Sistemas Operativos de Tiempo Real (RTOS) para sistemas embebidos con microcontroladores (MCUs), optimizados para recursos limitados como memoria y capacidad de procesamiento[1]. Aun así, a fin de mantener cierta portabilidad entre distintos fabricantes y arquitecturas, dichos RTOS carecen de un diseño optimizado para sacar provecho del soporte de hardware destinado a implementación de Sistemas Operativos disponible en algunos MCUs, y al mismo tiempo pierden rendimiento debido al nivel de abstracción necesario para lograr dicha portabilidad[2].

A su vez, el estándar de llamadas al sistema operativo POSIX es ampliamente adoptado, tanto en sistemas de tiempo real como de propósito general[3]. Para que se pueda decir que un sistema cumple con el estándar POSIX el sistema debe implementar por lo menos el estándar base[4]. En la actualidad varios sistemas embebidos, algunos de tiempo real, han seguido la tendencia de implementar interfaces del estándar POSIX como contiki[5], RTEMS[6], PikeOS[7], RTOS[8], SkyOS[9], eCos[10], etc. Por ello se considera adecuado que el sistema operativo derivado del kernel presentado en este trabajo soporte esta interfaz. Dentro de las interfaces más utilizadas están la creación y gestión de procesos, entrada/salida, comunicación sobre redes (sockets),

comunicación entre procesos (IPC), señales (Signals), hilos (threads), entre otras. Las llamadas al kernel (system calls o syscalls), que se describirán en la sección II , se diseñaron teniendo en cuenta los prototipos definidos por el estándar para la función que deben cumplir, a fin de facilitar la construcción de la API POSIX en las futuras etapas de este proyecto.

Otra razón importante para este trabajo de implementación de un kernel de tiempo real para ARMv7-M es que se busca desde el principio optimizar al máximo el consumo de memoria de datos y código, recurso aún escaso en algunos microcontroladores actuales. ARM es el principal proveedor de la industria de los microprocesadores de 32 bits integrados, ofreciendo una amplia gama de procesadores basados en una arquitectura común que proporciona alto rendimiento, líder en la industria en eficiencia energética y reducción de costos[11].

Se eligieron como procesadores objetivo el Cortex-M3 (núcleo ARMv7-M) y el Cortex-M4F (núcleo ARMv7E-M), dada la amplia variedad de implementaciones en microcontroladores de distintos fabricantes y la abundante bibliografía e información técnica por parte de ARM accesible en Internet[12]. Previo a este trabajo se analizó un kernel de tiempo real implementado sobre ARM7TDMI de código abierto[13], bajo los términos de la licencia pública GNU compatible con POSIX. Un requisito usual en este tipo de implementaciones es que las aplicaciones trabajen en un nivel de privilegio inferior al kernel, a fin de que éste las supervise. Por ello es requisito que la CPU disponga de una Unidad de Protección de Memoria (MPU). Para evaluar los resultados el sistema se implementó en un LPC1769 (Cortex-M3, NXP)[14] y en un STM32F407 (Cortex-M4F, STMicroelectronics)[15].

II. CARACTERÍSTICAS DE LA IMPLEMENTACIÓN

A. Inicialización

En un proyecto clásico de firmware embebido, existe un código de inicialización que realiza una configuración básica del hardware para luego llamar a la aplicación del usuario, cuyo punto de entrada es la función main() (Fig. 1a). Si una aplicación de este tipo requiriera multitarea, la única forma de resolverla sería mediante una ronda o loop secuencial de tareas (llamadas a función), que deben asegurar un comportamiento cooperativo (es decir, que cedan la utilización del CPU para que la próxima tarea pueda ejecutarse). En este caso el software supervisor del estado del sistema tampoco podría resolver problemas de asignación de recursos o desborde de memoria por parte de las tareas, ya que dependería de éstas para que le cedan tiempo de CPU.


189

El kernel propuesto en este trabajo cambia este esquema de programación de manera tal de inicializar sus servicios (scheduler, manejador de memoria dinámica, etc.) antes de crear dos hilos: uno denominado “idle” que se ejecuta cuando no hay ningún otro hilo en condición de ser ejecutado, y el hilo principal, que tiene como punto de entrada a main() (Fig. 1b). Luego se cambia el estado del procesador a nivel de usuario (denominado “user thread” en la arquitectura propuesta) y se ejecuta por primera vez el hilo principal. Esto se realiza de forma transparente al programador de aplicaciones, que solamente „ve‟ la ejecución de su función main() como rutina principal de su aplicación.

Finalmente, el hecho de aprovechar los niveles de privilegio disponibles en la arquitectura ARMv7-M, asegura que el código ejecutado por main() así como los hilos que éste pueda crear, no puedan modificar registros de control del CPU ni los periféricos privados del mismo (controlador de interrupciones y timertick, principalmente). Podrían definirse funciones que, mediante llamadas al kernel, eleven el nivel de privilegio y le den a la aplicación permisos temporales. Al mismo tiempo, si no se utilizan los niveles de privilegio, la MPU no tiene forma de diferenciar los atributos de cada región del mapa memoria.

B. Organización de memoria

El kernel desarrollado administra diferentes zonas de memoria, y según su destino, dichas zonas son configuradas con diferentes atributos de protección para los niveles de kernel (privilegiado) y usuario (no privilegiado). Para facilitar la denominación de los atributos, usaremos una notación similar a los permisos de un sistema de archivos tipo UNIX: rwxrwx, siendo las tres primeras letras los permisos de lectura, escritura y ejecución para nivel privilegiado, y las últimas tres para el nivel usuario. Se presenta un esquema orientativo en la Figura 2.

1) Heap de modo kernel (rw----) Se trata de la memoria dinámica requerida para el

almacenamiento de datos en tiempos de ejecución, tales como estructuras de contexto de los hilos y otros datos de nivel de kernel. El modelo de memoria dinámica utilizado es el denominado Two Level Segregate Fit[16].

2) Páginas para los hilos de modo usuario (rw-rw-) Es una memoria dividida en páginas de tamaño

configurable, donde se alojarán los segmentos de pila con el contexto de cada hilo. Los atributos de cada página se asignan de manera tal que un hilo no pueda acceder a la página de otro. Lógicamente, el kernel tiene acceso completo a todas.

3) Variables globales de modo kernel (rw----) Es la sección de memoria destinada a alojar las variables

globales del kernel.

4) Variables globales de modo usuario (rw-rw-) Es la sección de memoria para alojar las variables globales

de los hilos.

5) Memoria de programa (r-xr-x) Este segmento comprende el total de la memoria Flash del

MCU. En la Sección IV se describe el trabajo que se está realizando actualmente para subdividir esta sección según el privilegio del código ejecutado.

6) Periféricos (rw-rw-) Actualmente, tanto el kernel como los hilos de nivel usuario

tienen acceso completo a los periféricos del MCU, excepto los periféricos propios del procesador (NVIC, SysTick, SCB, etc.) que se encuentran en una zona del mapa de memoria específica denominada System Level (0xE0000000 a 0xFFFFFFFF)[17]. Al igual que la sección de código, se está trabajando en la asignación de periféricos del MCU accesibles por código no privilegiado, mediante una llamada al kernel.

(a)

(b)

Fig. 1. Modelo de inicialización clásico (a) y con el kernel (b).

Fig. 2. Atributos del mapa de memoria.


190

7) Background region (rwx---) La denominada “región de fondo” (conocida en la

bibliografía como background region) es aquella cuyo espacio de direcciones no quedó cubierto por ninguna otra sección definida en la configuración de la MPU. En este caso, se le asignó acceso sólo en modo privilegiado.

C. Manejo de hilos

El kernel maneja los hilos de ejecución según el diagrama de estados de la Figura 3, siguiendo una secuencia round-robin (secuencia circular; al llegar al último hilo de la lista, se comienza desde el principio) con prioridad (cantidad de ticks asignados a cada hilo). El comportamiento es el siguiente:

Al comienzo un nuevo hilo es creado en estado READY (listo) mediante la llamada al sistema thread_create(). (a)

Cuando se dan las condiciones para ser ejecutado (por prioridad o por un determinado evento) el scheduler selecciona el hilo en estado READY y carga su contexto en los registros del procesador. Así pasa al estado RUNNING (corriendo). Al hilo anterior, que se encontraba RUNNING, se le asigna el estado READY. (b)

En caso que el hilo requiera esperar algún evento de hardware, o simplemente ejecutar una pausa, el scheduler lo coloca en estado BLOCKED (bloqueado) y busca el siguiente hilo en condiciones de ser ejecutado. (c).

Cuando se produce el evento por el cual el hilo quedó en espera en el estado BLOCKED, el scheduler lo coloca nuevamente como READY para esperar a ser ejecutado en cuanto se cumplan las condiciones de prioridad. (d)

Un hilo puede finalizar de varias maneras:

o En C, ejecutando return; desde su función principal o la llamada al sistema thread_exit() desde cualquier subrutina.

o En Assembler, ejecutando bx lr .

En cualquiera de los casos, el kernel pone al hilo en estado ZOMBIE (e), esperando a que el hilo que lo creó recoja su valor devuelto mediante la llamada al sistema thread_join(), que al mismo tiempo libera los recursos de memoria utilizados por el hilo que finalizó. Si el hilo creador finalizó anteriormente, el hilo Idle se encarga de recoger los valores devueltos y liberar los recursos. Todos los hilos deben devolver un valor, que por defecto es del tipo void *.

Comportamiento en función de la prioridad: Cada hilo es creado con una determinada prioridad que puede tomar valores discretos mayores o iguales a 1. Dicho valor indica durante cuántos ticks de tiempo se ejecuta el hilo. Por ejemplo, un hilo con prioridad 5 se ejecutará durante 5 ticks de tiempo antes de cambiar nuevamente el contexto.

El hilo Idle se ejecuta solamente cuando no hay hilos en estado READY (por ejemplo, se encuentran todos en estado BLOCKED) o todos finalizaron. Este hilo ejecuta la instrucción WFI (Wait For Interrupt) que aguarda al siguiente tick del timer del sistema y llama al scheduler, si es que se dan las condiciones para realizar un cambio de contexto.

La Figura 4 muestra la estructura de contexto de los hilos creados: Se observa que se trata de una lista dinámica doblemente enlazada, que guarda el puntero a la página de pila asociada al hilo, su prioridad, su valor de retorno si es que se encuentra en estado ZOMBIE, su estado y un número único denominado Thread ID (TID), para identificarlo. Por otro lado, el campo PTID indica qué hilo fue el creador del actual.

D. Resumen de llamadas al kernel

A continuación se describen las llamadas al kernel actualmente implementadas:

kernel_init(): Esta función es llamada luego de la inicialización del hardware, llevada a cabo por las funciones ResetISR() y SystemInit(), pertenecientes a la librería CMSIS (Cortex Microcontroller Software Interface Standard[18]). kernel_init() se encarga de configurar rutinas de atención a excepciones no activadas en forma predeterminada, configurar periféricos usados en nivel de kernel (por ejemplo, UART3 para las funciones de salida estándar descriptas en la sección E), inicializar la memoria dinámica y crear los hilos main e idle. Luego, mediante una llamada al sistema, realiza un intercambio de punteros de pila, de manera tal que los hilos utilicen el denominado Process Stack Pointer (PSP), que está específicamente preparado para utilizarse en modo no privilegiado. El puntero de pila original (MSP, Main Stack Pointer) es reservado por si el kernel en algún momento necesita ejecutar hilos privilegiados. Actualmente, sólo se realizan las tareas de mantenimiento y cambio de contexto en las rutinas de atención de las llamadas al sistema y la excepción PendSV, descriptas en el siguiente parágrafo. Luego de intercambiar punteros de pila, configura el procesador para retornar de la interrupción en modo no

Fig. 4. Estructura de contexto de hilos y otros typedef‟s asociados.

Fig. 3. Diagrama de estados de un hilo.


191

privilegiado y continuar la ejecución en el punto de entrada de la aplicación del usuario, la función main().

thread_create(): Función que se encarga de crear nuevos hilos con una determinada prioridad. Se les puede asignar un nombre (char[]), capacidad útil para propósitos de depuración. Inicia en estado READY y se coloca al final de la lista dinámica de hilos.

thread_pause(): Pone al hilo en estado BLOCKED durante una determinada cantidad de ticks.

thread_join(): Esta función es normalmente llamada por un hilo que necesita esperar la finalización de otro creado por éste. Devuelve el valor de retorno del hilo finalizado liberando previamente los recursos de memoria.

thread_exit(): Equivale a ejecutar return desde la rutina principal del hilo. Lo coloca en estado ZOMBIE: no puede volver a ejecutarse. Aún así, sus recursos de memoria se mantendrán asignados hasta que el hilo “padre” ejecute thread_join().

requestSched(): Función que, mediante una llamada al nivel privilegiado (SVC – ServiceCall, en la arquitectura ARMv7-M), fuerza un cambio de contexto. Útil cuando se desea liberar voluntaria y momentáneamente la asignación de CPU al hilo actual.

schedule_next(): Función interna del scheduler, que recorre la lista de hilos y determina cuál es el siguiente a ejecutar. Actualiza la configuración de la MPU con los permisos de acceso al mapa de memoria del nuevo hilo.

state_update(): Función interna del scheduler, que recorre la lista de hilos actualizando su estado (RUNNING READY, RUNNING BLOCKED, BLOCKED READY y READY RUNNING).

Se puede observar que el cambio de contexto se lleva a cabo en una excepción diferente a la del temporizador SysTick, la denominada PendableServiceCall o PendSV. Normalmente se configura a PendSV con la prioridad más baja posible en el controlador de interrupciones, a fin de realizar el cambio de

contexto cuando no quede pendiente ninguna otra rutina de atención de interrupción. Esta secuencia debe realizarse de esta forma ya que los hilos se ejecutan en modo no privilegiado, y no puede retornarse desde modo privilegiado a modo no privilegiado si existen otros manejadores de interrupción pendientes[19], ya que se generaría una excepción de tipo UsageFault. Al mismo tiempo, ejecutar el cambio de contexto en un handler de mínima prioridad asegura el comportamiento de tiempo real, al permitir que todos los demás manejadores de interrupción finalicen antes de volver a modo usuario. Las Figuras 5 y 6 muestran un esquema de flujo de las mismas, tanto para la inicialización del kernel como para el momento en que se debe cambiar de contexto.

E. Bibliotecas estándar

En paralelo con la implementación de este kernel, y para fines de depuración, se implementaron algunas funciones estándar ANSI C, como printf() y sprintf(). En el caso del LPC1769, la salida estándar para esta biblioteca se direccionó a la UART3.

III. RESULTADOS OBTENIDOS

El kernel en su estado actual ya es capaz de compilarse junto a una función main() que cree diferentes tareas con prioridad determinada, que cumplirán la función requerida por el programador de nivel de aplicación. Actualmente las pruebas resultaron satisfactorias con:

Un stack TCP/IP que corre un web server con una página web con refresco automático y código HTML variable para reflejar cambios en variables internas (por ejemplo: estado de pines, valores analógicos, etc.).

Operaciones sobre variables de punto flotante, compiladas para un procesador sin FPU (cálculos por software).

Operaciones básicas sobre periféricos como UART y GPIO.

La configuración actual del kernel es la siguiente:

Tamaño de la memoria dinámica de kernel: 4kB.

Fig. 5. Secuencia de llamadas al kernel durante la inicialización.

Fig. 6. Secuencia de llamadas al kernel durante el cambio de contexto.


192

Tamaño de página para la pila de cada hilo: 1kB.

Banco de memoria RAM asignado a páginas: 16kB. Esto resulta en un total de 16 hilos posibles de ser creados bajo esta configuración.

Ventana de ejecución (tick): 1ms.

La Figura 7a muestra el código de la función main() utilizada para las pruebas, donde se observa la creación de 5 hilos cuyas funciones se mencionaron arriba. A modo de ejemplo, se observa en la Figura 7b el código de la tarea task1(). La Figura 7c muestra la consola stdout con la información enviada por las tareas: obsérvese la impresión de caracteres mezclada entre una tarea y otra, a falta de un semáforo que sincronice el acceso a stdout. La Figura 8 contiene una captura de la página web devuelta por el stack TCP/IP de la tarea web_main() a través de la interfaz Ethernet. En la Figura 9 se observa el hardware utilizado para las pruebas: LPCXpresso con LPC1769[20] y BaseBoard R2M[21].

La experimentación realizada sobre Cortex-M4F fue llevada a cabo con el hardware de la Figura 10. El mismo está orientado a la implementación de un transmisor/receptor SDR (Software-Defined Radio), y comprende un PCB propio con el oscilador local y mezcladores en cuadratura, y el kit de desarrollo STM32F4-Discovery[22]. El objetivo es que la aplicación SDR funcione sobre el kernel descripto en este trabajo. Debido a que este hardware no dispone de salida RS232 por la cual direccionar stdout, se realizaron mediciones sobre el tiempo muerto requerido para el cambio de contexto. La Tabla I muestra una comparación entre el rendimiento del LPC1769 y el STM32F407, indicando las frecuencias de reloj de cada uno.

TABLA I. COMPARACIÓN DE RENDIMIENTO

Tiempo de Cambio de Contexto [µs]

LPC1769 (120MHz) STM32F407 (168MHz)

4.83 1.75

IV. CONCLUSIÓN Y SIGUIENTES PASOS

A continuación se resumen los objetivos del grupo de investigación luego de las primeras pruebas de funcionamiento satisfactorias del kernel descripto en el presente trabajo:

El objetivo principal apunta a la implementación de un Sistema Operativo de Tiempo Real que responda al estándar POSIX con soporte de sockets TCP y UDP, USB y otros periféricos, de manera tal de presentar al programador de aplicaciones una interfaz estándar, con mínimas modificaciones al código fuente original de su aplicación, siempre que la misma fuera desarrollada en una plataforma cualquiera POSIX compatible, aprovechando así código disponible para portarlo a un Sistema Embebido de gama intermedia.

Actualmente, las aplicaciones son compiladas junto con el kernel, por lo que otra de las asignaturas pendientes de este proyecto es poder cargar archivos binarios de aplicaciones dinámicamente en la memoria de código y ejecutados según sea necesario, acercando este modelo de RTOS al utilizado en los sistemas operativos de propósito general.

Siguiendo este lineamiento, está proyectada la implementación de un intérprete por línea de comandos,

recibidos por el sistema mediante la interfaz estándar ya implementada a través de la UART.

Por otra parte, la implementación actual no segmenta totalmente la memoria de código y periféricos del MCU, por lo que los hilos no privilegiados pueden acceder al código del kernel. Si bien podrían ejecutar sus funciones en modo no privilegiado (lo cual generaría excepciones al

(a)

(b)

(c)

Fig. 7. Código de tareas implementado para las pruebas y consola stdout.


193

intentar modificar la memoria de datos, que sí está protegida), el caso ideal sería que directamente no se pueda leer la memoria de código del kernel.

Respecto a los periféricos, se está trabajando en funciones que permitan a un hilo no privilegiado solicitar acceso a un determinado periférico, y si el kernel lo considera, modificar los permisos de la MPU para ese hilo de manera tal que pueda acceder al periférico.

Los avances realizados hasta el momento permitieron al equipo comprender más a fondo la arquitectura ARMv7-M y su suporte para implementación de sistemas operativos:

Stack Pointers separados para hilos privilegiados (MSP) y no privilegiados (PSP).

Unidad de Protección de Memoria de 8 regiones con atributos configurables, más una background region con acceso sólo en modo privilegiado. A su vez cada región es divisible en 8 subsecciones que pueden deshabilitarse (se le aplican los atributos de la región de fondo). En el contexto de cada hilo se guarda la configuración asociada a las regiones y atributos que le fueron asignados.

Niveles de privilegio: Kernel (Privileged Thread / Privileged Handler) y Usuario (User Thread). Sumado a los privilegios que le otorgue la MPU, el nivel Usuario no puede modificar los registros de control de la CPU ni acceder a los periféricos privados del mismo.

Al mismo tiempo, implementar un kernel específico para la arquitectura mencionada, sacando máximo provecho de dicho soporte, evita mayores niveles de abstracción en el software que sumen tiempos muertos entre llamadas al sistema, hecho que aumenta la latencia del mismo en la respuesta a eventos de hardware y por ello dificultando su rendimiento en tiempo real. Hasta el momento, y según tiene conocimiento el equipo de

trabajo, solamente FreeRTOS desde su versión 6 provee soporte para MPU y niveles de privilegio[23], pero no es compatible con el estándar POSIX.

REFERENCIAS [1] “A Survey of Real-Time Operating Systems” (s.f.), Electrical and

Computer Engineering Department, Stevens Institute of Technology. http://www.ece.stevens-tech.edu/~ymeng/courses/CPE555/papers/rtos_paper.pdf

[2] Richard Barry, “Who wins when Cortex-M adds RTOS?”, 6 de Marzo de 2012, obtenido de http://www.embedded.com/electronics-blogs/industry-comment/4237614/Who-wins-when-Cortex-M-adds-RTOS-abstraction-layer-

[3] Estándar POSIX.1-2008, obtenido de

http://pubs.opengroup.org/onlinepubs/9699919799/

[4] González Harbour, M. (2001). POSIX de tiempo real.

[5] contiki. (s.f.). contiki OS. Obtenido de www.contiki-os.org.

[6] RTEMS. (s.f.). RTEMS Operating System. Obtenido de www.rtems.com.

[7] OS, Pike. (s.f.). Sysgo Embedding innovations. Obtenido de http://www.sysgo.com/products/pikeos-rtos-and-virtualization-concept/

[8] RTOS. (s.f.). Express logic. Obtenido de http://www.rtos.com/

[9] SKYOS. (s.f.). SkyOS. Obtenido de http://www.skyos.org/

[10] eCos. (s.f.). eCos. Obtenido de http://ecos.sourceware.org/

[11] Joseph Yui, The Definitive Guide to the ARM Cortex-M3 (2da. Ed.), Newnes, 2010.

[12] Procesadores Cortex-M (s.f.), obtenido de http://www.arm.com/products/processors/cortex-m/index.php

[13] Partikle RTOS (s.f.), obtenido de

http://www.fentiss.com/en/products/partikle.html.

[14] Microcontrolador LPC169 (s.f.), obtenido de http://www.nxp.com/products/microcontrollers/cortex_m3/LPC1769FBD100.html

[15] Microcontrolador STM32F407 (s.f.), obtenido de http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN11

[16] TLSF: Memory Allocator for Real-Time Embedded Systems, (s.f.), obtenido de http://www.gii.upv.es/tlsf/

[17] Joseph Yui, The Definitive Guide to the ARM Cortex-M3 (2da. Ed.), Newnes, 2010. Página 80.

[18] Cortex Microcontroller Software Interface Standard, (s.f.), obtenido de http://www.arm.com/cmsis/

[19] Joseph Yui, The Definitive Guide to the ARM Cortex-M3 (2da. Ed.), Newnes, 2010. Páginas 126 a 129.

[20] LPCXpresso con LPC1769, (s.f.), obtenido de http://www.embeddedartists.com/products/lpcxpresso/lpc1769_xpr.php

[21] BaseBoard R2M para LPCXpresso, (s.f.), obtenido de http://www.r2mingenieria.com.ar/producto.php?articulo_id=7

[22] STM32F4-Discovery, (s.f.), obtenido de www.st.com/stm32f4-discovery

[23] Richard Barry, “FreeRTOS V6.0.0 includes integrated memory protection (MPU) support for Cortex-M3 MCUs”, Octubre de 2009,

obtenido de http://www.freertos.org/press/FreeRTOS-MPU_a_free_memory_protected_RTOS_for_Cortex-M3.pdf

Fig. 10. Hardware utilizado (Cortex-M4F).

Fig. 9. Hardware utilizado (Cortex-M3).

Fig. 8. Página web embebida con el servidor TCP/IP, que funciona como una de las tareas creadas por main().


194

��ABC��

DAEF��E��

��ABC�CDE�


195


196

CASE 2013, AUGUST 2013 1

Modeling and Rapid Prototyping applied to theUpgrade of Mission-Critical Applications

using AADLGustavo Rodrıguez, Alfons Crespo, Jerome Hugues, and Manuel Amor

Abstract—Upgrade mission-critical applications such as theOperational Flight Program (OFP) of avionics embedded com-puter systems is a complex task. Requires software engineeringtechniques particularly difficult from capturing requirementsuntil its implementation. Modeling and Rapid Prototyping withArchitecture Analysis & Design Language (AADL) are techniquesthat can help upgrade the OFP mainly at the stage of formulatingand validating requirements.

Index Terms—Avionics Systems, Operational Flight Program,Modeling, Rapid Prototyping, AADL.

I. INTRODUCTION

UPGRADE mission-critical applications such as the OFPrunning in the aircraft’s Mission Computer (MC) is

a complex task. These are generally long life applications,thus, in the best case, it is upgrading applications based onsoftware engineering techniques particularly difficult. It is notuncommon for an OFP change or block update to take aslong as one year before released to the field. These softwareengineering techniques consist of a series of stages beginningwith requirements capture to implementation and testing [1].

In general, upgrading an OFP may be due mainly to tworeasons:

• correction of errors detected during system operation and• proposed improvements of the system by adding new

functionality.In either of the two cases it is necessary to evaluate how

the upgrade will affect the existing avionics system.Developers must apply software refinement in order to

proceed from a high-level abstract model to a final executablesoftware system by adding more details over time. Modelingand Rapid Prototyping are techniques that contribute to thedesign and incorporation of these upgrades [2] [3].

In software engineering, there are two main approachesto prototyping. One approach is to develop a draft imple-mentation (a throwaway or rapid prototype) in an attemptto learn more about the requirements on the software, throw

G. Rodrıguez is with Real-Time Systems Group, Department of Telecom-munications, Rio Cuarto National University. Rio Cuarto, Argentine. e-mail:[email protected]

A. Crespo is with Industrial Informatics and Real-Time Systems Group, De-partment of Systems Data Processing and Computers, Polytechnic Universityof Valencia. Valencia, Spain.

J. Hugues is with Department of Mathematics, Computer Science, andControl of the Institute for Space and Aeronautics Engineering (ISAE).Toulouse, France.

M. Amor is with Real-Time Systems Group, Department of Telecommuni-cations, Rio Cuarto National University. Rio Cuarto, Argentine.

the prototype away, and then develop production quality codebased on the experiences from the prototyping effort. The otherapproach (evolutionary prototyping) is to develop a high qua-lity system from the start and then evolve the prototype overtime. Unfortunately, there are problems with both approaches.

Model Driven Engineering (MDE), a software developmentmethodology promoted by the Object Management Group(OMG), focuses on creating and exploiting domain modelssimplifying the process of design and promoting communica-tion between customers and developers.

The AADL [4] together with Modeling and Analysis ofReal-time and Embedded systems (MARTE) [5] are conside-red as valuable candidates to support an MDE method for thedesign and the implementation of avionics systems.

The AADL was released by the SAE in November 2004,and is an architecture description language dedicated to em-bedded real time systems in safe-critical domains. It providesan industry-standard, text and graphical notation with precisesemantics to allow early function and quality properties ve-rification at the model level and automatic code generationfrom the models, which greatly improves productivity andassures high reliability. The core language is enhanced byannex languages that enrich the architecture description. Oneof them is directly connected to avionics systems. ARINC653annex: define patterns for modeling avionics systems.

The ARINC-653 standard [6] introduces the concept ofpartitioning. It consists in isolating applications in space andtime so each partition has an address space and a time slice toexecute their code. Using this partitioning architecture, severalapplications, at different criticality or security levels, can becollocated on the same processor [7] [8] [9] .

This paper describes the application of modeling and rapidprototyping based on AADL in upgrading mission-criticalapplications such as an OFP, applied mainly at the stage offormulating and validating requirements.

An overview of AADL on how it is used in upgradingan OFP is presented in this paper. Section II presents somebackground, as well as the goals of the upgrade an OFP. Next,in Section III, we discuss a rapid prototyping methodologyapplied to an avionics system and related work. In Section IVthere is a presentation of our case study using prototyping andmodel refinement with AADL and Ocarina. Finally, Section Vends this paper with a conclusion.


197


II. BACKGROUND

A. Modeling and Rapid Prototyping

Modeling is a way of thinking about problems using modelsorganized around real-world ideas [10].

Models are abstractions that portray the essentials of acomplex problem or structure by filtering out nonessentialdetails, thus making the problem easier to understand.

Abstraction is a fundamental human capability that permitsus to deal with complexity.

A prototype is any form of specification or implementationof hardware or software (or both) that is built or designed forevaluation purposes. When building a prototype, a designerhas typically in mind to design multiple copies once the designis sufficiently evaluated. All prototypes have in common thatthey are executable. Prototypes are also useful for formulatingand validating requirements, resolving technical design issues,and supporting computer aided design of both software andhardware components of future designs.

Rapid prototyping refers to the capability to implementa prototype with significantly less effort than it takes toproduce an implementation for operational use. It is a way tocollect data and feedback for changing requirements, unveildeviations from users constraints early, trace the evolution ofthe requirements, improve the communication and integrationof the users and the developers, provide early feedback ofmismatches between proposed software architectures and theconceptual structure of requirements.

Prototypes can either be developed as temporarily designsthat are not being used after some evaluations have providedthe designer with valuable insights, or they can directly evolveinto a product version of the respective design. Each ofthese approaches has its advantages and disadvantages. It willdepend on the designers constraints which type is the best fora certain project.

Software prototyping has many variants. However, all themethods are in some way based on two major types of proto-typing: Throwaway Prototyping and Evolutionary Prototyping.

• Throwaway: prototypes are built to validate a concept,prior to implementing the real system. The throwawayapproach is used to refine requirements.

• Evolutionary: prototypes tend to become the final prod-uct. Prototypes are refined to create more accurate ones.The last prototype actually corresponds to the final sys-tem. Then, feed-back on the system may be provided atvarious levels and the model is the main reference fordescribing the system.

The most common problem with throwaway prototypingis managerial, many projects start developing a throwawayprototype that is later, in a futile attempt to save time,evolved and delivered as a production system. This misuseof a throwaway prototype inevitably leads to unstructured anddifficult to maintain systems.

Notable examples of work in prototyping in embeddedsystems development include PSDL [11] [12], Rapide [13][14] and AADL and Ocarina [15] [16]. PSDL is based onhaving a reusable library of Ada modules which can beused to animate the prototype. Nevertheless, it seems that

Fig. 1: AADL components to develop an AADL Model

this approach would preclude execution until a fairly detailedspecification was developed. Rapide is a useful prototypingsystem, but it does not have as much flexibility to integrate aseasily with other tools as we desired. AADL and Ocarina arethe methodology used for this work.

B. AADL

The AADL is a standard architecture modeling language,developed by and for the avionics, aerospace, automotive,and robotics communities. It uses component-based notationfor the specification of task and communication architecturesof real-time, embedded, fault-tolerant, secure, safety-critical,software-intensive systems.

The language and its associated tools are used to model,analyze, and generate embedded real-time systems.

The AADL offers threads as schedulable units of concurrentexecution, processes to represent virtual address spaces whoseboundaries are enforced at runtime, and systems to supporthierarchical organization of threads and processes. The AADLsupports modeling of the execution platform in terms ofprocessors that schedule and execute threads; memory thatstores code and data; devices such as sensors, actuators, andcameras that interface with the environment; and buses thatinterconnect processors, memory, and devices. The Figure 1shows the different components to develop an AADL model.

Threads can execute at given time intervals (periodic),triggered by events (aperiodic) and paced to limit the executionrate (sporadic), by remote subprogram calls (server), or asbackground tasks. These thread characteristics are defined aspart of the thread declaration.

Application components interact with other applicationcomponents and devices exclusively through defined inter-faces. A component interface consists of ports for unidirec-tional flow of data (data ports for unqueued state data, andevent data ports for queued message data) and events (eventports) between threads and to and from devices; synchronoussubprogram calls between threads, possibly located on di-fferent processors; and access to data that is concurrency


198


Fig. 2: Generic avionics system architecture

controlled. Data port connections can be specified to per-form mid-frame (immediate) communication within the samedispatch period, or phase delayed (delayed) communicationfor data to be available after the deadline of the originatingthread. These semantics ensure deterministic transfer of datastreams between periodic threads, an important feature forembedded control systems. Deterministic data transfer meansthat a thread always receives data with the same time delay; ifthe receiving thread is over- or under-sampling the data stream,it always does so at a constant rate.

C. Avionics Systems

An avionics system is a collection of subsystems thatsupport flight through several functions to ensure that theaircraft’s mission to be carried out effectively. Figure 2 showsa generic avionics system architecture.

The total system may be considered to comprise a numberof major subsystems, each of which interacts to provide theoverall system function. Major subsystems themselves maybe divided into minor subsystems or equipment which in turnneed to operate and interact to support the overall system.Each of these minor subsystems is supported by componentsor modules whose correct functional operation supports theoverall system. The overall effect may be likened to a pyramidwhere the total system depends upon all the lower tiers.

An avionics system includes communications, navigation,the display and management of multiple systems, and the hun-dreds of systems that are fitted to aircraft to perform individualfunctions. An OFP is the software program embedded in theMC which enables to avionics system to perform its interactivetasks as designed.

The period of development of a complete cycle of an OFP(that is, the upgrade from one version to another) will dependon many factors such as, among others, the complexity, theoperational need and the availability of human and materialresources. However, average intervals can be set between 1and 1.5 years.

Moreover, a new OFP’s version provides improvements inthe operation of the systems, or incorporating new capabilities,and, of course, all this will result in a medium-to long-term,operational and logistical implications to be derived from itsimplementation.

The complete cycle management of a system that requiresoperating software includes all activities and tasks ranging

from the conception of the need for a new program until it isfully implemented and operational. All these activities can bedivided into three phases clearly identified and separated fromeach other, that determine the so-called software life cycle ona cascade-type model, this implies that is not possible to tacklethe tasks corresponding to a phase if you have not completedthe entire phase above.

This lifecycle definition remains cascaded along the diffe-rent tasks that compose each one of the phases, but with greaterflexibility, allowing varying degrees of overlap between tasksbased on the type of development and workflow in which layseach project or requirement. The three phases of the cycle are:

1) Phase I: Definition2) Phase II: Development3) Phase III: ImplementationThe objective of Phase I Definition is to study, analyze

and evaluate the implications that may involve incorporatingthe proposed changes. This stage is critical because it willdetermine the other two and includes those activities andtasks leading to obtain the widest possible knowledge for eachanomalies or proposals for change and its possible solutions tobe adopted for each case, so that, once satisfied the objectiveof this phase is to address the Phase II Development.

During Phase I Definition is essential to use tools to trans-form software engineering anomalies and proposed changesinto a particular requirement to be incorporated into the newversion. The rapid prototyping helps to understand and get abroader knowledge of the anomalies and proposals for changein order to turn into a formal requirement.

The motivation of rapid prototyping techniques in the PhaseI Definition may be:

• reduce cost and development time and• increases security and reliability of an avionics system.

III. A RAPID PROTOTYPING METHODOLOGY FORAVIONICS SYSTEMS

A typical OFP development process (upgrade) consists ofdevelopers (software engineers, programmers) and customers(pilots, analysts, etc.) collaborating together to develop severaloptions to evaluate for each requirement to be incorporatedinto the new version. These options are often coded in highlevel languages or graphical tools based on PC, with purposesof having throwaway prototypes. The customer then evaluatesand discusses on the different options and a requirements listis made.

This list becomes the basis for the software requirementsspecification that the development team uses while developsand tests the software. At the end of this process, whichusually takes more than 1 or 1.5 years, the customer can seethe resulting code in the flight simulator and later in flight.If problems are found at that time or during flight tests, anextensive period of time is often required to make changesand corrections.

A. Eliciting Requirements and Building Prototypes

Specification-based prototyping allows an iterative approachto building a formal specification. Initial versions of the


199


specification can focus on the desired control behavior andignore complicating details, such as sensor or actuator failures.

The specification can be evaluated in an equally simplifiedenvironment containing failure free sensors and actuators. Asthe understanding of the system and its environment deepens,both the specification and the environmental models will berefined. The following paragraphs outline the activities thatoccur as the models are constructed and refined [17].

As mentioned in previous sections, these throwaway pro-totypes are made in high-level languages, usually the de-velopment is ad hoc without considering any details of theimplementation.

As a result, even at this early stage of system specification,an executable prototype is available. In this fashion, theanalysts and stakeholders can actively evaluate and test thehigh-level requirements of the system early in the developmentcycle.

B. Refining the Model and Aspects of Human-Machine Inter-face

Initially all requirements are considered together and animpact analysis of the system is done. Importantly, there maybe requirements that are not entirely related to the philosophyof the system. At this time is when they are discarded.

The process includes the grouping of requirements in sets byaffinities or complexity. With the set of requirements defined,the prototype is refined increasingly incorporating more andmore realism, such as sensors and actuators. In general, itis actually a prototype for each set of requirements and as aresult of all this has several throwaway prototypes that providea total behavior of the system change proposal.

In cases where there are different options for a given re-quirement should be considered conducting various prototypesto select one of the options.

Finally, the requirements that contain human-machine inter-faces have special treatment. The prototype should not onlyfunctionally characterize the requirement but must additionallyallow a vision of it. Prototypes are generally more configurableand with the rise of graphical visualization tools based proto-types traditional languages are increasingly obsolete.

IV. CASE STUDY: UPGRADING AN OFP USING RAPIDPROTOTYPING WITH AADL

Upgrade an OFP can be a labor, sometimes even morecomplicated than creating a new one from scratch. The ModelDriven Engineering (MDE) is a comprehensive approach tosoftware system development (upgrade) that supports the en-tire product lifecycle. The AADL is considered in a numberof projects aiming at defining and implementing tools supportfor MDE.

In this section we detail a methodology for upgrading anOFP using rapid prototyping with AADL. Our case study isupdating an OFP, incorporating a set of navigation require-ments to the original design.

Each requirement is analyzed individually and are consi-dered different options to incorporate. The analysis includes

the development of several prototypes to simplify the decisionwhich option is best suited to the original design.

In our case we take the navigation requirements, specificallyrelated to the takeoff and landing of aircraft and routes. Itwas decided to make several throwaway prototypes to emulatethose conditions.

The process continues with AADL modeling of each of theoptions on the requirements.

A. AADL Model Creation

The process implements the following (possibly iterative)methodology to define and refine each requirement or set ofrequirements:

• data types and related functions to operate on them• supporting runtime entities (threads) and interactions

between them (through connection and ports)• association of functions to threads• mapping of threads onto processes andprocessors to form the deployed system.

The AADL allows graphical and textual modeling. At first,some graphics can be made to permit to be a starting pointfor developers thereafter textual models are more effective.

The Software Engineering Institute at Carnegie MellonUniversity developed the extensible Open Source AADL ToolEnvironment (OSATE). OSATE consists of a set of plug-insfor the open source Eclipse Platform [18].

As a result of this process an AADL model is obtained foreach prototype, including functional requirements to incorpo-rate another as well as some non-functional properties.

B. AADL Model Validation

Validation of a prototype by an AADL model takes onseveral forms. For this case study we used two forms:

1) semantic analysis validating the consistency of anAADL model,

2) analysis an AADL model with respect to functionaland nonfunctional properties of the embedded systemrepresented by the model.

Semantic analysis is performed using AADL compilerOcarina. Ocarina checks that the given AADL model isconforming to the AADL grammar and that some additionalrestrictions are verified:

• All event or data ports are connected,• All threads are either periodic or sporadic,• All shared data use a concurrent access protocol.

With respect to nonfunctional requirements was performeda schedulability analysis using Cheddar [19]. Cheddar is anAda 95 framework that provides tools and library to checkwhether AADL threads will meet their deadline at executiontime. Cheddar uses the Ocarina libraries to analyze the AADLmodels reducing significantly the time of analysis of each ofthe prototypes modeled.


200


Fig. 3: Process for evaluating options through Throwaway prototypes

C. Executable Code Generation

We use code generation facilities in Ocarina to:1) analyze the AADL model,2) expand it, compute required resources and3) generate code conforming to High-Integrity (HI) restric-

tions.First, the prototype model is built by the application de-

signer, he maps its application entities onto a hardware ar-chitecture. The throwaway prototype does not have the samehardware as the MC. The prototype works on an emulatedenvironment (QEMU) [20]. Then, this architecture is testedfor completeness and soundness, any mismatch in the configu-ration is reported by the analysis tool (e.g. lack of connectionfrom an object). Consequently, model processing occurs, andthe code is generated from this AADL model.

Code generation relies on well-known patterns for High-Integrity systems, supported by the minimal middleware calledPolyORB-HI [21].

Figure 3 shows the entire process, in it can be seen as thedeveloper and the customer participates in the refinement ofthe model and analysis of the options.

These steps allow the developer to go from the AADLmodel to executable code and forth, using one common modelannotated with all required functional and non-functionalelements, including its code base. Each tool works on the samemodel, allowing one to debug or enhance it at different steps.

Also, in our case study, this allowed that with small changesin the AADL model, different prototypes generated coveringdifferent options. Compared to a traditional process of upgradeof an OFP, it was observed that the incorporation of rapid pro-totyping with AADL has improved the quality and productionof prototypes impacting positively on requirements definitionprocess.

V. CONCLUSION

In this paper, we presented an application of modelingand rapid prototyping based on AADL in upgrading safety-critical systems such as an OFP, applied mainly at the stageof formulating and validating requirements.

Was described it as a process of updating an OFP, the stagesthat make up this process and particularly was introduced howthe rapid prototyping techniques contribute to the definition

stage both for the requirements engineers as well for customerstoo.

Rapid prototyping is a technique that has been used formany years in avionics systems but we selected the AADL toimplement an efficient rapid prototyping process for upgradingthe OFP, focusing on its design-by-refinement approach, andits extensibility through user-defined properties. We illustratedthis approach by presenting the tool chain built around theOcarina tool suite, Cheddar, QEMU and PolyORB-HI High-Integrity middleware.

We showed that an integrated set of tools enables the user tofocus directly on system upgrades, and leverage its architectureto directly generate code for High-Integrity systems withoutany user intervention. The prototypes generated in this waycan incorporate functional and nonfunctional requirements.Besides, analysis tools have been proposed to check modelconsistency and viability prior to generation. This increasesconfidence in the model while being fully automated.

ACKNOWLEDGMENT

The authors thank GSTR’s (Real-Time System Group - RioCuarto National University) members for their feedback onearlier version of this work.

This work is partially funded by the PPI 18/B215 Projectdependent on Science & Technical Secretary of the Rio CuartoNational University.

REFERENCES

[1] D. Morris, “Avionics operational flight program software support-ability,” Digital Avionics Systems Conference, 1990. Proceedings.,IEEE/AIAA/NASA 9th , vol., no., pp.265,267, 15-18 Oct 1990.

[2] F. Kordon, Luqi : An introduction to Rapid System Prototyping, IEEETransaction on Software Engineering Engineering, vol. 28 (9), pp. 817-821 (2002)

[3] F. Kordon, J. Henkel : An Overview of Rapid System Prototyping Today,Design Automation for Embedded Systems, vol. 8 (4), pp. 275-282(2003).

[4] SAE. Architecture Analysis & Design Language (AS5506). available athttp://www.sae.org, sep 2004.

[5] Modeling and Analysis of Real-time and Embedded systems.http://www.omg.org/omgmarte/

[6] ARINC 653: Avionics Application Software Standard Interface, AirlinesElectronic Engineering Committee (AEEC). 1996.

[7] J. Delange, L. Pautet, A. Plantec, M. Kerboeuf, F. Singhoff and F.Kordon. “Validate, simulate and implement ARINC653 systems usingthe AADL”. In ACM’s 12th Annual International Conference on Adaand Related Technologies - SIGAda09.

[8] M. Masmano, Ismael Ripoll, A. Crespo, “An overview of the XtratuMnanokernel” 1st Intl. Workshop on Operating Systems Platforms forEmbedded Real-Time applications. OSPERT 2005.

[9] M. Masmano, Y. Valiente, P. Balbastre, I. Ripoll, A. Crespo and J.J.Metge, “LithOS: a ARINC-653 guest operating for XtratuM”. 12th Real-Time Linux Workshop. Nairobi. Kenya. 2010.

[10] T. Quatrami. “Visual Modeling with Rational Rose and UML”. Addison-Wesley, 2000.

[11] B. Kramer, Luqi, and V. Berzins, “Compositional semantics of a real-time prototyping language”, IEEE Transactions on Software Engineer-ing, 19(5):453477, May 1993.

[12] Luqi, “Real-time constraints in a rapid prototyping language”, ComputerLanguages, 18(2):77103, 1993.

[13] D. Luckham, J. Vera, D. Bryan, L. Augustin, and F. Belz, “Partialorderings of event sets and their application to prototyping concurrenttimed systems”, Journal of Systems Software, 21(3):253265, June 1993.

[14] D. Luckham, J. Kenney, L. M. Augustin, J. Vera, D. Bryan, and W.Mann. “Specification and analysis of system architecture using Rapide”,IEEE Transactions on Software Engineering, 21(4):336354, April 1995.


201


[15] J. Hugues, B. Zalila, L. Paulet, F. Kordon, “Rapid Prototyping ofDistributed Real-Time Embedded Systems Using the AADL and Oca-rina”, Rapid System Prototyping, IEEE International Workshop on,pp. 106-112, 18th IEEE/IFIP International Workshop on Rapid SystemPrototyping (RSP ’07), 2007.

[16] T. Vergnaud and B. Zalila, “Ocarina: a Compiler for the AADL”,Technical report, Tlcom Paris, 2006. available at http://ocarina.enst.fr.

[17] M. Thompson, M. Heimdahl, “An integrated development environmentfor prototyping safety critical systems”; Proceedings of IEEE Interna-tional Workshop on Rapid System Prototyping, Clearwater Beach, FL.1999.

[18] Open Source AADL Tool Environment (OSATE). http://www.aadl.info.[19] F. Singhoff, J. Legrand, L. N. Tchamnda, and L. Marc. “Cheddar : a

Flexible Real Time Scheduling Framework.” ACM Ada Letters journal,24(4):1-8, ACM Press. Also published in the proceedings of the ACMSIGADA International Conference, Atlanta, 15-18 November, 2004,Nov. 2004.

[20] Quick EMUlator. http://www.qemu.org/[21] J. Hugues, B. Zalila, and L. Pautet. “Middleware and Tool suite for High

Integrity Systems”. In Proceedings of RTSS-WiP06, Rio de Janeiro,Brazil, Dec 2006. IEEE.


202

Ecualizador gráfico usando sistema de desarrollo con arquitectura ARM

Yonathan Neita Nova; Holman Montiel Ariza; Edwar Jacinto Gómez Universidad Distrital Francisco José de Caldas

El aplicativo que funciona como un ecualizador y como un reproductor de audio esta desarrollado sobre un dispositivo con arquitectura ARM y Android 2.3 como sistema operativo ya que la aplicación hace uso de algunas librerías que son funcionales a partir del API level 9. Para la interacción con el usuario dispone de dos actividades, en la principal donde se captura el audio para manipular las opciones de reproducción y establecer la variación de la ganancia de cada una de las cinco bandas del ecualizador y en la segunda donde se muestran por medio de una lista, los archivos con extensión de audio que se encuentren en la memoria externa del dispositivo.


203

Notas:

Notas:

www.sase.com.ar14 al 16 de agosto

Facultad de Ingeniería | UBA

Buenos Aires, Argentina

CA

SE

20

13

L

IBR

O D

E T

RA

BA

JO

S-F

OR

O T

EC

NO

LÓG

ICO

Y P

OS

TE

RS

Documents

Libro de Trabajos Foro tecnológico y Posters