implementación de un combinador radar utilizando

CARRERA DE ESPECIALIZACIÓN ENSISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Implementación de un combinador radarutilizando tecnología SoC-FPGA

Autor:Ing. Miguel Enrique del Valle Camino

Director:Ing. Nicolás Álvarez (FIUBA)

Jurados:Dr. Ing. Héctor A. Lacomi (UTN)

Esp. Ing. Jairo Alonso Mena Muñoz (FIUBA)Esp. Ing. Gerardo Puga (UNLP)

Este trabajo fue realizado en la ciudad de Resistencia,entre mayo de 2019 y diciembre de 2020.

I

Resumen

En la presente memoria se detalla la implementación de un equipo procesadorradar para el sistema de vigilancia y control aéreo de la Fuerza Aérea Argentina.El equipo desarrollado permite que a partir de las señales de un radar primarioy otro secundario asociado se logre la detección, procesamiento y trasmisión de

datos empaquetados.

El alcance del trabajo permitió desarrollar las capacidades adquiridas durante elcursado de la especialización, principalmente técnicas para el diseño e

implementación de circuitos digitales en lógica programable, programación demicroprocesadores, ingeniería y testing de software, desarrollo de aplicaciones

en sistemas operativos de propósito general y gestión de proyectos.

III

Agradecimientos

Este trabajo no hubiera sido posible sin mi esposa Noelia, que me acompaña cadadía con su incondicional apoyo, y mis hijos Agustín y Rosario que me ilumninancon su mirada.

Quiero agradecer al Comodoro Almirón por el impulso que le dio a este proyecto,a los operadores y mecánicos de radar de la Fuerza Aérea Argentina que hancolaborado, especialmente al Cabo Principal Carlos Juárez quien desde un inicioayudó con las mediciones y en buscar nuevas ideas, y a Pablito Arancibia, quiense ha convertido en un amigo y siempre brindó su mejor predisposición para eltrabajo.

Quiero agradecer especialmente al Grupo de Investigación en Radiaciones No Io-nizantes de la Universidad Nacional del Nordeste, especialmente a los ingenierosAlberto Daniel Valdez, Carlos Miranda y Juan Angel Chiozza, que permanente-mente buscan oportunidades para el desarrollo de sus alumnos y me permitie-ron conocer a otras excelentes personas y profesionales: Fabián Lovato, LeandroTorrent, Federico Valdez, Fernando Gonzalez y Matías Rodríguez. Sin ellos nohubiera sido posible llegar a este momento.

También deseo expresar mi gratitud con un amigo, el ingeniero Gabriel Ibarra,por estar y ayudarme cuando lo necesité.

Finalmente quiero agradecer a mi Director, el ingeniero Nicolás Álvarez, por suguía, y al grupo de personas que hacen posible el desarrollo de esta especializa-ción.

A todos GRACIAS.

V

Índice general

Resumen I

1. Introducción general 11.1. Radar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Radar primario de vigilancia . . . . . . . . . . . . . . . . . . 1Partes componentes de un radar primario . . . . . . . . . . . 2Radar secundario de vigilancia . . . . . . . . . . . . . . . . . 3Estaciones de radar . . . . . . . . . . . . . . . . . . . . . . . . 4Procesamiento de señales y procesamiento de datos radar . 4Distribución de señales y distribución de datos radar . . . . 5

1.2. Procesador monoradar . . . . . . . . . . . . . . . . . . . . . . . . . . 7Arquitectura del procesador monoradar . . . . . . . . . . . . 7Distribución de mensajes monoradar . . . . . . . . . . . . . 8

1.3. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Extractor Digital de Datos de Radar . . . . . . . . . . . . . . 10Mejoras al Extractor Digital de Datos de Radar . . . . . . . . 10

1.4. Objetivos y alcance del proyecto . . . . . . . . . . . . . . . . . . . . 11Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2. Introducción específica 132.1. Señales radar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1. Radar primario . . . . . . . . . . . . . . . . . . . . . . . . . . 14Sincronismo de rango . . . . . . . . . . . . . . . . . . . . . . 16Sincronismo de azimut . . . . . . . . . . . . . . . . . . . . . . 17

2.1.2. Radar secundario . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.3. Mensajes monoradar . . . . . . . . . . . . . . . . . . . . . . . 19

Protocolo ASTERIX 34 y 48 . . . . . . . . . . . . . . . . . . . 202.2. Tecnología SoC-FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Tarjeta ADC-SoC . . . . . . . . . . . . . . . . . . . . . . . . . 21Cyclone V SoC . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3. Requerimientos del trabajo . . . . . . . . . . . . . . . . . . . . . . . . 23

3. Diseño e implementación 253.1. Descripción del trabajo realizado . . . . . . . . . . . . . . . . . . . . 25

Elección de la tarjeta de desarrollo . . . . . . . . . . . . . . . 263.1.1. Entradas y salidas del sistema . . . . . . . . . . . . . . . . . 27

3.2. Descripción de las funciones implementadas . . . . . . . . . . . . . 283.2.1. Adaptación de señales de radar . . . . . . . . . . . . . . . . . 283.2.2. Conversión analógico a digital de video primario . . . . . . 303.2.3. Bloques constitutivos del sistema procesador . . . . . . . . . 313.2.4. Simulación de señales de radar . . . . . . . . . . . . . . . . . 32

VI

3.2.5. Sincronización . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.6. Filtro CFAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.7. Detector de ecos radar secundario . . . . . . . . . . . . . . . 373.2.8. Detector primario . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.9. Configurador de sectores . . . . . . . . . . . . . . . . . . . . 403.2.10. Detector de errores . . . . . . . . . . . . . . . . . . . . . . . . 413.2.11. Comunicación FPGA-HPS . . . . . . . . . . . . . . . . . . . . 423.2.12. Procesamiento y combinación de datos radar . . . . . . . . . 433.2.13. Configuración remota . . . . . . . . . . . . . . . . . . . . . . 463.2.14. Servidor de hora UTC . . . . . . . . . . . . . . . . . . . . . . 48

4. Resultados y ensayos 514.1. Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1.1. Recursos utilizados . . . . . . . . . . . . . . . . . . . . . . . . 524.1.2. Comportamiento operativo . . . . . . . . . . . . . . . . . . . 54

4.2. Ensayos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.1. Ensayos en FPGA . . . . . . . . . . . . . . . . . . . . . . . . . 564.2.2. Ensayos en HPS . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2.3. Pruebas operativas . . . . . . . . . . . . . . . . . . . . . . . . 57

5. Conclusiones 595.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 595.2. Conocimientos aplicados . . . . . . . . . . . . . . . . . . . . . . . . . 595.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Bibliografía 63

VII

Índice de figuras

1.1. Diagrama en bloques de un radar primario. Arriba el componentetransmisor, al medio el duplexor que evita que el pulso de potenciatransmitido dañe al receptor, abajo el componente receptor que secomporta como un superheterodino. . . . . . . . . . . . . . . . . . . 2

1.2. Principio de funcionamiento de un radar secundario. El equipo entierra transmite interrogaciones y el transponder de la aeronave res-ponde. Las preguntas y respuestas son codificadas y decodificadas.La aeronave es cooperativa con el sistema. . . . . . . . . . . . . . . . 3

1.3. Torre de una estación de radar donde se puede observar la antenade un radar primario de vigilancia y encima de este la antena deun radar secundario asociado1. . . . . . . . . . . . . . . . . . . . . . 5

1.4. Arquitectura de un sistema de distribución digital de señales y da-tos de radar de procesamiento analógico. . . . . . . . . . . . . . . . 6

1.5. Diagrama en bloques de la arquitectura de tubería para un proce-sador monoradar para radares con receptores analógicos, tambiénllamado extractor de datos radar. . . . . . . . . . . . . . . . . . . . . 7

1.6. Arquitectura de un sistema de distribución digital de mensajes mo-noradar de radares de procesamiento analógico. . . . . . . . . . . . 9

1.7. Procesador radar de la Marca Curtis-Wright2. . . . . . . . . . . . . . 91.8. Tarjeta procesador radar de la Marca Curtis-Wright3. . . . . . . . . 101.9. Fotografía del equipo Extractor de Datos Radar, subrack procesa-

dores, desarrollado por la Fuerza Aérea Argentina4. . . . . . . . . . 11

2.1. Video analógico de radar primario. . . . . . . . . . . . . . . . . . . . 142.2. Forma típica del eco recibido de radar primario. . . . . . . . . . . . 152.3. Detector tipo ventana deslizante. . . . . . . . . . . . . . . . . . . . . 152.4. Filtro de umbral adaptativo que funciona como un detector de ecos

de radar primario. La salida del CFAR entra al detector ventanapara establecer una correlación entre los ecos de diferentes emisiones. 16

2.5. La señal de sincronismo de rango marca el período de repeticiónde pulsos, es decir, el período del trabajo del radar primario y se-cundario de una estación radar. . . . . . . . . . . . . . . . . . . . . . 17

2.6. Las señales de sincronismo en azimut son dos. ACP marca las cuen-tas enteras en las que se dividen los 360 grados. ARP marca el pasode la antena radar por el norte geográfico. . . . . . . . . . . . . . . . 18

2.7. Tren de pulsos de la señal de video compuesto. Contiene en la mis-ma línea a los pulsos de interrogación y a los pulsos de respuesta. . 18

2.8. Formato de los bloques de datos radar establecidos en el protocoloASTERIX de EUROCONTROL. . . . . . . . . . . . . . . . . . . . . . 19

2.9. Tarjeta de desarrollo ADC-SoC. . . . . . . . . . . . . . . . . . . . . . 232.10. Hardware conectado al Cyclone V SoC que viene con la tarjeta

ADC-SoC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

VIII

3.1. Funciones del procesador monoradar diseñadas e implementadasen este trabajo final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2. Diagrama general de entradas y salidas del procesador monoradarimplementado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3. Tarjeta adaptora de señales de radar5. . . . . . . . . . . . . . . . . . 283.4. Flujo de la señal de video de radar primario que se digitaliza en los

conversores analógico a digital. . . . . . . . . . . . . . . . . . . . . . 303.5. Diagrama en bloques del procesador implementado en un circuito

integrado Cyclone V SoC. . . . . . . . . . . . . . . . . . . . . . . . . 313.6. Diagrama en bloques del simulador de señales radar. . . . . . . . . 333.7. Circuitos de sincronización del sistema de procesamiento con lógi-

ca programable del procesador monoradar. . . . . . . . . . . . . . . 353.8. Diagrama en bloques del filtro de umbral adaptativo CFAR imple-

mentado. La entrada son los n bits de resolución del video radarprimario, y la salida la comparación de la celda bajo test con elpromedio del entorno multiplicado por un factor k. . . . . . . . . . 36

3.9. Diagrama en bloques del detector secundario implementado enlenguaje VHDL. Una cadena de flip flops agrega celdas para ali-neación y guarda el tren de pulsos que permite identificar interro-gaciones y respuestas. . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.10. Diagrama en bloques del detector primario. Se implementó unamáquina de estados finita para cada cuenta de rango. Los datosde cada estado se almacenan en memoria RAM hasta la próximaemisión y los datos radar de salida en una FIFO. El filtro CFAR esla entrada para detectar primario y el detector secundario funcionarango a rango. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.11. Relación de aspecto entre los 32 sectores de configuración de pará-metros de funcionamiento que se implementaron, con respecto allímite de la cobertura radar en línea punteada. El giro de antena semarca con una flecha determinando el azimut. El barrido en rangoestá en función del tiempo. . . . . . . . . . . . . . . . . . . . . . . . . 40

3.12. Diagrama de la clase Puente en HPS que integra todas las funcio-nes que permiten la comunicación de los procesos con la FPGA. . . 43

3.13. Diagrama de la clase Procesador, que permite la extracción y elprocesamiento de los datos de radar. Estos, luego de empaquetarse,se despachan al hilo que transmite. . . . . . . . . . . . . . . . . . . . 44

3.14. Diagrama de actividad de Procesador::runP, método estático quecorre en el HPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.15. Diagrama del sistema de configuración remota implementado parael procesador monoradar. . . . . . . . . . . . . . . . . . . . . . . . . 46

3.16. Diagrama de la clase SocketService, que provee al procesador mo-noradar un servidor TCP/IP para atender clientes remotos quecontrolan y configuran el equipo. . . . . . . . . . . . . . . . . . . . . 47

3.17. Diagrama de la clase JsonConfig, que facilita el manejo de las confi-guraciones del procesador monoradar. Esta clase permite levantaral inicio la configuración y guardar en memoria no volátil las nue-vas, antes de ejecutar el cambio. . . . . . . . . . . . . . . . . . . . . . 47

3.18. Diagrama de la clase Radnmea. De forma similar a los mensajes deGPS, se usa una codificación y decodificación de mensajes de con-trol y configuraciones que proveen seguridad en la comunicacióndel procesador monoradar con aplicaciones remotas. . . . . . . . . 48

IX

4.1. Esquema ordenado de ensayos procesador monoradar. . . . . . . . 554.2. Diagrama de las herramientas utilizadas para probar el funciona-

miento del procesador monoradar. . . . . . . . . . . . . . . . . . . . 564.3. Durante las pruebas de integración del configurador de sectores se

utilizaron LEDs para verificar el valor de las señales en las entradasde cada sector. La flecha emula el paso de la antena. . . . . . . . . . 57

XI

Índice de tablas

4.1. Recursos FPGA utlizados . . . . . . . . . . . . . . . . . . . . . . . . 524.2. Recursos FPGA utilizados por entidades principales . . . . . . . . . 534.3. Consumo de memoria y procesador HPS . . . . . . . . . . . . . . . 54

XIII

Dedicado a mis padres que me enseñaron el valor de laeducación

1

Capítulo 1

Introducción general

En este capítulo se realiza una breve descripción del tipo de procesador radar im-plementado. Además se comenta la gestación del proyecto y finalmente se puedeencontrar definido el alcance.

1.1. Radar

Radar es un término derivado del acrónimo inglés radio detection and ranging quesignifica detección de radio y rango. Los radares son sistemas sensores que uti-lizan las ondas electromagnéticas para la detección y localización de objetos quereflejan energía, usualmente llamados blancos. La operación de estos sistemaspermite la medición de distancias, direcciones y velocidades. Son empleados enla vigilancia y control del espacio aéreo y pueden detectar objetos en ausencia deluz o en condiciones climáticas adversas.

Los radares de tecnología antigua carecen de procesamiento digital por lo que ne-cesitan de sistemas que permitan extraer, procesar y distribuir los datos de radar.Existen dos tipos de radar, los primarios y los secundarios, que pueden sincroni-zarse para generar información adicional a partir de la combinación de los datosextraídos.

Radar primario de vigilancia

Los radares, también llamados sensores, generan energía electromagnética que setransmite desde una antena hacia la dirección de propagación. Al encontrar unobjeto, la energía electromagnética se refleja en múltiples direcciones. Sólo unamínima parte de la energía reflejada retorna al sistema radar por la antena, pasaa los receptores, es amplificada y filtrada con técnicas para detectar al blanco enmedio de ruido. Este tipo de radares se denominan radares primarios. Los radaresprimarios de vigilancia, PSR del inglés Primary Survillance Radar, son utilizadoscon el propósito de detectar aeronaves o misiles en el espacio aéreo logrando loque se denomina cobertura radar.

Mediante procesamiento de señales se puede establecer si la señal recibida corres-ponde o no a un blanco. El cálculo del tiempo transcurrido entre la emisión delpulso de potencia y la recepción permite conocer la distancia, también llamadarango. El ángulo que forma la dirección de apuntamiento de la antena con res-pecto al norte geográfico es el azimut. Rango y azimut conforman la posición delblanco en dos dimensiones. En determinados casos se puede calcular el ángulocon respecto al horizonte conformando, con la altura, las tres dimensiones.

2 Capítulo 1. Introducción general

Partes componentes de un radar primario

Un radar es un sistema complejo que reúne principalmente componentes de elec-trónica de potencia, radiofrecuencia y procesamiento de señales. En la figura 1.1se puede observar un diagrama en bloques simplificado que muestra los compo-nentes básicos de un sistema radar primario.

En la parte superior de la figura se sitúa el componente transmisor que amplificauna forma de onda específica dependiendo del tipo de radar empleado. General-mente los radares de vigilancia aérea son del tipo pulsado, lo que significa queemiten pulsos de muy corta duración pero alta potencia.

FIGURA 1.1. Diagrama en bloques de un radar primario. Arriba elcomponente transmisor, al medio el duplexor que evita que el pul-so de potencia transmitido dañe al receptor, abajo el componente

receptor que se comporta como un superheterodino.

Los radares pulsados necesitan de un componente duplexor que permite la trans-misión de pulsos de alta potencia mientras se proteja al componente receptor y eldireccionamiento de los ecos recibidos. La antena de radar es el dispositivo quepermite transmitir la energía al espacio conformando un haz estrecho que favo-rezca la resolución en ángulos de azimut o altura y esperar los ecos que regresan.

El componente receptor de un radar primario debe amplificar señales débiles aniveles adecuados para la detección de blancos. Para lograr este objetivo trabajacomo un receptor superheterodino. La importancia de un amplificador de bajoruido está dada por la limitación que impone el ruido a las frecuencias de opera-ción de los radares.

A la salida del amplificador de bajo ruido, se emplea procesamiento de señales enfrecuencia intermedia. Con la fin de lograr detecciones y mitigar ecos no desea-dos generados por el entorno, también llamado clutter, el receptor debe trabajaren un rango dinámico amplio. En otras palabras, el receptor debe detectar ecosmuy débiles y al mismo tiempo evitar saturación del receptor por altos niveles depotencia.

1.1. Radar 3

Finalmente se realiza la demodulación y posterior amplificación en baja frecuen-cia. Se debe encontrar un nivel determinado para el cual las detecciones sean lassuficientes como para no perder blancos pero manteniendo las falsas alarmas, oecos no deseados, en un número razonable. Esta decisión se toma a la salida delreceptor para lograr alta probabilidad de detección.

Radar secundario de vigilancia

El radar secundario es en esencia un sistema de comunicaciones que permiteidentificar aeronaves y el cálculo de sus ubicaciones en vuelo. La principal dife-rencia entre un radar primario y uno secundario es que los primeros no necesitanque el objetivo responda. En cambio, el radar secundario necesita de un equipo abordo de la aeronave que responda a las interrogaciones por lo que se dice que elblanco es cooperativo.

El radar primario emite pulsos de potencia y espera las reflexiones pero no pue-de identificar a las aeronaves ni distinguir a dos blancos muy próximos entre sí.Para solucionar este problema se desarrolló el sistema militar IFF/SIF, del inglésIdentification Friend or Foe / Selective Identification Feature, que permite distinguiraviones amigos de los enemigos. En el ámbito civil se popularizó una versiónllamada SSR, del inglés Secondary Survillance System, o radar secundario de vigi-lancia. En la figura 1.2 se puede observar el principio de funcionamiento de unradar secundario.

FIGURA 1.2. Principio de funcionamiento de un radar secundario.El equipo en tierra transmite interrogaciones y el transponder de laaeronave responde. Las preguntas y respuestas son codificadas y

decodificadas. La aeronave es cooperativa con el sistema.


El radar secundario para realizar la medición emite pulsos codificados de interro-gación y espera pulsos codificados de respuesta. El sistema en tierra se encuentrasobre una torre y la antena es rotante. Con una antena direccional emite pulsosque codifican modos de interrogación. Las señales son recibidas por el equipoabordo de la aeronave llamado transponder que es receptor y transmisor. La res-puesta sale nuevamente codificada y se decodifica en el receptor del radar secun-dario. Dependiendo del modo, las respuestas pueden contener información decódigo de aeronave, altura, mensajes de error, pero al igual que en el radar pri-mario, el rango y azimut se calculan midiendo el tiempo que demora el pulso derespuesta en llegar y el ángulo con respecto al norte geográfico respectivamente.Una antena omnidireccional se utiliza como herramienta para evitar respuestasque ingresen por los lóbulos laterales de la antena principal.

Estaciones de radar

Las estaciones de radar son posiciones geográficas fijas donde se emplazan lossistemas de radar. Los centros de control del espacio aéreo reúnen la informaciónde las diferentes estaciones de radar.

Los radares primarios o secundarios que usan antenas rotantes constituyen loselementos típicos principales de las estaciones de radar. Cuando una estación es-tá constituida por dos sensores de diferente tipo y comparten una misma torre,manteniendo la misma dirección de apuntamiento, se puede realizar la combina-ción de las mediciones.

En la figura 1.3 se puede observar la torre de una estación con ambos tipos de ra-dar, en donde se destaca la diferencia de tamaño entre uno y otro, y como acom-pañan la misma dirección de apuntamiento. Usualmente el radar secundario seubica en la misma torre que el radar primario y se utilizan los sincronismos delúltimo.

Procesamiento de señales y procesamiento de datos radar

Los radares utilizan radiofrecuencias como portadora. En frecuencia intermediase utilizan técnicas de filtrado y procesamiento analógico de señales con el obje-tivo de mejorar la relación señal a ruido. En baja frecuencia el procesamiento deseñales permite detectar los ecos recibidos de posibles blancos.

Los radares actuales realizan procesamiento digital de señales inmediatamentedespués del amplificador de bajo ruido y generalmente incorporan una unidad decontrol y procesamiento que entrega datos. En cambio los radares de tecnologíamás antigua trabajan con filtros y detectores analógicos y entregan a la salida delos receptores una señal de video también analógico, comúnmente llamado videocrudo.

Los sistemas de vigilancia y control del espacio aéreo requieren de datos de radarporque están situados en lugares distantes a las estaciones de radar. El proce-samiento de datos permite que la información se pueda representar en consolasdigitales o integrar a sistemas de gestión y control. Este video transmitido por redde datos también es llamado video sintético.

1.1. Radar 5

FIGURA 1.3. Torre de una estación de radar donde se puede obser-var la antena de un radar primario de vigilancia y encima de este

la antena de un radar secundario asociado1.

Distribución de señales y distribución de datos radar

Un término popular para referirse a los herramientas que permiten la visuali-zación de datos radar es consola y pueden clasificarse según el tipo de repre-sentación. Las más utilizadas son las PPI, del inglés Plan Position Indicator querepresentan el radar en el centro de la pantalla, las distancias como círculos con-céntricos y el barrido de antena como una traza radial que gira con la velocidadde la antena.

Los radares de procesamiento analógico fueron diseñados con amplificadores devideo que retienen los valores altos de amplitud antes de ingresar a las consolas.El video amplificado se prepara de esta manera para la visualización en pantallascon tubos de rayos catódicos permitiendo que los operadores de radar puedan

1Imagen tomada de CAE Oxford Aviation Academy - RADIO NAVIGATION ATPL GROUNDTRAINING SERIES


identificar rápidamente los blancos y distinguirlos del clutter. La persistencia delas pantallas de fósforo antiguas permite visualizar a simple vista la disposiciónen dos dimensiones de los ecos recibidos y la traza que origina el recorrido de losblancos móviles scan a scan, es decir vuelta a vuelta. Por este motivo las consolasPPI se fabricaban con materiales fosforescentes capaces de retener la luminiscen-cia durante varias vueltas de antena radar.

En los sistemas de radar antiguos se utilizan splitters o divisores de señal ana-lógicos para mantener la operación de mas de una consola radar en paralelo enforma local o a una distancia máxima de unos dos mil metros. Existen equiposque pueden digitalizar el video analógico y representar el video crudo en unapantalla actual del tipo LCD (Liquid Crystal Display) o similar. En la figura 1.4 sepuede observar un diagrama de la arquitectura que puede tener un sistema dedistribución digital de señales y datos de radar de procesamiento analógico.

FIGURA 1.4. Arquitectura de un sistema de distribución digital deseñales y datos de radar de procesamiento analógico.

El video crudo contiene la información sin procesar y operadores experimentadospueden detectar con toda seguridad aeronaves de baja sección radar, es decir debajo coeficiente de reflexión a la frecuencia del radar, en el clutter. La desventajade este tipo de video es la dificultad de integrar automáticamente la informacióna otros sensores.

En el mercado actual se consiguen conversores y compresores de video crudo deradar capaces de transportar por red ethernet la información y descomprimirla enforma remota. No es la opción más utilizada por el costo que suponen los equiposy el ancho de banda utilizado. Este sistema de distribución de señales analógicasrequiere de cableado y hardware extra. La opción más utilizada es la de procesarel video en forma local y enviar la información sintetizada. La desventaja es la

1.2. Procesador monoradar 7

pérdida de información que se produce durante el procesamiento para obtenerblancos.

Las consolas de radar genéricas, normalmente, reciben datos de radar empaque-tados en protocolos estándares. A diferencia de las consolas de rayos catódicos lasconsolas digitales reciben plots, que son posibles blancos. También reciben pistaso tracks con información sobre la trayectoria de la aeronave, lo que requiere deprocesamiento de datos de vueltas anteriores.

1.2. Procesador monoradar

El procesamiento necesario para realizar las detecciones de un radar primario,otro secundario y la combinación de la información se denomina procesamientomonoradar.

El procesador monoradar utiliza datos de los sensores de una estación radar, porlo general radar primario y secundario asociado. Se puede diferenciar el proce-sador monoradar del multiradar, que utiliza los datos de diferentes estaciones eintegra datos de diferentes posiciones geográficas.

Arquitectura del procesador monoradar

Un procesador monoradar requiere datos de radar primario y de radar secun-dario. En el caso de los radares analógicos que no generan datos es necesariodigitalizar las señales de video, detectar los blancos y procesar la información ra-dar. El procesamiento monoradar incluye la combinación de los datos de radarprimario y secundario en un nuevo tipo de dato llamado combinado, el trackeo detrayectorias, y la transmisión de paquetes estandarizados.

En la figura 1.5 se puede observar la arquitectura pipeline o tubería de datos deun procesador monoradar para radares analógicos, también llamado extractor dedatos radar, debido a la tarea de extracción de datos a partir de señales de videoanalógico.

Para el flujo de datos de radar primario y para el flujo de datos de radar secunda-rio existen procesos productores y consumidores. El sistema requiere además dealmacenamiento o buffer que permita amortiguar las diferentes tasas de procesa-miento de cada instancia.

FIGURA 1.5. Diagrama en bloques de la arquitectura de tuberíapara un procesador monoradar para radares con receptores analó-

gicos, también llamado extractor de datos radar.

La primera instancia trabaja para detectar el eco, o retorno de la señal reflejada enun posible blanco, para el caso del detector de radar primario. De igual maneratrabaja en paralelo otra instancia para detectar la respuesta de una aeronave en elcaso del radar secundario.


En segundo lugar se puede observar la instancia de procesamiento. Es necesarioprocesar respuestas y ecos a fin de correlacionar los datos con cada blanco. Esimportante la alineación entre radar primario y secundario a fin de garantizarcorrelación en las etapas sucesivas.

Los datos de procesamiento primario y secundario deben pasar a una nueva eta-pa de procesamiento que los combine generando los plots correspondientes. Lacombinación de blancos primarios y secundarios se realiza asociando por cerca-nía.

Los datos de plots primarios, secundarios y combinados deben ser correlaciona-dos con los de vueltas anteriores para brindar datos de trayectorias y velocidades.De esta forma de generan los tracks.

Finalmente se requiere de la transmisión de datos empaquetados según un pro-tocolo para la decodificación y visualización en consolas radar de los mensajesmonoradar. El proceso de detección, procesamiento, combinación y trackeo se re-pite constantemente.

Distribución de mensajes monoradar

Para la transmisión de paquetes de datos se utilizan comunicaciones de red queunen las estaciones de radar con los centros de control. La tarea de operación essimplificada debido a que el procesador de datos correlaciona los posibles blancosde radar primario, secundario y la combinación de ambos.

En la figura 1.6 se puede visualizar el flujo de señales de radar analógico primarioy secundario hacia el hardware de adquisición y procesamiento de un procesadormonoradar. El procesamiento con software facilita el empaquetado y transmisiónde datos en formato de mensajes monoradar compuestos de plots y pistas de radarprimario, secundario y la combinación de ambos.

Los centros de vigilancia y control cuentan con sistemas procesadores multira-dar y multiprotocolo que pueden incluir a los mensajes monoradar enviados porlas estaciones de radar. En particular, los sistemas de vigilancia y control militarpueden integrar la información en sistemas de mando y control de operacionesmilitares complejas.

1.3. Antecedentes

En la República Argentina en el año 2003 la empresa INVAP comienza el desarro-llo de radares secundarios [1]. En el año 2004 con un decreto2 del Poder Ejecutivode la Nación se aprueba el Sistema Nacional de Vigilancia y Control Aeroespacialy con esto se da impulso al desarrollo de radares primarios y secundarios con elobjetivo de radarizar al país.

En el año 2005 INVAP comienza el desarrollo de radares primarios [2] y en elaño 2014 logra homologar y comenzar la producción en serie. Mientras tanto em-piezan a convivir los nuevos equipos de procesamiento digital con tecnologíasanteriores, radares primarios y secundarios de procesamiento analógico.

2Decreto 1407/2004

1.3. Antecedentes 9

FIGURA 1.6. Arquitectura de un sistema de distribución digital demensajes monoradar de radares de procesamiento analógico.

En el mercado internacional pueden encontrarse empresas que proveen produc-tos de hardware y software llave en mano y que cumplen con los requerimientospara digitalizar y procesar señales de sensores analógicos. En la figura 1.7 se pue-de observar el rack de un procesador radar de la marca Curtis-Wright y en lafigura 1.8 una tarjeta Osiris de la misma empresa que puede digitalizar y proce-sar video radar. La tarjeta trabaja con una FPGA y comunicación PCI (PeripheralComponent Interconnect) y ambos equipos son utilizados en arquitecturas como lasque se muestran en la figura 1.4.

FIGURA 1.7. Procesador radar de la Marca Curtis-Wright3.

3Imagen tomada de https://www.curtisswrightds.com/products/computing/radar/radar-video-processor.html

https://www.curtisswrightds.com/products/computing/radar/radar-video-processor.html

https://www.curtisswrightds.com/products/computing/radar/radar-video-processor.html


FIGURA 1.8. Tarjeta procesador radar de la Marca Curtis-Wright4.

El costo y logística de la compra de estos productos y servicios puede ser un pro-blema para algunos estados u organismos porque es necesario solicitar permisosinternacionales para la adquisición de tecnología para la defensa. Estos equipospueden tener un costo muy elevado, pudiendo superar el millón de dólares, queincluye la provisión de software, repuestos y capacitación.

Extractor Digital de Datos de Radar

La Fuerza Aérea Argentina ha desarrollado un equipo que se integra a las esta-ciones de radar que tienen sensores analógicos. Este equipo ha posibilitado quediferentes sistemas de radar, algunos hoy ya desactivados, puedan enviar los da-tos a los centros de control, haciendo posible la operación ininterrumpida delsistema de vigilancia. Este sistema respeta la arquitectura expuesta en la figura1.5 y permite generar los mensajes monoradar según el flujo de la figura 1.6.

El equipo, llamado Extractor Digital de Datos de Radar (E.D.D.R.), es un proce-sador monoradar. Se ha desarrollado con un diseño modular que posibilita la de-tección, asociación, trackeo y transmisión de la información radar. En la figura 1.9puede observarse la fotografía de uno de los equipos desarrollados por la Fuer-za Aérea Argentina, que es parte del E.D.D.R. y cumple funciones de procesadorprimario, secundario, combinador y trackeador.

Mejoras al Extractor Digital de Datos de Radar

En el año 2014 se han realizado las últimas mejoras al equipo E.D.D.R., con eldesarrollo de software en el subcomponente combinador-trackeador. Las referen-cias a este proyecto pueden encontrarse en los trabajos de Maestría de IgnacioA. Montamat, Combinador de Información Primaria y Secundaria para ExtractorDigital de Datos de Radar en Sistemas de Vigilancia [3], y de Santiago Rodríguez,Sistema de Seguimiento y Generación de Pistas para Radar Track While Scan [4],quienes han integrado el equipo de desarrollo durante ese tiempo.

4Imagen tomada de https://www.curtisswrightds.com/products/computing/radar/osiris.html

5Imagen tomada de la Tesis de Maestría en Sistemas de Radar e Instrumentación - "Sistema deSeguimiento y Generación de Pistas para Radar Track While Scan Santiago A. Rodríguez González- Universidad Nacional de Córdoba / Instituto Universitario Aeronáutico - 2019

https://www.curtisswrightds.com/products/computing/radar/osiris.html

https://www.curtisswrightds.com/products/computing/radar/osiris.html

1.4. Objetivos y alcance del proyecto 11

FIGURA 1.9. Fotografía del equipo Extractor de Datos Radar, su-brack procesadores, desarrollado por la Fuerza Aérea Argentina5.

En el año 2017 se firmó un acuerdo de cooperación entre la Facultad de CienciasExactas y Naturales y Agrimensura de la Universidad Nacional del Nordeste yel entonces Grupo III de Vigilancia y Control Aerospacial, hoy Base Aérea MilitarResistencia. Uno de los trabajos realizados a partir de la firma de dicho acuerdofue la implementación del E.D.D.R. de la Fuerza Aérea Argentina en una tarjetaADC-SoC. Este trabajo fue desarrollado y finalizado a principios del año 2019.

1.4. Objetivos y alcance del proyecto

En el mes de mayo de 2019 se da inicio al proyecto para la implementación deun nuevo procesador monoradar en una tarjeta de desarrollo con tecnología SoC-FPGA. El proyecto incluye desde la adquisición de señales de radar analógicashasta la transmisión de paquetes de datos y la aplicación de técnicas y herra-mientas aprendidas durante el cursado de la especialización.

Objetivos

El objetivo de este proyecto es la implementación de un procesador de señales deradar utilizando tecnología SoC-FPGA para lograr, esencialmente, un prototipoque entregue la información procesada, de un radar primario y otro secunda-rio asociado, empaquetada en protocolo estándar de mensajes monoradar, y quepermita al mismo tiempo, la configuración de sus parámetros de funcionamiento,calibración y detección de fallas.


Por un lado el propósito del trabajo es dotar a la Fuerza Aérea Argentina de unequipo que permita extraer datos procesados de las estaciones de radar que cuen-ten con dos tipos diferentes de radar, pero comparten generalmente la torre quehace girar a ambos. El procesador implementado debe combinar datos y entregarplots y tracks de datos radar primario, secundario y la combinación de ambos.

Por otro lado, además de mejorar el equipamiento actual, el trabajo tiene comopropósito desarrollar habilidades y generar soluciones tecnológicas para el áreade la defensa usando tecnología SoC-FPGA y aplicando los conceptos aprendidosdurante el cursado de la Especialización en Sistemas Embebidos.

Alcance

Encontrar el funcionamiento deseado del procesador monoradar para llegar a laetapa final de combinación de datos de radar primario y secundario requirió elsiguiente alcance:

Diseño e implementación de una tarjeta adaptadora de señales.

Adquisición de datos con conversor analógico a digital.

Diseño e implementación de simulador embebido de señales radar.

Diseño e implementación de módulo sincronizador del procesador mono-radar.

Implementación y mejoras en diseño de umbral adaptativo para detector deecos de radar primario.

Implementación de detector secundario.

Diseño e implementación de módulo detector primario.

Diseño e implementación de comunicación entre etapa de detección y pro-cesamiento.

Diseño e implementación de combinador de datos radar primario y secun-dario.

Diseño e implementación de configurador de sectores radiales y azimutalesen tiempo real.

Diseño e implementación detector de errores en tiempo real.

Diseño e implementación de configurador remoto.

Diseño e implementación de servidor de hora GPS.

Integración de procesador, trackeador y transmisor en un prototipo operati-vo.

En la planificación inicial no se contemplaba el diseño completo del procesadormonoradar debido a que se contaba con el E.D.D.R, pero debido a que los com-ponentes en FPGA estaban implementados con bloques propietarios IP de Intel,se decidió el re-diseño de componentes y la implementación en VHDL, lo queposibilita portabilidad y escalabilidad.

13

Capítulo 2

Introducción específica

En el presente capítulo se describen las formas de ondas y valores típicos de fre-cuencia y amplitud de señales de radares primarios y secundarios de vigilanciaque pueden utilizar el procesador monoradar desarrollado. Además se resumenlas características técnicas de la tecnología SoC-FPGA y en particular de la placaADC-SoC utilizada como plataforma de hardware del procesador monoradar.

2.1. Señales radar

El presente trabajo fue implementado específicamente en los radares de vigilan-cia FPS 113 y TPX 42 de la Fuerza Aérea Argentina. El primero de ellos es del tipoprimario y el segundo del tipo secundario. El procesador desarrollado, puede seradaptado fácilmente a otros radares analógicos de vigilancia. Por razones de con-fidencialidad, no se presentan datos técnicos específicos de los radares utilizadosen las mediciones.

Las señales analógicas de radar son las entradas del procesador implementado ylas salidas los mensajes monoradar. Pero antes de nombrar sus características, sepresentan datos de funcionamiento típicos de un radar de vigilancia.

Usualmente los radares primarios de vigilancia emiten una serie de pulsos muyestrechos y similares a una onda rectangular. Un ejemplo [5] de una forma deonda para un radar de mediano alcance que detecta aeronaves debería estar con-formado por:

Un breve pulso que dure un microsegundo.

Un tiempo entre pulsos de un milisegundo.

Una frecuencia de pulsos de un kilohertz.

Una potencia pico en el transmisor de radar de alrededor de un megawatt.

Con esos valores el promedio de potencia del transmisor es un kilowatt. Comoafirma Merrill Skolnick en este ejemplo, el promedio de potencia de un kilowattpodría ser menos que la potencia que requiere la iluminación de un salón. Seasume en este ejemplo que el radar está operando en la mitad de la frecuenciade microondas, aproximadamente desde los 2,7 a los 2,9 GHz, que es el anchode banda de frecuencia típica para los radares civiles de vigilancia aeroportuaria.Haciendo redondeo para simplificar, la longitud de onda podría ser de alrededorde 10 cm para este radar. Con la antena correcta el límite de su cobertura en rangopodría estar en las 50 o 60 millas aproximadamente.

14 Capítulo 2. Introducción específica

El eco recibido por el radar luego de reflejarse en un blanco puede variar en po-tencia, pero arbitrariamente se puede asumir a los fines de ilustrar, con valoresde alrededor 10-13 W. Si la potencia radiada por el transmisor es de 106 W (unmegawatt), la relación de potencia recibida sobre transmitida en este ejemplo esde 10-19, y el eco recibido es 190 dB menos que la señal transmitida. No es posibleseparar totalmente el eco, del ruido que acarrean las sucesivas etapas de detec-ción en los receptores. A la salida, los radares más antiguos, generan una señal devideo analógico que varía en amplitud, esa es la entrada al extractor y procesadorradar primario.

2.1.1. Radar primario

La extracción de datos de radar de sensores analógicos requiere la digitalizaciónde video primario. Un radar analógico usualmente brinda mas de un tipo de vi-deo, como por ejemplo video logarítmico, pero el más utilizado es video normalo video lineal.

El video analógico de radar primario también es llamado video crudo (raw video).En la figura 2.1 se puede observar la captura de pantalla de un osciloscopio re-presentando la forma que tiene la señal de entrada a los conversores analógicos adigital.

FIGURA 2.1. Video analógico de radar primario.

Dependiendo del lugar donde se haga la digitalización, el valor de amplitud detensión puede variar, pero, hay que estimar entre 1 y 5 voltios pico, con un valorcontinuo cercano a 0 Vcc y menos de 1 voltio de valor RMS. En la figura 2.1 elvideo se encuentra sincronizado con la señal de trigger del radar, es decir, con laseñal de sincronismo en rango. El ciclo de trabajo para los radares de vigilancia seencuentra alrededor de los 3 o 4 milisegundos. En la figura 2.2 se puede observarla forma de onda del video para un eco.

Los ecos recibidos se confunden con el ruido generado durante la recepción, quese suma a la tensión de la señal. Este video puede ser representado en una PPI,porque, el operador radar puede integrar visualmente en un entorno de rango yazimut, el resultado de sucesivas emisiones.

2.1. Señales radar 15

FIGURA 2.2. Forma típica del eco recibido de radar primario.

Generalmente el eco puede tener menos de 1 microsegundo de ancho y una am-plitud de alrededor de 3 voltios. Los valores varían en función del punto de salidadonde se decide tomar la señal, del tipo de radar, y del tipo de video.

Para identificar al blanco a partir del video lineal se pueden utilizar detectores. Elmás utilizado es el detector de ventana deslizante cuyo diagrama se observa enla figura 2.3. La entrada del detector se establece a partir de un umbral fijo para elvideo analógico. Sólo los ecos de mayor amplitud de tensión pasan, y se generauna señal digital que vale uno o cero lógico.

La ventana deslizante es un proceso continuo donde el nuevo dato reemplaza alanterior. La suma de las n emisiones anteriores para un mismo rango se comparacontra un número determinado.

FIGURA 2.3. Detector tipo ventana deslizante.

Como desventaja, este detector es susceptible a interferencia, porque una muestracon nivel alto de tensión, causa una detección y eleva la tasa de falsas alarmas.


El problema puede minimizarse con el uso de umbral adaptativo, como el delesquema de la figura 2.4.

FIGURA 2.4. Filtro de umbral adaptativo que funciona como undetector de ecos de radar primario. La salida del CFAR entra aldetector ventana para establecer una correlación entre los ecos de

diferentes emisiones.

Para realizar el promedio con técnicas digitales se utiliza un conversor ADC. Lastécnicas de umbral adaptativo asumen que la densidad de probabilidad del ruidoes conocida, excepto por pocos parámetros. A partir de las celdas de referencia,que forman parte del entorno cercano a la celda bajo test, se obtiene una esti-mación de esos parámetros. El más simple de esos detectores adaptativos es elCA-CFAR (cell-avarage constant false-alarm rate). Para mantener constante la tasade falsas alarmas, utiliza el promedio de las celdas cercanas.

Como el radar, dependiendo del diseño, logra recibir mas de 10 ecos por cadablanco, uno por cada emisión, posterior al filtro CFAR es necesario buscar unacorrelación para detectar blancos. De esta forma se completa una arquitecturamuy común: filtro CFAR más detector ventana.

Es necesario establecer una relación de compromiso entre las falsas alarmas y laprobabilidad de detección. Multiplicar el promedio por un coeficiente, permitesobrepasar la zona de ruido presente en la señal de video radar.

Sincronismo de rango

Las emisiones transmitidas por el radar están moduladas por la forma de ondadel pulso de potencia. El pulso que sincroniza el ciclo de trabajo también lo hacecon la cuenta de rango, que puede estar adelantada con respecto a la marca de 0millas náuticas (MN).

El tiempo total para completar un ciclo de trabajo del radar pulsado se llama PRT(Pulse Repetition Time), el recíproco se denomina PRF (Pulse Repetition Frequency) ycorresponde a la frecuencia de trabajo del radar. Las señales PRF que se encuen-tran adelantadas se denominan pretriggers. En la figura 2.5 se puede observar la


forma de onda rectangular de la señal PRF, sincronismo de rango. Los mínimos ymáximos de rango están dados por los tiempos de recepción, fuera de los cualesel radar no acepta señales de posibles ecos.

FIGURA 2.5. La señal de sincronismo de rango marca el períodode repetición de pulsos, es decir, el período del trabajo del radar

primario y secundario de una estación radar.

El tiempo mínimo sucede cerca de las 0 MN. Además, existe un tiempo durante elcual los receptores permanecen aislados, para evitar daños de pulsos de potenciadurante la transmisión. El tiempo máximo depende del alcance efectivo del radar.Si se utiliza un reloj para marcar las cuentas de rango a partir del pulso de PRF,la cuenta máxima supera al máximo rango por el llamado tiempo muerto, dondeya no se aceptan ecos.

Sincronismo de azimut

Con independencia del ciclo de trabajo del radar, la antena rotante gira a una ve-locidad constante. El posible blanco será radiado varias veces dependiendo de lavelocidad angular de giro. A los fines de tener una marca de ángulo las antenassincronizan las mediciones con la generación de pulsos equidistantes en tiempo,similares a los pulsos de sincronismo de rango, y con frecuencias similares. Porejemplo, una antena que gira a 6 RPM tendrá una vuelta de 10 segundos de du-ración. Debido al ancho del haz, que depende del tipo de antena, se producirán nreflexiones que regresan como ecos.

Es necesario establecer una referencia para la medición de ángulos en azimut.Para esto se toma la marca de paso por el norte geográfico que debería coincidircon la marca de cero cuentas de azimut. En la figura 2.6 se pueden observar lasseñales, ACP (Azimut Change Pulses) o señal de marca de cambio de azimut, y lasseñales ARP (North Reference Pulse or Azimuth Reference Pulse) o marcas de pasopor el norte. Las cuentas totales de azimut son múltiplos de 2n, generalmente 4096dentro de los 360 grados de la vuelta completa.

2.1.2. Radar secundario

El radar secundario de vigilancia modula en fase las preguntas y demodula lasrespuestas recibidas del transponder de la aeronave. La comunicación se reali-za sin la necesidad de un costoso duplexor debido a que pregunta y respuestausan diferentes frecuencias. El transpondedor de la aeronave recibe la señal deinterrogación en una frecuencia de 1030 MHz, y transmite las respuestas en unafrecuencia de 1090 MHz. Una vez demodulado la salida del radar secundario es elvideo, un tren de pulsos cuya presencia o no, codifica la respuesta y la pregunta.


FIGURA 2.6. Las señales de sincronismo en azimut son dos. ACPmarca las cuentas enteras en las que se dividen los 360 grados.

ARP marca el paso de la antena radar por el norte geográfico.

Las marcas de sincronismo para el radar secundario son generadas en el radarprimario. Además, por lo general, el sincronismo en rango se envía al radar se-cundario como un pre-trigger. Es decir, el pulso de PRF para el secundario seencuentra adelantado, para dar tiempo de generar las interrogaciones, y que lacuenta de rango coincida con el radar primario. Esta separación debe ser por lomenos equivalente al tiempo de la codificación más larga de pregunta.

En la figura 2.7 se pueden observar los pulsos de interrogación sobre la mismalínea de la respuesta. A este video se lo llama compuesto. En primer lugar, y antesdel pulso de pre-trigger aparecen los pulsos de pregunta del radar secundario. Ladiferencia entre el pulso P1 y P3 codifica cuatro tipos de interrogación diferentes.Posterior al pulso de pre-trigger pueden empezar a llegar las respuestas de laaeronave. El cálculo del tiempo transcurrido hasta el arribo señala la posiciónen rango de la aeronave. Las marcas de angulo del radar primario permiten laextracción del dato de azimut con respecto al norte.

FIGURA 2.7. Tren de pulsos de la señal de video compuesto. Con-tiene en la misma línea a los pulsos de interrogación y a los pulsos

de respuesta.


2.1.3. Mensajes monoradar

Los datos de radar procesados más comúnmente utilizados son los mensajes mo-noradar, que son datos estructurados para la transmisión de reportes de una es-tación de radar. Los reportes pueden corresponder a radares secundarios con-vencionales de vigilancia, radares monopulso, de modo S, radares primarios devigilancia convencionales, o radares primarios que usan procesamiento para ladetección de blancos que se mueven MTD (Moving Target Detection). Los destina-tarios de los mensajes son los equipos procesadores del sistema de vigilancia ycontrol del espacio aéreo.

La norma que se adopta para definir la estructura de los mensajes se encuentradetallada en los documentos [6] de EUROCONTROL, el organismo europeo parala navegación aérea segura. EUROCONTROL es una organización internacionalfundada en 1960 que trabaja junto a otras autoridades en lo que se refiere a coor-dinación y planificación del tránsito aéreo.

ASTERIX es el acrónimo de all-purpouse structured EUROCONTROL survillance in-formation exchange, y se encuentra detallado en un conjunto de documentos quedefinen la implementación de un formato de datos de bajo nivel para ser utiliza-dos en la gestión del tránsito aéreo. Se encuentra diseñado para su uso en redesde ancho de banda limitado, por eso las reglas que presenta son para transmitirtoda la información necesaria con mínima sobrecarga de datos.

Cada mensaje ASTERIX está constituido por bloques de datos (Data Blocks) deradar estandarizados. La menor unidad de datos está conformada por un octeto,es decir 8 bits. Los bloques tienen campos según la forma que se observa en lafigura 2.8.

FIGURA 2.8. Formato de los bloques de datos radar establecidosen el protocolo ASTERIX de EUROCONTROL.

Donde podemos identificar:

Categoría o clasificación del dato CAT (Data Category) es un campo de unocteto

Indicador de largo total en bytes LEN (Length Indicator) son dos octetos,CAT y LEN inclusive

Especificación de campo FSPEC (Field Specification)

Los mensajes deben estar compuestos por bloques de datos armados en el or-den que son definidos según un perfil determinado que se denomina UAP (UserApplication Profile). Este perfil establece un orden y cada campo tiene un númeroFRN (Field Reference Number).


Protocolo ASTERIX 34 y 48

El protocolo ASTERIX ofrece 256 categorías que se eligen dependiendo de la apli-cación, y cada una describe la estructura de deben tener los mensajes transmiti-dos. Los procesadores monoradar utilizan las categorías 34 y 48 para mensajes deestado y reportes de blanco, respectivamente, y son la evolución de las categorías1 y 2. Juntos constituyen la norma para la transmisión de mensajes monoradar.

La transmisión de mensajes monoradar requiere la transmisión de dos tipos demensajes:

Reporte de blancos emitidos por una estación de radar [7]

Mensajes de estado de la estación de radar y sus sensores [8]

El manejo del tiempo solo aplica a las antenas rotantes convencionales, y se hacecon la hora UTC (Coordinated Universal Time) que se imprime a cada reporte. Paraeste tipo de antenas también se aplican los mensajes de paso por el norte geográfi-co, uno por vuelta de antena. Por último, en este caso opcional, se pueden generardatos de marcas de azimut equidistantes que separan sectores azimutales.

Se pueden identificar cuatro tipos de mensajes categoría 34:

Mensajes de cruce de la antena de radar por el norte geográfico, marca deazimut cero

Mensajes de marcas de cambio de sector, 32 marcas equidistantes dentro delos 360 grados azimutales

Mensajes de informes de zonas de filtrado geográfico

Mensajes de informes sobre interferencias electrónicas (jamming strobe)

La categoría 48 define los mensajes que pueden extraerse de las detecciones desensores que comparten un mismo conjunto de antena rotante. Se aceptan siste-mas de radar primarios, secundarios o la combinación de ambos. En el últimocaso son los procesadores digitales los que permiten fusionar los dos tipos de ra-dar en un solo sistema y se asume que los subsistemas de antena de cada radarestán configurados para:

Garantizar coincidencia en la detección

Utilizar un solo sistema de referencia de coordenadas

Para la categoría 48 se pueden identificar dos tipos de reportes:

Reporte de plots, blancos primarios, secundarios o combinados

Reporte de tracks, pistas o trayectorias generadas por un sistema trackeadorcon la información de varios plots correlacionados

2.2. Tecnología SoC-FPGA

Un sistema embebido puede ser definido en un concepto amplio como un dispo-sitivo que contiene componentes estrechamente asociados para realizar una tareaen particular, como parte de un sistema mas grande, diseñado para trabajar con

2.2. Tecnología SoC-FPGA 21

poca o nula interacción humana. Independientemente de las funciones que cum-plan los sistemas embebidos es posible observar que lo integran dos componentesbien diferenciados, el hardware y el software.

Antes de describir a la tecnología SoC-FPGA, se empieza por identificar a los dis-positivos más diversificados, los microcontroladores o MCUs (microcontrollers).Estos últimos, en la actualidad se confunden con los microprocesadores o MPUs(microprocessors), por la complejidad y cantidad de recursos con que son construi-dos y la gran capacidad de procesamiento. Realizan tareas secuenciales y puedeno no correr un sistema operativo.

Por otro lado se pueden identificar a aquellos circuitos integrados que son fabri-cados para aplicaciones muy específicas, los ASIC (application-specific integratedcircuit), diseñados para una empresa en particular, no se pueden configurar paraotra cosa que su función original. Se diseñan en fábrica, buscan alta performanceasociada con bajo consumo de energía.

Los ASSPs (Application-specific standard parts) son diseñados para implemen-tarse de forma similar a los ASIC, para una función única, pero permiten su usoen múltiples sistemas. Para constituirse, un ASIC no necesariamente debe ser uncircuito digital, pero puede portar software, inclusive pueden integrar un micro-procesador. Tienen la ventaja de agregar hardware para una función muy especí-fica.

Cuando un ASIC o ASSP contiene a un procesador se llama comúnmente SoC(System-on-Chip). Es un circuito integrado que contiene uno o más microproce-sadores, procesadores digitales de señales DSPs (Digital Signal Processorors) oambos, junto a otros elementos de hardware.

La poca flexibilidad de los ASIC para adaptarse a usos diferentes, o modifica-ciones en el sistema del cual forman parte, se contrasta con el desempeño de lasFPGA (field-programmable gate arrays), que pueden ofrecer alto desempeño, bajoconsumo, y la posibilidad de re-programar la interconexión de sus partes compo-nentes de hardware, para formar circuitos digitales equivalentes. La ventaja delas FPGA radica en el procesamiento paralelo que pueden ofrecer.

Cuando se programa lógica para formar un microprocesador se obtienen los lla-mados softcores. Esa parte utilizada para el procesador en FPGA puede repro-gramarse. En cambio, cuando la FPGA comparte silicio con un microprocesador,y esa parte no es reprogramable, se llama SoC-FPGA y al procesador hardcore.Además puede integrar DSPs, diferentes tipos de memoria y más de un "hard-Processor".

Las empresas tienen nombres diferentes para cada uno de estos componentes,a veces relacionado con estrategias de venta, otras veces, porque algunas fueronpioneras y las demás continuaron el camino. Es esta memoria se adopta el nombrede SoC-FPGA para este tipo de dispositivos. Otros nombres pueden ser válidos,como por ejemplo PSoCs (Programmable SoCs) o All Programmable SoCs.

Tarjeta ADC-SoC

La tarjeta de desarrollo elegida para la implementación de un procesador mono-radar se llama ADC-SoC. Fue fabricada por la empresa Terasic como plataformapara usar un SoC-FPGA de la empresa Intel. En la figura 2.9 se puede observar


fotografías de la placa y en ella es posible identificar a los conectores y compo-nentes.

La parte de FPGA contiene o está asociada a:

Dispositivo Cyclone V SE 5CSEMA4U23C6N.

USB-Blaster II para la programación en modo JTAG.

Dos botones, cuatro Dip Switches, ocho LEDs.

Tres fuentes de reloj de 50 MHz.

Conector GPIO de cuarenta pines, conector compatible Arduino, conectordiez pines para entradas analógicas.

Conversores analógico a digital de 500 Ksps y SPI.

Dos conversores analógico a digital de 14 bits y 150 Msps con transforma-dores de acoplamiento y conectores SMA.

El componente HPS contiene o está asociado a:

Dispositivo ARM Cortex-A9 Dual-core de 925 MHz.

1 GB DDR3 SDRAM.

USB OTG y USB con conector Micro-AB.

Sócalo para tarjeta de memoria Micro SD

Interfaz I2C y acelerómetro.

UART a USB con conector USB Mini-B.

Dos botones para warm reset y cold reset.

Conector para conversor analógico a digital LTC2308 y reloj RTC.

Cyclone V SoC

Los dispositivos Cyclone V SoC FPGA de la empresa Intel son circuitos integra-dos con uno o dos microprocesadores ARM Cortex A9, un set de periféricos, uncontrolador de memoria multipuerto compartido con lógica programable y unaFPGA Cyclone V. Esto brinda flexibildad y ahorro de costos, en primer lugar, por-que en el microprocesador se puede implementar un sistema operativo de pro-pósito general, un sistema operativo de tiempo real RTOS (Real Time OperatingSystem) o programación Bare Metal sin sistema operativo.

En la figura 2.10 se pueden ver los componentes conectados a cada parte del Cy-clone V SoC.

El set de periféricos que tiene, evita el uso de recursos FPGA o procesamiento enel MCU. La memoria compartida por los dos componentes, FPGA y micropro-cesadores, permite establecer una variedad de comunicaciones de gran ancho debanda. La tecnología SoC elimina la necesidad de conexiones de entrada y salidaentre componentes.

2.3. Requerimientos del trabajo 23

FIGURA 2.9. Tarjeta de desarrollo ADC-SoC.

2.3. Requerimientos del trabajo

La implementación de un combinador radar utilizando tecnología SoC-FPGA re-quirió de un plan de trabajo. Durante este último se acordaron los siguientes re-querimientos:

Requerimientos funcionales:

El sistema debe integrar en una tarjeta de desarrollo ADC-SoC la adquisi-ción, detección, simulación, filtrado, calibración, detección de fallas, combi-nación y trackeo, de señales de una estación radar que reúna datos de radarprimario y secundario.

El sistema debe generar, a partir de los blancos primarios y secundarios,los plots y tracks en protocolo Asterix categoría 34 y 48, con hora UTC y deacuerdo a la necesidad de las redes existentes en la Fuerza Aérea Argentina.


FIGURA 2.10. Hardware conectado al Cyclone V SoC que vienecon la tarjeta ADC-SoC.

El software debe permitir que un usuario remoto pueda ingresar y perma-necer en comunicación con un proceso que saque mensajes informando lasfallas del equipo y/o la falta de señales de sincronismo o video.

La configuración, calibración y detección de fallas deben ser intuitivas y nodeben afectar al desempeño del combinador radar.

Requerimientos de validación:

El proceso de extracción completo debe convivir con los procesos de controly calibración, soportando por lo menos 2000 plots cada 10 segundos.

El sistema debe levantar las últimas configuraciones ante un reset.

Requerimientos de documentación:

El manual de usuario debe estar confeccionado de acuerdo al reglamentode escritura de la Fuerza Aérea Argentina.

El manual de instalación debe reunir los pasos necesarios para replicar elequipo en una nueva tarjeta de desarrollo ADC-SoC a partir de una compu-tadora frizada.

Requerimientos de metodología de trabajo:

La implementación debe utilizar GIT para el control de versión de cambios.

El diseño del software debe ser modular.

25

Capítulo 3

Diseño e implementación

En el presente capítulo se describe cada uno de los componentes del precesadormonoradar implementado y se comentan los criterios de diseño. Se explica el fun-cionamiento de la digitalización, procesamiento, configuración y comunicacionesen el orden de avance de las señales y datos de radar.

3.1. Descripción del trabajo realizado

En el presente trabajo se describe la implementación de un procesador monora-dar para radares de procesamiento analógico. Si bien el desarrollo se diseñó paraincorporarse a los radares primarios FPS 113 y secundarios TPX 42 de la FuerzaAérea Argentina, se puede emplear en otros radares de similares características.

En el proceso de diseño se buscó que hardware y software cumplan principal-mente con las siguientes propiedades:

Funcionalidad: capacidad de satisfacer una necesidad específica y en con-diciones específicas.

Fiabilidad: capacidad de funcionar sin fallas por un período determinadoen condiciones específicas.

Usabilidad: capacidad de ser entendido, aprendido y usado.

Mantenibilidad: capacidad de ser modificado en forma efectiva y eficiente,debido a necesidades evolutivas, correctivas o perfectivas.

Portabilidad: capacidad de programarse o ejecutarse en diferentes platafor-mas.

Se priorizaron estas propiedades porque se buscaba el desarrollo de un prototipooperativo, de operación continua y que no se afecte la seguridad operacional,un procesador radar para el sistema de vigilancia y control de la Fuerza AéreaArgentina.

En la figura 3.1 se pueden visualizar las funciones que se diseñaron e implemen-taron. El trabajo realizado comprendió el desarrollo de procesamiento en tiemporeal:

Digitalización de las señales de radar primario y secundario.

Filtrado sobre la señal de video radar primario.

Detección de ecos de radar primario y respuestas de radar secundario.

26 Capítulo 3. Diseño e implementación

Configuración sectorizada de parámetros.

Detección de errores.

Además requirió el desarrollo de software para la implementación de las siguien-tes funciones:

Asociación y combinación de datos de radar.

Control del sistema y transmisión de mensajes monoradar.

Parseo de configuraciónes remotas.

FIGURA 3.1. Funciones del procesador monoradar diseñadas e im-plementadas en este trabajo final.

Fue necesario implementar componentes externos al procesador monoradar peronecesarios para su funcionamiento:

Se diseñó una tarjeta adaptadora de señales de sincronismo antes de su en-trada al dispositivo.

Se implementó un servidor de hora en una placa de desarrollo EDU-CIAAy su poncho GPS.

Se desarrolló una aplicación para configuración remota que se comunicapor TCP/IP con el procesador monoradar.

El desarrollo del proyecto se encuentra versionado. En el presente capítulo sedescribe a la versión 2.0.0.

Elección de la tarjeta de desarrollo

Se decidió la utilización de una tarjeta de desarrollo ADC-SoC de la empresaTerasic que cumple con los objetivos del proyecto. La idea de trabajar con dichaplaca nació de un estudio de mercado realizado durante un proyecto anterior bus-cando una tarjeta de desarrollo con capacidad para realizar mejoras a un equipoE.D.D.R.

3.1. Descripción del trabajo realizado 27

La ventaja de esta placa como plataforma para el trabajo final son los conversoresanalógicos a digital de alta velocidad adecuados para la adquisición de video deun radar de vigilancia aérea y su relativo bajo costo. Esto permitió contener en lamisma tarjeta la adquisición de video radar primario y un circuito integrado conuna parte de lógica programable y otra parte de software.

En el componente de software de decidió instalar un sistema operativo Linuxcon el fin de implementar rápidamente sockets para la comunicación con la reddel sistema de vigilancia y control, sin requerimientos de cómputos en etapasposteriores. La arquitectura SoC-FPGA permitió comunicaciones programablesentre FPGA y HPS para adquirir los datos extraídos, lo que ahorra tiempos yredunda en mayor portabilidad y mantenibilidad.

3.1.1. Entradas y salidas del sistema

Para describir la implementación realizada durante el desarrollo del trabajo fi-nal se presenta la figura 3.2, donde se puede visualizar el diagrama general deentradas y salidas del procesador monoradar y en color azul los dispositivos ocomunicaciones que se encuentran dentro del alcance de la implementación.

FIGURA 3.2. Diagrama general de entradas y salidas del procesa-dor monoradar implementado.

Las entradas del sistema son los videos de radar primario, secundario y las se-ñales de sincronismo. Las salidas del procesador son los datos de radar enviadospor UDP y las configuraciones seleccionadas por TCP/IP.

El video de radar primario es analógico, por lo que se digitaliza con uno de losconversores analógicos a digital de la placa de desarrollo que tienen conectoresSMA (SubMiniature version A). El resto de las señales de video secundario y desincronismo deben pasar por una tarjeta adaptadora de señales, diseñada paraeste trabajo, antes de ser procesados en la ADC-SoC.


La extracción y procesamiento de datos se realiza en un circuito integrado Cy-clone V SoC. Las entradas de video son de 14 bits de resolución, el resto de lasseñales de radar entran por los pines de propósito general de entradas/salidas.El puerto físico de red es la única salida RJ-45 que viene soldada en la tarjeta.

Luego de la transmisión UDP los mensajes monoradar pueden ser adquiridosy visualizados en consolas que reproducen ASTERIX 34 y 48. En paralelo y sinafectar al procesamiento de datos, todos los parámetros de funcionamiento delprocesador pueden ser configurados por clientes TCP/IP desde una aplicación,también desarrollada para este trabajo.

3.2. Descripción de las funciones implementadas

El desarrollo de las funciones implementadas se presenta en forma ordenada se-gún el desplazamiento de datos de radar. En esta sección se describe en primerlugar la digitalización de señales, que comprende la adaptación de señales de ra-dar y la configuración de los conversores ADC. Luego se describe el procesadormonoradar, comenzando por la presentación de sus partes componentes. A conti-nuación se comenta el funcionamiento del servidor de hora implementado y porúltimo los detalles de la aplicación para configurar remotamente al sistema.

3.2.1. Adaptación de señales de radar

Para digitalizar las señales, durante el transcurso del trabajo final, se utilizó unatarjeta adaptadora desarrollada con anterioridad al inicio de este, a los fines decontar con las señales de radar limitadas a las tensiones de trabajo de la placa dedesarrollo. Esta tarjeta permitió empezar a trabajar con señales reales de radardesde el inicio del proyecto.

Con el cursado de la materia Diseño de Circuitos Impresos se decidió el diseñode la nueva tarjeta adaptadora, que puede observarse en la figura 3.3. Es de doblecapa, está construida de acuerdo con los estándares de fabricación de una empre-sa en particular y los conceptos aprendidos sobre buenas prácticas. La principaldiferencia con la anterior es que cuenta con salidas duplicadas para permitir quepuedan convivir dos equipos E.D.D.R. con el nuevo procesador monoradar im-plementado en este trabajo.

FIGURA 3.3. Tarjeta adaptora de señales de radar1.

3.2. Descripción de las funciones implementadas 29

El diseño de la tarjeta adaptadora se realizó con KiCad, una plataforma de soft-ware libre para el diseño de circuitos electrónicos y su conversión a PCB (PrintedCircuit Board). Se decidió elegir a la empresa Dai Ichi Circuitos S.A. para imprimirla placa. Se tomaron en cuenta las medidas estándar de ancho de pistas y tamañode agujeros recomendados por la empresa.

La nueva placa adaptadora se diseñó a partir de las pruebas realizadas con la an-terior en un radar FPS 113 de la Fuerza Aérea Argentina teniendo en cuenta laoptimización de conectores, componentes y cantidad de entradas y salidas. Partede las mejoras realizadas tuvo en cuenta el rediseño de esquemáticos para de-finir adecuadamente la jerarquía y dividir el circuito en varias hojas mejorandosu comprensión, respetando el sentido de avance de la señales y los niveles lógi-cos. Con respecto al PCB se cambiaron los encapsulados de algunos componentesmejorando la disposición en la placa, se agregaron agujeros de sujeción, áreas decobre y se generó el diseño 3D.

La placa permite contar con las siguientes entradas de señales:

Video analógico de radar primario (X2): si bien no se utiliza en el proyecto,permite adaptar con un circuito pasivo el nivel de tensión de dos entradasde video diferentes, una para cada canal de la ADC-SoC.

Video de radar secundario (X1): permite bajar el nivel de tensión del tren depulsos de preguntas y respuestas a niveles lógicos de trabajo de la FPGA.

Señales de sincronismo (X3): PRF, ACP y ARP.

Las salidas que ofrece la placa en conectores SMA son:

Video analógico de radar primario (X2): dos salidas, una para cada canalconversor analógico a digital de la ADC-SoC, no se utilizan en el proyecto.

Video radar primario digitalizado y filtrado por la ADC-SoC (X2): señal desalida del filtro CFAR de la ADC SoC para la conexión de dos E.D.D.R.

Video de radar secundario y señales de sincronismo (X8): video secunda-rio, PRF, ACP y ARP adaptadas y con salida duplicada, que permiten laconexión de dos E.D.D.R.

La placa tiene pines de entrada/salida que se conectan a:

GPIO ADC-SoC (X6): salida de señales de radar adaptadas para el proce-sador implementado y entrada de video digital CFAR para alimentar dosE.D.D.R.

GPIO EDU-CIAA (X1): salida de ARP adaptada para sincronizar el servidorde hora.

Es necesario destacar que la tarjeta desarrollada permite la operación en paralelodel sistema anterior para realizar las comparaciones entre ambos equipos, peroen un futuro esas salidas no se utilizarán, sólo aquellas que utiliza el procesadormonoradar implementado en la ADC-SoC.

1Imagen tomada del repositorio de la materia Diseño de Circuitos Impresos (CESE)https://github.com/cese-dci/tp-dci–migueledvc.git


3.2.2. Conversión analógico a digital de video primario

Dos conversores analógicos a digital AD9254 en la placa de desarrollo ADC-SoCsirven a los propósitos de convertir el video analógico lineal de un radar primariode vigilancia FPS 113. La tarjeta cuenta a la entrada de los ADC con acoplamientopor transformadores para balancear la entrada de señal y con la posibilidad demodificar la posición de entrada en el devanado primario y a la salida el nivel dereferencia del conversor. En la figura 3.4 se puede observar cómo la señal ingresaa uno de los ADC y se conecta a los pines de la FPGA del Cyclone V SoC.

FIGURA 3.4. Flujo de la señal de video de radar primario que sedigitaliza en los conversores analógico a digital.

De las pruebas realizadas con las cuatro posibilidades se pudo establecer la me-jor configuración. La selección del punto de entrada en el devanado primario serealiza modificando la posición de una resistencia de valor 0 Ohm. La seleccióndel voltaje de referencia para el AD9254 se realiza cambiando de posición un jum-per en la placa ADC-SoC y de esta manera se conforman las cuatro posibilidades.La mejor combinación fue la que permitió la máxima excursión en la tensión deentrada.

El video del radar es siempre positivo y no contiene componente de continua.Sin embargo, si hubiera, el transformador actúa como un filtro pasa altos. Con lasconfiguraciones realizadas se logró que el máximo valor que es posible digitalizar,sin recortar la señal, esté apenas por encima del valor de tensión pico de videodel radar en el punto de salida de los receptores, donde se toma la señal de videoprimario en el radar utilizado.

Se ocupa la señal digitalizada de 14 bits como valor entero no signado y las si-guientes configuraciones generales en el AD9254:

Modo de comunicación serie SPI desactivado.

Modo de salida de datos binario seleccionado.

Estabilizador del ciclo de trabajo desactivado.

Durante el desarrollo de las funciones del procesador de datos radar se verá cómofue posible extraer el dato de máxima amplitud detectada para cada blanco ycomprobar lo explicado acerca de la máxima excursión de tensión.


Con lógica programable y máquinas de estado fue posible implementar un detec-tor de video radar conectado al ADC. Además, el AD9254 tiene una salida digitalllamada OR que permite cambiar su nivel lógico al digitalizar valores fuera derango. Ambas señales son utilizadas por el detector de errores del sistema desa-rrollado para información del técnico y operador.

3.2.3. Bloques constitutivos del sistema procesador

El procesador implementado en la Cyclone V SoC puede dividirse en un com-ponente de lógica programable FPGA y otro de software HPS. Para cada uno deellos se desarrollaron subcomponentes que cumplen con las funciones de la figu-ra 3.5.

FIGURA 3.5. Diagrama en bloques del procesador implementadoen un circuito integrado Cyclone V SoC.

Las señales digitales ingresan al Cyclone V SoC en el caso de la operación conseñales reales de radar. Para los efectos de prueba y simulación se implementó unmódulo simulador que emula las señales digitalizadas. Se establecen dos modosde operación, real o simulado. Además se implementó un modulo generador deblancos que inyecta señales digitales de blancos independientemente del modoreal o simulado.

Las señales digitales de video primario ingresan a un filtro de umbral adaptativodel tipo CFAR, que evalúa la amplitud de la señal antes y después de la celda bajotest. La salida del filtro establece la presencia o no de video de radar primario.De la misma manera, el módulo detector secundario establece la presencia o node la respuesta de una aeronave a la pregunta del radar secundario. El detectorprimario recibe las señales de CFAR y detector secundario, extrae los datos deazimut y rango para ambos, y código y modo para el secundario.


El detector primario implementa rango por rango una máquina de estados quedetecta la presencia de un posible blanco y envía los datos al procesador en elHPS. Las respuestas de radar secundario, en cambio, son enviadas al procesadoruna a una, y es en el HPS donde se realiza la asociación y centrado para generar elblanco secundario. Durante el desarrollo del trabajo se implementó una máquinade estados para el secundario, pero finalmente se tomó la decisión de llevar eseproceso al HPS debido a la flexibilidad que ofrece la programación de software.

El procesamiento de datos en HPS se realiza con un programa desarrollado enC++ que corre en Linux Poky 8.0. El hilo procesador extrae datos de una memoriaFIFO que comparte con la FPGA. En este procesador se realiza la combinación dedatos radar y el empaquetado. Los datos ya procesados se envían a una memoriaFIFO de salida. El transmisor es un hilo que tiene por función transmitir por socketUDP los mensajes ASTERIX 34 y 48.

El trackeador es un proceso que reúne datos de vueltas anteriores, genera la corre-lación, predice el comportamiento y envía las pistas al transmisor. Este compo-nente fue desarrollado por personal de la Fuerza Aérea Argentina y agregado alproyecto. Hasta acá el proceso es continuo y respeta la arquitectura de tubería dedatos.

Por otro lado se desarrolló un sistema de configuración en tiempo real implemen-tado en FPGA. El configurador es un módulo que actúa sobre un sectorizador quealterna 32 sectores de configuración que dependen del rango y azimut, es decir,del barrido continuo del radar. Estos sectores pueden ser reconfigurados en cual-quier momento por el módulo configurador del HPS.

Se desarrolló también un módulo configurador en HPS que se comunica por TC-P/IP con múltiples clientes y, luego de parsear los mensajes, realiza las configura-ciones a todo el sistema, incluyendo los 32 sectores. Se han desarrollado mensajesestandarizados propietarios del proyecto que deben ser codificados y decodifica-dos. Se pueden configurar parámetros generales o particulares de uno o variossectores.

En todo momento funciona el proceso BIT (Built In Test), un detector de erro-res. Este proceso detecta con máquinas de estado la presencia y frecuencia de lasseñales de radar. Actúa en tiempo real sobre LEDS de la placa de desarrollo yenviando mensajes a la memoria FIFO que comparte con los mensajes de radar.A estos datos se suman los mensajes de paso por el norte y cambios de sector.

3.2.4. Simulación de señales de radar

Durante el desarrollo de la implementación de funciones de detección y procesa-miento de datos de radar primario y secundario, fue imprescindible la utilizaciónde un simulador de señales de radar. Aunque en el inicio del proyecto se utili-zaron las señales simuladas de un equipo E.D.D.R., fue necesario desarrollar unsimulador embebido en la misma FPGA que se ocupa para el resto del proce-dador monoradar, con el objetivo de facilitar las pruebas de integración de cadamódulo VHDL, y verificar el diseño de los circuitos digitales programados.

En la figura 3.6 se puede observar el diagrama en bloques del simulador de se-ñales de radar. El funcionamiento se encuentra en el mismo dominio de reloj queel procesador. El sincronismo se hace a partir de uno de los relojes físicos de laplaca que es la entrada de un PLL (Phase Lock Loop), y este último a su vez genera


salidas sincronizadas de frecuencias múltiplos de 2. De esta manera es posibleoriginar trenes de pulsos para obtener:

Sincronismo en rango PRF.

Sincronismo en azimut ACP.

Señal de paso por el norte geográfico ARP.

Video primario de 14 bits de resolución.

Video compuesto de radar secundario, tren de pulsos de interrogación y derespuesta.

FIGURA 3.6. Diagrama en bloques del simulador de señales radar.

Todas las señales dependen del valor de constantes que pueden ser modificadaspara programar el comportamiento de diferentes radares. La modificación de lasconstantes del proyecto puede hacerse en un archivo VHDL que se agrega comobiblioteca, lo que se conoce como archivo paquete o package file del trabajo.

La frecuencia del sincronismo en rango es el reloj del sistema de procesamiento.La frecuencia del sincronismo de azimut está determinada por el valor que puedaalcanzar un contador en el generador de pulsos de azimut ACP. De la mismamanera la frecuencia de la señal de paso por el norte está dada por un contadoren el generador de ARP. Los generadores de sincronismo activan habilitacionesde salida de video.

Los niveles de tensión de video simulado se generan con valores de n bits de re-solución, la misma cantidad que utilice el filtro adaptativo CFAR. En este casotambién se programa una constante resolución de video que parametriza todoslos módulos que correspondan. Por último, la señal de video secundario es lla-mada video compuesto, debido a que en el mismo tren de pulsos se programó lacodificación de interrogaciones y de respuestas. A los fines de este trabajo finalse implementaron interrogaciones en modo 3/A, y como respuesta un código deaeronave conocido.


Aunque un circuito asíncrono permitiría la simulación completa del procesadormonoradar, imitando señales externas, el proceso de aprendizaje del diseño decircuitos en lógica programable ayudó a comprender la importancia de imple-mentar una red síncrona y las dificultades que plantea programar módulos condiferente dominio de reloj. Por estos motivos, el diseño del simulador implemen-tado, así como todo el procesador que funciona en la FPGA, es totalmente sín-crono. El criterio utilizado para el diseño del simulador permitió su uso durantela etapa de desarrollo, y permitirá la comprobación de funcionamiento, de la tar-jeta ADC-SoC y las comunicaciones de red con el sistema de vigilancia y controlde la Fuerza Aérea Argentina.

3.2.5. Sincronización

El trabajo realizado en lógica programable fue diseñado para minimizar proble-mas de tiempos y sincronismo. El sistema toma la señal de uno solo de los relojesfísicos de la placa ADC-SoC conectado a uno de los pines de la FPGA. Se decidióla utilización de PLLs, parte del catálogo gratuito que se encuentra en la bibliote-ca de Intel asociado al software Quartus Prime. Se pueden reconfigurar estos IPs(Intellectual Property) con la herramienta MegaWizard Plug-In Manager, parte delmismo software. A partir de la generación de relojes de sincronismo se diseñarone implementaron en módulos VHDL los siguientes circuitos:

Adquisidores de video que conforman la señal dando salidas sincronizadas.

Adquisidores de señales de sincronismo que conforman las salidas tambiénsincronizadas.

Un subcomponente sincronizador que reúne módulos VHDL para actuarcomo fuente de sincronismo de todo el sistema de procesamiento.

En la figura 3.7 se pueden observar algunas de las funciones más importantes quecumplen los circuitos de sincronismo.

La idea de diseñar un módulo sincronizador surgió a partir de analizar el funcio-namiento de los radares que generalmente tienen un subsistema que cumple estafunción específica. Las entradas son los relojes del sistema y las salidas permitengenerar:

Cuenta de azimut.

Cuenta de rango alineada con el pulso de radar que marca las 0 MN.

Habilitación del ciclo de trabajo del procesador.

Señales de sincronismo de la memoria FIFO de salida.

La cuenta de azimut está dada por la resolución que pueda tener el radar. Elmódulo contador de azimut utiliza el reloj de rango porque la conformación dela señal ACP se hace con ese mismo reloj.

La cuenta de rango debe tener una resolución igual o menor a la resolución enrango del radar y a su ciclo de trabajo, teniendo en cuenta que incrementa el ta-maño de la memoria que se necesita para los detectores y que la implementaciónaumenta en potencias enteras de 2.

La señal PRF de entrada se encuentra adelantada con respecto a la señal que mar-ca las 0 MN, es decir, la posición de la estación de radar. Para que el sistema


FIGURA 3.7. Circuitos de sincronización del sistema de procesa-miento con lógica programable del procesador monoradar.

utilice la cuenta correcta de rango el módulo sincronizador genera la habilitacióndel procesador un instante después de la cuenta de 0 millas y hasta el alcancemáximo de los radares, con el fin de evitar detecciones inválidas. Se puede selec-cionar la salida de una cadena de flip flop tipo D, y así alinear las detecciones deambos radares.

La sincronización del funcionamiento de la memoria FIFO implementada, queamortigua la transferencia de datos hacia el HPS, también se genera en el sub-compoenente sincronizador. Por ese motivo se requiere la señal de salida de losdetectores, que indica la presencia de un dato para la escritura en memoria, ypor otra parte sincroniza la solicitud de lectura que viene del HPS. Las señales desincronismo de FIFO son:

Reloj de lectura

Reloj de escritura

Habilitación de lectura

Habilitación de escritura

3.2.6. Filtro CFAR

Se ha implementado un filtro de umbral adaptativo del tipo CFAR, previo a la de-tección de video primario, que utiliza la salida de 14 bits del conversor analógicoa digital o del simulador primario, promedia las celdas anteriores y posteriorespara evaluar la celda bajo test, para así establecer un nivel de comparación. Lasalida del filtro determina la posibilidad de existencia de un blanco.


El subcomponente CFAR es una cadena de desplazamiento cuyo diagrama enbloques puede observarse en la figura 3.8. Todo el circuito CFAR, al igual que elresto del trabajo realizado en FPGA, puede parametrizarse, permitiendo modifi-car rápidamente, por ejemplo, el número de bits de resolución o la cantidad deceldas en los bloques de la figura.

En primer lugar se encuentran las celdas de retardo. Dependiendo del pulso desincronización en rango utilizado por el radar primario y secundario, puede sernecesario agregar celdas de retardo para alinear ambos detectores y posibilitar lacombinación.

En segundo lugar y en forma simétrica con respecto a la celda bajo test, se en-cuentran los bloques de celdas de referencia. Estas celdas desplazan el dato den bits mientras cada bloque suma en forma parcial las celdas que se desplazan.De esta manera se conforman dos circuitos de suma que dan salida a un módulocomparador. La implementación permite la selección de tres promedios:

Promedio de todas las celdas de referencia

Promedio del bloque de celdas con más alto valor

Promedio del bloque de celdas con valor más bajo

FIGURA 3.8. Diagrama en bloques del filtro de umbral adaptativoCFAR implementado. La entrada son los n bits de resolución delvideo radar primario, y la salida la comparación de la celda bajo

test con el promedio del entorno multiplicado por un factor k.

Continuo a la celda bajo test se posicionan las celdas de guarda, que son las su-ficientes como para que la forma de onda de la señal a evaluar no influya en elpromedio del entorno. El comparador selecciona alguna de las opciones de pro-medio y multiplica por un factor que influye directamente en la probabilidad dedetección. El problema de seleccionar un factor bajo como coeficiente es el au-mento de las falsas alarmas.

El diseño del circuito se realizó de forma tal que en ningún momento se pierderesolución. Es decir que el umbral multiplicado mantiene la resolución de 14 bits


digitalizados. Se implementó una manera de ingresar el coeficiente multiplicadordesde el HPS y otra para guardar el valor en diferentes sectores que dependendel rango y del azimut. Además se encuentra en etapa de evaluación una ver-sión que permite automatizar el valor teniendo en cuenta la cantidad de blancosdetectados, una forma de mantener la tasa de falsas alarmas.

El video primario de radar digitalizado pasa por un transformador, lo que originauna salida entera no signada de 14 bits con promedio alrededor de 213, es decir,8192. Como el video de radar es siempre positivo se implementó un circuito quesolo multiplica por valores válidos. Multiplicar por valores menores a 1 o muycercanos a ese número da como resultado una tasa no válida de falsas alarmasporque el promedio gira en torno a la mitad de la excursión del ADC. Multiplicarpor números mayores a 2 lleva el promedio a valores superiores a la máximaexcursión. Por lo tanto se ingresan 214 valores de multiplicador, o lo que es lomismo, 16383 valores equivalentes a multiplicar entre 1 y 2. Así se mantiene laresolución. La salida del filtro CFAR es la presencia o no de una señal reflejada enun posible blanco.

3.2.7. Detector de ecos radar secundario

A diferencia del radar primario, no se necesita un filtro para la señal de video se-cundario debido a que el IFF demodula la respuesta de las aeronaves en un trende pulsos que debe respetar la forma estándar. A la salida de la tarjeta adaptadorade señales, ingresa al Cyclone V SoC un video digital adaptado. Este video pue-de ser compuesto o no. La implementación que se presenta en este trabajo finalutiliza el primero de los dos, por lo que sólo se usa un pin conector para adquiririnterrogación y respuesta. Por lo tanto, se desarrolló un módulo VHDL llamadodetector secundario que recibe un tren de pulsos y cuando identifica la codifica-ción de una interrogación o una respuesta habilita la salida de modo y presenciade respuesta, respectivamente.

En la figura 3.9 se puede observar el diagrama en bloques del detector secundarioimplementado. El ancho de los pulsos que codifican preguntas y respuestas seencuentra parametrizado con respecto al reloj utilizado. Una cadena de FFD (FlipFlop tipo D) permite hacer el corrimiento de los pulsos entrantes. Además seagregan celdas extra para la alineación que permita combinación de primario ysecundario.

La interrogación del radar se decodifica emisión a emisión y el detector secun-dario habilita la detección de respuestas sólo si se habilitó un modo. Los modosposibles pueden ser modo 1, modo 2, modo 3/A o modo C. La detección de res-puestas de radar secundario se realiza pulso a pulso de las cuentas de rango. Esdiferente la detección de ecos de radar primario. Durante el desarrollo del trabajofinal se pensó en utilizar una máquina de estados para generar el dato de blan-co secundario en FPGA, pero finalmente se decidió implementar en software laasociación de respuestas.

A partir de la detección de una respuesta, el dato que está almacenado en la ca-dena de FFD contiene el código del modo correspondiente. El azimut y el rangose extraen de la cuenta para cada uno de ellos que sale del sincronizador, perose tomó la decisión de llevar el manejo de la carga de datos a una máquina deestados del detector primario que se presenta en la siguiente sección. Por un lado


FIGURA 3.9. Diagrama en bloques del detector secundario imple-mentado en lenguaje VHDL. Una cadena de flip flops agrega cel-das para alineación y guarda el tren de pulsos que permite identi-

ficar interrogaciones y respuestas.

se simplifica la implementación, y por otro deja la posibilidad a futuro de realizarla combinación en FPGA si otra arquitectura de hardware así lo requiere.

3.2.8. Detector primario

En esta instancia del trabajo, a partir de la salida del fitro CFAR, es decir, la pre-sencia de señal de radar primario, y la presencia de respuesta de radar secunda-rio, se diseñó un detector ventana. La diferencia fundamental entre un detectorventana típico con el implementado en este trabajo final es que, generalmente,los primeros emplean un número fijo de ancho de palabra, donde la palabra sonlas n celdas anteriores para una cuenta de rango determinada. En cambio en estedetector se empleó una máquina de estados finita FSM, del ingles Finite State Ma-chine por cada cuenta de rango, utilizando una memoria RAM para guardar losdatos y estados.

El diagrama de la implementación del detector se puede observar en la figura3.10. La máquina de estados parte del estado inicial y avanza al estado creciendocada vez que una señal de video superó el umbral CFAR. En el caso de que parala siguiente emisión e igual cuenta de rango no se supere el umbral, una cuentaempieza a crecer una unidad por emisión hasta llegar al máximo de tolerancia.Hay un estado por cada ausencia, si se supera la tolerancia se pasa al estadocomparando (C) y el ciclo vuelve a comenzar.

La máquina de estados finita permite extraer un blanco de radar primario en fun-ción de la detección de sucesivas presencias de señal para una misma cuenta derango, principio de funcionamiento de un detector ventana deslizante. El detectortiene por función cargar en una memoria FIFO los datos de radar primario cuan-do la máquina de estados se encuentre en el estado de comparación. Si el valorde cuenta de ecos es mayor al coeficiente configurado se habilita una señal parala carga de rango y azimut, que son los datos de radar primario de 2 dimensiones(2D) como el FPS 113.


FIGURA 3.10. Diagrama en bloques del detector primario. Se im-plementó una máquina de estados finita para cada cuenta de ran-go. Los datos de cada estado se almacenan en memoria RAM has-ta la próxima emisión y los datos radar de salida en una FIFO. Elfiltro CFAR es la entrada para detectar primario y el detector se-

cundario funciona rango a rango.

El módulo detector primario, en cada uno de los estados, habilita la misma señalde carga si hay una detección de radar secundario. En este caso los datos de modoy código también se cargan con valores válidos.

La máquina de estados mantiene actualizado el dato de amplitud de tensión di-gitalizado de video primario y almacena el valor más alto para guardar en me-moria FIFO una vez que se habilite la carga. De esta manera se puede comprobarel nivel de la señal analógica de video radar primario sin tener que conectar unosciloscopio. Además se puede realizar procesamiento para filtrar señales débi-les, o completar los campos ASTERIX correspondientes a la potencia de señal. Sedecidió transferir al HPS en cada habilitación de carga de FIFO:

Cuenta de rango.

Cuenta de azimut.

Bandera dato primario.

Bandera dato secundario.

Bandera dato paso por el norte.

Bandera dato cambio de sector.

Dato amplitud de tensión de video primario.


Dato código de aeronave.

Dato modo de interrogación.

Número de ecos por cada detección de la máquina de estados de radar pri-mario.

El almacenamiento de los datos de radar en una memoria FIFO permite continuarsu procesamiento en el HPS, sin necesidad de hacerlo en tiempo real, facilitandola implementación de las funciones de asociación, combinación, empaquetado,control y transmisión.

3.2.9. Configurador de sectores

El presente trabajo final presenta una implementación de configuración sectori-zada de los parámetros de funcionamiento de los circuitos implementados en laFPGA. Los sectores cambian en función del rango y azimut, es decir, del barridoque hace el haz de la antena radar.

A partir de las pruebas realizadas y de la consulta a personal operativo de la Fuer-za Aérea Argentina, se implementaron 32 sectores, de los cuales 8 son azimutalesy 4 radiales. En la figura 3.11 se puede ver la relación de aspecto entre los sectoresy el máximo alcance de un radar como el FPS 113.

FIGURA 3.11. Relación de aspecto entre los 32 sectores de configu-ración de parámetros de funcionamiento que se implementaron,con respecto al límite de la cobertura radar en línea punteada. Elgiro de antena se marca con una flecha determinando el azimut.

El barrido en rango está en función del tiempo.

Como el clutter se forma generalmente en sectores cercanos a la antena de radar,la implementación para un radar FPS 113 emplea tres sectores radiales hasta las50 millas y un sector radial desde las 50 hasta el límite de la cobertura, totalizandolos cuatro sectores radiales. De todas maneras los límites de sector se encuentranparametrizados con valores de constantes en un paquete (package).

Las configuraciones implementadas permiten modificar:

Coeficiente multiplicador CFAR.


Tipo de algoritmo CFAR.

Valor de umbral de comparación detector primario.

Valor de tolerancia máquina de estados finita detector primario.

Selección de modo sectorizado o no sectorizado.

Selección de video canal ADC A o canal ADC B.

Selección de número de sector a configurar.

Selección de modo manual o automático para manejar el multiplicador CFAR.

Habilitación carga de configuración.

3.2.10. Detector de errores

Este trabajo contempla la detección de errores, más comúnmente conocida comoBIT (Built in Test). Este tipo de arquitecturas integra en el hardware del equipocircuitos para detectar errores. Muchas veces tienen como propósito evitar que secontinúe con un procedimiento, por eso se considera también como elementos decontrol del sistema.

Se diseñó e implementó un circuito detector de errores por cada señal radar pri-mario a adquirir:

Detector ausencia de video radar primario.

Detector pulsos ACP con valores de frecuencia fuera de tolerancia.

Detector pulsos ARP con valores de frecuencia fuera de tolerancia.

Detector pulsos PRF con valores de frecuencia fuera de tolerancia.

Los circuitos se implementaron como máquinas de estados finitos. Para el casodel video primario el circuito verifica que, por cada ciclo de trabajo del radar,exista por lo menos un dato de video digitalizado que sobrepase el umbral es-tablecido. El valor se configura desde el HPS al iniciar la aplicación procesadormonoradar. La configuración se levanta desde un archivo .json que contiene todaslas variables que maneja el procesador. Para el caso de las señales de sincronismo,de rango y azimut, se implementaron máquinas de estado, para verificar que lascuentas se reinicien dentro de márgenes de tiempo establecidos, pero al mismotiempo un valor de cuenta suficiente como para comprobar que la frecuencia delas señales de entrada es la correcta.

Los relojes de cada subcompoenente de hardware en la FPGA siempre funcionan,no se deshabilitan, para aumentar la confiabilidad del circuito implementado. Noes un requisito el consumo de energía. En la versión 2.0.0, los detectores de errorse conectan a un módulo .vhd llamado built_in_test, que es el único que manejalas salidas a LEDs, y envía un mensaje de 32 bits al HPS. En el programa BIT seconfigura que señales conectar a los LEDs. La palabra de 32 bits contiene infor-mación sobre el estado del sistema y se carga permanentemente en una memoriaFIFO, junto a los datos de radar.

El programa procesador que corre en el HPS y envía a transmitir los datos deradar ya empaquetados tiene la responsabilidad de evaluar el estado del disposi-tivo y buscar:


Error en las señales de entrada.

Número de blancos por encima del valor de tolerancia.

Los eventos que pueden encender LEDs son:

Error en video primario, dos canales.

Error en ACP.

Error en ARP.

Error en PRF.

Paso por el norte.

Detección de eco primario.

Detección de respuesta secundario.

Detección entrada ADC fuera de rango, dos canales.

3.2.11. Comunicación FPGA-HPS

Sin dudas, una de las ventajas de utilizar tecnología SoC-FPGA para este tipode aplicaciones es la velocidad y flexibilidad para armar las comunicaciones dedatos y de control entre la parte de FPGA y el HPS. Para implementar este puentese tomaron las siguientes decisiones:

Utilizar el lenguaje VHDL para la implementación de los circuitos digitalesen FPGA.

Establecer una comunicación bidireccional de 32 bits.

Utilizar el puente (Lightweigth HPS-to-FPGA AXI).

Utilizar el mismo reloj físico de sincronismo que el PLL del procesador ra-dar en la FPGA.

Usar el sistema operativo Linux Yocto Pocket 8.0.

El primer paso para implementar la comunicación fue el diseño del hardwareque se programa con la herramienta Plattform Designer de Intel Altera. Todos loscomponentes utilizados son parte de la biblioteca del software, pero se empezóa trabajar a partir de los archivos GHRD (Golden Hardware Reference Design) queofrece la empresa Terasic para el producto ADC-SoC[9].

Es necesario destacar que el diseño de la comunicación no implicó ningún tipode modificación del sistema Linux. Esta decisión se tomó en primer lugar parafacilitar el desarrollo de actualizaciones y en segundo lugar para no dilatar laplanificación del trabajo debido a la extensión que ya supone la implementacióndel procesador monoradar.

A los fines de minimizar la carga de trabajo, no perder flexibilidad y evitar erroresse agregaron periféricos PIO (Parallel Input/Output) para cada uno de los canalesde comunicación de 32 bits, y se tuvieron en consideración los siguientes criterios:

Cada puerto PIO debe tener 32 bits, no menos.

Las direcciones de los puertos PIO deben ir ordenadas según su uso dentrodel procesador y siguiendo la misma convención de nombres que en FPGA.


Cada puerto PIO debe dejar libre los 32 bits siguientes en su dirección, paraque las direcciones avancen de a 64 bits.

Para mantener Linux sin modificaciones sólo se agrega al proyecto el archi-vo de cabecera con los macros de direcciones.

Una vez finalizada la carga de componentes, se compiló con la herramienta Platt-form Designer para generar la programación del hardware. Con la herramientaSoC-EDS (Intel SoC FPGA Embedded Development Suite) se modificó la cabecerahps_0.h, desde la terminal del programa y con un script del GHRD. Este archivodebe agregarse al firmware del proyecto antes de la compilación. Contiene losmacros para las siguientes comunicaciones en el HPS con la FPGA dentro de lasdirecciones habilitadas para el puente Lightweight:

Entrada datos FIFO

Entrada Banderas FIFO

Salida Reset FIFO

Salida de habilitación lectura FIFO

Salida de datos de configuración

Salida de habilitación de configuraciones

Con el archivo hps_0.h se implementó una clase Puente en HPS que integra to-das las funciones que permiten la comunicación de los procesos con la FPGA. Enla figura 3.12 se puede observar el diagrama de la clase. La transferencia de da-tos se hace accediendo a los punteros correspondientes a cada palabra de datos,configuración, habilitación o bandera.

FIGURA 3.12. Diagrama de la clase Puente en HPS que integratodas las funciones que permiten la comunicación de los procesos

con la FPGA.

3.2.12. Procesamiento y combinación de datos radar

El desarrollo de la clase Procesador es el punto central de este proyecto, debido aque en este proceso se realiza la combinación entre los datos de radar primario ysecundario, generando así los mensajes monoradar. Hasta la entrada de la claseProcesador los métodos y circuitos implementados facilitan la información y lasconfiguraciones. El diagrama se puede ver en la figura 3.13.


FIGURA 3.13. Diagrama de la clase Procesador, que permite la ex-tracción y el procesamiento de los datos de radar. Estos, luego de

empaquetarse, se despachan al hilo que transmite.

En la figura 3.14 se puede observar el diagrama de actividad del método estáticorunP, de la clase Procesador, un hilo que ejecuta las siguientes tareas:

Extracción de datos de radar de la memoria FIFO compartida con la FPGA.

Control de errores.

Asociación de respuestas de radar secundario.

Combinación de datos de radar primario y secundario.

Actualización de la hora UTC con variables globales.

Empaquetado ASTERIX.

Transmisión a una memoria FIFO compartida con clase Transmisor.

La clase Procesador recibe por referencia la instancia de Puente y así puede acce-der a la memoria FIFO que se comparte con la FPGA. La extracción de datos sehace realizando consultas constantes, sin uso de interrupciones, es decir, hacien-do (Polling). Al inicio del programa se resetea la memoria FIFO para evitar datoserróneos debido a que la FPGA comienza a funcionar cuando se alimenta la placaADC-SoC.

Una vez corriendo, runP trabaja buscando datos cuando las banderas de memo-ria permanezcan en el estado intermedio (HALF) entre vacío (EMPTY) y lleno(FULL). Los datos recibidos pueden corresponder a:

Datos de blancos radar primario y/o respuestas radar secundario.

Marca de paso por el norte.

Marca de sector, 32 por cada vuelta.

Dato de error.


FIGURA 3.14. Diagrama de actividad de Procesador::runP, métodoestático que corre en el HPS.

Los datos de radar pueden ser de radar primario y/o secundario. Para el casode la extracción de ambos tipos se corre el método de procesamiento primario yluego el secundario. Los datos de blancos y respuestas se procesan para:

Validar la información.

Asociar respuestas de radar secundario.

Buscar en un entorno datos de radar para combinar.

Calcular el centro del blanco.

Cuando llega de la memoria FIFO un dato de cambio de sector, marca que hanpasado alrededor de 11 grados de azimut. Se despachan los blancos que ya nopodrían ser correlacionados con un nuevo dato y se empaquetan según el proto-colo ASTERIX 34 o 48. De la misma manera, cuando llega una marca de paso porel norte se actualiza la hora UTC y el mensaje correspondiente de ASTERIX 34. Lahora de cada blanco se calcula sumando un tiempo a partir del dato de azimut.

Se ha implementado un mecanismo que permite cargar en una palabra de la me-moria FIFO un dato de 32 bits de error generado en la FPGA con máquinas de


estado que monitorean las señales de radar para detectar desconexiones o pará-metros no inválidos. Esto permite mantener actualizado el sistema de control delprocesador monoradar para evitar transmitir mensajes erróneos.

El método que tiene como función empaquetar deposita los datos radar ya pro-cesados en una memoria fifo que se comparte con el hilo Transmisor.

3.2.13. Configuración remota

En este trabajo se desarrolló un sistema de control y configuración remoto quese enlaza con el procesador monoradar mediante una comunicación TCP/IP. Elsistema de configuración remoto funciona de acuerdo con el esquema de la figura3.15.

FIGURA 3.15. Diagrama del sistema de configuración remota im-plementado para el procesador monoradar.

Se decidió embeber en el procesador un servidor que atienda múltiples clientesremotos utilizando una clase específica llamada SocketService. El diagrama de laclase puede observarse en la figura 3.16.

El método SocketService::runServerTCP corre en el hilo principal del proceso pro-cesadorMonoradar. Recibe por referencia las instancias de las clases JsonConfig yRadnmea. De esta manera se parsean y guardan las configuraciones.

En la figura 3.18 se puede observar el diagrama de clase de Radnmea. La ideade utilizar una biblioteca para parsear las configuraciones, surgió del trabajo conmensajes GPS para obtener la hora del procesador monoradar. Se diseñó Radn-mea a partir de una biblioteca llamada"minmea, a lightweight GPS NMEA 0183


FIGURA 3.16. Diagrama de la clase SocketService, que provee alprocesador monoradar un servidor TCP/IP para atender clientes

remotos que controlan y configuran el equipo.

parser library"[10]. El desarrollo de mensajes propietarios del proyecto provee se-guridad a la comunicación, y permite codificar y decodificar mensajes de controly configuración, aumentando la fiabilidad.

FIGURA 3.17. Diagrama de la clase JsonConfig, que facilita el ma-nejo de las configuraciones del procesador monoradar. Esta clasepermite levantar al inicio la configuración y guardar en memoria

no volátil las nuevas, antes de ejecutar el cambio.

Para el manejo de las configuraciones se decidió la utilización del protocolo json[11].Luego de un análisis de las bibliotecas disponibles para C++ de eligió la desarro-llada por Niels Lohmann[12], "JSON for Modern C++". El diagrama para esta clasepuede observarse en la figura 3.17.

La clase Radnmea y la clase JsonConfig reciben por referencia la instancia dePuente. Así, junto a SocketService se envían, reciben y parsean los siguientes men-sajes:

Mensajes de configuración del procesador HPS y variables globales del pro-yecto en FPGA.

Mensajes de configuración de todos los sectores al mismo tiempo.

Mensajes de configuración de un sector en particular.


FIGURA 3.18. Diagrama de la clase Radnmea. De forma similara los mensajes de GPS, se usa una codificación y decodificaciónde mensajes de control y configuraciones que proveen seguridaden la comunicación del procesador monoradar con aplicaciones

remotas.

Mensaje de configuración de un anillo en particular.

Mensaje de solicitud de la configuración actual.

Mensaje de control.

3.2.14. Servidor de hora UTC

La transmisión de mensajes monoradar exige un campo de hora UTC. Para im-plementar el empaquetado ASTERIX durante el proyecto se extrajo el dato dehora del sistema Linux donde corre el procesador. En forma paralela se imple-mentó un servidor de hora GPS con un dispositivo EDU-CIAA. El GPS elegidoes que que trae el poncho que para tal fin fue desarrollado por Iván Sierra[13]. Esnecesario aclarar que si bien se realizaron pruebas de operación, el servidor aúnno fue incorporado a la versión final del prototipo.

Debido al alto costo de los equipos servidores NTP (Network Time Protocol Server)de uso en radar, que pueden rondar los 20.000 dólares, se decidió la implementa-ción de un equipo sencillo pero capaz de entregar un valor de hora que permitagenerar los valores para cada blanco detectado. La señal de paso por el norte geo-gráfico permite sincronizar el valor más recientemente adquirido. El protocoloNMEA 0183 es una especificación utilizada por receptores GPS.

El servidor se implementó en una placa de desarrollo EDU-CIAA que recibe datosdel poncho GPS por UART. La versión presentada no utiliza sistema operativo.La recepción de los datos se realiza en tiempo de interrupciones hasta obteneruna sentencia completa, y se inicia un timer que debe avanzar hasta la deteccióndel paso por el norte, también detectado por una interrupción.


Posterior a la recepción se realiza el parseo de los datos y la extracción de la horaUTC quedando a la espera de la comunicación con el procesador de datos radar.Finalmente el procesador del HPS es quien actualiza el valor para la tarea deempaquetado ASTERIX.

Se utilizaron máquinas de estado en tiempo de interrupciones para la recepciónUART del firmware y tecnicas TDD con la herramienta ceedling (unity + cmock)para el desarrollo.

51

Capítulo 4

Resultados y ensayos

En este capítulo se comentan los resultados obtenidos y se presentan las estrate-gias utilizadas para comprobar el funcionamiento unitario de cada uno los com-ponentes. Finalmente se detallan los pasos realizados en la integración de los di-ferentes módulos.

4.1. Resultados obtenidos

Se logró la implementación de un prototipo operativo de procesador monoradar,que permite entregar al sistema de vigilancia y control del espacio aéreo de laFuerza Aérea Argentina datos de radar primario, secundario y combinado, a par-tir de las señales analógicas de una estación de radar. El sistema implementado hasuperado las pruebas operativas realizadas por personal operador de radar. Estasse han efectuado contrastando los resultados obtenidos con los de un ExtractorProcesador de Datos de Radar (E.D.D.R.) preexistente.

El sistema desarrollado es capaz de:

Digitalizar las señales de video lineal de radar primario en dos canales con-versores analógico a digital diferentes.

Adaptar y digitalizar las señales de video radar secundario y las demásseñales de sincronismo radar.

Simular video digital de radar primario, secundario y señales de sincronis-mo para evaluar el funcionamiento del procesador, transmisión de mensajesde radar, configuraciones y las comunicaciones con otros equipos.

Filtrar con técnicas CFAR las señales de radar primario seleccionando múl-tiples configuraciones en tiempo real.

Detectar blancos de radar primario y secundario en medio clutter.

Asociar respuestas de radar secundario y combinarlas con los blancos de-tectados de radar primario.

Permitir configuraciones remotas de sistema, configuración de parámetrosde funcionamiento de 32 sectores diferentes que trabajan en tiempo real,más uno para la operación no sectorizada.

Detectar en tiempo real errores por ausencia de las señales de radar o valo-res fuera de rango.

52 Capítulo 4. Resultados y ensayos

Empaquetar y transmitir mensajes ASTERIX 34 y 48 con hora UTC actuali-zada por GPS.

Permitir la integración de un proceso trackeador.

4.1.1. Recursos utilizados

El sistema desarrollado en este trabajo para la Fuerza Aérea Argentina incluye elsiguiente material electrónico:

Nueva placa adaptadora de señales.

Procesador implementado en una tarjeta de desarrollo ADC-SoC.

Servidor de hora implementado en una EDU-CIAA con poncho GPS.

Programa configurador como cliente TCP/IP del procesador.

El procesador implementado en la ADC-SoC requirió desarrollo en lógica progra-mable FPGA. La configuración general del dispositivo se realizó según el ejemploGHRD (Golden Hardware Reference Desing) que dispone Terasic para descargar. Lacompilación alcanzó a 49 archivos de extensión .vhd desarrollados para este tra-bajo, incluyendo las RAMs. Si se suman a los archivos de configuración del siste-ma HPS, y los generados con la herramienta gráfica MegaWizard Plug-In Manager(PLLs y FIFO), da el total de 237 archivos compilados con Quartus Prime 18.1.0Lite Edition.

La implementación de un procesador monoradar en una tarjeta de desarrolloADC-SoC de la empresa Terasic utilizó, para la versión 2.0.0., revisión a que hacereferencia este trabajo final, los recursos de hardware que se observan en la tabla4.1. Es importante conocer el nivel de utilización de los recursos del SoC-FPGA,porque permite extraer conclusiones.

TABLA 4.1. Recursos de lógica programable utilizados en el pro-cesador monoradar

Recurso Total Utilizado Porcentaje

ALMs 15.880 7.396 47 %Registros de lógica dedicados 31.760 13.772 47 %Pines 314 216 69 %Bits bloques de memoria 2.764.800 794.077 29 %PLLs 5 1 20 %DLLs 4 1 25 %Bloques DSP 84 2 2 %

Se puede observar la utilización de 7.396 ALMs (Adaptive Logic Modules). Estenúmero no es el espacio ocupado por el trazado final, sino que surge de restar lasALMs que podrían ser utilizadas en caso de que el diseño crezca, haciendo másdenso el circuito. En realidad se utilizó un 59 % del total de ALMs. Si se busca enel informe Fitter Report, se puede observar que se han utilizado 1334 LABs (LogicArray Blocks) de un total de 1588, es decir, un 84 %.

Algo similar sucede con los recursos de memoria. El porcentaje utilizado de losbits totales es de 29 %. Debido a la implementación se utilizó un 40 %. La memoria

4.1. Resultados obtenidos 53

en uso corresponde solamente a bloques M10K, exactamente 108 de 270. Esto esresultado de opciones de compilación automáticas.

De estos valores, un porcentaje corresponde a cada una de las funciones entida-des principales que pueden verse en la tabla 4.2. No se desglosa la informaciónen entidades de menor nivel. Se muestra en este caso el total de recursos requeri-dos, no los implementados, cuyo valor es mayor. En el primer renglón se puedeobservar el total, debido a que el Top Level Design es la entidad de mayor nivel.

TABLA 4.2. recursos de lógica programable utilizados por entidad

Entidad ALMs Registros Bits bloquesde lógica de memoria

dedicados

Top Level Design (total) 7.395,5 13.546 794.077Soc system 4.670,8 6.538 526.336CFAR a 845,2 2.300 336CFAR b 830,5 2.330 0Configurador 445,0 1.409 0Procesador 221,6 445 267.405Detector de errores 169,2 190 0Punta de prueba 100,5 113 0Simulador 42,2 63 0Anti rebote 25,3 32 0Reset HPS 14,5 21 0Reset debug 11,5 37 0Adquisición de video 6,3 56 0Cold reset 3,3 8 0Warm reset 2,0 4 0PLL 0 0 0

Un porcentaje importante de los recursos es ocupado por el soc_system. El filtroadaptativo CFAR ocupa el segundo lugar en el uso de recursos combinacionalesy suma dos instancias, una para cada ADC. Los dos bloques DSP de la tabla 4.1se utilizan para multiplicar. El procesador implementado incluye principalmenteal sincronizador y a los detectores primario y secundario, ocupa el segundo lugaren el uso de memoria. Lo último se debe a que agrupa las memorias RAM y FIFO.La memoria RAM ocupa el mayor porcentaje de ambos; de los 267.405 bits quenecesita el procesador, 253.952 son para la la entidad dual_port_ram.

Por otro lado, la implementación de un procesador monoradar en una tarjeta dedesarrollo ADC-SoC requirió el desarrollo de software que corre en Linux. En latabla 4.3 se muestran valores de porcentaje de uso de recursos del procesador HPSpara situaciones diferentes. Se configuró el sistema para elevar la tasa de falsasalarmas y observar cómo sube el uso de procesador cuando aumentan la canti-dad de blancos transmitidos por vuelta de antena. El tamaño de memoria virtualque usa el procesador monaradar se mantiene contante. En la primera columnase puede ver el porcentaje de CPU total libre. En las columnas 2 a 4 se muestrael consumo de CPU y el tamaño de memoria virtual en valores promedios apro-ximados pero sólo para el procesador monoradar. La memoria se mantiene en elmismo valor. Los valores salen de utilizar el comando # top desde una comunica-ción SSH con la placa.


TABLA 4.3. Primera columna se refiere al porcentaje libre (IDLE)de CPU total. Las últimas tres columnas se refieren al programaprocesador monoradar (PM) que corre en el HPS: memoria virtualutilizada, porcentaje de memoria virtual utilizada y porcentaje de

CPU utilizado.

Blancos por vuelta %CPU(IDLE) VSZ(PM) %VSZ(PM) %CPU(PM)

40 98 % 40.780 4 % 1 %300 97 % 40.780 4 % 2 %1000 93 % 40.780 4 % 4 %2500 91 % 40.780 4 % 5 %3500 88 % 40.780 4 % 6 %4096 86 % 40.780 4 % 6 %

Se puede ver que el sistema permanece estable y en porcentajes bajos de uso de losrecursos. Esto se debe a que el procesador está diseñado para descartar blancos eir al modo sleep cuando aumenta la tasa de datos que ingresan a la FIFO. Sólo sepermite procesar 4096 blancos por vuelta de antena. Si se supera esa cantidad elHPS no se ve afectado, y el desempeño continúa como en la última fila de la tabla4.3.

4.1.2. Comportamiento operativo

El procesador implementado cumple la funcionalidad esperada. Ha pasado satis-factoriamente las pruebas realizadas por personal operador de radar de la FuerzaAérea Argentina. El comportamiento operativo fue contrastado con otro equiposimilar preexistente llamado E.D.D.R. Se ha comprobado su funcionamiento enclutter y con señales de un radar primario FPS 113 y otro secundario TPX 42.

El equipo desarrollado ha comprobado la fiabilidad de operación. Se mantieneoperando sin fallas e ininterrumpidamente, con excepción de las veces que seha reprogramado por actualizaciones. El procesador se ha sometido a diferentesconfiguraciones que incrementaron la cantidad de datos de salida hasta valoresfuera de rango de las consolas operativas, que por arriba de un número deter-minado de blancos eliminan al resto de los que ingresan, y se ha mantenido enfuncionamiento sin presentar problemas.

La usabilidad es una característica lograda, en parte, gracias a que el desarrollodel sistema fue realizado con el asesoramiento de los futuros usuarios. El hard-ware casi no requiere capacitación, debido a la arquitectura de la tecnología SoC-FPGA. El comportamiento del procesador se programa con las configuracionesremotas desde una computadora que corre una aplicación.

El uso de la aplicación es intuitivo y requiere poca instrucción. Debido a quesiempre es posible que el operador coloque valores extremos permitidos o realicesaltos en el valor de las constantes que perjudiquen la operación, se diseñó elsoftware con un límite en la cantidad de plots por sector. Luego de hacer pruebascon valores límites, se comprobó que el sistema es tolerante al máximo númerode plots por vuelta permitidos.

El proyecto entregado a la Fuerza Aérea Argentina se encuentra totalmente ver-sionado con la herramienta git. Se generó la documentación correspondiente a

4.2. Ensayos 55

cada módulo y se programó la totalidad del proyecto utilizando buenas prácticasque cada lenguaje exige.

El sistema de procesamiento y de configuración es portable a otras plataformas dehardware. Puede ser utilizado en otros sistemas de radar con pocos cambios en suprogramación. El componente FPGA se programó con VHDL y usando un paque-te de constantes que parametriza su funcionamiento y tamaño. El componente desoftware se programó en C++ sobre Linux. Este último no utiliza interrupcionesni timers, tampoco drivers.

4.2. Ensayos

El desarrollo de los ensayos para comprobar el funcionamiento del procesadormonoradar sigue el flujo de las señales y datos de radar, debido a que es el mismodel diseño e implementación y surge naturalmente de la arquitectura tipo pipeline.En la figura 4.1 se pueden observar algunos de los ensayos más importantes y elorden necesario al inicio del proyecto. El color de las flechas se va oscureciendosegún el avance.

FIGURA 4.1. Esquema ordenado de ensayos procesador monora-dar.

La comprobación de funcionamiento de los primeros módulos se facilitó por con-tar con la programación del E.D.D.R., lo que permitió en un principio llegar a unprototipo rápidamente. A partir de ese momento, con el avance del nuevo diseño,se hizo indispensable el desarrollo del simulador de señales de radar.


Al momento de modificar una parte del circuito o desarrollar una nueva se tuvoen cuenta de mantener el resto en una versión probada. A esto contribuyó positi-vamente usar un estricto control de versiones, sobre todo porque el diseño tuvoidas y vueltas.

4.2.1. Ensayos en FPGA

Para cada uno de los módulos de lógica programable VHDL se desarrolló un testbench. Las simulaciones se realizaron con la herramienta ModelSim-Altera. Lasventajas del diseño síncrono permitieron comprobar el funcionamiento de cadacomponente por separado y la integración de algunos de esta manera.

Se realizaron pruebas unitarias, de integración y operativas, que incluyeron prue-bas funcionales y de rendimiento. En la figura 4.2 se observa un diagrama de lasherramientas utilizadas para probar el funcionamiento del procesador monora-dar.

FIGURA 4.2. Diagrama de las herramientas utilizadas para probarel funcionamiento del procesador monoradar.

La forma de implementar gran porcentaje de los circuitos fue la utilización deun método de diseño[14] estructurado para la programación VHDL, que permiteincrementar el nivel de abstracción manteniendo el código sintetizable. A partirde la adopción de este criterio de diseño se logró aumentar la mantenibilidad, elentendimiento y evitar discrepancias entre la simulación y la síntesis.

La limitación de las simulaciones para este proyecto radica en la diferencia detiempos entre algunas señales, lo que dificultó las pruebas de integración. Para

4.2. Ensayos 57

minimizar el problema fue de utilidad usar componentes de la placa de desarro-llo, como los LEDs.

Un ejemplo fueron las pruebas de integración del configurador de sectores, dondese utilizaron LEDs para verificar una señal a la entrada de los filtros. Se configuróuna mitad de la vuelta de antena con un valor y la otra mitad con otro valor,mirando con atención qué LED se encendía, como se observa en la figura 4.3.

FIGURA 4.3. Durante las pruebas de integración del configuradorde sectores se utilizaron LEDs para verificar el valor de las señalesen las entradas de cada sector. La flecha emula el paso de la antena.

Otro ejemplo es el desarrollo de un circuito que deja encendido un LED el tiemposuficiente para que el paso de una señal muy rápida pueda ser visto. Esto ayu-dó a las pruebas de integración cuando se necesitaba ver presencia de señales,detección de blancos reales o simulados.

El uso del osciloscopio no sólo permitió comprobar el funcionamiento de la tarjetaadaptadora de señales sino que también sirvió para ver el comportamiento deseñales de sincronismo del sistema, como por ejemplo sincronismo de la memoriaFIFO.

4.2.2. Ensayos en HPS

El desarrollo del procesador monoradar en HPS comenzó por la implementaciónde una aplicación programada en C que utilizaba el puente Lightweight para sa-car datos de la FPGA. Contar con otras versiones de empaquetado y transmisiónfacilitó la tarea inicial. De ese momento en adelante el simulador de señales deradar en la FPGA permitió prescindir de algunos programas de test.

Se ha utilizado también depuración con la herramienta Eclipse DS-5 que Intelprovee gratuitamente cuando se programa sobre Linux un Cyclone V SoC e im-presiones de pantalla para buscar errores durante el desarrollo. Está pendiente eluso de tests unitarios sobre el código escrito con C++.

4.2.3. Pruebas operativas

Se realizaron pruebas operativas con radares primarios FPS 113 y secundariosTPX 42, de la Fuerza Aérea Argentina. Permanentemente se realizan compro-baciones con vuelos comerciales que sobrevuelan rutas aéreas. Pero además deobservar las rutas regulares, se realizaron comprobaciones con aviones más pe-queños, generalmente vuelos de ocasión en aeródromos cercanos.


La comprobación más importante se realizó con una aeronave Learjet 35 que hizoun vuelo de prueba solicitado específicamente para este propósito y que permi-tió comparar el desempeño de un E.D.D.R. preexistente al proyecto y el nuevoprocesador monoradar.

La consola del radar permitió ver los mensajes monoradar, plots primarios se-cundarios o combinados, sobre la visualización del video crudo, para establecerla diferencia entre el dato extraído y la señal original.

59

Capítulo 5

Conclusiones

5.1. Conclusiones generales

En la presente memoria se documentó la implementación de un prototipo operati-vo de procesador monoradar para la Fuerza Aérea Argentina, capaz de digitalizary procesar señales de una estación de radar compuesta por un radar primario y unradar secundario de vigilancia aérea, y de transmitir datos de blancos primarios,secundarios y la combinación de los anteriores. Particularmente se implementóun procesador digital para radares analógicos que permite la operación remotaen múltiples consolas y la posibilidad de integrar sensores radar analógicos a lared del sistema de vigilancia y control del espacio aéreo.

Se implementó en lógica programable un filtro de umbral adaptativo, detectoresde blancos radar, detectores de error y configuraciones en tiempo real, a partir delas señales digitalizadas. También se implementó, pero con software, un serviciode configuración remoto, un servidor de hora y un procesador de datos de radar.

Se documentó la totalidad del proyecto de forma detallada, el código fuente seimplementó siguiendo las buenas prácticas y se realizó un estricto control de ver-siones. Se efectuaron tests unitarios a cada uno de los archivos de lógica progra-mable y se utilizó el lenguaje VHDL para facilitar la portabilidad y escalabilidad.Se utilizó programación orientada a objetos sobre Linux embebido para el proce-samiento de datos y las comunicaciones con el sistema de vigilancia y control.

La implementación permite el ahorro de costos en desarrollo de actualizaciones,en adquisición de repuestos, en instalación, mantenimiento, capacitación y ope-ración, debido a que el procesador se encuentra embebido en una tarjeta de de-sarrollo de bajo costo y fácil adquisición. La tarjeta porta un circuito integradoSoC-FPGA que contiene una parte de lógica programable y un microcontrolador.

Se cumplieron los requisitos en su totalidad y se realizaron pruebas operativas enun radar primario FPS 113 y en un radar secundario TPX 42 de la Fuerza AéreaArgentina, de resultados exitosos con la aprobación del personal operativo de lainstitución. Por lo tanto se concluye que los objetivos planteados al comienzo deltrabajo fueron alcanzados satisfactoriamente y que una gran parte de los conoci-mientos adquiridos durante la especialización se volcaron en el proyecto.

5.2. Conocimientos aplicados

Durante el desarrollo de este trabajo final se aplicaron conocimientos adquiridosa lo largo de la Especialización en Sistemas Embebidos. La tecnología SoC-FPGA

60 Capítulo 5. Conclusiones

y el tema elegido, un procesador para señales de radar, contribuyeron a que todaslas asignaturas de la especialización aporten herramientas indispensables para larealización del proyecto.

El orden de cursada de las asignaturas acompañó el proceso de desarrollo deltrabajo final. A continuación se resaltan las materias que incorporan los conoci-mientos más relevantes:

Gestión de proyectos: facilitó la elaboración de la planificación del trabajofinal, la gestión de los recursos y la elaboración de esta memoria.

Ingeniería de software: facilitó el proceso de desarrollo asegurando la cali-dad del firmware.

Programación de microprocesadores: permitió el uso de las buenas prácti-cas en programación de sistemas embebidos y la implementación del pro-cesamiento con microprocesadores ARM A9 y ARM M4.

Circuitos lógicos programables: se aprendió el lenguaje VHDL, el diseño demódulos y sus bancos de prueba, lo que permitió implementar el procesa-miento en lógica programable.

Microarquitecturas y softcores: ayudó a comprender los fundamentos de laarquitectura y diseño con tecnologías SoC-FPGA, eje del trabajo final.

Sistemas operativos de tiempo real I y II: facilitó el diseño y la implementa-ción del procesador monoradar y en particular del servidor de hora.

Sistemas operativos de propósito general: facilitó el desarrollo del proce-sador de datos radar implementado en C++ sobre Linux embebido y fueimportante el aporte para la implementación de sockets UDP y TCP/IP, esdecir, para el envío de datos radar y para la comunicación con una aplica-ción remota de control.

Testing de software en sistemas embebidos: facilitó la implementación deun plan maestro de pruebas, pruebas unitarias y de integración y el métodode desarrollo dirigido por pruebas (Test-Driven Development), que se aplicóen el servidor de hora.

Diseño de circuitos impresos: se aprendió el uso de herramientas de soft-ware libre con las cuales se diseñó durante la cursada la placa adaptadorade señales de radar.

Desarrollo de aplicaciones sobre sistemas operativos de propósito general:facilitó la implementación de las comunicaciones entre procesos y la im-plementación de una aplicación de control del procesador monoradar conlenguaje Python.

5.3. Trabajo futuro

En primer lugar, a partir de la experiencia adquirida con la implementación deun prototipo operativo de procesador monoradar para radares analógicos, se pre-senta una posible mejora al sistema. Teniendo en cuenta que los recursos utiliza-dos de la placa de desarrollo ADC-SoC son inferiores al 50 % de su capacidadtotal, se puede incorporar un filtro de respuesta finita FIR (Finite Impulse Respon-se), posterior a la digitalización de video de radar primario. Este agregado puede

5.3. Trabajo futuro 61

aprovechar la máxima tasa de muestreo del conversor analógico a digital, pu-diendo incorporar filtro pasa altos, pasa banda o cualquier otro tipo, siempre enlógica programable y cuidando optimizar la detección de la forma de onda deleco recibido para un radar en particular.

En segundo lugar, se puede desarrollar con la misma placa de desarrollo ADC-SoC un procesador radar que permita comprimir el video analógico crudo y des-comprimirlo en forma remota. El procesador actual sólo genera los mensajes mo-noradar, pero en el proceso de generación del blanco, a partir de la detección deecos, inevitablemente se pierde información.

Finalmente, es importante destacar que el trabajo realizado genera experienciasuficiente para desarrollar y gestionar proyectos en el área de la defensa y especí-ficamente con el uso de tecnología SoC-FPGA. Más allá del ámbito de los radaresanalógicos se puede trabajar en el desarrollo de otros equipos para el área de ladefensa con la misma tecnología.

63

Bibliografía

[1] Oscar N. Bria. Desarrollo y Fabricación de Radares Secundarios en Argentina.Visitado el 2020-11-12. 2010. URL:https://www.icao.int/SAM/Documents/2010/SURAUTOSEM/10%20INVAP_DesarrolloFabricacionRadaresSecundarios.pdf.

[2] INVAP. Radar Primario Argentino. Visitado el 2020-11-12. 2020. URL:https://www.invap.com.ar/old/es/espacial-y-gobierno/proyectos-de-gobierno/radar-primario-argentino-3d-rpa.html.

[3] Ignacio A. Montamat. Combinador de Información Primaria y Secundaria paraExtractor Digital de Datos de Radar en Sistemas de Vigilancia. UniversidadNacional de Córdoba, 2015.

[4] Santiago A. Rodriguez Gonzalez. Sistema de Seguimiento y Generación dePistas para Radar Track While Scan. Universidad Nacional de Córdoba -Instituto Universitario Aeronáutico, 2019.

[5] Merrill Skolnik. Radar Handbook. McGraw-Hill, 2008.[6] EUROCONTROL. All-purpose structured EUROCONTROL surveillance

information exchange. Visitado el 2020-11-16. 2020. URL:https://www.eurocontrol.int/asterix.

[7] EUROCONTROL. Specification for Surveillance Data Exchange ASTERIX Part4 Category 048 Monoradar Target Reports. EUROCONTROL, 2020.

[8] EUROCONTROL. Specification for Surveillance Data Exchange ASTERIX Part2b Category 034 Monoradar Service Messages. EUROCONTROL, 2007.

[9] terasIC. ADC-SoC. Visitado el 2020-11-22. 2020. URL:https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=1061&PartNo=1.

[10] Kosma Moczek y Patryk Szymczak. minmea, a lightweight GPS NMEA 0183parser library. Visitado el 2020-11-23. 2020. URL:https://github.com/kosma/minmea.

[11] European Computer Manufacturers Association (ECMA). JavaScript ObjectNotation. Visitado el 2020-11-23. 2020. URL:https://www.json.org/json-en.html.

[12] Niels Nlohmann. JSON for Modern C++. Visitado el 2020-11-23. 2020. URL:https://github.com/nlohmann/json.

[13] Iván Sierra. Poncho GPS L86. Visitado el 2020-11-23. 2017. URL:https://github.com/ciaa/Ponchos/tree/master/GPS_L86.

[14] Jiri Gaisler. A Structured VHDL Design Method. Visitado el 2020-11-12. 2020.URL: https://www.gaisler.com/doc/vhdl2proc.pdf.

https://www.icao.int/SAM/Documents/2010/SURAUTOSEM/10%20INVAP_DesarrolloFabricacionRadaresSecundarios.pdf

https://www.icao.int/SAM/Documents/2010/SURAUTOSEM/10%20INVAP_DesarrolloFabricacionRadaresSecundarios.pdf

https://www.invap.com.ar/old/es/espacial-y-gobierno/proyectos-de-gobierno/radar-primario-argentino-3d-rpa.html

https://www.invap.com.ar/old/es/espacial-y-gobierno/proyectos-de-gobierno/radar-primario-argentino-3d-rpa.html

https://www.eurocontrol.int/asterix

https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=1061&PartNo=1

https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=1061&PartNo=1

https://github.com/kosma/minmea

https://www.json.org/json-en.html

https://github.com/nlohmann/json

https://github.com/ciaa/Ponchos/tree/master/GPS_L86

https://www.gaisler.com/doc/vhdl2proc.pdf