Disen˜o e implementacio´n de sistema de recepcio´n para
comunicaciones ae´reas ACARS (aircraft communications
addressing and reporting system) utlizando la tecnolog´ıa de
Radio Definido por Software para brindar informacio´n de la
Geo-localizacio´n de las aeronaves en tiempo real.
Kevin Herney Rodr´ıguez Go´mez
Universidad Militar Nueva Granada
Facultad de Ingenier´ıa
Bogota´, Colombia
2017

Disen˜o e implementacio´n de sistema de recepcio´n para
comunicaciones ae´reas ACARS (aircraft communications
addressing and reporting system) utlizando la tecnolog´ıa de
Radio Definido por Software para brindar informacio´n de la
Geo-localizacio´n de las aeronaves en tiempo real.
Kevin Herney Rodr´ıguez Go´mez
Trabajo de grado presentado como requisito parcial para optar al t´ıtulo de:
Ingeniero en Telecomunicaciones
Director(a):
M.Sc. Jose de Jesu´s de Rugeles
Universidad Militar Nueva Granada
Facultad de Ingenier´ıa
Bogota´, Colombia
2017

Ante todo Dios y mis padres, motor de motivacio´n e innegable apoyo.
A la Facultad de Ingenier´ıa Telecomunicaciones por la formacio´n que me han dado.
Es gracias a ustedes que es posible el presente trabajo.
En verdad, gracias.
Kevin Herney.

Resumen
En el contexto de las comunicaciones ae´reas, del constante desarrollo tecnolo´gico, el au-
mento del nu´mero de aeronaves, la eficiencia del control de las actividades ae´reas y la se-
guridad de las aeronaves se han vuelto requerimientos vitales; por ello la existencia de un
sistema alterno que cumpla el papel de seguir monitoreando las actividades ae´reas en caso de
una emergencia. Actualmente el aeropuerto internacional el Dorado ubicado en la ciudad de
Bogota´ utiliza la tecnolog´ıa ACARS como modelo de control y mantenimiento de las activi-
dades de las aeronaves en la sabana Cundi-Boyacense. Por ello el presente trabajo contempla
el disen˜o de un sistema de comunicacio´n basado en un prototipo de recepcio´n en la banda de
frecuencias ae´reas, una base de datos donde se almacena los mensajes ACARS recibidos y un
aplicativo Web como plataforma interactiva en tiempo real de la informacio´n dispuesta en la
base de datos. El prototipo de recepcio´n utiliza tecnolog´ıa de Radio Definido por Software
cuyo dispositivo manipulado es un RTL-SDR junto con un programa de procesamiento de
sen˜ales. El software para procesar las sen˜ales provenientes del espectro electromagne´tico es
GNU-Radio. El aplicativo Web plasma la ubicacio´n en tiempo real de los mensajes ACARS
desde la base datos previamente disen˜ado.
iii

I´ndice de figuras
3.1. Diagrama general de OOOI ACARS . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Ejemplo cuando se reciben en tiempo real los mensajes ACARS. . . . . . . . 22
4.2. Mensajes ACARS de acuerdo a la sintonizacio´n de SDR-RADIO. . . . . . . . 23
4.3. Mensajes ACARS del audio Grabacio´n. . . . . . . . . . . . . . . . . . . . . . 25
4.4. Mensajes ACARS del audio Tres Tonos. . . . . . . . . . . . . . . . . . . . . 25
4.5. Mensajes ACARS del audio Multi-Tonos de Baja-potencia. . . . . . . . . 26
5.1. Resumen de la demodulacio´n de mensajes ACARS. . . . . . . . . . . . . . . . 29
5.2. Generador de Radio Frecuencia HAMEG. Con Frecuencia de 501MHz y una
potencia de -37.5 dBm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3. Sen˜al del generador RF en el dominio de la frecuencia recibido por el RTL-
SDR. A simple vista la sen˜al no esta´ ubicada exactamente en los 501 MHz . . 32
5.4. Una vista detallada del offset que existe en el RTL-SDR. Frecuencia real don-
de el RTL-SDR esta sintonizando la frecuencia de 501 MHz del generador
HAMEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5. Calculo de PPM en Simulink para una frecuencia de 501 MHz . . . . . . . . 33
5.6. Imagen espectral del corrimiento de frecuencia de la sen˜al recibida por el RTL-
SDR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.7. Calculo de PPM en Simulink para una frecuencia de 131.719 MHz. Dicha
frecuencia se ajusta tambie´n en el henerador HAMEG . . . . . . . . . . . . . 34
5.8. Procedimiento de recepcio´n de sen˜al ACARS del primer Sub-modulo. . . . . . 35
5.9. RTL-SDR Source con el ajuste de PPM. . . . . . . . . . . . . . . . . . . . . . 36
5.10. Bloque del filtro Pasa-Bajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.11. Conversio´n de una sen˜al compleja (Sen˜al I/Q) a una sen˜al real o en fase.
Re-muestreo de la sen˜al a trave´s de la relacio´n Decimacio´n e interpolacio´n
(Desmuestreo y Muestreo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.12. Funcio´n de filtro en el espectro de los mensajes ACARS simulta´neamente. . 38
5.13. Sub-mo´dulo de recepcio´n ACARS . . . . . . . . . . . . . . . . . . . . . . . . 39
5.14. Diagrama de bloques de la demodulacio´n ACARS en GNU-Radio. . . . . . . 40
5.15. Procedimiento de demodulacio´n de la sen˜al ACARS del Segundo Sub-modulo. 40
5.16. Bytes resultante de la sen˜al ACARS. . . . . . . . . . . . . . . . . . . . . . . . 41
5.17. Bytes resultante de la sen˜al ACARS. . . . . . . . . . . . . . . . . . . . . . . . 42
v
I´NDICE DE FIGURAS
5.18. Prototipo Final para captar sen˜ales ACARS a trave´s de un RTL-SDR en tiem-
po real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.19. Resultado del proceso de recepcio´n y demodulacio´n en tiempo real con el dis-
positivo RTL-SDR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.20. La sen˜al captada por el RTL-SDR se guarda en un archivo .WAV, con la
finalidad de analizar los problemas de demodulacio´n en tiempo real. . . . . . 45
5.21. Programa de GNU-Radio para demodular la misma sen˜al captada por el RTL-
SDR por medio de un archivo .WAV . . . . . . . . . . . . . . . . . . . . . . . 46
5.22. Diagrama del flujo de desmuestreo de una tarjeta de sonido . . . . . . . . . . 47
5.23. Nuevo Prototipo de Recepcio´n-Demodulacio´n de sen˜ales ACARS en tiempo
real a trave´s del RTL-SDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.24. Nuevo Prototipo de Recepcio´n-Demodulacio´n de sen˜ales ACARS en tiempo
real a trave´s del RTL-SDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.25. Configuracio´n del Filtro PasaAbajo en Gnu-Radio . . . . . . . . . . . . . . . 50
5.26. Configuracio´n de una De-modulacio´n AM en GNURadio . . . . . . . . . . . . 50
5.27. Resultado de la Demodulacion del prototipo optimizado . . . . . . . . . . . . 51
6.1. Estructura de un mensaje ACARS. . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2. Tabla ASCII para el protocolo ACARS . . . . . . . . . . . . . . . . . . . . . . 56
6.3. Ejemplo practico para usa la tabla ASCII en el protocolo ACARS . . . . . . 57
6.4. Caja Blanca del bloque de decodificador de GNU-Radio . . . . . . . . . . . . 58
6.5. Resultado del bloque decodificador ACARS en GNU-Radio . . . . . . . . . . 59
7.1. Diagrama de la estructura de la interfaz gra´fica del usuario, con las tecnolog´ıas
a emplear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2. Aplicacio´n web, basado en HTML5 y CSS3 . . . . . . . . . . . . . . . . . . . 66
7.3. Creacio´n de un Mapa centrado en la ciudad de Bogota´ con un Marker de
Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.4. La ubicacio´n real en la ciudad de New York cuando se ejecuto´ el co´digo en el
lado del cliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.5. La ubicacio´n real en la ciudad de New York cuando se ejecuto´ el co´digo en el
lado del cliente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.6. Mapa antes de 30 segundos de la consulta . . . . . . . . . . . . . . . . . . . . 80
7.7. Mapa despues de 30 segundas de la consulta . . . . . . . . . . . . . . . . . . . 81
7.8. Trayectoria en tiempo real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.9. Diagrama por defecto del bloque embedded Python de GNU-Radio. . . . 84
7.10. Co´digo del bloque de GNU-Radio para insertar los mensajes ACARS en MySQL
a trave´s de embedded Python de GNU-Radio. I Parte . . . . . . . . . . . 86
7.11. Bloque de ACARS MySQL con embedded Python de GNU-Radio. I Parte 87
7.12. El objeto ObjectACARS como parametro de entrada del Bloque de ACARS
MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.13. Algoritmo para hallar la longitud de un mensaje ACRS . . . . . . . . . . . . 91
7.14. Algoritmo para captar un Mensaje ACARS . . . . . . . . . . . . . . . . . . . 92
7.15. Resultado de I mensaje de los algoritmos desarrollados . . . . . . . . . . . . . 93
vi
I´NDICE DE FIGURAS
7.16. Resultado de II mensaje de los algoritmos desarrollados . . . . . . . . . . . . 94
7.17. Archivo XML de los mensajes ACARS contenidos en la base de datos por
medio de PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.18. I Algoritmo para determinar la longitud y ubicacio´n dela coordenada geogra´fi-
ca de cada mensaje ACARS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.19. II Algoritmo para extraer la longitud y latitud del mensaje ACARS . . . . 100
7.20. Ubicacio´n geogra´ficas de los mensajes ACARS dispuestos en la base de datos 101
7.21. Tabla Dina´mica como contenedor de los mensajes ACARS en tiempo real . . 105
8.1. Visualizacio´n de la ubicacio´n de uno de los mensajes de la tabla dina´mica de
la Figura 8.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.2. Tabla de la primera sen˜al ACARS De-Modulada. . . . . . . . . . . . . . . . . 111
8.3. Visualizacio´n del mensaje de la tabla dina´mica de la Figura 8.2 sobre el mismo
mapa de la Figura 8.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.4. Tabla de la segunda sen˜al ACARS De-Modulada. . . . . . . . . . . . . . . . . 113
8.5. Visualizacio´n de la ubicacio´n y el mensaje de la tabla dina´mica de la Figura 8.4114
8.6. Tabla de tercera sen˜al ACARS De-Modulada. . . . . . . . . . . . . . . . . . . 115
8.7. Visualizacio´n de la ubicacio´n y el mensaje de la tabla dina´mica de la Figura 8.6116
8.8. Resultado de una mala decodificacio´n del prototipo de recepcio´n. . . . . . . . 117
8.9. Visualizacio´n de los mensajes erra´ticos decodificados de la Figura 8.8 en la
Tabla Dina´mica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
vii

I´ndice de cuadros
4.1. Resultados experimentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Audios experimentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Tabla de aplicaciones I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.2. Tabla de aplicaciones II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
ix

I´ndice general
I´ndice de figuras V
I´ndice de cuadros IX
1. Introduccio´n 1
2. Preliminares 3
2.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. Objetivos Espec´ıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Marco de Referencia 7
3.1. Navegacio´n, Vigilancia y Comunicacio´n Ae´rea . . . . . . . . . . . . . . . . . . 8
3.1.1. ACARS: Aircraft Communications Addressing and Reporting System 9
3.1.1.1. Mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1.2. Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1.3. Modos de operacio´n ACARS . . . . . . . . . . . . . . . . . . 11
3.1.1.4. OOOI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Comunicaciones Ae´reas en Colombia . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1. ACARS en Colombia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1.1. Primer Paso: Solicitud . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1.2. Segundo Paso: Sincronizacio´n . . . . . . . . . . . . . . . . . 15
3.2.1.3. Tercer Paso: Autorizacio´n . . . . . . . . . . . . . . . . . . . . 17
3.3. Radio Definido por Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2. Software (GNU-Radio) . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Ana´lisis Experimental: Frecuencia y Trama ACARS 21
4.1. Identificacio´n de frecuencia de Operacio´n . . . . . . . . . . . . . . . . . . . . 21
4.2. Ana´lisis de los mensajes ACARS en Matlab . . . . . . . . . . . . . . . . . . . 24
4.2.1. Audio Grabacio´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
xi
I´NDICE GENERAL
4.2.2. Tres Tonos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3. Multi-Tonos de Baja-potencia . . . . . . . . . . . . . . . . . . . . . . . 24
5. I Fase: Demodulacio´n 27
5.1. Demodulacio´n ACARS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. Ajuste PPM: Correccio´n del Offset de frecuencia . . . . . . . . . . . . . . . 30
5.2.1. SDR-CONSOLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.2. Matlab (Simulink) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3. Implementacio´n de mo´dulo ACARS: Recepcio´n . . . . . . . . . . . . . . 35
5.4. Implementacio´n de mo´dulo ACARS: Demodulacio´n . . . . . . . . . . . 40
5.5. Demodulacio´n en tiempo real del prototipo: Archivos .WAV . . . . . . 44
5.6. Prueba de desmuestreo de la tarjeta de sonido . . . . . . . . . . . . . . . . . . 45
5.7. Optimizacio´n de Prototipo: Concepto desmuestreo con Demodulacio´n AM. 48
5.7.1. Relacio´n de Desmuestreo . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.7.2. Demodulacio´n AM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6. II Fase: Decodificacio´n 53
6.1. Trama ACARS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2. Bloque de decodificacio´n ACARS en GNU-Radio . . . . . . . . . . . . . . . . 56
7. III Fase: Interfaz Gra´fica 61
7.1. Ana´lisis y Planteamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.1.1. API MySQL-Python . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.1.2. Base de Datos (MySQL) . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.1.3. JAVASCRIPT- Google Maps . . . . . . . . . . . . . . . . . . . . . . . 64
7.2. Metodolog´ıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.3. Disen˜o de Pagina Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3.1. Pa´gina Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3.2. API Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3.2.1. Creacio´n de un Mapa con Google Maps . . . . . . . . . . . . 65
7.3.2.2. Activacio´n de la ubicacio´n de GPS del usuario . . . . . . . . 67
7.3.2.3. Programacio´n de la trayectoria en el mapa . . . . . . . . . . 71
7.4. Desarrollo de aplicativo JavaScript y PHP . . . . . . . . . . . . . . . . . . . . 73
7.4.1. Consultas al BD desde la pa´gina Web con PHP. . . . . . . . . . . . . 74
7.4.2. Peticiones al servidor con programacio´n AJAX. . . . . . . . . . . . . . 77
7.4.3. Optimizacio´n de co´digo AJAX para trayectoria en tiempo real. . . . . 79
7.5. Programacio´n de aplicativo entre MYSQL y GNU-Radio . . . . . . . . . . . . 83
7.5.1. Trabajando con block Python embedded de GNU-Radio . . . . . . . 83
7.5.2. Conexio´n a la DB con Python y MySQL desde GNU-Radio . . . . . . 85
7.5.3. Control de flujo de datos de los Mensajes ACARS . . . . . . . . . . . 87
7.5.3.1. Control de Flujo: Ca´lculo de nu´mero de items del mensaje 88
7.5.3.2. Control de Flujo: Control de Items del mensaje . . . . . . 90
7.6. Optimizacio´n del sistema ACARS . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.6.1. Co´digo PHP: Consultas de los mensajes ACARS con PHP. . . . . . 94
xii
I´NDICE GENERAL
7.6.2. Co´digo PHP: Extraccio´n de la ubicacio´n geogra´fica de las consultas. 98
7.6.3. Co´digo JavaScript: Visualizacio´n de mensajes en tabla dina´mica . . 101
8. III Fase: Pruebas Experimentales 107
8.1. I Escenario: Aeropuerto El Dorado . . . . . . . . . . . . . . . . . . . . . . . 110
9. Conclusiones 119
Bibliograf´ıa 121
xiii

Cap´ıtulo 1
Introduccio´n
El presente trabajo se basa en el disen˜o de un prototipo de recepcio´n ACARS que funcione
como sistema alterno para caso de una emergencia, desarrollado en el grupo de investigacio´n
GISSIC del semillero MAXWELL de la universidad militar Nueva granada. La estructura
del proyecto se desarrolla contextualizando el entorno del trabajo con un marco de referencia.
Posterior a ello se introduce una prueba experimental para identificar el estado de operacio´n
del protocolo en la ciudad de bogota´. El proyecto esta´ basado en IV fases y finaliza con las
conclusiones.
El marco de referencia introduce los conceptos mas importantes de aviacio´n civil y de
Radio Definido por Software para entender el presente trabajo. De forma general el capitulo
se divide en dos marcos. El primero detalla del concepto de comunicaciones Ae´reas/Proto-
colo ACARS y el estado de dicha infraestructura en Colombia. El segundo marco explica la
tecnolog´ıa usada desde el punto de vista de Software y Hardware.
Debido a que no existe documentacio´n de las frecuencias de operacio´n ACARS en Colom-
bia. En el capitulo denominado Ana´lisis experimental abarca la pruebas necesarias para
verificar el funcionamiento de la infraestructura ACARS en la ciudad de bogota´, con cercan´ıa
al aeropuerto internacional ELDorado. Para ello se realiza las pruebas para identificar las
frecuencias de operacio´n y analizar la trama ACARS. Todo ello se realiza a trave´s de softwa-
res externos denominados SDRConsole y PlanePlotter.
La Fase I se desarrolla la teor´ıa referente a la demodulacio´n ACARS y todos los para´me-
tros requeridos para llevar a cabo la implementacio´n de un sistema ACARS en GNURadio,
teniendo en cuenta los conceptos de procesamiento de sen˜ales y protocolo ACARS. En la
presente fase se debe lograr el disen˜o de un programa de recepcio´n ACARS en GnuRadio a
trave´s del RTL-SDR.
La Fase II se basa en documentar el procedimiento de convertir los datos binarios en una
trama ACARS segu´n teor´ıa de decodificacio´n. Dicho proceso se desarrolla con el programa
de GNURadio.
1
1. INTRODUCCIO´N
El resultado de la Fase I y la Fase II es un programa GNURadio capaz de entregar en
un archivo de texto la informacio´n de la sen˜al ACARS captado por un dispositivo RTL-SDR.
La Fase III constituye el disen˜o de la aplicacio´n del usuario para visualizar los resulta-
dos de la trama ACARS en tiempo real. Los requerimientos para desarrollar la interfaz gra´fica
se basa en una base de datos, una aplicacio´n Python para conectar el programa GNURadio
con MySQL y una aplicacio´n Web con tecnolog´ıa de Google API.
La Fase IV se basa en analizar estad´ısticamente los l´ımites del programa planteado
desde el punto de cobertura, efectividad de Decodificacio´n, eficiencia del de la interfaz gra´fica
y la veracidad de la Informacio´n presentada.
2
Cap´ıtulo 2
Preliminares
2.1. Objetivos
2.1.1. Objetivo General
Disen˜ar e Implementar un sistema de comunicacio´n alterna de emergencia ae´rea ACARS
(Aircraft Communications Addressing and Reporting System) mediante Radio Definida por
Software (SDR), para brindar informacio´n de Geo-Localizacio´n de las aeronaves en tiempo
real.
2.1.2. Objetivos Espec´ıficos
Disen˜ar e implementar un sistema de demodulacio´n MSK de las sen˜ales ACARS en una
plataforma hardware de radio definido por software.
Decodificar la trama ACARS para acceder a la informacio´n contenida segu´n el tipo de
mensaje.
Desarrollar aplicacio´n API de Google para la visualizacio´n de la informacio´n de los
mensajes ACARS de las aeronaves en tiempo real.
Realizar pruebas de reconocimiento de los mensajes ACARS de las aeronaves con el
sistema desarrollado para identificar la eficiencia del prototipo.
2.2. Planteamiento del problema
En la vida moderna del hombre en pleno siglo XXI existe la necesidad de monitorear y
analizar el tra´fico ae´reo de las aeronaves que las personas e instituciones gubernamentales (Ya
sean militares, o civiles) demandan ante los desastres naturales que pueda incurrir los aviones.
3
2. PRELIMINARES
Con el sistema de comunicacio´n ACARS permite registrar la trayectoria, informacio´n
comu´n y meca´nica (Combustible, Disponibilidad de Asientos, Estado de la tripulacio´n, Con-
dicio´n Clima´tica), informacio´n correspondiente a cada avio´n con el fin de evitar impactos
y desastres ae´reos, informacio´n de estado de la aeronave desde la u´ltima posicio´n dada una
emergencia.
Dicha sistema infraestructura es costosa y la envergadura es tan amplia que es dif´ıcil
desarrollar. Dado que es una infraestructura compleja, existe una tecnolog´ıa denominada Ra-
dio Definida por Software. Este permite desarrollar sistemas ma´s econo´micos, que para un
sistema alterno como un SDR-RTL cumple la necesidad del proyecto con total suficiencia.
Adema´s, el aprendizaje del funcionamiento y la implementacio´n de sistema en comunicacio-
nes ae´reas con dispositivos SDR (USRP o RTL-SDR) es limitado, permiten bajo un rango
de frecuencias, demodular y hacer todo el proceso de tratamiento de sen˜ales con algu´n tipo
de programa que reconozca como lo es MATLAB o GnuRadio. Es por ello que analizar las
sen˜ales provenientes del sistema ACARS es posible a un bajo costo.
Teniendo en cuenta todas las posibilidades de cualquier tipo desastre o una falla en la
infraestructura de un sistema ACARS, no existe un sistema de comunicacio´n de contingencia
que permita conocer la u´ltima posicio´n conocida de la aeronave y por consiguiente la tra-
yectoria recorrida al instante de la emergencia.Actualmente la aerona´utica civil colombiana
a trave´s de la ARINIC puede disponer de una infraestructura de ACARS como soporte para
los pilotos y la torre de control cuando aterriza y despega.
2.3. Estado del Arte
El art´ıculo ACARS Data Identification and Application in Aircraft Maintenan-
ce [16] propone dos me´todos relevantes para establecer la estructura de los formatos de los
mensajes ACARS. Dichos me´todos se utilizan para identificar las partes de un mensaje de
descarga (DownLink) y mensajes de subida (Uplink). El autor denomina los me´todos como
de formato fijo y el posterior como formato modular.
Los mensajes ACARS se dividen segu´n el tipo de formato: en mensajes downLink y men-
sajes Uplink. Los paquetes Uplink (Desde la estacio´n base y la aeronave) difiere con los
paquetes de Downlink (Desde la aeronave y la estacio´n base). De manera que en dichos for-
matos contiene todos los para´metros del protocolo ACARS la cual dispone del campo texto
en la cual contiene la informacio´n del mensaje.
El autor concluye, que el me´todo de formato fijo es usado para conocer el inicio y el final
del mensaje. Y el me´todo de formato modular es o´ptimo para identificar el campo de texto
de un mensaje.
4
2.3 Estado del Arte
El art´ıculo Experimental encryption of aircraft communication addressing and
reporting system (ACARS) aeronautical operational control (AOC) messages.[12]
Curtis Risley, JamesMcMath y el capita´n Brian Payne proponen realizar una simulacio´n de
un sistema para encriptar mensajes AOC con la finalidad de medir el grado de cumplimiento
de los requisitos militares de seguridad y confiablidad en los mensajes AOC de un sistema
ACARS.
La simulacio´n se lleva a cabo en Boston en donde se tomaron los respectivos datos (Mensa-
jes AOC). Utilizaron una encriptacio´n comercial denominado FORTEZZA. Durante las prue-
bas se hallo´ una situacio´n cr´ıtica, puesto que el taman˜o del mensaje aumentaba linealmente
respecto al mensaje original. Consecuentemente la interaccio´n del medio con las estaciones
base en la comunicacio´n tambie´n es un factor cr´ıtico al emplear CSMA, pues tiene que sensar
el medio antes de transmitir, lo que causa retraso y por lo tanto congestio´n de mensajes. A
manera de conclusio´n los autores recomiendan mejorar los esta´ndares que puedan optimizar
los procesos de encriptacio´n en la CMU de la aeronave.
El investigador Jun Kitaori del instituto de investigaciones de navegaciones electro´nicas,
de la ciudad de Tokyo,Japo´n en el articulo A performance comparison between VDL
mode 2 and VHF ACARS by protocol simulator.[7] justifica la necesidad de conocer
los bene´ficos te´cnicos de las dos tecnolog´ıas VHF y VDL2.
El proyecto utiliza una simulacio´n bajo los dos protocolos mencionados sobre el simulador
OPNET para evaluar las eficiencias de los dos modelos. El taman˜o del mensaje var´ıa para
algunos casos mayores a 660 Bytes como inferiores a dicho taman˜o.
En las u´ltimas de´cadas se ha visto la necesidad de mejorar el rendimiento de la velocidad
de transmisio´n, procesamiento y enrutamiento de los mensajes. Esta mejora esta denominado
como la tecnolog´ıa VDL2.
Kitaori concluye que un sistema basado en VDL2 puede procesar hasta cuatro veces ma´s
ra´pido que un sistema VHF dado el caso extremo de tener una comunicacio´n congestionada.
De manera que actualmente la infraestructura ACARS existente, esta´ migrando de VHF a
VDL2 la cual se le esta´ conociendo como la nueva generacio´n de las comunicaciones aerona´uti-
cas conocida como ACARS ATN.
5

Cap´ıtulo 3
Marco de Referencia
El presente capitulo contextualiza el entorno de las comunicaciones Ae´reas, presentando
los conceptos generales de la aviacio´n civil. De igual forma se detalla la tecnolog´ıa empleada
en el proyecto.
En el inicio del capitulo explica de manera histo´rica y conceptual la estructura de la avia-
cio´n civil. Como parte de toda esa gran estructura ae´rea, profundizamos el tema intere´s, El
protocolo ACARS. Dicha profundizacio´n abarca desde su definicio´n, entidades que soportan
y regulan el protocolo, los detalles te´cnicos ma´s importantes y su funcionamiento general.
Posteriormente se da un panorama general del estado ae´reo en el suelo colombiano, as´ı como
la aplicacio´n de la infraestructura ACARS en el aeropuerto Internacional el Dorado de la
ciudad de Bogo´ta.
Al final del capitulo introducimos el concepto de la tecnolog´ıa de radio definida por
software desde el punto de vista de hardware y software. Como Hardware explicamos la
estructura electro´nica del dispositivo RTL-SDR. Y como software detallamos la definicio´n de
GNURadio, en que´ consiste y su aplicacio´n en las redes Inala´mbricas.
7
3. MARCO DE REFERENCIA
3.1. Navegacio´n, Vigilancia y Comunicacio´n Ae´rea
A lo largo de la historia del hombre las aeronaves han sido herramientas esenciales en
el ambiente civil y be´lico. Y fue solo en el escenario be´lico el que permitio´ la evolucio´n tec-
nolo´gica para la comunicacio´n, navegacio´n y la vigilancia de las aeronaves con un centro de
control ae´reo. A finales de la segunda guerra mundial, la experiencia tecnolo´gica obtenida fue
aprovechada para la aviacio´n civil con la creacio´n de la ICAO la Organizacio´n de aviacio´n
civil en 1944.
A partir de ese momento se introdujo el concepto ATC(Control de tra´fico Ae´reo, en sus
siglas en ingle´s Air Traffic control). Son todos los controles necesarios de las actividades ae´reas
que existen en un aeropuerto.
Desde entonces, se han mantenido tres aspectos importantes que permiten a los pilotos y
las torres ATC ejercer un control sobre las actividades ae´reas. Dichos aspectos han sido na-
vegacio´n, vigilancia y comunicaciones. Normalmente se le denominan CNS (Communication,
Navigation and surveillance). [14]
La navegacio´n se basa en soportar la propia posicio´n y velocidad respecto al plan de vuelo
establecido. Por ello que la planificacio´n, rastreo, grabacio´n y el control del movimiento del
avio´n, son las cuatro funciones principales de la navegacio´n.[14]
La vigilancia se fundamenta en determinar la posicio´n y velocidad a trave´s de medios
externos de la aeronave. Los primeros medios externos que cumpl´ıan esta funcio´n fueron los
radares. Existen dos tipos de radares. Los radares sobre la aeronave y los radares puesta
en tierra. En los radares sobre la aeronave, el radar primario de navegacio´n pasivo en que
el radar puesta en tierra detecta la energ´ıa del radar pasivo para calcular la velocidad y la
altitud de la aeronave. El radar secundario de navegacio´n activa transmite una re´plica de la
sen˜al originada por el radar puesta en tierra. La infraestructura de vigilancia principalmente
radares ha permitido crear un sistema de prevencio´n de coalicio´n de aeronaves. Al mismo
tiempo han servido como pronostico y prevencio´n meteorolo´gica para las aeronaves. [14]
En los u´ltimos an˜os existe un sistema alterno de navegacio´n denominado ADSB (Auto-
matic dependent surveillance – Broadcast). Es un sistema de vigilancia automa´tico basado en
la comunicacio´n de datos. Este sistema permite uso GPS a trave´s de sate´lites SATCOM para
crear una visualizacio´n del tra´fico ae´reo de tiempo real [14]. La implementacio´n de este tipo
de tecnolog´ıa ha sido bene´fica en aeropuertos pequen˜os que no tienen una infraestructura de
radares para las actividades de aterrizaje y despeje.
Las comunicaciones como parte de la CNS para soportar las actividades ATC se ha
efectuado por comunicacio´n por voz. Dicha comunicacio´n por voz se ajusta a un rango de
frecuencia espec´ıfica para contactar con la l´ınea de la torre de control. El gran problema era
que la demanda de aviones era demasiada y generaba esperas para hacer contacto con la torre
8
3.1 Navegacio´n, Vigilancia y Comunicacio´n Ae´rea
de control. Tampoco se puede asignar largos rangos de frecuencias para suplir la necesidad
de comunicacio´n, pues como se sabe el espectro radioele´ctrico es recuso limitado.
Fue por ello que en la de´cada de los 70s se introdujo el concepto de la comunicacio´n por
datos para las actividades ae´reas entre la aeronave y la torre de control. Desde entonces se
le ha conocido como ACARS. Paralelo al sistema ACARS tambie´n se desarrollo´ sistemas
alternos de Comunicacio´n como sistema ATN (Aeronautical Telecommunication network).
Un sistema ATN es un modelo por capas OSI para comunicaciones de datos presenta-
do por la ISO. Dicha infraestructura esta´ basada en siete capas para trasmitir mensajes
ATN. Es importante aclarar que na red ATN comparte la estructura tecnolo´gica en tierra de
ACARS.[14]
3.1.1. ACARS: Aircraft Communications Addressing and Reporting Sys-
tem
ACARS conocido como (Aircraft Communications Addressing and Reporting System)
es una infraestructura de comunicacio´n ae´rea de datos entre estaciones bases en tierra y
aeronaves. Muchas aerol´ıneas utilizan dicha infraestructura para controlar el tra´fico ae´reo,
comunicaciones con las autoridades ae´reas y sus propios centros de operacio´n (Aerol´ıneas).
[2]
Existen principalmente cuatro proveedores que soporta un servicio ACARS, estos se cla-
sifican por regiones continentales [1]:
ARINIC (Rockell Collins) en Estados Unidos
CANADIAN en Canada.
JAPANESE en Japon
SITA en otras regiones
Los mensajes ACARS que se transmiten en redes VHF operan en el rango de frecuencias
(118 Mhz- 137Mhz)[1].
Rockell Collins es una compan˜´ıa que soporta este tipo de infraestructura y en ma´s
de 150 pa´ıses, y en Estados Unidos ejerce como ente de la ARINC (Aeronautical Radio
Incorporated).[2]
Aclarado lo anterior, ACARS en te´rminos te´cnicos es una comunicacio´n que trabaja con
un ancho de canal de separacio´n de 25KHz y una tasa de bits de 2400bps. Trabaja con un
esquema de modulacio´n (MSK-AM). Como control de acceso utiliza CSMA de tipo no Per-
sistente. CSMA No-persistente en sensar el canal para poder trasmitir un mensaje. Es decir,
9
3. MARCO DE REFERENCIA
verifica si el enlace esta libre para trasmitir, dado el enlace estuviera ocupado vuelve reitera-
damente a sensar hasta que el enlace este libre para enviar el mensaje. Finalmente, ACARS
no soporta ninguna correccio´n de errores (FEC). [8]
3.1.1.1. Mensajes
Hay dos tipos de mensajes:
1. Mensaje “Uplink”: Se refiere a todos los mensajes enviados desde la estacio´n base
en tierra hacia la aeronave.
2. Mensaje “Downlink”: Se refiere a todos los mensajes enviados desde la aeronave
hacia la estacio´n base en tierra.
Los mensajes ACARS principalmente tiene dos usos. Los mensajes ATC (Control de
tra´fico Ae´reo, en sus siglas en ingle´s Air Traffic control) y mensajes AOC (Trafico opera-
cional ae´reo, en sus siglas en ingle´s Air Operational Traffic). [16]
Los mensajes ATC funcionan para comunicar la aeronave y la torre de control de un
aeropuerto. Normalmente el contenido del paquete son solicitudes de despeje. Los mensajes
AOC son comunicaciones entre el avio´n y centro de control de su aerol´ınea. Su contenido son
reportes del estatus real de la aeronave en el trayecto de su vuelo[16]. Dichos mensajes son
vitales para los trabajos de mantenimiento de las compan˜´ıas ae´reas, pues permiten anticipar
los cambios pertinentes de una aeronave cuando aterriza.
Entre otras cosas, ACARS tiene la propiedad de pasar de un modo “Data Link” (Trans-
misio´n de mensajes digitales) a “Voice Communication” (Transmisio´n analo´gica), a trave´s de
un mensaje Downlink donde registra el Numero o ID de comunicacio´n, que de acuerdo al ID
de comunicacio´n la estacio´n sintoniza una frecuencia especifica para ejercer la transmisio´n
por Voz. [11]
3.1.1.2. Infraestructura
El funcionamiento de una infraestructura ACARS esta soportado por sate´lites INSMART
y SATCOM, Antenas VHF, VDLM2 o VDL2 (VHF-Data LINK, Es un tipo de tecnolog´ıa
VHF con ventajas de velocidad de procesamiento y enrutamiento), Torres de control que
ejercen funciones de ATC y los centros de operacio´n de las aeronaves. [2]
Dependiendo del lugar de la aeronave, se define que´ tipo de tecnolog´ıa conforma una red
ACARS. Si la aeronave esta sobre tierra, los mensajes ACARS viajan sobre redes VHF y
VDLM2. En cambio, Si el avio´n esta sobre un oce´ano, dichos paquetes se enrutan sobre redes
HFDL (High Frecuency data link) y sate´lites INSMART/SATCOM [2]. De esa manera una
10
3.1 Navegacio´n, Vigilancia y Comunicacio´n Ae´rea
infraestructura ACARS permite transportar mensajes ACARS sobre todo el globo terra´queo.
Como bien es sabido la necesidad de mejorar la eficiencia de la velocidad de enrutamien-
to y procesamiento para las redes VHF, existen las redes VDL2. Las redes VDL2 es una
migracio´n de tecnolog´ıas que evita congestio´n del tra´fico ae´reo entre los mensajes salientes
y entrantes[8]. Por ello es importante aclarar que el presente trabajo se desarrolla en redes
VHF. Para ello limitamos el termino de comunicaciones ACARS solo para redes VHF.
Conociendo la infraestructura ACARS en tierra, solo falta hablar acerca de los equipos
que soportan el servicio ACARS sobre la aeronave. Existen principalmente dos equipos impor-
tantes la MU (Unidad de gestio´n en sus siglas en ingle´s Management Unit) y CDU (Unidad
de visualizacio´n en sus siglas en ingle´s Control Management Unit).[16]
La MU esta´ disen˜ado para recibir/enrutar Mensajes Uplink y transmitir Mensajes Down-
link sobre equipos VHF. La MU cuando establece una comunicacio´n satelital, lo realiza a
trave´s de una unidad de informacio´n satelital SDU (Satelite Data Unit). [16]
Dentro la CDU existe un componente que funciona como origen de los mensajes ACARS
(Mensajes Downlink AOC). Dicho componente es conocido como FMS. Una FMS esta´ ubi-
cado en la cabina de piloto de la aeronave. [16]
3.1.1.3. Modos de operacio´n ACARS
ACARS opera bajo cuatro modos importantes de operacio´n [13]:
Off Mode: EL Modo Apagado ocurre cuando la MU esta fuera de operacio´n.
Demand Mode: EL Modo Demanda entra en operacio´n cuando tiene que: generar
mensajes Downlink para reportar eventos pre-definidos y responder mensaje de peticio´n
(Mensaje Uplink).
Polled Mode: El Modo Compartido ocurre cuando la MU recibe un mensaje Uplink
con cabecera de tipo de mensaje la cual esta´ contenida con el cara´cter “ j”. Este es
utilizado en zonas de alto tra´fico ae´reo. La MU entrara en modo polled solo cuando sea
requerido por la estacio´n base. La estacio´n base hace este tipo de peticio´n perio´dica-
mente a alguna aeronave cada dos segundos. De manera que si la MU tiene un mensaje
Downlink en cola este puede transmitir. Caso contrario env´ıa un mensaje con cabacera
“ DEL”.
Failed Mode: El Modo Fallido ocurre debido a las pruebas de error que ejerce la MU
continuamente. De manera que, si detecta errores en la MU, entra en este modo de
operacio´n.
Voice Mode: El Modo voz pude ocurrir bajo una peticio´n desde la aeronave o la
estacio´n base. Se puede efectuar en el modo demanda o compartido.
11
3. MARCO DE REFERENCIA
3.1.1.4. OOOI
OOOI(OUT,OFF,ON,IN) son eventos basados en el status de la aeronave. OUT significa
fuera de Puerta. OFF significa que la aeronave no esta en tierra. ON significa que la aeronave
esta sobre tierra. IN significa que la aeronave esta en Puerta. [17]
12
3.1 Navegacio´n, Vigilancia y Comunicacio´n Ae´rea
F
ig
u
ra
3
.1
:
D
ia
g
ra
m
a
g
en
er
a
l
d
e
O
O
O
I
A
C
A
R
S
13
3. MARCO DE REFERENCIA
3.2. Comunicaciones Ae´reas en Colombia
El sistema de comunicaciones existente basado en una red VHF tiene una limitacio´n fun-
damental, la cual es, que el intercambio de informacio´n entre el avio´n y la unidad de ATC
se restringe solamente a mensajes de voz, por medio de ondas de radiofrecuencia utilizando
modulacio´n en amplitud AM-DBL. Resulta insuficiente para todo el flujo de trafico Ae´reo
que existe en el pa´ıs [6]. Para superar esta limitacio´n, en el Plan Nacional de Navegacio´n
Ae´rea presentado por la Direccio´n de Servicios a la Navegacio´n Ae´rea de la Secretar´ıa de Sis-
temas Operacionales de la Unidad Administrativa Especial de Aerona´utica Civil(U.A.E.A.C)
ha desarrollado avances para la vigilancia ae´rea colombiana [4].
Para la vigilancia ATC sobre del espacio colombiano se realiza bajo el sistema RADAR
primario y secundario, cuyo desarrollo ha sido importante en la u´ltima de´cada. La cobertura
RADAR esta´ limitada a a´reas continentales y costeras sin cobertura posible sobre las costas
ocea´nicas. [10]
La red nacional de radares ha venido amplia´ndose desde 1990 que hasta el an˜o 2010 cuen-
ta con 20 sistemas de vigilancia radar. Once Secondary Surveillance Radar (SSR) y nueve
Primary Surveillance Radar (PSR) instalados en el territorio nacional. [4]
La infraestructura de la aerona´utica civil colombiana tambie´n cuenta en el campo de
navegacio´n, una plataforma de radio ayuda instaladas en tierra. Dicha estructura permite
una cobertura de baja densidad en lugares donde las condiciones son particulares, caso tal la
amazon´ıa y la regio´n ocea´nica[6]. La infraestructura actual de los sistemas de radio ayudas
cuenta con 49 Sistemas VOR, 51 Sistemas DME (49 Asociados a los VOR + 2 Sistemas DME
Independientes), 11 Sistemas ILS Y 26 Sistemas NDB [10].
Los NDB (Non Directional Beacon) proveen gu´ıa de informacio´n horizontal de no preci-
sio´n indicando el rumbo a las aeronaves en las fases de ruta y aproximacio´n. Los VOR (VHF
Omni-directional Range) proveen gu´ıa de informacio´n horizontal de no precisio´n indicando el
radial de rumbo en todas las direcciones a las aeronaves en ruta y aproximacio´n. Los DME
(Distance Measurement Equipment) proveen la distancia oblicua en millas na´uticas, desde la
aeronave hasta la estacio´n en tierra.Los ILS (Instrument Landing System) proveen gu´ıa de
informacio´n horizontal y vertical de precisio´n a las aeronaves en la fase de aproximacio´n y
aterrizaje indicando a estas la alineacio´n con el eje de la pista y el a´ngulo de descenso en
la aproximacio´n a la misma. Las aeronaves que cuentan con la avio´nica de navegacio´n GPS
Ba´sico (RAIM), pueden navegar procedimientos de no precisio´n en las fases de vuelo de ruta
y aproximacio´n. [6]
14
3.2 Comunicaciones Ae´reas en Colombia
3.2.1. ACARS en Colombia
La frecuencia de operacio´n del protocolo ACARS se basa de acuerdo a la organizacio´n
del espectro radio ele´ctrico de cada pa´ıs, que esta´n sujetas a las pol´ıticas y las necesidades
de la organizacio´n gubernamental encargada de las actividades ae´reas. En Colombia dicha
organizacio´n es la Aerona´utica Civil.
La aerona´utica civil de la unidad administrativa especial junto con la direccio´n de servi-
cios a la navegacio´n ae´rea desarrolla un procedimiento para la autorizacio´n de salidas
via Data Link en el aeropuerto Dorado de Bogota´ [3] que entro´ en vigor en noviem-
bre de 2013. Este sistema notifica a los usuarios de la aviacio´n colombiana la actualizacio´n
del sistema de automatizacio´n para la expedicio´n de la autorizacio´n de salidas conocida co-
mo (DEPARTURE CLEARANCE). Dicha comunicacio´n v´ıa Data Link se realiza desde las
aeronaves y la torre de control del aeropuerto Internacional el Dorado de la ciudad de Bogota´.
El servicio se soporta con equipos del protocolo ACARS. La finalidad de implementar
este sistema se basa u´nicamente en solicitar y recibir la autorizacio´n de salida de manera
automa´tica. Para enviar los mensajes ACARS se realiza mediante un proveedor de servi-
cios ACARS como SITA o ARINIC. El procedimiento para la autorizacio´n de salidas de las
aeronaves se realiza en tres pasos.
3.2.1.1. Primer Paso: Solicitud
La tripulacio´n debe solicitar la autorizacio´n mediante un mensaje RCD (DEPARTURE
CLEARANCE REQUEST). La solicitud debe realizarse con 20 minutos de antelacio´n ante el
SLOT asignado por la oficina DFM. El contenido del mensaje contiene los siguientes datos:
Distintivo de llamada.
Aero´dromo de despegue.
Posicio´n de parqueo.
Aero´dromo de destino.
Designador de la informacio´n ATIS recibida.
Tipo de aeronave.
Registro de la aeronave.
3.2.1.2. Segundo Paso: Sincronizacio´n
Despue´s de realizar la solicitud, el sistema recibe analiza el mensaje RCD :
15
3. MARCO DE REFERENCIA
S´ı el mensaje RCD se recibe con conformidad establecido en 3.2.1.1, entonces env´ıa un
mensaje CLD (DEPARTURE CLEARANCE UPLINK MESSAGE)
S´ı sistema detecta alguna inconsistencia en la informacio´n del mensaje RCD, entonces
env´ıa un mensaje FSM (FLIGHT SYSTEM MESSAGE).
CLD El contenido del mensaje es:
Identificacio´n de la aeronave;
Aero´dromo de destino;
Pista asignada para la salida;
Procedimiento de salida (SID);
Co´digo Transponder;
Siguiente frecuencia;
Designador de la informacio´n ATIS vigente a la hora;
SLOT asignado por la oficina DFM (EOBT);
Informacio´n adicional
Este mensaje no es una autorizacio´n por parte del sistema. Es en cambio un acuerdo
de ambas partes, en donde cada una de las partes se ajusta a las condiciones para que
exista una coherencia.
Si la tripulacio´n no acepta las condiciones del mensaje, debera´ contactar al controlador
de Autorizaciones Eldorado, en la frecuencia 121.6 MHz para recibir la autorizacio´n de
salida por este medio.
FSM El contenido del mensaje se basa en indicar un REVERT TO VOICE PROCE-
DURES. La tripulacio´n debe ajustar en la frecuencia 121.6 MHz para una NUEVA
AUTORIZACIO´N de salida con el controlador de Autorizaciones Eldorado.
Las inconsistencias dadas para generar el mensaje FMS son:
Errores de sintaxis del mensaje RCD (ERROR IN MESSAGE)
El plan de vuelo no se encuentra en el sistema FLIGHT PLAN NOT HELD o existe
ma´s de un plan de vuelo MULTIPLE FLIGHT PLANS HELD
La autorizacio´n ya fue dada DCL (ALREADY GIVEN)
El servicio no se encuentra disponible DCL (SERVICE CURRENTLY NOT AVAILABLE)
Incompatibilidad en el tipo de aeronave AIRCRAFT TYPE MISMATCH
Posicio´n de parqueo no enviada STAND MISMACTH
Solicitud enviada muy pronto REQUEST SENT TOO EARLY
Solicitud enviada muy tarde REQUEST SENT TOO LATE
Autorizacio´n cancelada CLEARANCE CANCELLED
16
3.3 Radio Definido por Software
3.2.1.3. Tercer Paso: Autorizacio´n
Si la tripulacio´n esta conforme con el mensaje pre-Autorizacio´n CLD, debera´ enviar un
mensaje CDA(DEPARTURE CLEARANCE READBACK) a menor brevedad posible.
Si pasados los 10 minutos despue´s de la emisio´n del mensaje CLD, la tripulacio´n no ha
aceptado la pre-autorizacio´n. El sistema asumira´ que se ha presentado un error y anulara´ el
permiso mediante una generacio´n de un mensaje FSM.
3.3. Radio Definido por Software
Las redes de comunicacio´n de datos se ha vuelto un componente vital en la sociedad
moderna que se ha extendido en todas las aplicaciones educativas, empresariales, militares,
seguridad, comerciales y gubernamentales. Todos ellos soportados por sistemas cableados e
inala´mbricos como los servicios de telefon´ıa fija y movil, Internet, Televisio´n, transferencia
de archivos y servicio de streaming. Servicios que se han vuelto particularmente inala´mbricos
gracias al desarrollo de la tecnolog´ıa (SDR) Radio Definido por Software.
El desarrollo de SDR se da gracias a la ra´pida evolucio´n de la micro-electro´nica donde los
transmisores y receptores se han vuelto versa´tiles, potentes y portables. En SRD los radios
transmisores por medio de Software en banda-base se basan en la Modulacio´n/Demodulacio´n,
codificacio´n, Correccio´n de errores y compresio´n de sen˜ales [18].
3.3.1. Hardware
Antes de describir la estructura de un radio definido por software, es necesario conocer
un radio digital. Se sabe que un radio digital esta compuesto por:
Antena Seccio´n donde esta ubicado la antena encargada de recibir o transmitir las sen˜ales
electromagne´ticas.
RF La seccio´n RF es la responsable de transmitir/Recibir la sen˜al en una frecuencia. Lo
usual es volver una sen˜al Banda-Base (Sen˜al IF) en una sen˜al Pasa-banda(Sen˜al RF)
(Transmisor).
ADC/DAC El convertidor Ana´logo/Digital se basa en hacer las conversiones pertinentes
de una sen˜al continua de radio frecuencia (IF) en una sen˜al digital basada en secuencias
binarias.
Modulacio´n/demodulacio´n El modulo de Modulacio´n se basa en convertir la sen˜al digi-
tal en una sen˜al banda base o la sen˜al original. En este modulo se aplica todos los
componentes de procesamiento como filtros, Desmuestreo y remuestreo.
17
3. MARCO DE REFERENCIA
Banda-Base La seccio´n banda base son las operaciones de tratamiento de la sen˜al origi-
nal como Codificacio´n. Normalmente se usa para la implementacio´n de algu´n tipo de
protocolo de la capa de enlace de datos.
Entonces un radio digital SDR se base en implementar todos los componentes de RF,
Modulacio´n, ADC y Banda-Base en un solo componente electro´nico programable. Dicho dis-
positivo son denominados FPGAs. La idea es ajustar todos esos componentes mediante un
software, permitiendo diversas configuraciones para diferentes aplicaciones en un solo dispo-
sitivo SDR.
Actualmente hay muchos dispositivos SDR tales como las populares USRPs (Universal
software radio peripheral), HackRF y RTL-SDR. Los RTL-SDR son dispositivos de procesa-
miento de sen˜ales de bajo costo, la cual puede programar cualquier aplicacio´n del espectro
Radioele´ctrico usando tecnolog´ıa SDR. Es importante aclarar que el disen˜o este tipo de dis-
positivos esta basado solo para recibir sen˜ales ma´s no como radio transmisores.
La estructura de un dispositivo RTL-SDR basado en el chip MICRO-R82022T se es-
tructura en convertir la sen˜al RF en una sen˜al IF mediante un multiplicador basado en un
PLL-VCO.
Fvco = FRF − Fif (3.1)
Luego un filtro Pasa-abajo donde elimina el componente de alta frecuencia. Dicho filtro
funciona como un decimador para bajar el numero de muestras la cual el dispositivo puede
trabajar. Despues pasa por un convertidor ADC la cual opera a una frecuencia de 28.8Mhz.
Luego de obtener una sen˜al digital, se descompone en dos sen˜ales: En fase y Cuadratura. Lo
anterior se logra a trave´s de dos multiplicadores, uno de ellos desfasado 90 grados para lograr
la sen˜al en cuadratura. [15]
3.3.2. Software (GNU-Radio)
GNU-Radio es un software gra´fico que utiliza un conjunto de herramientas en progra-
macio´n de alto nivel para el procesamiento de sen˜ales recreando y disen˜ando sistemas de
comunicaciones. GNU-Radio ejecuta programas basado en lenguaje Python, cuyos progra-
mas internos se ejecutan en C++. Para exista coherencia entre los lenguajes GNURadio
utiliza como API una interfaz SWIG.
Pero al nivel de usuario toda la estructura de GNU-Radio se basa en Pyhton, desde su
ejecucio´n de sus programas y la configuracio´n de los bloques. Los bloques de GNURadio va
desde las funciones de demodulacio´n, Filtros, PLL hasta sistemas compactos ya realizados
como de-moduladores para televisio´n digital terrestre, de-modulacio´n GSM, correccio´n de
errores que permiten disen˜ar sistemas de comunicaciones mas complejos.
18
3.3 Radio Definido por Software
El diagrama de flujo que usa GNU-Radio se basa en un grafo denominado Grafo Dirigido
Aciclico (DGA) [5]. Es un Grafo basado en vertices cuyo bordes dirigidos NO son ciclicos. En
GNU-Radio dichos ve´rtices son los bloques, la cual deben ser por lo menos uno el origen de
los datos. Los datos fluyen unilateralmente hacia una direccio´n donde finaliza en uno o varios
ve´rtices.
Para cada bloque, el flujo esta medido por el numero de items que puede procesar. La
cantidad de Items depende de cuanto espacio puede haber en el buffer de salida y cuantos
items esta´n disponibles en el buffer de entrada. Para mantener ese control de flujo, GNU-
Radio permite controlar entonces el ma´ximo de items que puede salir un bloque o todos los
bloques de un diagrama.[5]
19

Cap´ıtulo 4
Ana´lisis Experimental: Frecuencia y Trama
ACARS
La primera parte se basa en inspeccionar el espectro radio-ele´ctrico asignado para apli-
caciones ae´reas para establecer las frecuencias de operacio´n ACARS. Consecuentemente, se
hace un ana´lisis de los mensajes ACARS interceptados en Matlab.
Luego en el segundo fragmento de prueba, se documenta el comportamiento espectral
en la banda de frecuencia de las sen˜ales ACARS. Este ana´lisis se basa en el driver para
Matlab, desarrollado por un grupo de acade´micos de la universidad de Strathclyde en el
libro “Software Defined radio Using MATLAB y SIMULINK and the RTL-SDR” [15] cuya
referencia se encuentra al final del documento. La necesidad del presente ana´lisis se argumenta
en el transcurso del documento.
4.1. Identificacio´n de frecuencia de Operacio´n
Inicialmente el objetivo es identificar las frecuencias de operacio´n para luego analizarlas.
Para ello usaremos el software RADIO-SDR. Pero viene una pregunta importante, como se
valida si efectivamente en esa frecuencia se esta´n transmitiendo mensajes ACARS. Para ello
se utiliza un programa de codificacio´n PlanePloter que permite codificar los tonos de frecuen-
cia cuando se trasmite un mensaje ACARS. Es decir, utiliza el mezclador este´reo para grabar
la frecuencia de sintonizacio´n (En primera instancia a 131.50 MHz) y codificar el mensaje
ACARS. La relacio´n de ambos programas (RADIO-SDR y PLANEPLOTTER) permite de
manera experimental identificar las frecuencias de operacio´n.
El me´todo es:
Analizar desde la frecuencia de 131.50 Mhz como es el comportamiento espectral cuando
se reciben los mensajes.
21
4. ANA´LISIS EXPERIMENTAL: FRECUENCIA Y TRAMA ACARS
Figura 4.1: Ejemplo cuando se reciben en tiempo real los mensajes ACARS.
22
4.1 Identificacio´n de frecuencia de Operacio´n
Figura 4.2: Mensajes ACARS de acuerdo a la sintonizacio´n de SDR-RADIO.
Simulta´neamente poner en modo escucha el programa PlanePloter para evidenciar efec-
tivamente son frecuencia de operacio´n de mensajes ACARS.
En la Figura 4.1 es un caso de la frecuencia de las diferentes pruebas que se ejecutaron.
La cual se puso en modo escucha en diferentes frecuencias con una duracio´n de un minuto
y medio. Y simulta´neamente en el programa se iba evidenciando las frecuencias que recib´ıan
mensajes ACARS. (Ver Figura 4.2).
Luego de simultaneas pruebas, en la tabla 4.1 se evidencia tres frecuencias de operacio´n
de sen˜ales ACARS.
Frecuencia (Mhz) Caracter´ısticas
131.550
En esta frecuencia no se registra mucha acti-
vidad.
131.719
En esta frecuencia se registra mayor cantidad
de mensajes ACARS, pero con muy baja po-
tencia.
131.917
No esta´n reincidente como la frecuencia de
131.719 Mhz pero la potencia en que se reci-
ben los mensajes es mayor a las dos frecuencias
anteriores.
Cuadro 4.1: Caracter´ısticas Frecuenciales - Frecuencias ACARS cercanas al aeropuerto
Internacional el Dorado en la ciudad de Bogota´
23
4. ANA´LISIS EXPERIMENTAL: FRECUENCIA Y TRAMA ACARS
4.2. Ana´lisis de los mensajes ACARS en Matlab
Cuando se refiere a “Tono”, se esta´ referenciando a un mensaje ACARS que se identifi-
ca con un cambio de sonido como si escuchara una sen˜al sinusoidal. Las grabaciones donde
esta´n contenidos los mensajes ACARS se cargan en Matlab como archivo de audio (Ver Ta-
bla 4.2). La finalidad momenta´nea de este ana´lisis, es observar el comportamiento de la sen˜al.
Los tonos analizados son los siguientes:
Nombre (.wma)
Grabacio´n
Un Tono
Tres Tonos
Multi-Tonos de Baja-potencia
Cuadro 4.2: Audios de prueba - Cuatro grabaciones (Audio) de las tres diferentes frecuencias
de operacio´n ACARS. Para analizar el comportamiento en Matlab
4.2.1. Audio Grabacio´n
La sen˜al de la figura 4.3, cuyo recuadros corresponden a los mensajes ACARS. Se tiene
en cuenta que influye el componente de ruido en la sen˜al.
4.2.2. Tres Tonos
El audio Tres Tonos tiene la particularidad de recibir sen˜ales de alta potencia y de
larga duracio´n de la frecuencia 131.917 Mhz. Cuando los mensajes son provenientes con ca-
racter´ısticas de un nivel de potencias altos, es fa´cil observar los mensajes ACARS de esa sen˜al.
Ya al observar la figura 4.2 y la figura 4.3, existe un patro´n de la variacio´n del nivel de
voltaje del mensaje ACARS, tal como se representa en recuadro azul de la figura 4.4.
4.2.3. Multi-Tonos de Baja-potencia
La sen˜al de figura 4.5 es dif´ıcil de diferenciar un mensaje ACARS a comparacio´n de las
anteriores Figuras. Dicha sen˜al se intercepto en la frecuencia de 131.719 MHz, donde los
24
4.2 Ana´lisis de los mensajes ACARS en Matlab
Figura 4.3: Mensajes ACARS del audio Grabacio´n.
Figura 4.4: Mensajes ACARS del audio Tres Tonos.
25
4. ANA´LISIS EXPERIMENTAL: FRECUENCIA Y TRAMA ACARS
Figura 4.5: Mensajes ACARS del audio Multi-Tonos de Baja-potencia.
mensajes son muy reiterativos, pero con muy baja potencia.
Dada la escasez de informacio´n acerca de la frecuencia de operacio´n del protocolo ACARS
en Colombia, en el documento se comprueba e identifica dichas frecuencias de manera ex-
perimental. La metodolog´ıa usada permite adema´s de comprobar la frecuencia de operacio´n,
el comportamiento temporal de los mensajes ACARS. Pero no refleja informacio´n espectral
acerca de la modulacio´n(Demodulacio´n) utilizada y tampoco es concluyente para establecer
si la sen˜al esta de-modulada.
26
Cap´ıtulo 5
I Fase: Demodulacio´n
El presente capitulo desarrolla el programa de GNURadio para la demodulacio´n de sen˜ales
ACARS proveniente del espectro radioele´ctrico por medio del dispositivo RTL-SDR. Inicial-
mente se contextualiza los conceptos de la modulacio´n ACARS. Antes de empezar a disen˜ar
el programa de GNURadio, Documentamos el procedimiento para ajustar el corrimiento de
frecuencia que tienen los dispositivos RTL-SDR. El programa de GNURadio se basa en dos
mo´dulos: La recepcio´n y la demodulacio´n ACARS. El modulo de recepcio´n son todos los
componentes necesarios para ajustar todos los errores de frecuencia y fase que pueda incurrir
en la sen˜al recibida por el RTL-SDR. El modulo de Demodulacio´n se basa en la conversio´n
de la sen˜al en bits ACARS mediante un bloque predeterminado en GNURadio. Luego de
desarrollar todo el programa de GnuRadio, se le realiza pruebas en un escenario real para
realizar los ajustes necesarios para optimizar el sistema de tal forma que pueda demodular
los mensajes ACARS de manera correcta.
27
5. I FASE: DEMODULACIO´N
5.1. Demodulacio´n ACARS
ACARS empezo´ a funcionar bajo el rango de frecuencias de VHF con una demodulacio´n
AM bajo la modulacio´n digital MSK (No es ma´s que la misma demodulacio´n FSK pero con
fase continua) o CPFSK (Modulacio´n de fase continua) (Con k=0.5). La Modulacio´n MSK es
un caso especial de la Modulacio´n FSK. Se basa en dos estados de frecuencias representando
los bits ‘1’ y ‘0’ respectivamente. La diferencia se basa en que MSK es un caso de fase conti-
nua, es decir evita discontinuidades de fase o cambios bruscos en la forma de onda cuando se
genera la transicio´n de una frecuencia a otra frecuencia, y permite un ancho de banda ma´s
eficiente.
Bajo el esta´ndar ARINIC 618 describe el funcionamiento ba´sico de la comunicacio´n ai-
re/Tierra de las aeronaves usando el protocolo ACARS. De acuerdo con la teor´ıa de la mo-
dulacio´n MSK, la frecuencia asignada para el s´ımbolo ‘1’ es 1200HZ con fase 0 y para el
s´ımbolo ‘0’ se asigna una frecuencia de 2400HZ con fase de 180. La velocidad de transmisio´n
por el medio es 2400 bps. Adema´s, tiene una sen˜alizacio´n ACARS o “Sen˜al ACARS”, que en
te´rminos pra´cticos es un cambio de estados de los bits obtenidos por la demodulacio´n MSK. [9]
Smsk = A cos (2pifc ± pipk
2Tb
+ φ) (5.1)
f1 = (fc − 1
2Tb
)
f2 = (fc +
1
2Tb
)
(5.2)
La sen˜alizacio´n ACARS funciona de la siguiente manera: Si el bit original se mantiene
en un mismo estado (El anterior bit es igual al actual) el bit resultante se intercala. Caso
contrario, si el bit original actual es diferente al bit anterior, el bit resultante mantiene el
estado del bit resultante anterior [9]. Por ejemplo:
P = {0, 1, 0, 0, 1, 1, 1, 0, 0, 1, 0} Bits originales
P ′ = {0, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0} Mensaje ACARS. (5.3)
La demodulacio´n hace ese procedimiento inverso; de-modula la sen˜al MSK, luego ejerce
la sen˜alizacio´n inversa para obtener los bits originales.
Para ejercer la demodulacio´n MSK existe dos formas: de forma COHERENTE y NO-
COHERENTE. La modulacio´n NO-COHERENTE se basa en multiplicar por la portadora
previo a un filtro pasa-bajo. Y luego ejerce una decisio´n en base a un envolvente en donde se
hace una comparacio´n y decisio´n. La forma COHERENTE se basa en un PLL retroalimen-
tado con VCO, la cual detecta el cambio de fase y as´ı determinar la salida digital de dicho
28
5.1 Demodulacio´n ACARS
Figura 5.1: Resumen de la demodulacio´n de mensajes ACARS.
29
5. I FASE: DEMODULACIO´N
demodulador. De igual manera existe un me´todo para volver la forma NO-COHERENTE
en una demodulacio´n Coherente, mediante el me´todo de recuperacio´n de la portadora. Este
permite entrar en sincron´ıa en frecuencia y fase de acuerdo con la sen˜al de entrada. Esta se
le denomina como la demodulacio´n OQPSK especial para MSK.
La comparacio´n de las dos formas de demodulacio´n frente a la relacio´n de SNR y el BER,
existe una mejor eficiencia con la forma COHERENTE. Existe menor probabilidad a mayor
capacidad de existencia de ruido. Por ello implica usar una demodulacio´n coherente, aunque la
dificultad esta´ en la complejidad circuito. Mientras que la demodulacio´n NO-COHERENTE
es ma´s sencilla de ejercer, pero implica resultados inferiores respecto a la relacio´n SNR y BER.
5.2. Ajuste PPM: Correccio´n del Offset de frecuencia
Un offset de frecuencia en un sistema de recepcio´n puede ser cr´ıtico a medida que el
ancho de banda de la sen˜al a recibir sea estrecho. Adema´s, se ha experimentado que dicho
corrimiento no es fijo sino variable. Es decir, en un periodo de tiempo la frecuencia de la
portadora del RTL-SDR oscila en una frecuencia (Fo) diferente a la frecuencia banda base
(Fc). Por ello es importante hacer la correccio´n del corrimiento de frecuencia.
Todos los dispositivos RTL.SDR tienen un corrimiento de frecuencia que va desde los
5Khz hasta los 60Khz. Todos los dispositivos no tienen el mismo Offset de frecuencia, de ma-
nera que cada dispositivo RTL-SDR se debe realizar dicha prueba. El valor o la variable que
corrige dicho defecto se denomina PPM (Partes por millo´n), y esta medido por la siguiente
formula:
PPM =
foffset
fc ∗ 10−6
′
(5.4)
Donde foffset es la diferencia entre la frecuencia que esta´ transmitiendo y la frecuencia
que esta midiendo el RTL-SDR. Es muy importante mantener este ca´lculo, ya que dicha di-
ferencia va cambiando a media que se va aumentando la frecuencia. Es decir, si el RTL-SDR
recibe una sen˜al con una frecuencia promedio a 100MHZ el offset aproximadamente sera´ 7
KHz; Pero si se transmite a una frecuencia mayor a 500MHz el offset AUMENTA a 30KHz
aproximadamente. De manera concluyente, a medida que aumentamos la frecuencia de ope-
racio´n del RTL-SDR, ma´s cr´ıtico va a ser el offset de frecuencia.
De acuerdo con lo anterior, no es sensato definir una diferencia experimental o una correc-
cio´n manual para cada frecuencia de recepcio´n del dispositivo RTL. Ma´s bien se debe definir
un u´nico valor para todo el rango de frecuencias de dicho dispositivo. La afirmacio´n anterior
se logra definiendo un PPM del offset de frecuencia.
30
5.2 Ajuste PPM: Correccio´n del Offset de frecuencia
Figura 5.2: Generador de Radio Frecuencia HAMEG. Con Frecuencia de 501MHz y una potencia
de -37.5 dBm
La metodolog´ıa de la presente prueba es la siguiente:
Ajustar una frecuencia espec´ıfica a un nivel de potencia cercana a los -35dBm en un
generador de radio frecuencia.
De forma experimental a trave´s de SDR Console intentar aproximar una diferencia entre
la Frecuencia RF (Fc) y la frecuencia que mide el dispositivo RTL-SDR (Fo). Calcular
un PPM. (Considerando el error de visualizacio´n del ojo humano).
Comparar el anterior resultado, con la herramienta de Matlab de RTL-SDR para cal-
cular un PPM.
Visualizar el efecto que tiene PPM en GNU Radio.
Al medir la diferencia entre Fc y Fo de manera espectral, se debe ajustar un desmuestreo
de la frecuencia de muestreo menor a los 400Khz/s. Para obtener una mejor resolucio´n es-
pectral, para disminuir el error del ojo humano. (Tener en cuenta teor´ıa de Nyquist, pues el
ancho de banda de una sen˜al esta´ limitado por su frecuencia de muestreo).
Como primera instancia ajustamos una frecuencia mayor a los 400Mhz con la respectiva
nivel de potencia (El nivel de potencia debe ser considerado segu´n las interferencia que se
encuentren en el espectro. Idealmente se debe hacer las pruebas donde no haya interferencia
de sen˜ales en ese rango de frecuencia).
En otro lado de la ecuacio´n, ajustamos en el dispositivo RTL-SDR a trave´s de SDRCon-
sole, exactamente la frecuencia que se encuentra en la imagen anterior.
5.2.1. SDR-CONSOLE
Evidentemente existe un offset de frecuencia negativa (Corrimiento hacia la izquierda).
Para aumentar la resolucio´n espectral disminuimos su frecuencia de muestreo para ajustar
31
5. I FASE: DEMODULACIO´N
Figura 5.3: Sen˜al del generador RF en el dominio de la frecuencia recibido por el RTL-SDR. A
simple vista la sen˜al no esta´ ubicada exactamente en los 501 MHz
Figura 5.4: Una vista detallada del offset que existe en el RTL-SDR. Frecuencia real donde el
RTL-SDR esta sintonizando la frecuencia de 501 MHz del generador HAMEG
mejor la frecuencia del dispositivo Fo.
Visiblemente al ajustar y medir la frecuencia de operacio´n, existe una diferencia entre la
frecuencia que se esta´ transmitiendo (501 Mhz) y la frecuencia que esta´ recibiendo en el RTL
(500.9581 Mhz). Es decir, existe un offset igual a 31.9Khz. De manera que si calculamos el
valor de PPM
PPMexp =
31900
501 ∗ 106 ∗ 10−6
PPMexp = 63,67
(5.5)
5.2.2. Matlab (Simulink)
Para comparar y definir el alcance del ca´lculo anterior, realizamos la misma prueba, pero
en un ca´lculo automatizado realizado en un programa Simulink en Matlab. Matlab realiza un
calculo espectral en donde encuentra todos los picos de la sen˜al de manera espectral, y luego
32
5.2 Ajuste PPM: Correccio´n del Offset de frecuencia
Figura 5.5: Calculo de PPM en Simulink para una frecuencia de 501 MHz
compara entre todos los valores picos, el valor ma´s grande. Entonces el valor ma´s grande sera´
la frecuencia Fo del dispositivo RTL.
Evidentemente en un valor ma´s exacto de offset de frecuencia, su PPM en un valor redon-
deado es exactamente igual al ca´lculo experimental realizado en SDRConsole. En la siguiente
imagen espectral de Matlab se puede evidenciar ma´s claramente el corrimiento de frecuencia.
Ahora para soportar la afirmacio´n de que a medida que disminuimos la frecuencia de ope-
racio´n el offset de la sen˜al disminuye, son directamente proporcionales, pero su valor PPM se
mantiene. Para ellos ajustamos el generado RF a la frecuencia de operacio´n ACARS hallado
experimentalmente, es decir adicionando el error de offset frecuencial de131.719MHz.
Tal como se afirmo´, el offset de frecuencia disminuye a 8.2KHz, pero su valor PPM se
mantiene entre el rango de 62 y 63. Entonces se puede concluir que el valor nominal de la
frecuencia ACARS no debe ser 131.719 MHz sino 131.7108MHz, que en un valor aproximado
se maneja en 131.710Mhz.
Entonces al ajustar la simulacio´n a 63 PPM, entonces el RTL se ajusta automa´ticamente
a la frecuencia base del mismo dispositivo de manera correcta, solo con un offset de frecuencia
de 100 Hz, corrimiento de frecuencia que el mismo dispositivo es capaz de controlar. Pues el
dispositivo no es capaz de enganchar la portadora cuando el offset de frecuencia es mayor a
1 KHz.
PPMexp =
8200
131,719 ∗ 106 ∗ 10−6
PPMexp = 62,65
(5.6)
33
5. I FASE: DEMODULACIO´N
Figura 5.6: Imagen espectral del corrimiento de frecuencia de la sen˜al recibida por el RTL-SDR.
Figura 5.7: Calculo de PPM en Simulink para una frecuencia de 131.719 MHz. Dicha frecuencia
se ajusta tambie´n en el henerador HAMEG
34
5.3 Implementacio´n de mo´dulo ACARS: Recepcio´n
Figura 5.8: Procedimiento de recepcio´n de sen˜al ACARS del primer Sub-modulo.
5.3. Implementacio´n de mo´dulo ACARS: Recepcio´n
Establecido ya las frecuencias de operacio´n del protocolo ACARS-VHF en la ciudad de
Bogota´ y la teor´ıa de demodulacio´n digital banda-base y pasa-banda, Filtros FIR, Interpo-
lacio´n, Decimacio´n y la definicio´n de software definida por Software (SDR) para comprender
este sistema de recepcio´n ACARS.
El sistema de demodulacio´n y decodificacio´n se basa en los trabajos en GNU-Radio (gr-
acars2) desarrollados por Antoine Neuenschwander. Estos desarrollos resumen el trabajo de
un mo´dulo de recepcio´n ACARS mediante un dispositivo SDR en tiempo real presentado en
el presente trabajo.
El mo´dulo de recepcio´n ACARS se pude dividir en dos sub-mo´dulos. El primer sub-modulo
se basa en acondicionar la sen˜al ACARS recibida por el dispositivo SDR en condiciones o´pti-
mas para el siguiente sub-modulo (DSP). El segundo sub-mo´dulo recibe la sen˜al condicionada
para ejercer la demodulacio´n y la decodificacio´n de una manera o´ptima.
El primer sub-modulo (Ver Figura No 5.8) cuando hablamos de condicionar la sen˜al, se
refiere hacer el procesado de sen˜al para corregir errores de recuperacio´n tal como la sincroni-
zacio´n en fase y en frecuencia de la sen˜al recibida por el dispositivo RTL. Y de igual manera
efectuar un filtro pasa-abajo para procesar la sen˜al sobre la banda seleccionada. Y aplicar
una relacio´n de submuestreo y desmuestreo para entregar una sen˜al muestreada a 48KHz.
La idea de explicar cada sub-mo´dulo se fundamenta en explicar en detalle cada funciona-
lidad de cada bloque funcional explicado en la Figura No 1, pero plasmado en GNU-Radio.
Inicialmente debe disponer de un bloque para adaptar el dispositivo SDR a GNURadio,
que para el desarrollo de este proyecto se basa en un dispositivo RTL-SDR. Funcionalmente
este se encarga de adaptar la sen˜al recibida por el dispositivo para poderlo procesar en la
plataforma de GNURadio. Los para´metros para destacar son la frecuencia de sintonizacio´n
(Frecuencia de operacio´n ACARS), la frecuencia de muestreo (Redondea desde los 500KHz
35
5. I FASE: DEMODULACIO´N
Figura 5.9: RTL-SDR Source con el ajuste de PPM.
a los 2MHz) y la ganancia o amplificacio´n del ancho de banda a recibir. (Ver Figura 5.9
Ya con la sen˜al captada, es necesario limitar el ancho de banda de trabajo a trave´s de un
filtro Pasa-Abajo. Dicho disen˜o del filtro pasa-bajo se puede facilitar a trave´s Filter Firdes,
que es un programa de GNURadio que se puede ejecutar a trave´s de un emulador de python.
La idea de usar la aplicacio´n, es conocer la respuesta del filtro y aplicarlo en algu´n filtro FIR
de GNU-Radio. (Ver Figura 5.10)
Los para´metros de disen˜o del filtro son la ganancia, la frecuencia de muestreo (Para´me-
tro que define el ancho de banda de la sen˜al a trave´s de la teor´ıa de Nyquist), la banda de
transicio´n que viene siendo la diferencia entre FIN DE PASABANDA e INICIO DE BANDA
DE DETENCIO´N y la atenuacio´n del filtro.
Luego de adecuar la sen˜al en el ancho de banda adecuado, solo resulta separar la sen˜al
en fase de la sen˜al IQ a trave´s de un mo´dulo que convierta un dato complejo a un dato real.
(Ver Figura 5.11)
La relacio´n de Re-muestreo es para ajustar dicha sen˜al a un muestreo de 48KHz. Dicho
muestreo es necesario para que la demodulacio´n del segundo Sub-Modulo sea o´ptima. La
relacio´n funciona de la siguiente manera:
36
5.3 Implementacio´n de mo´dulo ACARS: Recepcio´n
Figura 5.10: Bloque del filtro Pasa-Bajo.
Figura 5.11: Conversio´n de una sen˜al compleja (Sen˜al I/Q) a una sen˜al real o en fase. Re-
muestreo de la sen˜al a trave´s de la relacio´n Decimacio´n e interpolacio´n (Desmuestreo y Muestreo)
37
5. I FASE: DEMODULACIO´N
Figura 5.12: Funcio´n de filtro en el espectro de los mensajes ACARS simulta´neamente.
RelationResampler =
Interpolacion
Decimacion
(5.7)
Sampler48Khz = Relation ∗ SampleRate(in) (5.8)
Si “Sample rate” es 500KHz entonces debe existir una relacio´n tal que la sen˜al quede
muestreada a 48KHz(Aplicar la ecuacio´n 5.7 y con el resultado usar la formula 5.8):
RelationResampler =
96
1000
Sampler48Khz = 0,096 ∗ 500Khz
Sampler48Khz = 48Khz
(5.9)
De manera que al simular el programa del Sub-mo´dulo de la Figura No 5.12, se obtiene
los siguientes resultados: (Ver Figura No 5.13)
En la figura 5.13, se puede evidenciar el funcionamiento del sub-mo´dulo de recepcio´n des-
de cuando capta la sen˜al mediante el bloque de RTL-SOURCE en el diagrama de Waterfall.
Igualmente, los dos diagrama de inferiores se evidencia los mensajes ACARS captados por el
dispositivo SDR. Dichos mensajes pasan por un filtro pasa-abajo.
38
5.3 Implementacio´n de mo´dulo ACARS: Recepcio´n
Figura 5.13: Sub-mo´dulo de recepcio´n ACARS
39
5. I FASE: DEMODULACIO´N
Figura 5.14: Diagrama de bloques de la demodulacio´n ACARS en GNU-Radio.
Figura 5.15: Procedimiento de demodulacio´n de la sen˜al ACARS del Segundo Sub-modulo.
5.4. Implementacio´n de mo´dulo ACARS: Demodulacio´n
El segundo Sub-Mo´dulo de la Figura 5.15 trata de hacer el procedimiento de demodula-
cio´n de la sen˜al ACARS de acuerdo con los para´metros de decisio´n de bits de la Demodulacio´n
MSK-FSK. El resultado de dicho de Sub-modulo es entregar paquetes de ocho bits (Bytes).
De manera que la combinacio´n de los dos sub-mo´dulos suman la recepcio´n de una sen˜al
ACARS con un dispositivo SDR en tiempo real. El proceso de Decodificacio´n es el bloque
faltante para el segundo sub-mo´dulo. Cuando se habla de una sen˜al condicionada, quiere
decir que se entrega una sen˜al limitada a un ancho de banda predefinido a un muestreo
de 48Khz. Es el para´metro mediante por el cual la demodulacio´n se puede considerar o´pti-
ma. Los bloques necesarios para la demodulacio´n en GNU-Radio se presenta en la Figura 5.14
La demodulacio´n se basa en la modulacio´n MSK-FSK. El proceso de Decodificacio´n se
explica en la siguiente fase, ya que esta se basa en una teor´ıa que respalda dicha decodificacio´n
utilizada en este trabajo. El resultado se evidencia en la figura 5.16.
Por cada byte, hay 7 bits de informacio´n donde el LSB y MSB esta´n invertidas. Tambie´n
existe un bit de paridad. (Ver Figura 5.17). En la Figura 5.16, se evidencia que la frecuen-
cia de muestreo debe ser de 48KHz. Y la velocidad de bits en ACARS es equivalente a 2400Hz.
Los para´metros esenciales a tener en cuenta fueron los siguientes:
La sen˜al debe estar muestreada a 48Khz para poder ser de-modulado correctamente.
40
5.4 Implementacio´n de mo´dulo ACARS: Demodulacio´n
Figura 5.16: Bytes resultante de la sen˜al ACARS.
41
5. I FASE: DEMODULACIO´N
Figura 5.17: Bytes resultante de la sen˜al ACARS.
La sen˜al captada debe estar limitada por un filtro, de tal manera que pueda ser eficien-
temente espectral sin necesidad de perder informacio´n.
42
5.4 Implementacio´n de mo´dulo ACARS: Demodulacio´n
F
ig
u
ra
5
.1
8
:
P
ro
to
ti
p
o
F
in
a
l
p
a
ra
ca
p
ta
r
se
n˜
a
le
s
A
C
A
R
S
a
tr
av
e´s
d
e
u
n
R
T
L
-S
D
R
en
ti
em
p
o
re
al
.
—
43
5. I FASE: DEMODULACIO´N
Figura 5.19: Resultado del proceso de recepcio´n y demodulacio´n en tiempo real con el dispositivo
RTL-SDR.
5.5. Demodulacio´n en tiempo real del prototipo: Archivos .WAV
En la anterior prueba se verifica la funcionalidad del sistema de cumplir la demodulacio´n
a partir de archivos .WAV. La finalidad de la presente prueba analizar el comportamiento del
prototipo para Demodular mensajes ACARS en tiempo real.
Al realizar el proceso de recepcio´n y demodulacio´n de manera continua y en tiempo real.
Evidentemente alcanza a captar mensajes, pero solo logra Demodular solo un campo de to-
do el mensaje ACARS. Es decir, en dicha imagen logra captar dos mensajes.(Ver Figura 5.19)
El para´metro SYNC, se cuenta para sincronizar el inicio del mensaje, de manera que, s´ı
detecta el inicio del mensaje pero no de-modula el resto mensaje. Entonces, se identifica las
dificultades del prototipo, para definir si son errores de la recepcio´n o errores de la demodu-
lacio´n del sistema.
La metodolog´ıa es la siguiente: El resultado de la recepcio´n de la sen˜al, es decir antes de
Demodular dicha sen˜al se guarda en un archivo .WAV. Para luego Demodular dicho archivo
.WAV en otra instancia de la prueba. Como se puede apreciar en la figura 5.20.
44
5.6 Prueba de desmuestreo de la tarjeta de sonido
Figura 5.20: La sen˜al captada por el RTL-SDR se guarda en un archivo .WAV, con la finalidad
de analizar los problemas de demodulacio´n en tiempo real.
A partir del mismo archivo .WAV obtenido en la anterior prueba, se realiza la demodula-
cio´n en otra prueba (Ver Figura 5.21):
Se logra Demodular el archivo .WAV en el programa de la Figura 5.21, cuando en tiempo
real no logro el prototipo Demodular los mensajes ACARS de manera completa. Entonces se
logra mediante la presente prueba definir que existe problemas en el mo´dulo de recepcio´n, es
decir, el proceso de adecuacio´n de la sen˜al a trave´s del filtro pasa-abajo y desmuestreo.
En conclusio´n, se deja abierto un ana´lisis ma´s abierto desde el punto de vista de los
problemas que puedan estar pasando en te´rminos de sincronizacio´n de la portadora, frecuencia
y fase de la sen˜al recibida. Tambie´n hay que analizar el efecto de la tarjeta sonido en el
prototipo, ya que al guardar un archivo .WAV se esta´ utilizando la tarjeta de sonido. Pues
la tarjeta de sonido si logra adaptar la sen˜al a 48KS/s, funcio´n que no logra el proceso de
desmuestreo del prototipo de la figura 5.18en el bloque Resampler.
5.6. Prueba de desmuestreo de la tarjeta de sonido
Teniendo en cuenta la dificultad del presente prototipo Demodular completamente un
mensaje ACARS en tiempo real. Los resultados de la anterior prueba, concluye que solo es
capaz de Demodular los mensajes si convierte la sen˜al entrante en un archivo .WAV mediante
la tarjeta de sonido del equipo.
En esta prueba es determinar cua´l debe ser el factor de desmuestreo ma´s o´ptima para
una tarjeta de sonido. Es decir, cada cuanto “samples” se deben eliminar desde la frecuencia
de muestreo del RTL (En orden de los MS/s) hasta la frecuencia de la tarjeta de sonido
(48KS/s) para que pueda Demodular en tiempo real.
Sabiendo que una mayor cantidad de muestras implica una mayor cantidad de combina-
45
5. I FASE: DEMODULACIO´N
Figura 5.21: Programa de GNU-Radio para demodular la misma sen˜al captada por el RTL-SDR
por medio de un archivo .WAV
ciones (Un nu´mero mayor de niveles) o un rango dina´mico mayor, es decir, existe una mayor
resolucio´n de bits. Entonces la pregunta que deja la afirmacio´n anterior es ¿Cua´l es mi reso-
lucio´n del prototipo? y ¿Cua´l debe ser la resolucio´n que debe recibir la tarjeta de sonido?
Para contestar las dos preguntas anteriores, se plantea el siguiente ana´lisis:
Si la frecuencia de muestreo del dispositivo RTL de la sen˜al entrante es de 2.5 MS/s y
la frecuencia de salida de la tarjeta de sonido para la demodulacio´n ACARS es 48KS/S, la
relacio´n de desmuestreo (Decimacio´n) es aproximadamente 50. Es decir, para lograr bajar la
frecuencia de muestreo a 48KS/s debe quitar 50 muestras perio´dicamente hasta llegar a las
2 500 000 muestras de la sen˜al entrante en un segundo.
Ir =
fRTL
fTsonido
Ir ∼= 50
(5.10)
Pero, entonces cual debe ser el factor ideal para que pueda la tarjeta de sonido operar de
la manera ma´s o´ptima. La teor´ıa de articulo [2], define que un desmuestreo o submuestreo
debe ocurrir cada 4 muestras (2), es decir, quitar cuatros muestras y mantener una muestra.
fRTL = 4
n ∗ fTsonido (5.11)
46
5.6 Prueba de desmuestreo de la tarjeta de sonido
Figura 5.22: Diagrama del flujo de desmuestreo de una tarjeta de sonido
En la ecuacio´n define la relacio´n de sobre-muestreo en te´rminos de la resolucio´n de bits.
Entonces para determinar cua´l es la resolucio´n que entrega mi prototipo:
fRTL
fTsonido
= 4n (5.12)
Entonces la resolucio´n de entrada (n) se adapta a la ecuacio´n No 3. De manera que
despejando n, queda de la siguiente manera:
log
(
fRTL
fTsonido
)
= n log (4)
n = log
(
log 50
log 4
)
Ir ∼= 3
(5.13)
El resultado anterior significa que dicho sobre-muestreo, implica un aumento de resolucio´n
de 3 bits. Si la tarjeta de sonido opera a partir de 8 bits entonces:
N = 28+n
N = 28+3
(5.14)
La resolucio´n que recibe el sistema son del formato de 11 bits y la tarjeta de sonido opera
bajo 8 bits, entonces debe se debe ajustar el prototipo de tal manera que pueda bajar la
resolucio´n de bits aproximadamente 3 bits con la relacio´n 4n de la tarjeta de sonido.
En conclusio´n, cuando se quiere adaptar alguna aplicacio´n con la tarjeta de sonido de un
ordenador, debe al final del proceso de desmuestreo ajustar una escala de Decimacio´n de 4
muestras.
A partir del ana´lisis anterior, en la siguiente prueba se debe ajustar de acuerdo con el
ana´lisis anterior el proceso de desmuestreo. Con la finalidad de mejorar la demodulacio´n en
tiempo real de los mensajes ACARS.
47
5. I FASE: DEMODULACIO´N
Figura 5.23: Nuevo Prototipo de Recepcio´n-Demodulacio´n de sen˜ales ACARS en tiempo real a
trave´s del RTL-SDR
Teniendo en cuenta las caracter´ısticas de un convertidor Ana´logo-Digital (ADC), la fre-
cuencia de muestreo no es tan importante para las aplicaciones de un dispositivo RTL-SDR,
pues solo basta con la frecuencia de muestreo de la tarjeta de sonido.
5.7. Optimizacio´n de Prototipo ACARS: Demodulacio´n AM
aplicando concepto de desmuestreo de tarjeta de sonido.
Teniendo en cuenta el ana´lisis de la anterior prueba, se realiza una modificacio´n al proto-
tipo de la Figura 5.18, de tal manera que pudiera cumplir con los requerimientos de la tarjeta
de sonido. El nuevo prototipo se evidencia en la Figura 5.24.
Se mantiene el bloque de recepcio´n del dispositivo RTL, as´ı como tambie´n el filtro. Se
cambia la relacio´n de desmuestreo y la aplicacio´n de una demodulacio´n AM.
5.7.1. Relacio´n de Desmuestreo
Si utilizamos una frecuencia de muestre de 1.15MS/s, entonces la relacio´n de desmuestreo
al valor ma´s aproximado es 24:
Ir =
1,15MS/s
48KS/s
Ir ∼= 24
(5.15)
Pero como la tarjeta debe hacer un desmuestreo en factor 4, entonces anterior a ello debe
existir un factor de Decimacio´n tal que N x 4 =24. Dicho factor debe ser igual a 6.
48
5.7 Optimizacio´n de Prototipo: Concepto desmuestreo con Demodulacio´n AM.
F
ig
u
ra
5
.2
4
:
N
u
ev
o
P
ro
to
ti
p
o
d
e
R
ec
ep
ci
o´
n
-D
em
o
d
u
la
ci
o´
n
d
e
se
n˜
a
le
s
A
C
A
R
S
en
ti
em
p
o
re
a
l
a
tr
av
e´s
d
el
R
T
L
-S
D
R
49
5. I FASE: DEMODULACIO´N
Figura 5.25: Configuracio´n del Filtro PasaAbajo en Gnu-Radio
Figura 5.26: Configuracio´n de una De-modulacio´n AM en GNURadio
En GNURadio en el prototipo quien satisface la Primera Decimacio´n con factor de 6 es
el bloque de filtrado.Luego para satisfacer la segunda Decimacio´n con factor 4 es el bloque
de demodulacio´n AM.
5.7.2. Demodulacio´n AM
La finalidad de forzar una Decimacio´n en una demodulacio´n AM, es para que pueda des-
muestrear la sen˜al conforme la envolvente que produce una demodulacio´n AM. La envolvente
esta´ controlada por la velocidad del canal de la tarjeta de sonido, as´ı como la Decimacio´n de
audio. Es por ello que este bloque se adapta mejor para la finalidad de des-muestrear la sen˜al
en factor de 4 muestras a trave´s de la tarjeta de sonido.
El ana´lisis del resultado se obtiene que por primera vez logra Demodular un mensaje com-
pleto en tiempo real, pero con una probabilidad de reconocer mensajes ACARS. Es decir,
tienen que pasar muchos mensajes para que el prototipo pudiera Demodular completamente
el mensaje.
50
5.7 Optimizacio´n de Prototipo: Concepto desmuestreo con Demodulacio´n AM.
Figura 5.27: Resultado de la Demodulacion del prototipo optimizado
51

Cap´ıtulo 6
II Fase: Decodificacio´n
En este capitulo desarrolla la teor´ıa pertinente de la estructura de una trama ACARS,
dependiendo si es un mensaje Downlink o mensaje Uplink. Para ello se identifica la estructura
de un Byte (Byte entregado por el programa de GnuRadio) y conocer la tabla de traduccio´n
ASCII para pasar de un Byte a un dato tipo CHAR. Cumpliendo con las dos caracter´ısti-
cas anteriores se evidencia la decodificacio´n ACARS a trave´s del programa de GnuRadio en
desarrollo de la Fase I. Como u´ltima prueba se realiza una comparacio´n de decodificar un
mismo mensaje ACARS bajo el programa pago PlanePloter y el programa de GnuRadio.
53
6. II FASE: DECODIFICACIO´N
6.1. Trama ACARS
BIT ”Sync”: Son dos bytes “+” y ” *” la cual habilita transmisio´n del Bloque ACARS
donde esta´ contenido el mensaje.
SYN: Son dos Bytes que ejercen la sincronizacio´n del bloque ACARS.
SOH: Habilita el comienzo del bloque ACARS.
Modo: Registra la informacio´n acerca de la informacio´n de la estacio´n base. Si la
cobertura es de tipo B, el indicador sera´ 2.
Direccio´n: Define el ID del aeronave o MU.
ACK-NACK: Para´metro para notificar el estado del anterior mensaje. ACK notifica
una recepcio´n positiva y NACK notifica una retransmisio´n del mensaje anterior ante
una notificacio´n negativa.
Label: Indicador que define el tipo de mensaje.
Block ID: Es identificador nume´rico secuencial que sirve como para´metro para duplicar
un mensaje ante un NACK o cuando no se responde una peticio´n. De manera que cuando
se duplica el mensaje se deja el mismo nu´mero secuencial.
STX: Indicador de comienzo del mensaje.
Mensaje: Esta´ contenida la informacio´n nativa del MU. Ma´ximo puede contener 220
Bytes.
ETX-ETB: Fin del mensaje.
BCS: Fin de transmisio´n del bloque ACARS.
54
6.1 Trama ACARS
F
ig
u
ra
6
.1
:
E
st
ru
ct
u
ra
d
e
u
n
m
en
sa
je
A
C
A
R
S
.
55
6. II FASE: DECODIFICACIO´N
Figura 6.2: Tabla ASCII para el protocolo ACARS
La estructura del bloque ACARS esta´ definido por una tabla de comparacio´n de Bits
Vs Bytes (Ver Figura 6.2). De manera que la traduccio´n de los bits ACARS a datos CHAR
(Byte) se realiza a trave´s de la tabla presentada.
6.2. Bloque de decodificacio´n ACARS en GNU-Radio
Por cada byte, hay 7 bits de informacio´n donde el LSB y MSB esta´n invertidas. Tambie´n
existe un bit de paridad. (Ver Imagen 6.3). En la tabla de la figura 6.2, la columna corresponde
a los Bits menos significativo y las filas referente a los bits ma´s significativos.
56
6.2 Bloque de decodificacio´n ACARS en GNU-Radio
Figura 6.3: El primer Byte de la Figura donde sus primero 4 bits menos significativos son
(0000) y los 4 bits mas significativos son (010), al cruzar fila y columna de la figura 6.2 el
resultado es SP. El segundo Byte, sus bits 4 bits menos significativos (0111) y sus 4 bits mas
significativos (100), al cruzar fila y columna de la figura 6.2 el resultado es N.
57
6. II FASE: DECODIFICACIO´N
F
ig
u
ra
6
.4
:
L
os
b
it
s
en
tr
an
te
s,
so
n
lo
s
B
y
te
s
en
tr
eg
a
d
o
s
p
o
r
el
b
lo
q
u
e
d
e
G
N
U
-R
a
d
io
d
e
la
d
em
o
d
u
la
ci
o´
n
A
C
A
R
S
.
P
a
ra
ca
d
a
B
y
te
en
tr
an
te
ti
en
e
q
u
e
id
en
ti
fi
ca
r
lo
s
b
it
s
M
S
B
y
lo
s
b
it
s
L
S
B
p
a
ra
co
n
ve
rt
ir
d
ic
h
o
B
y
te
en
u
n
a
d
at
o
C
H
A
R
a
tr
av
e´s
d
e
la
ta
b
la
A
S
C
II
.
E
n
p
ro
gr
am
ac
io´
n
P
yt
h
o
n
re
al
iz
a
u
n
C
a
se
:S
w
it
ch
p
a
ra
es
ta
b
le
ce
r
u
n
o
rd
en
en
tr
a
d
a
co
h
er
en
te
a
la
tr
a
m
a
A
C
A
R
S
d
e
la
fi
g
u
ra
6
.1
.
E
st
e
p
or
u
lt
im
o
so
b
re
sc
ri
b
e
el
re
su
lt
ad
o
(M
en
sa
je
A
C
A
R
S
)
en
u
n
te
x
to
p
la
n
o
58
6.2 Bloque de decodificacio´n ACARS en GNU-Radio
F
ig
u
ra
6
.5
:
D
e
ac
u
er
d
o
co
n
la
te
or´
ıa
d
e
la
co
m
p
o
si
ci
o´
n
d
e
la
tr
a
m
a
d
e
u
n
m
en
sa
je
A
C
A
R
S
,
se
p
u
ed
e
ve
ri
fi
ca
r
en
p
ri
m
er
a
in
st
a
n
ci
a
lo
s
b
it
s
d
e
S
Y
N
(*
+
),
y
lo
s
d
em
a´s
b
lo
q
u
es
ex
p
li
ca
d
o
s
en
la
te
o
r´ı
a
p
re
li
m
in
a
r
d
e
es
te
ca
p
it
u
lo
.
59

Cap´ıtulo 7
III Fase: Desarrollo interfaz gra´fica
ACARS
El capitulo Interfaz Gra´fica se desarrolla un aplicativo capaz de visualizar los mensajes
en una mapa de Google Maps. Para llevar a cabo lo anterior, empezamos disen˜ando un
aplicativo Web basado en HTML5/CSS3. En el aplicativo web se anida el API de google
Maps a trave´s de JavaScript. Posteriormente, conviene toda la programacio´n de la API de
Google Maps en JavaScript para plasmar la trayectoria de la aeronave y el historial actual
de la aeronave. Luego se realiza el procedimiento para disen˜ar y desarrollar la base de datos.
Despue´s programar la conexio´n con la base de datos y hacer las respectivas consultas con
PHP y JavaScript obteniendo los mensajes estructurados en archivos con XML. Habiendo
desarrollado la base de datos y el aplicativo Web solo falta adaptar la conexio´n entre GNU-
Radio-Python-SQL(Base de datos).
61
7. III FASE: INTERFAZ GRA´FICA
7.1. Ana´lisis y Planteamiento
Las API incluyentes en la anterior imagen hacen parte de la librer´ıa de servicios web
de google maps API. Cada API realiza una funcio´n espec´ıfica:
Directions API: Es un servicio que permite calcular la ruta ma´s o´ptima de un mapa
esta´tico (No en tiempo real. El resultado se resuelve a trave´s de una peticio´n http.
Distance Matrix API: Es un servicio que permite calcular el tiempo y la distancia
dada una ruta.
Elevation API: Es un servicio que permite determinar una elevacio´n promedio dada
una ubicacio´n geogra´fica.
Geocoding API: Es un servicio de conversio´n entre una direccio´n (Calle. Carrera
Avenida) y una ubicacio´n Geogra´fica. Dicho de otra manera, como una caja negra, si la
entrada es una direccio´n obtienes una localizacio´n geogra´fica, y viceversa, si la entrada
es una localizacio´n geogra´fica la salida es una direccio´n.
Time Zone API: Es un servicio que proporciona la diferencia horaria entre dos ubi-
caciones geogra´ficas de la tierra. Este tipo de solicitudes son HTTPS.
Roads API: Es un servicio que permite la mejor aproximacio´n geome´trica de una ruta
y el l´ımite de velocidad de un veh´ıculo a trave´s de la geolocalizacio´n GPS.
Places API: Es un servicio que proporciona informacio´n de lugares como negocios,
restaurantes etc., a trave´s de la base de datos de Google.
Todos los API-Google mencionados son servicios web, cuya utilidad es el intercambio de
informacio´n basado en JSON. Es decir, hace una peticio´n http a trave´s de una URL y una
llave google maps, y este a su vez devuelve una respuesta en texto plano con datos organi-
zados y estructurados. De modo que no existe API Google-Python capaz de desplegar una
interfaz gra´fica tal como un mapa para disen˜ar la trayectoria de una aeronave.
En conclusio´n, no satisface las necesidades y requerimientos del proyecto. GoogleMaps-
Python es un servicio web, es decir solo entrega una respuesta de una solicitud WEB. Entrega
un ACK de un servicio API.
Teniendo en cuenta conclusio´n anterior, el planteamiento resulta en utilizar un mapa
dina´mico basado en WEB a trave´s de API-JAVASCRIPT Y ANDROID MAP, soportado por
una base de datos (BD). Dicha DB esta´n almacenados toda la informacio´n de los mensajes
ACARS capturados por el programa receptor (RTL). La insercio´n de los datos de los mensajes
a la DB se ejecuta con una API Python-Mysql. La anterior estructura se resume en la figura
7.1
62
7.1 Ana´lisis y Planteamiento
Figura 7.1: Diagrama de la estructura de la interfaz gra´fica del usuario, con las tecnolog´ıas a
emplear
63
7. III FASE: INTERFAZ GRA´FICA
7.1.1. API MySQL-Python
Dicho aplicativo cubre la funcionalidad de insertar los datos en la base de datos de una
manera eficiente. Dicha eficiencia se mide con la disponibilidad de la informacio´n en el flujo
de datos entre el programa receptor y la base de datos. Se debe cumplir el requisito de ¿Co´mo
adaptar la conexio´n entre GNU-Radio (python y C) y una base de datos en MySQL?
7.1.2. Base de Datos (MySQL)
El disen˜o de la base de datos es el requerimiento ma´s importante de este planteamiento,
pues es el soporte para que la interfaz pueda funcionar. El disen˜o de la base de datos esta´
sujeto a los requerimientos de la interfaz gra´fica y los tipos de mensajes ACARS Downlink y
Uplink que existen.
La funcionalidad ma´s importante de la interfaz gra´fica es trazar la trayectoria o conocer la
ubicacio´n de una aeronave, y la representacio´n histo´rica de una aeronave (Estado en tiempo
real de la aeronave). La representacio´n histo´rica se lleva a cabo a trave´s de la clasificacio´n
de los tipos de mensajes ACARS. Para ello se debe hacer un trabajo de investigacio´n de,
cua´les son los tipos de mensajes existentes y desarrollar el aplicativo SQL para organizar
dicha informacio´n.
En base de los requerimientos del pa´rrafo anterior se deben disen˜ar las tablas relacio-
nales de la base de datos de tal manera que las consultas sean sencillas y los recursos de
programacio´n sean mı´nimas.
7.1.3. JAVASCRIPT- Google Maps
En esta seccio´n del planteamiento se desarrolla todo el soporte Web para poder contener
el aplicativo de Google Maps en JavaScript. Para ello primeros se debe configurar un servidor
WEB (Apache 2 ), luego el soporte HTML para el disen˜o sencillo de un pa´gina WEB, despue´s
la conexio´n con la base de datos y hacer las respectivas consultas (PHP y JavaScript) para
procesar la informacio´n. Posteriormente, conviene toda la programacio´n de la API de Google
Maps en JavaScript para plasmar la trayectoria de la aeronave y el historial actual de la
aeronave.
7.2. Metodolog´ıa
La Metodolog´ıa se desarrolla desde la interfaz gra´fica hacia el programa Python-MySQL.
Los pasos a seguir son los siguientes:
Disen˜ar pa´gina Web (HTML5-CSS3) y API Google Maps.
64
7.3 Disen˜o de Pagina Web
Desarrollar el aplicativo WEB para la conexio´n a la base de datos con PHP-AJAX. (La
base de datos simula mensajes de posicio´n de la aeronave para trazar la trayectoria).
Programar Aplicativo para insertar los datos de manera ordenada a la base de datos a
trave´s de C-Python(GNURadio)-MySQL.
Optimizacio´n de la conexio´n del DB y el aplicativo web para trazar varias trayectorias
en tiempo real.
7.3. Disen˜o de pa´gina Web con (HTML5-CSS3) y API Google
Maps
7.3.1. Pa´gina Web
El disen˜o de la pa´gina se divide en dos componentes; la pa´gina de inicio y el archivo de Ja-
vaScript la cual soporta el API de google Maps. Inicialmente, se tiene como criterio de disen˜o,
que la pa´gina web presente a manera de introduccio´n de que´ se trata la aplicacio´n Web y pos-
teriormente el mapa en otra pa´gina. El resultado de aplicacio´n web se muestra en la figura 7.2.
La pa´gina ofrece dos servicios. El primer servicio soporta la trayectoria de la aeronave en
tiempo real sobre un mapa. El segundo servicio presenta el historial de las actividades de los
aviones que haya recibido el RTL-SDR. Como primera instancia solo se desarrolla el primer
servicio como el principal aplicativo del proyecto.
7.3.2. API Google Maps
En esta seccio´n se debe logra programar el archivo JavaScript donde esta contenido el
mapa y lograr anexar dicho archivo a la pa´gina Web. En primer lugar, definimos la confi-
guracio´n ba´sica del API Google maps. Luego aumentamos la complejidad del co´digo para
conocer la ubicacio´n del dispositivo del usuario (Celular o computador) a trave´s de GPS o
red Mo´vil/WIFI. Por u´ltimo, agregamos el co´digo necesario para trazar trayectorias sobre el
mapa.
7.3.2.1. Creacio´n de un Mapa con Google Maps
La funcio´n initMap se ejecuta impl´ıcitamente por el elemento ”map” en la etiqueta
¡div¿del cuerpo HTML. Dicha funcio´n es utilizada para solicitar autorizacio´n a GOOGLE
MAPS para ejecutar el contenido del mapa a trave´s de KEY. dicho KEY es administrado
por Google API MANAGER.
65
7. III FASE: INTERFAZ GRA´FICA
Figura 7.2: Aplicacio´n web, basado en HTML5 y CSS3
66
7.3 Disen˜o de Pagina Web
Para generar un mapa es necesario crear una instancia a trave´s de ”new google.maps.Map(PARAMETROS)”.
A cuantos Google maps se ejecuten as´ı mismo son el nu´mero de instancias que se deben rea-
lizar.
1 function inMainMap () {
2 var centerLoad= {lat: 4.697558 , lng: -74.098894 };
La siguiente funcio´n espec´ıfica donde centrara el map la cargarse en el archivo HTML. El
centro se especifica con la Latitud y longitud en decimales. y el zoom esta´ la escala desde 0
(Nivel tierra)
1 var Mainmap = new google.maps.Map(document.getElementById(’map’), {
2 zoom: 10,
3 center:centerLoad
4 });
La instancia Marker permite agregar marcadores al mapa. La ubicacio´n esta´ controlada
por la variable centerLoad (Dicha ubicacio´n corresponde a la ciudad de Bogota´.)
1 var marker= new google.maps.Marker ({
2 position:centerLoad ,
3 map:Mainmap
4 });
El resultado del co´digo completo se refleja en la figura 7.3.
7.3.2.2. Activacio´n de la ubicacio´n de GPS del usuario
El me´todo navigator.geolocation.getCurrentPosition(OBJECT 1, OBJECT 2) entrega
dos atributos en forma de objetos. Cada objeto es una instancia que contiene informacio´n
de la solicitud. OBJECT1 obtiene informacio´n respecto a la ubicacio´n del dispositivo como
altura, velocidad. OBJECT2 contiene la informacio´n de errores del navegador al rechazar
la geolocalizacio´n. La instancia InfoWindow es la clase de la ventana de informacio´n para
desplegar datos de algu´n evento.
1 var infoWindow = new google.maps.InfoWindow ({map: map });
67
7. III FASE: INTERFAZ GRA´FICA
Figura 7.3: Creacio´n de un Mapa centrado en la ciudad de Bogota´ con un Marker de Google
Maps
68
7.3 Disen˜o de Pagina Web
Solicita permiso de localizacio´n al navegador a trave´s de navigator.geolocation.
1 if (navigator.geolocation) {
2 navigator.geolocation.getCurrentPosition(
3 function(position) {
4 var pos = {
5 lat: position.coords.latitude ,
6 lng: position.coords.longitude
7 };
8 infoWindow.setPosition(pos);
9 infoWindow.setContent(’Location found.’);
10 map.setCenter(pos);
11 },
12 function () {
13 handleLocationError(true , infoWindow , map.getCenter ());
14 });
15 }
16 else{handleLocationError(false , infoWindow , map.getCenter ());}
17 function handleLocationError(browserHasGeolocation , infoWindow , pos){
18 infoWindow.setPosition(pos);
19 infoWindow.setContent(browserHasGeolocation ?
20 ’Error: The Geolocation service failed.’ :
21 ’Error: Your browser doesn\’t support geolocation.’);
22 }
El resultado del co´digo anterior se refleja en la figura 7.4.
69
7. III FASE: INTERFAZ GRA´FICA
Figura 7.4: La ubicacio´n real en la ciudad de New York cuando se ejecuto´ el co´digo en el lado
del cliente.
70
7.3 Disen˜o de Pagina Web
7.3.2.3. Programacio´n de la trayectoria en el mapa
Ubicaciones de la primera trayectoria:
1 var trajec =[
2 {lat :4.633911 , lng : -74.176484} ,
3 {lat :4.649833 , lng : -74.155068} ,
4 {lat :4.662140 , lng : -74.136945} ,
5 {lat :4.691128 , lng : -74.081322} ,
6 {lat :4.745104 , lng : -74.031218} ,
7 {lat :4.830095 , lng : -73.965087} ,
8 {lat :4.907013 , lng : -74.016900}
9 ];
Ubicaciones de la segunda trayectoria:
1 var trajec2 =[
2 {lat :4.608863 , lng : -74.022617} ,
3 {lat :4.643611 , lng : -74.143302} ,
4 {lat :4.695503 , lng : -74.196541} ,
5 {lat :4.777298 , lng : -74.267555}
6 ]
Luego creamos las instancias Polyline para crear las l´ıneas en base de las ubicaciones.
1 var flightTraject= new google.maps.Polyline ({
2 path: trajec ,
3 geodesic: true ,
4 strokeColor: ’#FF0000 ’,
5 strokeOpacity: 1.0,
6 strokeWeight: 2
7 });
8
9 var flightTraject2= new google.maps.Polyline ({
10 path: trajec2 ,
11 geodesic: true ,
12 strokeColor: ’#000000 ’,
71
7. III FASE: INTERFAZ GRA´FICA
Figura 7.5: La ubicacio´n real en la ciudad de New York cuando se ejecuto´ el co´digo en el lado
del cliente.
13 strokeOpacity: 1.0,
14 strokeWeight: 2
15 });
Luego de crear y configurar los atributos de los objetos creados a partir de las instancias
anteriores lo implementamos en el objeto map, donde se encuentra el mapa a trave´s de la
funcio´n setMap.
1 flightTraject.setMap(map);
2 flightTraject2.setMap(map);
El resultado del co´digo anterior se evidencia en la Figura 7.5
72
7.4 Desarrollo de aplicativo JavaScript y PHP
En la siguiente seccio´n, se realiza el codigo para obtener dichas ubicaciones desde una
base de datos MySQL y generar un script .sh donde perio´dicamente este insertando datos a
la DB (Simula el papel funcional de GNURadio). El resultado de esta prueba es que se simula
en tiempo real el movimiento de la aeronave en google Maps.
7.4. Desarrollo del aplicativo WEB para la conexio´n a la base
de datos con PHP-AJAX.
En esta fase del proyecto ya existe una aplicacio´n Web capaz de mostrar de una manera
amable al usuario el contexto del proyecto. Tambie´n existe el archivo .js capaz de manipular
un mapa con GPS y trazar trayectorias sobre la misma.
El objetivo de esta fase es hacer peticiones perio´dicas al servidor a trave´s de AJAX por
medio de JQUERY. La finalidad es obtener los datos desde la DB de las ubicaciones para
poder trazar una trayectoria. Dichas peticiones no son ma´s que consultas que se realizan a
trave´s de PHP.
La ventaja de usar AJAX sobre JavaScript es obtener los datos del servidor sin necesidad
de recargar toda la pa´gina, de manera que solo se actualiza el mapa. Dicha ventaja permite
que sea ma´s ra´pido el programa y menos carga de bajada para el servidor. Hay que tener en
cuenta que AJAX es una extensio´n de JAVASCRIPT, es decir hereda la sintaxis de JavaS-
cript, pero con funcionalidades potentes para aplicaciones en tiempo real.
En primer lugar, se debe instalar y configurar un servidor Web (APACHE 2) para alojar
los archivos de la pa´gina web, archivos de JavaScript y PHP. La ruta para alojar dichos
archivos en el servidor en Ubuntu se encuentra en la ruta varwwwhtmlTU CARPETA. Ini-
cialmente la base de datos se disen˜a e implementa una tabla donde contiene el Nu´mero de
vuelo y la posicio´n Geogra´fica (Latitud y Longitud) a trave´s de un archivo sql.
– COMIENZO DEL FICHERO .sql –
1 DROP database ACARS;
2 CREATE database ACARS;
3 USE ACARS;
4 CREATE TABLE Vuelo
5 (
6 ID INT NOT NULL AUTO_INCREMENT ,
7 Identificacion CHAR (9),
8 Latitud FLOAT(6,3),
9 Longitud FLOAT (6,3),
73
7. III FASE: INTERFAZ GRA´FICA
10 PRIMARY KEY (ID)
11 ) ENGINE=InnoDB;
12
13 INSERT INTO Vuelo VALUES (null ,’AV965 ’,’4.633911 ’,’ -74.176484 ’);
14 INSERT INTO Vuelo VALUES (null ,’AV965 ’,’4.649833 ’,’ -74.155068 ’);
15 INSERT INTO Vuelo VALUES (null ,’AV965 ’,’4.662140 ’,’ -74.136945 ’);
16 INSERT INTO Vuelo VALUES (null ,’AV965 ’,’4.691128 ’,’ -74.081322 ’);
17 INSERT INTO Vuelo VALUES (null ,’AV965 ’,’4.745104 ’,’ -74.031218 ’);
18 INSERT INTO Vuelo VALUES (null ,’AV965 ’,’4.830095 ’,’ -73.965087 ’);
19 INSERT INTO Vuelo VALUES (null ,’AV965 ’,’4.907013 ’,’ -74.016900 ’);
20
21 SELECT * FROM Vuelo;
Ya existiendo una DB, los pasos a seguir hacer es la conexio´n con PHP desde la pa´gina
web para realizar la consulta de la longitud y la latitud de la tabla VUELO. Luego de
poder hacer consultas desde la pa´gina Web, se procede a realizar dichas peticiones desde el
archivo JavaScript a trave´s de AJAX. Y por u´ltimo realizar el co´digo necesario para que
dichas solicitudes se hagan perio´dicamente de tal manera que se cargue solamente el mapa.
Finalmente insertar datos a la DB para comprobar el funcionamiento de la trayectoria en
tiempo real sin necesidad de recargar totalmente la pa´gina.
7.4.1. Consultas al BD desde la pa´gina Web con PHP.
La funcio´n del archivo PHP es realizar la conexio´n a la DB y extraer los datos a trave´s
de consultas. Dichos datos se organizan de una manera estructurada a trave´s de un archivo
XML. Desde la perspectiva de una caja negra, la entrada son peticiones SQL y la salida es
un archivo XML donde los datos son la respuesta del servidor de la peticio´n SQL.
Antes de comenzar se debe precisar que la para la versio´n 7 de PHP o superiores la clase
MYSQL ya no existe. Para ello se debe utilizar MYSQLi. En PHP existen dos formas de
programar, en forma procedimental y la programacio´n orientado a objetos. En este proyecto
el estilo de programacio´n usado es la Orientado a objetos. Cabe resaltar que las dos formas
de programacio´n tienen la misma eficiencia de co´digo. En primer lugar, se debe realizar una
conexio´n a la DB.
1 <?php
2
3 // CONNECTION.PHP
74
7.4 Desarrollo de aplicativo JavaScript y PHP
4
5 // Carga la configuracion
6 $config = parse_ini_file(’conf.ini’);
7
8 // Conexion con los datos del ’config.ini’
9
10 $connect= new mysqli(
11 ’localhost ’,
12 $config[’username ’],
13 $config[’password ’],
14 $config[’dbname ’]);
15
16 if ($connect ->connect_errno) {
17 echo "Fallo al conectar a MySQL: " . $connect ->connect_error;
18 }
19 /*else {
20 echo ’Conectado a la base de datos ’;
21 }*/
22 ?>
El archivo conf.ini es un texto plano donde contiene un ARRAY. Dicho ARRAY esta´ la
informacio´n de la Base de Datos, tal como el usuario, la contrasen˜a y el nombre de la DB.
La funcio´n parse ini file convierte el ARRAY en una variable PHP. A partir de la clase
MYSQLi se crea el objeto CONNECT a trave´s de la instancia new mysqli . El condicional
permite controlar la conexio´n segu´n si fue exitosa o fallo´ la conexio´n.
En segundo lugar, se realiza la consulta y organiza los datos en un archivo XML.
1
2
3 <?php
4 // LOCATION.PHP
5 // Archivo de conexion a la base de datos
6 require(’connection.php’);
7
8 $result= $connect ->query("SELECT Identificacion ,Latitud ,Longitud FROM
9 Vuelo ORDER BY ID ASC");
75
7. III FASE: INTERFAZ GRA´FICA
10 if(! $result ){
11 echo "Lo sentimos , este sitio web esta experimentando problemas.";
12 }/*else {
13 echo ’Consulta correcta ’;
14 }*/
15
16 // Start XML file , create parent node
17 $dom = new DOMDocument("1.0");
18 $node = $dom ->createElement("traject");
19 $parnode = $dom ->appendChild($node );
20 header("Content -type: text/xml");
21
22 // Add to XML document node
23 while ($row = $result ->fetch_assoc ()){
24 $node = $dom ->createElement("traject");
25 $newnode = $parnode ->appendChild($node );
26 $newnode ->setAttribute("Identificacion", $row[’Identificacion ’]);
27 $newnode ->setAttribute("Latitud", $row[’Latitud ’]);
28 $newnode ->setAttribute("Longitud", $row[’Longitud ’]);
29 }
30 echo $dom ->saveXML ();
31 ?>
La funcio´n require(’connection.php’) carga el archivo connection.php, realizado en el
co´digo anterior. La variable $connect− >query es un llamado de la funcio´n query al objeto
connect declarado en el archivo connect.php. Los para´metros de la funcio´n query es un peti-
cio´n SQL. En este caso se realizar una consulta a la tabla Vuelo de la base de datos ACARS
creados anteriormente. La peticio´n SQL es: (”SELECT Identificacion,Latitud,Longitud
FROM Vuelo ORDER BY ID ASC”) cuyo resultado lo entrega de manera ascendente segu´n
el ID. (ID es un campo de la tabla Vuelo de la Base de Datos ACARS).
Con la sentencia $dom =new DOMDocument(”1.0”); creamos el archivo XML. La idea
es anexar el resultado de la base de datos en archivo XML. Un archivo XML esta´ compuesto
de nodos, este a su vez hereda hijos. Para diferenciar un nodo de otro nodo es a trave´s de sus
atributos. En este ejemplo solo usaremos nodos con atributos.
A trave´s de un While se crear un nodo diferente con su respectivo atributo cada fila de la
76
7.4 Desarrollo de aplicativo JavaScript y PHP
tabla consultada. Dicha funcionalidad se ejecuta con while ($row = $result− >fetch assoc() .
Primero se asigna un nombre a cada nodo con la sentencia $node = $dom− > createEle-
ment( ”traject”);. Se crea una herencia del nodo creado con $newnode = $parnode − >
append Child ($node);. Y a cada Sub-nodo se le asigna un valor en forma de un atributo con
$newnode− >setAttribute(”Latitud”, $row [’Latitud’]);. El primer para´metro es el nombre
que se le asigna en el archivo XML y el segu´n para´metro es el nombre del campo en la tabla
consultada en la base de datos.
Por ultimo exportamos el archivo XML con la sentencia echo $dom-¿saveXML(); . Para
acceder al resultado del co´digo anterior se debe indicar la ubicacio´n del archivo Location.php
segu´n el servidor que se este´ usando.
7.4.2. Peticiones al servidor con programacio´n AJAX.
Manteniendo el mismo co´digo JavaScript de los ejemplos anteriores, cuyas funciones han
sido crear un Mapa de Google en archivo HTML a trave´s de una llave de GOOGLE API. Di-
bujar marcadores y trayectorias sobre el mapa creado. Y por el ultimo la ubicacio´n por GPS
del usuario. El co´digo a implementar esta´ basado en JQUERY, es decir, se escribe AJAX con
Jquery. En resumidas palabras JQUERY es una forma de escribir JavaScript de una manera
ma´s sencilla y eficiente. El co´digo adicional es el siguiente:
1 var filename = ’xxxxxxxx.php’;
2 function request (){
3 $.ajax({
4 type: "GET",
5 cache: false ,
6 url: filename ,
7 dataType: "xml",
8 success: parseXML ,
9 error : onXMLLoadFailed
10 });
11 }
La variable var filename = ’http://10.0.1.52/ACARS/include/location.php’ ;es la ubica-
cio´n del archivo XML, creado a partir de PHP. La IP es la ubicacio´n del servidor. Para evitar
problemas es recomendable escribir la direccio´n IP del servidor en vez de LOCALHOST. El
inicio de JQUERY se denota por la variable peso ($) $.ajax() . El primer para´metro type: es el
tipo de peticio´n. ”GET” es para obtener un resultado y ”POST” para insertar algu´n valor. El
77
7. III FASE: INTERFAZ GRA´FICA
segundo para´metro cache: es para indicarle que no guarde informacio´n adicional del servidor,
para evitar sobrecarga en el servidor. El tercer para´metro indicamos la ubicacio´n del archivo
en el servidor. El cuarto para´metro a pesar de que es un archivo PHP el resultado es un docu-
mento XML, se debe especificar el resultado de dicha peticio´n. Los dos para´metros siguientes
son las acciones a seguir en caso en que la peticio´n haya sido correcta (success: parseXML) ,
caso contrario cuando haya ocurrido algu´n error (error : onXMLLoadFailed) . Vale la pena
aclarar que los dos anteriores para´metros son funciones.
En caso que haya ocurrido algu´n error se ejecuta la funcio´n onXMLLoadFailed(), solo
muestra un error. Tal como esta´ escrito:
1 function onXMLLoadFailed (){ alert("Servicio no disponible. Contacte
2 con el Administrador para mas informacion")}
Dado el caso que la peticio´n haya sido exitosa, AJAX ejecuta la funcio´n parseXML() .
Esta funcio´n se debe leer el archivo XML y extraer dichos valores. Despue´s, hacer las instan-
cias respectivas para insertar los marcadores y la trayectoria con las ubicaciones geogra´ficas
obtenidas desde el XML mediante la base de datos. El co´digo correspondiente es el siguiente:
1 function parseXML(xml){
2 var markerCoords =[];
3 var marker =[];
4
5 $(xml).find("traject").each(function(i){
6 var lat = $(this).attr(’Latitud ’);
7 var lng = $(this).attr(’Longitud ’);
8 markerCoords[i] = new google.maps.LatLng(parseFloat(lat),parseFloat(lng ));
9 marker[i]= new google.maps.Marker ({
10 map:map
11 });
12 marker[i]. setPosition(markerCoords[i]);
13 });
14 var flightTraject= new google.maps.Polyline ({
15 path: markerCoords ,
16 geodesic: true ,
17 strokeColor: ’#FF0000 ’,
78
7.4 Desarrollo de aplicativo JavaScript y PHP
18 strokeOpacity: 1.0,
19 strokeWeight: 2
20 });
21 flightTraject.setMap(map);
22 // alert(markerCoords );
23 }
La funcio´n parseXML(xml) es un para´metro que recibe como argumento el resulta-
do de la peticio´n Ajax, en este caso es un archivo XML. Es decir, la funcio´n recibe co-
mo variable o un objeto denominado xml. Para fines posteriores declaramos dos arrays.
En este array var marker=[]; se almacena los objetos instanciados de cada marcador y
var markerCoords=[]; recibe las ubicaciones geogra´ficas para dibujar la trayectoria y los
marcadores sobre el mapa.
Luego con la funcio´n find sobre el objeto XML busca el nombre de cada nodo traject,
a trave´s de un bucle mediante each $(xml).find(”traject”).each(function(i) . Con la fun-
cio´n attr(’Latitud’); extrae el valor del atributo para cada nodo en una variable var lat =
$(this).attr(’Latitud’);. La variable markerCoords[i] guarda todas las ubicaciones para cada
ciclo que encuentra un nodo en el archivo XML. Luego realiza una instancia para convertir las
variables geogra´ficas (de variables STRING a variables FLOAT con parseFloat) en objetos a
trave´s de new google.maps.LatLng.
Posterior, con marker[i].setPosition(markerCoords[i]) ; plasma los marcadores segu´n las
coordenadas en un mapa. Y flightTraject.setMap(map); dibuja la trayectoria de todas las
ubicaciones almacenadas en el array flightTraject .
7.4.3. Optimizacio´n de co´digo AJAX para trayectoria en tiempo real.
Ahora la cuestio´n es cada cuanto debe realizar las peticiones de consulta al servidor. Se
pensar´ıa en implementar un while controlado al co´digo AJAX escrito. De tal manera que rea-
liza el mismo co´digo indefinidamente cada cierto tiempo. Sin embargo, en JavaScript existe
un me´todo de la clase JQUERY que permite ejecutar una misma funcio´n cada cierto tiempo.
Teniendo en cuenta el me´todo request() para la peticio´n AJAX, el “Bucle” se define de la
siguiente manera:
1 setInterval(request , 30000);
79
7. III FASE: INTERFAZ GRA´FICA
Figura 7.6: Como la funcio´n es cada 30 segundos, au´n no ha enviado la peticio´n al servidor
(Archivo PHP).
Cuyo primer para´metro es una funcio´n, en este caso la funcio´n donde esta´ contenido el
co´digo AJAX. El segundo para´metro es el tiempo reiterativo (en ms) que va ejecutar la fun-
cio´n definido en el primer para´metro.
Al ejecutar el co´digo completo, la secuencia se define de la siguiente manera:
Antes de hacer la consulta (Antes de 30segundos). Ver Figura 7.6
Despues de hacer la consulta (Despues de 30 Segundos) Ver Figura 7.7
Para simular una trayectoria en tiempo real, simulamos dicho comportamiento agre-
gando una nueva ubicacio´n desde la Base de datos. Ver Figura 7.8
80
7.4 Desarrollo de aplicativo JavaScript y PHP
Figura 7.7: Pasado los 30 segundos obtiene la respuesta del servidor y lo plasma en el mapa.
Hay que tener en cuenta que los marcadores son las ubicaciones geogra´ficas y la trayectoria es la
unio´n de los mismas. La idea de cada marcador es que al ocurrir el evento de un click sobre un
marcador despliegue el mensaje ACARS.
81
7. III FASE: INTERFAZ GRA´FICA
Figura 7.8: Al agregar un nuevo punto geogra´fico a la base de datos, el mapa, pasado los 30
segundos actualiza el nuevo marcador.
82
7.5 Programacio´n de aplicativo entre MYSQL y GNU-Radio
7.5. Programacio´n de aplicativo para insertar los datos de ma-
nera ordenada a la base de datos a trave´s de Python
(GNURadio)-MySQL.
Teniendo el resultado de la demodulacio´n y la decodificacio´n en GNU-Radio, el paso
a seguir es insertar los datos en una base de datos MySQL desde GNU-Radio. Desde un
archivo Python actu´a como un buffer para identificar un mensaje ACARS e inmediatamente
insertar los datos a la base de datos. El Buffer esta implementado con un control de flujo de
datos. Dicho control permite establecer la longitud del mensaje, ya que esta es variable segu´n
el contenido del paquete. Dicho archivo Python se ejecuta simulta´neamente a trave´s de un
bloque de GNU-Radio denominado embedded de GNU-Radio.
7.5.1. Trabajando con block Python embedded de GNU-Radio
El bloque Python embedded permite interactuar los datos provenientes de otro bloque de
GNURadio, para realizar cualquier actividad escrita en Python y obtener una nueva salida
de datos; en otras palabras, una caja blanca. La estructura del co´digo por defecto de este
bloque se refleja en la Figura 7.9
El diagrama de la Figura 7.9 resume la estructura del co´digo que entrega por defecto
GNURadio. La cuestio´n es co´mo adaptar nuestro co´digo en la estructura dada. Para empe-
zar, si se necesita anexar un API adicional o una librar´ıa externa, Inicio es el espacio ideal
para declarar librer´ıas, API, Archivos .PY o bloques de GNURadio.
Por la Clase GnuRadio puede interpretar el bloque dado. Existen varios tipos de bloques
como SycBlock y BasicBlock. De acuerdo a la clase heredada por GnuRadio se pueden ins-
tanciar los para´metros y funciones contenidos dentro del me´todo work() .
Los para´metros iniciales se refieren a los tipos de variables que se van a manipular. Dichas
variables se deben declarar con la librer´ıa numpy. Para declarar el tipo de variable sea entrada
o salida se define como in sig= [np.complex64] , donde complex64 es una variable compleja.
Para identificar que´ tipos de variables existen y cua´l es el adecuado segu´n la aplicacio´n a
programar, se debe consultar la referencia de la librer´ıa numpy.
En la funcio´n def work(self, input items, output items) es donde ocurre toda la magia.
Aca´ definimos el tratamiento que se le va a dar a los datos entrantes. Por ejemplo , establecer
el flujo de datos entre la salida con los datos entrantes output items[0][:]=input items[0]. Vale
aclarar que la funcio´n work() se ejecuta cada vez que la variable es diferente de cero, es decir,
es un Bucle controlado por los datos que existan en la entrada del bloque Python embedded.
83
7. III FASE: INTERFAZ GRA´FICA
F
ig
u
ra
7
.9
:
D
ia
g
ra
m
a
p
o
r
d
ef
ec
to
d
el
b
lo
q
u
e
e
m
be
d
d
ed
P
y
th
o
n
d
e
G
N
U
-R
a
d
io
.
84
7.5 Programacio´n de aplicativo entre MYSQL y GNU-Radio
7.5.2. Conexio´n a la DB con Python y MySQL desde GNU-Radio
En primer lugar, hay que descargar la librer´ıa MySQL para Python que se encuentra en la
pa´gina oficial de MySQL. En la pa´gina oficial se encuentra la referencia de las clases, me´todos
y ejemplos para conectar a la base de datos desde Python. En este apartado realiza una gu´ıa
de co´mo adaptar la librer´ıa MySQL en GNURadio, gu´ıa que dif´ıcilmente se encuentra en
algu´n documento.
Al principio de este documento ya hab´ıamos creado nuestra base de datos ACARS con una
tabla denominada Vuelo, cuyo propo´sito hab´ıa servido para insertar ubicaciones geogra´ficas
para comprobar el funcionamiento del aplicativo de Google Maps. Ahora, se crea otra tabla
en la base de datos para almacenar los mensajes ACARS provenientes de GNURadio. Dicha
tabla se define como mensaje, el co´digo SQL se define de la siguiente manera:
1 CREATE TABLE mensaje
2 (
3 IDm INT NOT NULL AUTO_INCREMENT ,
4 fecha TIMESTAMP DEFAULT CURRENT_TIMESTAMP ,
5 iniM VARCHAR (3),
6 modo VARCHAR (2),
7 rgo VARCHAR (8),
8 ack VARCHAR (4),
9 tipo CHAR(2),
10 numero VARCHAR (6),
11 iniT VARCHAR (4),
12 vuelo VARCHAR (10),
13 textI text ,
14 finT VARCHAR (4),
15 PRIMARY KEY (ID)
16 ) ENGINE=InnoDB;
Todos los campos de la tabla mensajes son respectivamente la estructura de la trama de
un mensaje ACARS. A excepcio´n del campo IDm INTy el campo fecha TIMESTAMP.
Estos dos campos se generan de manera automa´tica. El primero es un identificador y el se-
gundo registra la hora y fecha en que fue agregado dicho mensaje a la base de datos.
Habiendo instalado la librer´ıa de MySQL en Python, es posible empezar a programar
nuestro co´digo en Python embedded para conectar nuestro flujo de datos de GNU-Radio en
85
7. III FASE: INTERFAZ GRA´FICA
Figura 7.10: Co´digo del bloque de GNU-Radio para insertar los mensajes ACARS en MySQL
a trave´s de embedded Python de GNU-Radio. I Parte
86
7.5 Programacio´n de aplicativo entre MYSQL y GNU-Radio
Figura 7.11: Bloque de ACARS MySQL con embedded Python de GNU-Radio. I Parte
nuestra base de datos. Con la estructura anterior del bloque Python embedded de la Figura
7.9, vamos a explicar el co´digo de la Figura 7.10 para conectar e insertar un mensaje ACARS
a la DB.
En el recuadro Inicio se agrega la librer´ıa MySQL import mysql.connector. El Objeto
permite insertar los valores de usuario, contrasen˜a, Direccio´n IP y nombre de la Base de
datos. Y adema´s, la librer´ıa import errorcode que es un me´todo que retorna un error dado
caso que´ ocurriera.
Pasando a la clase del bloque de Python, adicionamos el co´digo para conectarse a la
DB. Para ello recurrimos a un Try para intentar la conexio´n y Except dado caso que no
se pueda ejecutar la conexio´n. En Try ejecutamos el me´todo connect()a trave´s del objeto
cnx = mysql.connector para insertar los para´metros de conexio´n. Y ejecutamos el mensaje
que la conexio´n fue exitosa con print Data Base ACARS Connnected . En Except ejecuta dos
IF donde la primera se ejecuta cuando los para´metros indicados no coinciden con la Base de
Datos. La segunda se ejecuta cuando la base de datos no existe.
En Para´metros Iniciales establecemos el tipo de variable a utilizar. Dado que se mani-
pulan datos tipo Byte, establecemos out sig=[np.int8] para los datos entrantes y salientes.
En este momento el bloque resultar´ıa como la figura 7.11.
Luego de establecer las condiciones iniciales del bloque Python, ahora solo falta programar
las funcionalidades al bloque ACARS MySQL. Esencialmente la idea es obtener un mensaje
a trave´s de la variable output items[0] , extraer y organizar los datos en variables de un
diccionario. Posteriormente realizar la instancia de la conexio´n SQL para insertar los datos en
la Base de Datos. Dentro de la funcio´n Works, el diccionario data G inicializa las variables
de los campos de la tabla mensaje creado anteriormente.
7.5.3. Control de flujo de datos de los Mensajes ACARS
GnuRadio tiene bloques predeterminados que determinan el flujo de datos del flujograma.
Este flujo de datos esta dado por ı´tems o muestras contenidos en objetos denominados Array.
87
7. III FASE: INTERFAZ GRA´FICA
De modo que el flujo de datos en GnuRadio esta´ dada por el taman˜o o longitud de los arrays.
En Python un array es un objeto de la librer´ıa Numpy cuyo atributos y me´todos permiten
la manipulacio´n de los datos.
Existen generalmente dos bloques predeterminados en GnuRadio que en la pra´ctica son
clases constructoras programados en Python. La clase SyncBlock y Bloques Variables. Los
bloques variables son el tipo de clases que permiten configurar con un escalar la correlacio´n
que existe con los datos entrantes y los datos salientes. Es decir, permite un taman˜o variable
del array saliente con respecto a longitud del array entrante. La clase SyncBlock no permite
que exista array variable entre los datos entrantes y salientes, es decir la longitud del objeto
Array para in y out debe ser la misma.
Si se tiene en cuenta que los mensajes ACARS no son mensajes con longitud fija sino va-
riable, no existe un mecanismo que permita de manera automa´tica identificar el comienzo y el
termino de un paquete ACARS. El resultado ser´ıa que se inserten datos de manera aleatoria
sin lograr identificar un mensaje ACARS. Por esa razo´n debe existir dentro del programa
de GnuRadio un mecanismo que permita identificar la longitud de un mensaje ACARS y
posteriormente capturar dicho mensaje de manera inmediata antes de insertar los datos en
la base de datos.
Dado que el bloque Python Embbeded utiliza la clase SyncBlock, no permite cambiar la
longitud de un array. Por ello se disen˜a otro bloque Python Embbeded para calcular la longi-
tud o el nu´mero de ı´tems que tiene el mensaje ACARS en tiempo real junto con un Mo´dulo
Python como clase constructora. En el bloque MySQL ACARS obtiene el mensaje ACARS
de acuerdo con la longitud del mensaje calculado previamente y posteriormente insertarlo en
la base de datos.
7.5.3.1. Control de Flujo: Ca´lculo de nu´mero de items del mensaje
Antes de describir el co´digo para hallar la longitud de un mensaje ACARS es pertinente
programar la clase constructora o un constructor que permita manipular el resultado de di-
cho ca´lculo. La manipulacio´n se refiere a “transportar” el resultado de la clase Control Flujo
hacia la otra clase MySQL ACARS como un objeto.
El constructor se programa bajo el bloque de GnuRadio denominado Python Module,
cuya funcionalidad permite ejecutar el co´digo escrito e importar dicha programacio´n en cual-
quier bloque de GNURadio. Para este caso sirve como puente entre los dos bloques Python
Block, el primero donde se calcula la longitud denominado Flujo ACARS y el segundo ya
denominado MySQL ACARS donde captura el mensaje segu´n la longitud calculado, dado
por el objeto de la clase constructor y pertinentemente la insercio´n del mensaje en la Base
de datos.
88
7.5 Programacio´n de aplicativo entre MYSQL y GNU-Radio
La clase constructor Items queda determinado de la siguiente manera:
1 class Items:
2
3 def __init__(self ,NoItems=0,ack =0):
4 self.NoItems=NoItems
5 self.ack=ack
6
7 def get_NoItems(self):
8 return self.NoItems
9 def get_ack(self):
10 return self.ack
11 def set_NoItems(self ,n):
12 self.NoItems=n
13 def set_ack(self ,a):
14 self.ack=a
15
16 AcarsObject=Items ()
Un constructor permite inicializar variables cuya manipulacio´n ejecuta me´todos inheren-
tes al objeto al instanciar una clase. El me´todo constructor en Python esta´ determinado por
la palabra reservada init cuya funcionalidad consiste en inicializar los variables al instan-
ciar la clase Items. Dichas variables son: el No de ı´tems donde contiene el taman˜o de array
donde cabe un mensaje ACARS y la confirmacio´n para indicar la existencia de un mensaje.
Para cada variable existe un me´todo SET y un me´todo GET. El me´todo set permite inser-
tar o actualizar el valor de la variable. El me´todo GET permite realizar consultas del valor
actual de la variable. La instancia ocurre con la sentencia AcarsObject¯Items(), cuyo objeto
es AcarsObject instancia del clase Items().
Creamos un nuevo Python Block y manteniendo la misma estructura del bloque MySQL
en la Figura 7.9 configuramos el para´metro de entrada para lograr inicializar el objeto Acar-
sObject. El objeto AcarsObject debe ser para´metro de entrada de los dos bloques embebidos:
Flujo ACARS y MySQL ACARS (Ver Imagen 7.12). Tal requerimiento permite la existencia
de un puente de control entre esos dos bloques.
Luego de detallar el constructor e inicializar las variables y el objeto AcarsObject, se
describe el algoritmo para calcular la longitud del mensaje ACARS. (Ver Imagen 7.13 )
El algoritmo presentado en la figura 7.13 explica de forma general el funcionamiento del
89
7. III FASE: INTERFAZ GRA´FICA
Figura 7.12: El objeto ObjectACARS como parametro de entrada del Bloque de ACARS MySQL
bloque de Flujo ACARS. Por cada array entrante en el bloque se recorre todos los elementos
del vector a trave´s de un FOR. Al mismo tiempo un contador para cada contar cada elemen-
to del Array recorrido. De acuerdo con la teor´ıa de la estructura de una trama ACARS, los
caracteres *+ identifica el inicio de un mensaje ACARS y el cara´cter ¡ETX¿define el fin del
mensaje. El algoritmo es sencillo, si al recorrer el Array existen dos caracteres +* consecu-
tivos inicializa el contador en cero. Si al recorrer el Array existe el cara´cter ¡ETX¿entonces
el contador ha contado N veces desde el inicio hasta el final del mensaje, es decir la longitud
del paquete. Al cumplirse la anterior condicio´n define la longitud del mensaje y el valor “on”
ACK a trave´s del objeto AcarsObject con el me´todo SET para cada variable.
7.5.3.2. Control de Flujo: Control de Items del mensaje
En realidad, se realiza una modificacio´n en la estructura en el co´digo escrito en el bloque
MySQL ACARS. En primera instancia agregamos un para´metro inicial al bloque, tal como
se hizo en el bloque de Flujo ACARS en la Figura 7.12.
Despue´s de inicializar el objeto ObjectACARS, en la Figura 7.14 describe el algoritmo
para capturar el mensaje ACARS de acuerdo con la longitud calculado. Este u´ltimo co´digo
es au´n ma´s sencillo que el anterior. En vez de un contador, este es un acumulador del Array
90
7.5 Programacio´n de aplicativo entre MYSQL y GNU-Radio
Figura 7.13: Algoritmo para hallar la longitud de un mensaje ACRS
91
7. III FASE: INTERFAZ GRA´FICA
Figura 7.14: Algoritmo para captar un Mensaje ACARS
92
7.6 Optimizacio´n del sistema ACARS
Figura 7.15: Resultado de I mensaje de los algoritmos desarrollados
entrante del bloque. El acumulador esta contantemente condicionado a un estado lo´gico. El
estado lo´gico debe cumplir que la longitud del acumulador deber ser exactamente a la longi-
tud del mensaje calculado previamente en el bloque y el reconocimiento (ACK) debe ser igual
a 1. Cuando lo anterior se cumple, el acumulador se vuelve una lista para ser tratado por el
co´digo de insercio´n a la base de datos ya programada. Es importante sen˜alar que despue´s de
haber insertado el mensaje a la DB, volver NULL o vaciar el acumulador para contener el
pro´ximo mensaje.
Los resultados de los algoritmos de la Figura 7.13 y Figura 7.14 se puede apreciar en
la Figura 7.15 y la Figura 7.16.En la Figura 7.15 corresponde a un mensaje ACARS cuya
longitud es calculado y es totalmente diferente al taman˜o del paquete ACARS DE LA Figura
7.16, logrando as´ı identificar cada mensaje de manera correcta e independiente para lograr
insertar dichos mensajes en la base de datos.
7.6. Optimizacio´n del sistema para visualizar los mensajes
ACARS entre DB y aplicativo Web
Por ahora existe la aplicacio´n de GNU-Radio para insertar los mensajes demodulados
y decodificados en una base de datos, y la plataforma web para conocer la ubicacio´n de la
aeronave como tambie´n la interaccio´n de los mensajes ACARS con el usuario. Solo resta
adaptar el sistema para mostrar los mensajes ACARS en una tabla dina´mica y las coordena-
das geogra´ficas por medio de PHP, JavaScript y HTML.
93
7. III FASE: INTERFAZ GRA´FICA
Figura 7.16: Resultado de II mensaje de los algoritmos desarrollados
PHP como la programacio´n del servidor para realizar la consulta de los mensajes ACARS
provenientes del programa GNURadio en la base de datos y organizar los datos en archivos
XML. Como agregado PHP tiene la obligacio´n de revisar e identificar en cada mensaje con-
sultado la existencia de una coordenada geogra´fica para indexarlo en otro archivo XML para
el API de Google Maps. JavaScript para realizar peticiones personalizadas al servidor para la
tabla dina´mica y la inclusio´n de los puntos geogra´ficos en Google Maps. Por u´ltimo, HTML
para disen˜ar la tabla dina´mica, el contenedor de los mensajes ACARS.
7.6.1. Co´digo PHP: Consultas de los mensajes ACARS con PHP.
Manteniendo la estructura del co´digo explicado en la seccio´n 7.4.1 para realizar la con-
sulta en la base de datos y organizar los datos en un archivo XMl. En esa seccio´n explica
como realizar la conexio´n a la DB como la consulta a una base de datos. El u´nico cambio es
la estructura de la consulta, debido a que la tabla contiene mas campos pero con la misma
estructura de programacio´n.
Solo es necesario definir y describir de que forma se organiza la informacio´n del mensaje
ACARS en el archivo XML. Vale la pena resaltar que se introduce nuevos comando XMl
DOM basado en PHP para obtener el resultado de la Figura 7.17
1 <?php
2 // Archivo de conexion a la base de datos
94
7.6 Optimizacio´n del sistema ACARS
3
4 require(’connection.php’);
5
6 $result= $connect ->query("SELECT IDm ,fecha ,modo ,rgo ,ack ,tipo ,numero ,Nsge ,
7 vuelo ,textI ,finT FROM mensaje ORDER BY IDm ASC");
8
9 if(! $result ){
10 echo "Lo sentimos , este sitio web esta experimentando problemas.";
11 }
12
13 // Start XML file , create parent node
14 $dom = new DOMDocument("1.0");
15 $node = $dom ->createElement("ACARS");
16 $parnode = $dom ->appendChild($node );
17
18 header("Content -type: text/xml");
19
20 // Add to XML document node
21
22 $i=0;
23 while ($row = $result ->fetch_assoc ()){
24 $i=$i+1;
25 $nod = $dom ->createElement("Mensaje");
26 $newnode = $parnode ->appendChild($nod);
27 $newnode ->setAttribute("Mensaje", $i);
28 $newnode ->setAttribute("Fecha", $row[’fecha ’]);
29
30 $ID = $dom ->createElement("Identificacion");
31 $ID = $newnode ->appendChild($ID);
32 $ID ->setAttribute("Vuelo",$row[’vuelo ’]);
33
34 $RGO = $dom ->createElement("RGO");
35 $RGO = $ID ->appendChild($RGO);
36 $text = $dom ->createTextNode($row[’rgo’]);
37 $text = $RGO ->appendChild($text);
38
95
7. III FASE: INTERFAZ GRA´FICA
39 $ACK = $dom ->createElement("Acknowledgement");
40 $ACK = $ID ->appendChild($ACK);
41 $text = $dom ->createTextNode($row[’ack’]);
42 $text = $ACK ->appendChild($text);
43
44 $Nmsge = $dom ->createElement("No_Mensaje");
45 $Nmsge= $ID ->appendChild($Nmsge );
46 $text = $dom ->createTextNode($row[’Nsge’]);
47 $text = $Nmsge ->appendChild($text);
48
49 $Con = $dom ->createElement("Contenido");
50 $Con = $newnode ->appendChild($Con);
51 $Con ->setAttribute("Tipo",$row[’tipo’]);
52
53 $Mod = $dom ->createElement("Modo");
54 $Mod= $Con ->appendChild($Mod);
55 $text = $dom ->createTextNode($row[’modo’]);
56 $text = $Mod ->appendChild($text);
57
58 $Sec = $dom ->createElement("Secuencia");
59 $Sec= $Con ->appendChild($Sec);
60 $text = $dom ->createTextNode($row[’numero ’]);
61 $text = $Sec ->appendChild($text);
62
63 $tex = $dom ->createElement("Informacion");
64 $tex= $Con ->appendChild($tex);
65 $text = $dom ->createTextNode($row[’textI’]);
66 $text = $tex ->appendChild($text);
67 }
68 echo $dom ->saveXML ();
69 ?>
En la seccio´n 7.4.1 establecimos que la funcio´n fetch assoc() emula una sentencia FOR
sistema´tico. Es decir por N consultas halla en la variable result N ciclos va a realizar. Te-
niendo en cuenta lo anterior, para contar los mensajes existentes para el final de todos los
96
7.6 Optimizacio´n del sistema ACARS
Figura 7.17: Archivo XML de los mensajes ACARS contenidos en la base de datos por medio
de PHP
ciclos se logra por medio de la variable i=i+1 . Un archivo XML es un texto plano cuya
organizacio´n es un modelo jera´rquico, compuesto por nodos, Sub-Nodos y atributos don-
de los subnodos son nodos hijos del nodo padre. Esa jerarqu´ıa se logra con la sentencia
NodoPadre −> appendChild(NodoHijo) .En la Figura 7.17 el nodo Mensaje es nodo hijo
del nodo padre ACARS. As´ı como el nodo Identificacio´n y Contenido son hijos nodos del
Sub-nodo padre Mensaje. El procedimiento para organizar los datos jera´rquicamente es el
siguiente, Primero crea el nodo a partir del nodo PADRE que es ACARS. Luego indexar dicho
elemento en algu´n Subnodo Padre.
Luego de haber construido todo el a´rbol genealo´gico del archivo XMl, solo resta insertar
los datos. En XML existen dos formas: por Atributo y por Texto. En la Imagen 7.17, el
Sub-nodo padre Mensaje tiene dos Atributos: Mensaje y Fecha. El valor de los Nodos Hijos
como NoMensaje o Informacio´n no tienen atributos sino valores por Texto. Para insertar un
valor tipo texto es necesario crear un nodo tipo Texto a partir del nodo padre ACARS y
la variable de la consulta MySQL, para luego insertar el Nodo tipo Textual en el nodo Hijo.
Para valores tipo Atributo solo es necesario indexar en el nodo hijo la variable del atributo y
la variable MySQL, con la sentencia serAttribute .
97
7. III FASE: INTERFAZ GRA´FICA
7.6.2. Co´digo PHP: Extraccio´n de la ubicacio´n geogra´fica de las consultas.
En la anterior seccio´n exportamos en archivos XML por medio de PHP los mensajes
ACARS, listos para ser tratados en el aplicativo WEB. Solo queda exportar otro tipo de
archivo XML donde contenga los mensajes cuya informacio´n este contenida una ubicacio´n
geogra´fica. Es decir, si de los N mensajes contenidos en el archivo XML solo un pequen˜o
grupo de N son mensajes que contienen una informacio´n geogra´fica. El algoritmo debe ser
capaz de seleccionar solo ese pequen˜o grupo y extraer la ubicacio´n geogra´fica para disponerla
en otro archivo XML.
Entonces, hay dos archivos XML, el primero esta´n contenidos todos los mensajes ACARS
que existan en la base de datos para ser dispuesto en la Tabla Dina´mica del aplicativo Web.
Y el segundo archivo XMl son las coordenadas geogra´ficas de cada mensaje (No todos los
mensajes contienen informacio´n acerca de la ubicacio´n geogra´fica de la aeronave) para ser
utilizado en el API de Google Maps programado en el aplicativo Web.
Primero se debe filtrar los mensajes cuya informacio´n se relacione con una coordena-
da Geogra´fica. Para ello existe la etiqueta /POS, que identifica una coordenada sexagesi-
mal(Grados, Minutos y Segundos). La ubicacio´n referente es N (Norte) y W (Oeste). La
estructura para la coordenada N esta determinada por (DDMMS)y W (DDDMMS) donde
D son grados, M Minutos y S segundos. Conociendo la estructura de una ubicacio´n en el
mensaje ACARS, el primer algoritmo (Ver Figura 7.18) describe determinar la ubicacio´n de
la coordenada dentro del mensjae ACARS y el taman˜o de la misma. Y el segundo algoritmo
es extraer la ubicacio´n N y W para convertirlo en sistema decimal e insertarlo en un archivo
XML.
El algoritmo de la Figura 7.18 se constituye en un FOR en la cual recorre todo el array
donde esta contenido la consulta MySQL. Si al recorrer el Array no encuentra la palabra
/POS pasa a la siguiente consulta. Al encontrar la etiqueta /POS captura la posicio´n en el
array para fines del segundo algoritmo. Al mismo tiempo genera dos contadores incremental,
esto con la finalidad de calcular la longitud de cada coordenada.
El segundo algoritmo (Ver Figura 7.19) se detalla en co´digo en PHP, cuyo funcio´n es
volver a recorrer el Array y extraer las dos coordenadas a partir de la longitud y la ubicacio´n
de la etiqueta /POS con la variable (init).
1 <?php
2 $Lagrados=$latitud [0]. $latitud [1];
3 $Laminutos=$latitud [2]. $latitud [3];
4 $Lasegundos=$latitud [5];
5
6 $Lngrados=$longitud [0]. $longitud [1]. $longitud [2];
98
7.6 Optimizacio´n del sistema ACARS
Figura 7.18: I Algoritmo para determinar la longitud y ubicacio´n dela coordenada geogra´fica
de cada mensaje ACARS
99
7. III FASE: INTERFAZ GRA´FICA
Figura 7.19: II Algoritmo para extraer la longitud y latitud del mensaje ACARS
100
7.6 Optimizacio´n del sistema ACARS
Figura 7.20: Ubicacio´n geogra´ficas de los mensajes ACARS dispuestos en la base de datos
7 $Lnminutos=$longitud [3]. $longitud [4];
8 $Lnsegundos=$longitud [6];
9
10 $latituds= $Lagrados +( $Laminutos /60)+( $Lasegundos /3600);
11 $longituds =-( $Lngrados +( $Lnminutos /60)+( $Lnsegundos /3600));
12 ?>
La conversio´n de sexagesimal a decimal de la Figura 7.19 es la sumatoria de la divisio´n de
los grados en 1, los minutos en 60 y los segundos en 3600. Para efectuar la anterior operacio´n
es necesario extraer de la variable Latitud y Longitud los grados, minutos y segundos mante-
niendo la estructura (DDMMS) para latitud y (DDDMMS) para longitud. En la Figura 7.20
esta resultado al insertar la variable latituds y longituds como atributo del nodo padre
traject.
7.6.3. Co´digo JavaScript: Visualizacio´n de mensajes ACARS en una tabla
dina´mica con AJAX
Cuando se dice de una tabla dina´mica se refiere a una tabla basada en AJAX, es decir
peticiones al servidor reiteradamente por un lapso constante de tiempo. Esto permite una vi-
sualizacio´n de los mensajes ACARS en tiempo real. En la seccio´n 7.4.2 explica el co´digo para
realizar peticiones personalizadas al servidor con AJAX por medio de JQUERY. La u´nica
sentencia adicional es $(”.ola”).empty() cuya funcionalidad permite vaciar el contenido de
la tabla HTML para evitar que se repitan los mensajes de la peticio´n anterior. La etiqueta
.ola hace referencia a la clase HTML donde esta programada la tabla.
1
2 function Message (){
101
7. III FASE: INTERFAZ GRA´FICA
3 var filename = ’xxxxxx.php’;
4
5 setInterval(request , 10000);
6
7 function request (){
8 $(".ola").empty ();
9 $.ajax({
10 type: "GET",
11 cache: false ,
12 url: filename ,
13 dataType: "xml",
14 success: parseXML ,
15 error : onXMLLoadFailed
16 });
17 }
Cuando la pticio´n AJAX es sastidfactoria, el paso a seguir es extraer la informacio´n del
archivo XMl. Como bien hab´ıamos explicado en XML existen dos formas de insertar datos,
en JavaScript tambien existe esos mismos dos modos. Por atributo, la forma de extraer
los datos se logra con la sentencia .attr(Atributo) . Por Nodo textual, se realiza con la
sentencia .text() .
1 function parseXML(xml){
2 $(xml).find("Mensaje").each(function(i){
3 var NoMensaje = $(this).attr(’Mensaje ’);
4 var fecha = $(this).attr(’Fecha’);
5 var id = $(this).find(’Identificacion ’).attr(’Vuelo’)
6 var rgo = $(this).find(’Identificacion ’).find(’RGO’).text ();
7 var ack = $(this).find(’Identificacion ’).find(’Acknowledgement ’).text ();
8 var SecMensaje = $(this).find(’Identificacion ’).find(’No_Mensaje ’).text ();
9 var tipo = $(this).find(’Contenido ’).attr(’Tipo’);
10 var modo = $(this).find(’Contenido ’).find(’Modo’).text ();
11 var secuencia = $(this).find(’Contenido ’).find(’Secuencia ’).text ();
12 var mensaje = $(this).find(’Contenido ’).find(’Informacion ’).text ();
102
7.6 Optimizacio´n del sistema ACARS
Cada nodo del archivo XML esta almacenado en las variables de JavaScript, es decir, ya esta´n
almacenados en el dispositivo del usuario, solo falta mostrar dichas variables en el aplicativo
WEB. Para ello, seleccionamos la etiqueta de HTML $(”.ola”) donde esta´ la tabla para
lograr insertar los datos en cada campo de la tabla. Lo anterior se cumple gracias al coman-
do append(Codigo HTML) . Esa sentencia permite indexar algu´n co´digo HTML, en este caso
vamos a insertar una fila de la tabla para cada mensaje ACARS. Donde <tr> indica una fila
de la tabla y <td> un campo de de la fila.
1 $(".ola"). append("<tr ><td >"+NoMensaje+"</td ><td >"+fecha+"</td ><td >"
2 +modo+"</td ><td >"+rgo+"</td ><td >"+ack+"</td ><td >"+tipo+"</td ><td >"
3 +secuencia+"</td ><td >"+SecMensaje+"</td ><td >"+id+"</td ><td >"
4 +mensaje+"</td ></tr >");
5 });
6 }
Pasando al cuerpo HTML, la etiqueta <table> enmarca todo en contenido de la tabla.
Con la etiqueta <thead> declaramos el encabezado de la misma. Tenga en cuenta que utiliza
las mismas sentencias <tr> y <th> para definir la fila y los campos. Y por ultimo la clase .ola
en la etiqueta <tbody> que a trave´s de JavaScript insertan las filas en la tabla de manera
implicita. El resultado del metodo y el codigo empleado para materializar la tabla dina´mica
se refleja en la Figura 7.21.
1 <h1 id ="tiB">Live ACARS Messages </h1>
2 <table border="1" id="same">
3 <thead >
4 <tr>
5 <th class="1">N</th>
6 <th class="2">Date</th>
7 <th class="3">Mode</th>
8 <th class="4">RGO</th>
9 <th class="5">Acknowledgement </th>
10 <th class="6">Label </th>
11 <th class="7">Sequence </th>
12 <th class="8">Seq Message </th>
13 <th class="9">Flight </th>
14 <th class="10">Message </th>
15 </tr>
103
7. III FASE: INTERFAZ GRA´FICA
16 </thead >
17 <tbody class="ola">
18 </tbody >
19 </table>
104
7.6 Optimizacio´n del sistema ACARS
F
ig
u
ra
7
.2
1
:
T
ab
la
D
in
a´
m
ic
a
co
m
o
co
n
te
n
ed
o
r
d
e
lo
s
m
en
sa
je
s
A
C
A
R
S
en
ti
em
p
o
re
a
l
105

Cap´ıtulo 8
III Fase: Pruebas Experimentales
El actual capitulo describe el prototipo completo puesta en marcha desde la recepcio´n
hasta el aplicativo Web. Esta seccio´n presenta dos escenarios de pruebas, el primer escenario
es en cercan´ıa al aeropuerto internacional el Dorado de Bogota´ DC. El segundo escenario
el prototipo estara´ ubicado en la ciudad de Cajica. Para el segundo escenario y de forma
permanente, el sistema de recepcio´n estara´ dispuesto en las instalaciones de WIRID LAB
en el Campus de la Universidad Militar Nueva Granada ubicado en la ciudad de Cajica´,
Cundinamarca.
107
8. III FASE: PRUEBAS EXPERIMENTALES
Antes de comenzar con la pruebas es importante realizar un resumen de la estructura del
prototipo as´ı como el listado de los co´digos desarrollados para el funcionamiento de todo el
sistema.Desde la estructura del sistema es claro que se basa en tres bloques. Respectivamente
los bloques son: el componente de recepcio´n y procesamiento de sen˜ales ACARS, Los com-
ponentes para adaptar el sistema con GNU-Radio y MySQL (Base de Datos), y el servicio
Web para la visualizacio´n de los mensajes ACARS.
El primer Bloque esta contenido todos los componentes de GNU-Radio de procesamiento
de sen˜ales para adaptar la sen˜al recibida por dispositivo RTL-SDR sin errores de fase, fre-
cuencia y tiempo de la sen˜al ACARS. Despue´s de haber mitigado los errores de recepcio´n,
el sistema se adapta una demodulacio´n ACARS para entregar mensajes decodificados. El
segundo bloque sin salir de GNU-Radio se disen˜a, desarrolla e implementa un par de algo-
ritmos con la capacidad de controlar el flujo de los mensajes ACARS tal que la insercio´n del
contenido de los mensajes en la base de datos sea eficiente.
I Bloque
Co´digo Caracter´ısticas
ACARS.grc
Prototipo de recepcio´n, De-Modulacio´n, Codi-
ficacio´n, Control de Flujo e insercio´n de datos
en la base de datos.
II Bloque
Co´digo Caracter´ısticas
ControlFlujo.py
Algoritmo de control de flujo ACARS desarro-
llado en Python e implementado como bloque
de GNURadio dentro del archivo ACARS.grc
ACARSMySQL.py
Algoritmo de insercio´n de datos ACARS en
MySQL desarrollado en Python e implemen-
tado como bloque de GNURadio dentro del
archivo ACARS.grc
Cuadro 8.1: Software Desarrollado - Archivos y aplicaciones desarrollados durante el bloques
I y el Bloque II. Todos los desarrollos se basan totalmente en el entorno de GNURadio.
108
El tercer bloque es el aplicativo web cuyos servicios son la visualizacio´n de todos los men-
sajes ACARS en una tabla y el servicio de Google Maps para observar la ubicacio´n de los
mensajes cuyo contenido tenga una posicio´n gra´fica. Los dos servicios se ejecutan en tiempo
real. Este es el bloque donde mas desarrollo a nivel de software contiene, Pues se trabaja con
programacio´n del lado del servidor PHP, Servicios de tiempo real para servidores Jquey-Ajax
y los servicios WEB implementados en HTML5-CSS-JavaScript.
III Bloque
Co´digo Caracter´ısticas
LocationACARS.php
Algoritmo de consulta y estructura de los mensajes cuyo con-
tenido exista una coordenada geogra´fica en archivos XML
desarrollado en PHP.
mensajeACARS.php
Algoritmo de consulta y estructura de los mensajes consul-
tados en archivos XML desarrollado en PHP.
AcarsMess.js
Algoritmo para procesar archivo XML de
mensajeACARS.php y estructurarlo en la tabla HTML.
Archivo basado en JavaScript-Jquery-Ajax.
geolocation.js
Algoritmo para procesar archivos XML de
locationACARS.php y proyectarlo en la API de Goo-
gle Maps. Archivo basado en JavaScript-Jquery-Ajax.
index.html
Archivo HTML como presentacio´n del aplicativo Web
ACARS.
liveMap.html
Archivo HTML contenedor del API de google maps y script
geolocation.js
liveTable.html
Archivo HTML contenedor de la tabla dina´mica y script
AcarsMess.js
Cuadro 8.2: Software Desarrollado - Archivos desarrollados durante en el III bloque.
109
8. III FASE: PRUEBAS EXPERIMENTALES
Figura 8.1: Visualizacio´n de la ubicacio´n de uno de los mensajes de la tabla dina´mica de la
Figura 8.2
8.1. I Escenario: Aeropuerto El Dorado
La prueba se desarrolla en el aeropuerto internacional El Dorado cuya metodolog´ıa con-
siste en captar las sen˜ales ACARS en la frecuencia 131.917MHZ. En la Figura 8.1 visualiza
tres mensajes ACARS codificados en la tabla dina´mica donde solo uno de ellos contiene infor-
macio´n geogra´fica de la aeronave. El mensaje donde esta contenido la coordenada geogra´fica
se plasma sobre el API de google Maps de la Figura 8.2.
110
8.1 I Escenario: Aeropuerto El Dorado
F
ig
u
ra
8
.2
:
T
a
b
la
d
e
la
p
ri
m
er
a
se
n˜
a
l
A
C
A
R
S
D
e-
M
o
d
u
la
d
a
.
111
8. III FASE: PRUEBAS EXPERIMENTALES
Figura 8.3: Visualizacio´n del mensaje de la tabla dina´mica de la Figura 8.2 sobre el mismo mapa
de la Figura 8.1
Cada punto de google maps debe desplegar informacio´n complementaria como parte del
mensaje, tal como se refleja en la Figura 8.3. El mensaje No 3 de la Figura 8.2tiene como
referencia TA0352 como nu´mero de vuelo, la cual coincide con la informacio´n que despliega
en el cuadro de dialogo de la Figura 8.3. Al mismo tiempo el aplicativo Web identifica otro
mensaje ACARS y los plasma de manera automa´tica, en tiempo real y sin interrumpir o
actualizar la pagina.(Ver Figura 8.3). El nuevo mensaje corresponde a los nuevos mensajes
de la tabla dina´mica de la Figura 8.4. Y desde luego el cuadro de dialogo en Google Maps tal
como se ve en la Figura 8.5.
112
8.1 I Escenario: Aeropuerto El Dorado
F
ig
u
ra
8
.4
:
T
a
b
la
d
e
la
se
g
u
n
d
a
se
n˜
a
l
A
C
A
R
S
D
e-
M
o
d
u
la
d
a
.
113
8. III FASE: PRUEBAS EXPERIMENTALES
Figura 8.5: Visualizacio´n de la ubicacio´n y el mensaje de la tabla dina´mica de la Figura 8.4
Siguiendo la secuencia de la prueba, la tabla dina´mica de la Figura 7.6 dos de los tres
mensajes disponibles, contienen informacio´n geogra´fica cuyo ID de Vuelo es el mismo. Quiere
decir que el aplicativo web debe reconocer que cuando existan varios puntos geogra´ficos de un
mismo vuelo debe trazar una sola trayectoria entre los mismos. El resultado de la trayectoria
en Google maps se refleja en la Figura 8.7.
114
8.1 I Escenario: Aeropuerto El Dorado
F
ig
u
ra
8
.6
:
T
a
b
la
d
e
te
rc
er
a
se
n˜
a
l
A
C
A
R
S
D
e-
M
o
d
u
la
d
a
.
115
8. III FASE: PRUEBAS EXPERIMENTALES
Figura 8.7: Visualizacio´n de la ubicacio´n y el mensaje de la tabla dina´mica de la Figura 8.6
Ahora, el prototipo tiene una deficiencia cuando existe errores de codificacio´n que son
provocados por los errores de recepcio´n del sistema. Un ejemplo se puede ver en la figura
8.8 como resultado la de-modulacio´n y la codificacio´n. Visiblemente existe incoherencia en
el contenido de los mensajes donde los algoritmos del aplicativo Web son ineficientes para
comprender que accio´n tomar e identificar los mensajes ACARS como control del flujo de
datos. El resultado se refleja en la Figura 8.9.
116
8.1 I Escenario: Aeropuerto El Dorado
Figura 8.8: Resultado de una mala decodificacio´n del prototipo de recepcio´n.
Figura 8.9: Visualizacio´n de los mensajes erra´ticos decodificados de la Figura 8.8 en la Tabla
Dina´mica.
117

Cap´ıtulo 9
Conclusiones
El protocolo ACARS esta´ basado en un esquema MSK basado en una demodulacio´n AM
cuyo ranfo de frecuencia en la zona de Cundinamarca va desde los 130 Mhz hasta los 132Mhz.
El funcionamiento de OOOI de ACARS en Colombia se evidencia en las pruebas realizadas en
el Aeropuerto Internacional el Dorado de la ciudad de Bogota´ cuyas actividades reportadas
fueron la posicio´n de la aeronave pro´ximo a aterrizar, Numero de Gate o Sala de espera donde
ten´ıa que permanecer la aeronave, la confirmacio´n o asignacio´n del vuelo y la autorizacio´n de
despeje. Las otras pruebas realizadas en la ciudad de Cajica´, Cundinamarca cuya ubicacio´n
es alejada de algu´n punto de control ae´reo, reporta informacio´n de la ubicacio´n geogra´fica y
altitud de la aeronave, detalles te´cnicos y meca´nicos del avio´n y el origen/destino del vuelo.
Los dos lugares de prueba confirman que el funcionamiento de OOOI del protocolo ACARS
clasifica el tipo de informacio´n que puede enviar una aeronave.
En te´rminos teo´ricos la demodulacio´n FSK se vuelve un esquema MSK siempre en cuan-
do la diferencia de frecuencia de operacio´n sea la mitad de la tasa de bits. La magnitud del
vector distancia desde el origen y un s´ımbolo en un diagrama IQ, siempre es contante pero
variable en fase en ma´s o menos 90 grados, cuya dependencia esta´ dada por la disposicio´n de
los bits que componen un mensaje ACARS.
El desarrollo del prototipo de recepcio´n ACARS evidencia que los sistemas de recepcio´n
pra´cticos son muy sensibles a los errores de frecuencia, tiempo y fase. Para mitigar el error
de fase y de tiempo se utilizan me´todos de sincronizacio´n como la deteccio´n por correlacio´n
empleado por el prototipo como mecanismo de sincronismo para recuperar los s´ımbolos en
la demodulacio´n MSK. Los errores de frecuencia y de fase esta´ muy relacionado por la re-
cuperacio´n de la portadora del Hardware de recepcio´n utilizado. El ajuste de correccio´n de
frecuencia PPM utilizado en el dispositivo de recepcio´n RTL-SDR cumple con satisfaccio´n la
correccio´n de los errores de frecuencia y fase.
En un dispositivo RTL-SDR el corrimiento de frecuencia es directamente proporcional a
la frecuencia RF o frecuencia de recepcio´n. Es decir, la fluctuacio´n frecuencial del cristal del
RTL-SDR se vuelve inestable a medida que la frecuencia de recepcio´n aumenta o disminuye.
119
9. CONCLUSIONES
Ese comportamiento permite una variacio´n dina´mica del corrimiento de frecuencia. Por ello
es muy importante realizar el ca´lculo PPM para sistemas de recepcio´n basados en RTL-SDR.
GNU-Radio es un sistema de procesamiento de sen˜ales flexible para implementar API’s
gracias a los bloques Python Block Embedded y Python Module. En base que GNU-RADIO
funciona con programacio´n Python, existen infinidad de API para desarrollar aplicaciones ma´s
complejas en GNU-Radio. Gracias a ello se logro´ desarrollar adaptar una API de MySQL pa-
ra Python en GNU-Radio para poder insertar los datos del flujograma en la base de datos
MySQL en tiempo real. La capacidad de mantener los mensajes en una base de datos, per-
mite generar cualquier tipo de desarrollo de software como aplicaciones web (Utilizados en el
prototipo del presente trabajo), desarrollo de aplicaciones mo´viles y desarrollo de aplicaciones
en la nube.
El alcance de este proyecto no logra una simulacio´n real de una infraestructura ACARS
dada la limitacio´n de la cobertura del dispositivo RTL-SDR. Para que efectivamente se logre
un sistema ACARS como infraestructura alterna para casos de emergencia es necesario dis-
poner una red de RTL-SDR conectados a una central. La central es la base de datos cuyos
nodos esta´n conectados a ella con la finalidad de clasificar los mensajes. La clasificacio´n de
los mensajes debe estar basado en el funcionamiento OOOI para que pueda abarcar grandes
extensiones espacio manteniendo las actividades ae´reas por ma´s tiempo. La programacio´n
para recolectar y clasificar los mensajes provenientes de los sistemas de recepcio´n debe lo-
grarse con programacio´n de lado del servidor. El desarrollo obtenido en la visualizacio´n de los
resultados de la demodulacio´n/Decodificacio´n en el proyecto debe ser optimizado para que el
contenido de interno de los mensajes ACARS sea un lenguaje explicito, legible y entendible
para el ojo humano.
120
Bibliograf´ıa
[1] EASA (European Aviation Safety Agency). Capitulo 15. Te´cnicas digitales
/ Sistemas de instrumentos electro´nicos. techreport, EASA, 2005. Modulo 5 de la
EASA Parte 66. Modulos necesarios para la obtencio´n de la Licencia de Mantenimiento
de Aeronaves. 9
[2] Rockwell Collins. ARINC Aviation. Aircraft Communications Addressing
and Reporting System (ACARS). Rockwell Collins, 2551 Riva Road, Annapolis,
MD 21401. Available from: https://www.rockwellcollins.com/Services_and_
Support/Information_Management/~/media/DA843DB0792946C58740F613328E5022.
ashx. 9, 10
[3] Aeronautica Civil. AUTORIZACIO´N DE SALIDAS VIA DATA LINK EN EL AE-
ROPUERTO ELDORADO DE BOGOTA. Aeronautica Civil, Centro Nacional de Ae-
ronavegacio´n CNA Av. El Dorado No. 112-09 Bogota´ D.C., November 2013. 15
[4] Unidad Administrativa Especial de Aerona´utica Civil U.A.E.A.C. Plan de
Navegacio´n Ae´rea para Colombia. Aerona´utica Civil Colombiana, Bogota´, volumen i:
requerimientos operacionales edition, 2010. 14
[5] The Free & Open Software Radio Ecosystem. GNU Radio Manual and C++
API Reference 3.7.10.1. GNU-RADIO PROJECT, reference 3.7.10.1 edition. Available
from: http://gnuradio.org/doc/doxygen/. 19
[6] Leonardo Go´mez. Vigilancia DepenDiente automa´tica (aDS-b) en colombia.
Ciencia y Poder Ae´reo, 10(1):21–32, 2015. 14
[7] Jun Kitaori. A performance comparison between VDL mode 2 and VHF
ACARS by protocol simulator. In Digital Avionics Systems Conference, 2009.
DASC’09. IEEE/AIAA 28th, pages 4–B. IEEE, 2009. 5
[8] Jun Kitaori. A performance comparison between VDL mode 2 and VHF
ACARS by protocol simulator. In Digital Avionics Systems Conference, 2009.
DASC’09. IEEE/AIAA 28th, pages 4–B. IEEE, 2009. 10, 11
121
BIBLIOGRAFI´A
[9] Yun Lin, Chao Lv, Xiaochun Xu, and Bin Lin. An Improved Method of De-
modulation for Air-Ground Data Link Communication System. International
Journal of Future Generation Communication and Networking, 7(2):1–8, 2014. 28
[10] He´ctor Matamoros. Estudio de CNS para Colombia. Francia: Ecole Nationale
de l’a Aviation Civile ENAC, 1999. 14
[11] Lionel K. Anderson Msc. ACARS - A User’s Guide. Las Atalayas, first edition,
2010. 10
[12] Curtis Risley, James McMath, and B Payne. Experimental encryption of
aircraft communications addressing and reporting system (ACARS) aero-
nautical operational control (AOC) messages. In Digital Avionics Systems, 2001.
DASC. 20th Conference, 2, pages 7D4–1. IEEE, 2001. 5
[13] ARINC Specification. 618-5. Air/ground character-oriented protocol speci-
fication, 2000. 11
[14] Cary R Spitzer and Cary Spitzer. Digital Avionics Handbook. CRC press,
2000. 8, 9
[15] Robert W Stewart, Kenneth W Barlee, Dale SW Atkinson, and Louise H
Crockett. Software Defined Radio using MATLAB & Simulink and the
RTL-SDR. Strathclyde Academic Media, 2015. 18, 21
[16] Shuguang Sun. Acars data identification and application in aircraft mainte-
nance. In Database Technology and Applications, 2009 First International
Workshop on, pages 255–258. IEEE, 2009. 4, 10, 11
[17] Thomas H Wright and James J Ziarno. System and method of providing
OOOI times of an aircraft, November 28 2000. US Patent 6,154,636. 12
[18] Alexander M Wyglinski, Maziar Nekovee, and Y Thomas Hou. Cogniti-
ve radio communications and networks. IEEE Communications Magazine,
Guest editorial, 2008. 17
122