Simulación y guíado de aeronaves utilizando programación orientada a objetos

MASTER UNIVERSITARIO EN INGENIER´ IA AERON´ AUTICA TRABAJO FINAL DE MASTER Simulaci´on y Guiado de Aeronaves utilizando Programaci´on Orientada a Objetos Autor Lucas Peris Lozano Master Universitario en Ingenier´ıa Aeron´autica Universitat Polit`ecnica de Val`encia Escuela T´ecnica Superior de Ingenier´ıa del Dise˜no 2015-2016 Resumen Los simuladores de vuelo se han convertido hoy en d´ıa en una herramienta fundamental tanto para la formaci´on de pilotos como para otras aplicaciones tales como la prueba y validaci´on de nuevos planes de misi´on y el desarrollo de sistemas de guiado y control. Esto ´ultimo es de gran utilidad hoy en d´ıa, especialmente cuando se aplica a aeronaves no tripuladas (UAVs). La simulaci´on de las misiones de dicho tipo de aeronaves puede llegar a convertirse en una herramienta fundamental en el desarrollo de aeronaves no tripuladas, especialmente en aquellas empresas o instituciones que no disponen del presupuesto necesario para realizar numerosos ensayos de vuelo. La capacidad de simular la misi´on permite encontrar fallos tanto en el concepto mismo de la misi´on, como fallos debidos a las filosof´ıas de guiado y control aplicadas en el veh´ıculo, todo ello de forma sencilla y a un coste muy reducido. Cabe destacar que la correcta planificaci´on de una misi´on y el dise˜no del sistema de navegaci´on, guiado y control de una aeronave son temas muy complejos y que requieren de un estudio en profundidad para poder garantizar la seguridad en las operaciones. El enfoque de este trabajo consiste en la realizaci´on de una aplicaci´on gr´afica que englobe conceptos tanto de simulaci´on de aeronaves como de guiado y control de las mismas. Adem´as, se ha implementado una serie de instrumentaci´on en la cabina del simulador que permitir´a obtener una visi´on m´as realista de la simulaci´on, as´ı como familiarizar al lector con distintos conceptos de instrumentaci´on de aeronaves. Todo esto se ha realizado con el objetivo principal de ofrecer una plataforma modular y ampliable que pueda servir para fines docentes de desarrollo de software para aplicaciones aeron´auticas. Debido a los temas tan amplios que se abordan en este trabajo, en la implementaci´on del proyecto se ha profundizado en distinta medida en cada uno de los temas especificados anteriormente. Sin embargo, se han abordado todos los temas por igual desde el punto de vista de la documentaci´on, del estudio del estado del arte y del dise˜no de los sistemas que los componen. Abstract Flight simulators have become nowadays a fundamental tool for both pilot training and other applications such as the test of new mission plans and the development of guidance and control systems. The latter is very useful these days, especially when its applied to unmanned aerial vehicles (UAVs). The mission simulation of that kind of aircrafts could become a fundamental element for the development of unmanned aircrafts, specially in companies or institutions that do not have the required budget for an intensive flight test program. The ability of simulating a complete mission allows the engineers to find errors in the mission concept as well as errors due to the guidance and control philosophies applied to the vehicle, all that in a very simple and cost-effective way. It must be noted that an adequate mission planning procedure and the design of a guidance, navigation and control system of an aircraft are extremely complex subjects, which require an in-depth study in order to guarantee the operational security requirements. The scope of this work consists on the design and implementation of a graphical application which includes concepts of both aircraft simulation and their guidance and control. Additionally, a number of navigation instruments has been implemented in the simulator’s cockpit, which will lead to a more realistic vision of the simulation, as well as familiarize the reader with different concepts related to aircraft instrumentation. The main objective of this work is to offer a modular and easily expandable that can be used for educational purposes in the fields of software development for aeronautical applications. Due to the breadth of the subjects seen in this project, the depth of their implementation in this project has been different for each of them. However, all the aspects of this project have been treated equally from the points of view of documentation, study of the state of the art and the design of their systems and components. MASTER UNIVERSITARIO EN INGENIER´ IA AERON ´ AUTICA Simulaci´on y Guiado de Aeronaves utilizando Programaci´on Orientada a Objetos Lucas Peris Lozano 13 de julio de 2016 ´ Indice ´ Indice ........................................ I ´ IndicedeFiguras.................................. V ´ IndicedeTablas .................................. VII 1 Introducci´on 1 1 Motivaci´ondeltrabajo............................ 1 2 Objetivos ................................... 2 3 Estudio del estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Control de aeronaves . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Guiadodeaeronaves......................... 5 3.3 Instrumentaci´on de aeronaves . . . . . . . . . . . . . . . . . . . . 6 3.4 Desarrollo de interfaces gr´aficas . . . . . . . . . . . . . . . . . . . 7 3.5 Simulaci´on de vuelo . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2 Dise˜no del sistema 11 1 Descripci´on del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.1 Detalles y estructura . . . . . . . . . . . . . . . . . . . . . . . . . 11 2 Metodolog´ıa de dise˜no . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1 Metodolog´ıa del dise˜no de software . . . . . . . . . . . . . . . . . 13 2.2 Metodolog´ıa del dise˜no del cockpit . . . . . . . . . . . . . . . . . 15 3 Modelo de desarrollo de proyecto . . . . . . . . . . . . . . . . . . . . . . 16 3.1 M´etodo V (V-Model) . . . . . . . . . . . . . . . . . . . . . . . . 16 4 Requerimientos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 Nomenclatura de los requisitos . . . . . . . . . . . . . . . . . . . 18 4.2 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . 19 4.4 Caracter´ısticas deseables o “nice to have”............. 20 5 Herramientas utilizadas en el desarrollo . . . . . . . . . . . . . . . . . . 20 5.1 JavaTM - Entorno NetBeans . . . . . . . . . . . . . . . . . . . . . 20 5.2 Motor de simulaci´on - X-Plane . . . . . . . . . . . . . . . . . . . 21 5.3 Otrosoftware............................. 22 3 Implementaci´on de la interfaz gr´afica y los instrumentos 23 I 1 Interfaz gr´afica: cockpit. Generaci´on de instrumentos . . . . . . . . . . . 23 1.1 Panel de instrumentos . . . . . . . . . . . . . . . . . . . . . . . . 23 1.2 Fondo ................................. 26 1.3 Controles: Mandos de vuelo y palanca de gases . . . . . . . . . . 26 2 Implementaci´on de los instrumentos . . . . . . . . . . . . . . . . . . . . 29 2.1 Clase instrument y sus m´etodos principales . . . . . . . . . . . 29 2.2 ADI - Attitude Director Indicator: Horizonte artificial . . . . . . 33 2.3 ALT - Alt´ımetro: Indicador de altitud . . . . . . . . . . . . . . . 35 2.4 ASI - Airspeed Indicator: Indicador de velocidad . . . . . . . . . 37 2.5 HI - Heading Indicator: Indicador del heading de la aeronave . . 42 2.6 T/S TC - Coordinador de giro . . . . . . . . . . . . . . . . . . . 44 2.7 VSI - Vertical Speed Indicator: Indicador de la velocidad vertical 52 2.8 TCAS................................. 55 4 Implementaci´on de interfaces con perif´ericos 65 1 Interfaz de comunicaci´on con X-Plane . . . . . . . . . . . . . . . . . . . 65 1.1 Elecci´on del simulador . . . . . . . . . . . . . . . . . . . . . . . . 65 1.2 Desarrollo de la interfaz de comunicaci´on con X-Plane . . . . . . 67 1.3 Implementaci´on del c´odigo . . . . . . . . . . . . . . . . . . . . . 67 2 Interfaz de comunicaci´on con la antena de tr´afico a´ereo . . . . . . . . . . 69 2.1 Descripci´on.............................. 69 2.2 Men´u de configuraci´on . . . . . . . . . . . . . . . . . . . . . . . . 69 2.3 Implementaci´on del c´odigo . . . . . . . . . . . . . . . . . . . . . 70 5 Implementaci´on del autopiloto 73 1 Descripci´on .................................. 73 2 Arquitectura del autopiloto . . . . . . . . . . . . . . . . . . . . . . . . . 73 3 Implementaci´on de los algoritmos de guiado y control . . . . . . . . . . 74 3.1 Fasederollout ............................ 76 3.2 Fasederotaci´on ........................... 78 3.3 Fasedeascenso............................ 79 3.4 Fasedecrucero............................ 82 4 Men´udeconfiguraci´on............................ 84 4.1 Par´ametros de configuraci´on . . . . . . . . . . . . . . . . . . . . 85 4.2 Indicador de estado y bot´on Engage/Disengage . . . . . . . . . . 86 4.3 Archivos de configuraci´on del autopiloto . . . . . . . . . . . . . . 87 4.4 Mensajes de aviso y error . . . . . . . . . . . . . . . . . . . . . . 89 6 Resultados 91 1 Procedimiento de an´alisis de los resultados . . . . . . . . . . . . . . . . . 91 2 Dise˜no de los casos de prueba o Test Cases ................ 91 2.1 Definici´on del entorno de pruebas . . . . . . . . . . . . . . . . . . 92 II 2.2 Casos de prueba implementados . . . . . . . . . . . . . . . . . . 93 3 Resultados de los casos de prueba . . . . . . . . . . . . . . . . . . . . . . 104 4 Trazabilidad de los requisitos . . . . . . . . . . . . . . . . . . . . . . . . 104 5 An´alisis de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7 Conclusiones y trabajos futuros 107 1 Conclusiones ................................. 107 2 Trabajosfuturos ............................... 110 Referencias 115 III CAP´ ITULO 1. INTRODUCCI ´ ON Avoidance System). Esto tiene un inter´es no solamente desde el punto de vista del desarrollo, sino tambi´en desde un punto de vista did´actico, ya que puede permitir que en un futuro otros alumnos experimenten con la herramienta para poder implementar as´ı sistemas m´as complejos y completos. La creaci´on de una plataforma modular que integre los m´odulos de simulaci´on, autopiloto y tr´afico a´ereo mediante el lenguaje Java, puede llegar a tener multitud de utilidades en un futuro, siendo f´acilmente ampliable y actualizable. Adem´as, la implementaci´on en Java permite que el mismo programa pueda ser utilizado en diversos sistemas operativos sin necesidad de recompilar de nuevo el programa. 2. Objetivos Con los cuatro aspectos claves anteriores en mente, se plantean los siguientes objetivos para la realizaci´on del presente proyecto: 1. Capacitar al alumno para el dise˜no de herramientas inform´aticas para la simulaci´on de vuelo y gesti´on del tr´afico a´ereo. Esta es una especializaci´on de gran inter´es para la Ingenier´ıa Aeron´autica y con un gran n´umero de aplicaciones tanto en la industria como en la rama de investigaci´on. 2. La integraci´on en un mismo proyecto de distintas ´areas de estudio del Master Universitario en Ingenier´ıa Aeron´autica, tales como: Algoritmos de guiado y control de aeronaves. Instrumentaci´on de aeronaves. Desarrollo de interfaces gr´aficas. Simulaci´on de vuelo. 3. Afianzar los conocimientos obtenidos en el transcurso del Master, realizando una plataforma sobre la que se pueda realizar multitud de trabajos futuros. Para ello se realizar´a una implementaci´on de software mediante el uso de un lenguaje orientado a objetos que permita generar un c´odigo modular f´acilmente adaptable, ampliable y modificable. 4. Estudiar el estado del arte de las disciplinas mencionadas anteriormente, as´ı como los desarrollos futuros que se prev´e que se realicen en dichos campos. Para ello se realizar´a un estudio bibliogr´afico en el que se consultar´an multitud de fuentes, lo que permitir´a obtener un mayor conocimiento del estado actual y futuro de las disciplinas de estudio. El cumplimiento de dichos objetivos se analizar´a en las conclusiones del presente documento, donde se evaluar´a el grado de cumplimiento de cada uno de ellos. En caso de no cumplir de forma completa con alguno de ellos, se propondr´an una serie de medidas o actuaciones que permitan mejorar dicho grado de cumplimiento. 2 Master Universitario en Ingenier´ıa Aeron´autica 3. ESTUDIO DEL ESTADO DEL ARTE 3. Estudio del estado del arte Con el prop´osito de sentar unos antecedentes de los ´ultimos avances realizados en los principales campos de estudio que constituyen este proyecto, se procede a estudiar el estado del arte de cada uno de ellos, citando a la bibliograf´ıa correspondiente en cada caso. 3.1. Control de aeronaves Los algoritmos de guiado y control utilizados en una aeronave son un elemento fundamental para garantizar la seguridad y la operatividad de la misma. Tradicionalmente, dichos algoritmos se implementan en el sistema de Gesti´on de Vuelo, conocido como FMS por sus siglas en ingl´es (Flight Management System). Como es de esperar, existen multitud de filosof´ıas de control aplicables a las aeronaves. Sin embargo, el presente estudio se centrar´a en enumerar algunas de las t´ecnicas de control adaptativo por ser el tipo de control en el que se centra la investigaci´on hoy en d´ıa. En las siguientes l´ıneas se proceder´a a enumerar algunas de las m´as extendidas as´ı como la bibliograf´ıa correspondiente. Gain Scheduling o Planificaci´on de Ganancias: Esta t´ecnica es una de las m´as extendidas en el control de aeronaves y goza de muchos a˜nos de uso en el sector aeron´autico. La t´ecnica consiste en la creaci´on de multitud de controladores lineales, ajustados cada uno de ellos para un punto de operaci´on en concreto dentro de la envolvente de vuelo. El sistema se encarga de monitorizar una serie de variables (altitud y velocidad o n´umero de Mach, por ejemplo) para obtener el punto de operaci´on y a partir de ah´ı elegir el controlador correspondiente. De esta forma, si se consigue realizar un mapeado de los distintos puntos de funcionamiento dentro de la envolvente de vuelo, se puede conseguir un controlador que se adapte a las condiciones de operaci´on de cada instante. Se trata, por tanto, de una de las formas m´as sencillas de implementar un control adaptativo. Los fundamentos te´oricos de dicho esquema de control se pueden consultar en [1]. Las t´ecnicas de Gain Scheduling se vienen aplicando desde hace muchos a˜nos en aeron´autica debido a la relativa sencillez (en comparaci´on con otros m´etodos m´as complejos) con la que se puede obtener un control adaptativo robusto [2]. En los ´ultimos a˜nos est´an apareciendo multitud de nuevas t´ecnicas de control adaptativo, sin embargo, esta t´ecnica sigue gozando de cierta popularidad en el ´ambito de la investigaci´on y se siguen desarrollando estudios hoy en d´ıa tal y como se puede ver en las siguientes referencias. En [3,4] se realizan sendos estudios de la estabilidad del sistema de gain scheduling. Adem´as [3] profundiza sobre el caso de aeronaves con un comportamiento altamente no lineal y estudia la estabilidad tanto de los Master Universitario en Ingenier´ıa Aeron´autica 3 CAP´ ITULO 1. INTRODUCCI ´ ON controladores de cada uno de los puntos de operaci´on como del sistema en general que gestiona dichos controladores. Adem´as, se trata de un tema que suscita un cierto inter´es en el ´ambito acad´emico, un ejemplo de esto ser´ıan las Tesis [5–7]. Adaptive pole placement: Este m´etodo basa su efectividad en la modificaci´on de la localizaci´on de los polos de la funci´on de trasferencia utilizada de forma din´amica. De esta forma se consigue un sistema de control capaz de adaptarse a perturbaciones y a transitorios. Este tipo de control adaptativo no goza de tanta popularidad como el anterior hoy en d´ıa; sin embargo, se pueden encontrar numerosas referencias en la literatura de los ´ultimos 20 a˜nos ( [8–10], por nombrar algunos) y tambi´en algunos ejemplos m´as recientes aplicados a UAVs, como es el caso de [11]. Iterative learning control (ILC): Este m´etodo de control consiste en la utilizaci´on del error de la repetici´on anterior para ajustar las ganancias del controlador. Este m´etodo es de gran utilidad para procesos repetitivos y tradicionalmente se ha utilizado en el control de brazos rob´oticos industriales, donde se realiza una misma acci´on repetidas veces y se necesita un control muy fino. Sin embargo, en los ´ultimos a˜nos se est´a empezando a aplicar este tipo de t´ecnicas en peque˜nas aeronaves no tripuladas, en especial en multi-rotores. En [12] se realiza un estudio de las distintas t´ecnicas de control adaptativo y se opta por utilizar t´ecnicas de ILC por su utilidad en el control de cuadric´opteros durante despegues, aterrizajes y transiciones. Otro ejemplo ser´ıa el de [13], donde lo que se persigue es mejorar el comportamiento de un cuadric´optero al realizar maniobras agresivas. Model Identification Adaptive Controllers (MIAC) yModel Reference Adaptive Controllers (MRAC):El m´etodo MIAC se basa en la utilizaci´on de un algoritmo de estimaci´on de la funci´on de transferencia del sistema que se recalcula en cada instante bas´andose en las medidas tomadas instantes antes. De esta forma se ajusta el controlador en cada instante, bas´andose en la funci´on de transferencia obtenida. En cambio, los m´etodos MRAC hacen uso de un modelo din´amico inicial y ajustan y corrigen dicho modelo en cada instante de tiempo. El uso de estos tipos de control adaptativo se est´a convirtiendo en algo bastante extendido a medida que aumentan los recursos computacionales disponibles en los autopilotos, y no son extra˜nas las investigaciones que comparan las prestaciones de ambos ( [14,15]). 4 Master Universitario en Ingenier´ıa Aeron´autica 3. ESTUDIO DEL ESTADO DEL ARTE Figura 1.1: Esquema de guiado de un controlador MIAC (izqda) y un controlador MRAC (dcha). Fuente: [14] El control de aeronaves es un campo de investigaci´on en constante crecimiento y en el que se han realizado numerosos estudios e innovaciones en los ´ultimos a˜nos. Prueba de esto son el n´umero de publicaciones que se realizan al a˜no relativas a control adaptativo, as´ı como el n´umero de equipos de investigaci´on dedicados a dicha materia. Adem´as, la integraci´on de sistemas de control adaptativos en aeronaves no tripuladas es un tema de inter´es por parte de agencias como la NASA no s´olo desde el punto de vista del dise˜no de aeronaves y sus controladores, sino tambi´en desde el punto de vista de su certificaci´on [16]. 3.2. Guiado de aeronaves Las estrategias de guiado de aeronaves es otro de los campos en constante desarrollo y que, al igual que en el caso del control de aeronaves, ha visto como la aparici´on de los UAVs ha propiciado un desarrollo mucho m´as acusado en los ´ultimos a˜nos. Las t´ecnicas de guiado aplicadas a este tipo de aeronaves han evolucionado notablemente, pasando de guiados muy simples consistentes en el seguimiento de un rumbo constante a t´ecnicas mucho m´as complejas. En este apartado el autor se centrar´a principalmente en las t´ecnicas de guiado aplicadas a UAVs, debido a que las aeronaves no tripuladas son fuente de la mayor parte de los estudios realizados hoy en d´ıa en cuanto a t´ecnicas de guiado. En [17], se presenta una t´ecnica de guiado muy novedosa para permitir el repostaje en vuelo de un UAV. El sistema se basa en la utilizaci´on de c´amaras que graban a la aeronave que va a realizar la transferencia de combustible y que permiten obtener la posici´on relativa de dicha aeronave con respecto al UAV que va a realizar el docking. De forma similar, en [18] se utilizan c´amaras estereosc´opicas para calcular la posici´on relativa de un target, con la intenci´on de interceptarlo o seguirlo. Una aplicaci´on m´as simple es la presentada en [19], donde se presenta una estrategia de guiado que permite compensar los efectos del viento. La gesti´on de grupos de aeronaves no tripuladas es un aspecto de gran inter´es, en [20] se realiza un estudio para optimizar las trayectorias de grupos de UAVs de forma que se pueda recopilar la mayor informaci´on posible del terreno o de las regiones de inter´es. Master Universitario en Ingenier´ıa Aeron´autica 5 CAP´ ITULO 1. INTRODUCCI ´ ON La gran popularidad de la que gozan las aeronaves no tripuladas tanto en el sector profesional como en el de ocio, ha llevado a la creaci´on de nuevas regulaciones en cuanto al guiado de estas aeronaves en el espacio a´ereo. Prueba de esto es la regulaci´on creada en 2015 por la Civil Aviation Authority brit´anica [21]. 3.3. Instrumentaci´on de aeronaves Los instrumentos de vuelo utilizados en las aeronaves tripuladas han experimentado un gran cambio en las ´ultimas d´ecadas. Como en la mayor parte de los sectores tecnol´ogicos, se ha realizado una transici´on desde instrumentos anal´ogicos a instrumentos integrados en pantallas digitales que permiten una mejora sustancial de la cantidad y la visibilidad de la informaci´on mostrada. La constante mejora de los instrumentos de navegaci´on es otro punto a tener en cuenta, donde el concepto de Navegaci´on Basada en Prestaciones (PBN, Performance-Based Navigation) se muestra como el futuro de la navegaci´on a´erea. Una definici´on del concepto PBN se puede encontrar en el Manual de la OACI [22]. Sin embargo, la Tesis [23] presenta una definici´on elaborada y clara del concepto de PBN y su utilidad. El TCAS (Traffic Alert and Collision Avoidance System) es sin duda uno de los instrumentos de gran importancia en los cockpit de hoy en d´ıa. La funci´on de estos sistemas es la de alertar y evitar las posibles colisiones entre aeronaves, algo de vital importancia en los espacios a´ereos actuales, donde la ocupaci´on de los mismos es cada vez m´as alta. Este tipo de sistemas se basan en una naturaleza colaborativa, es decir, necesitan de la colaboraci´on del resto de aeronaves del espacio a´ereo, las cuales proporcionan los datos correspondientes de posici´on y velocidad, entre otros. Puesto que en el presente trabajo se ha implementado un TCAS de tipo I, se proceder´a a describir en mayor profundidad el sistema en secciones posteriores. En cuanto a los desarrollos presentes y futuros, cabe mencionar que el TCAS de tipo II es el que actualmente se utiliza en la gran mayor´ıa de la aviaci´on comercial. Este tipo de TCAS no solamente advierte del peligro de colisi´on, sino que da unas directrices al piloto sobre c´omo evitar dicha colisi´on. Pese a tratarse de un sistema que lleva en funcionamiento numerosos a˜nos, se siguen desarrollando mejoras al mismo, tal y como se puede observar en [24, 25], donde se muestra informaci´on de los cambios en la regulaci´on y en las capacidades del sistema. Aunque el TCAS II sigue siendo utilizado y desarrollado hoy en d´ıa, la intenci´on en un futuro es migrar hacia otro tipo de sistemas cooperativos llamados ADS-B (Automatic Dependent Surveillance Broadcast) basados en la distribuci´on de la posici´on GPS y las trayectorias de las distintas aeronaves. Esta red de distribuci´on la 6 Master Universitario en Ingenier´ıa Aeron´autica 3. ESTUDIO DEL ESTADO DEL ARTE componen tanto las aeronaves que se encuentran en el espacio a´ereo como los controladores de tr´afico a´ereo. A partir de dichas posiciones y trayectorias y mediante una l´ogica muy similar a la empleada en el TCAS tradicional, se realizar´ıan los c´alculos correspondientes para evaluar el riesgo de colisi´on. Esta tecnolog´ıa se encuentra actualmente en fases de desarrollo, sin embargo se prev´e su entrada en servicio en aviaci´on civil en los pr´oximos a˜nos. En la tesis [26] se puede encontrar una definici´on extensa del sistema ADS-B as´ı como un estudio de los beneficios que puede llegar a implicar su implantaci´on. En 2010 la FAA publica en el CFR Part 19 [27] la regulaci´on sobre la cual se rigen los sistemas ADS-B. Dos a˜nos antes, en 2008, la misma organizaci´on plantea un estudio para evaluar las ventajas de la utilizaci´on de sistemas ADS-B, para ello instala el sistema en 12 Boeing 747-400 de United Airlines y en 2010 empieza a probar dicho sistema en condiciones reales. En diciembre de 2015 se publica un informe que recopila los resultados [28]. En este estudio se puedo demostrar que los sistemas ADS-B pueden permitir un ahorro significativo de combustible al permitir una optimizaci´on mayor de las rutas. Sin embargo, tambi´en se hace hincapi´e en la necesidad de formaci´on de los pilotos y ATCs para que el sistema se utilice correctamente y se pueda dar dicho ahorro de combustible. 3.4. Desarrollo de interfaces gr´aficas La digitalizaci´on del cockpit y la gran cantidad de instrumentos que se han a˜nadido en los ´ultimos a˜nos han propiciado una preocupaci´on por parte de las autoridades reguladoras en cuanto a la seguridad. La cantidad de informaci´on que se muestra en las cabinas de una aeronave comercial va en aumento a medida que evolucionan los instrumentos y se vuelven m´as complejos. El desarrollo de las interfaces gr´aficas de los equipos de electr´onica de consumo se rige por factores tales como la presentaci´on clara y ordenada de la informaci´on, as´ı como la consecuci´on de un dise˜no que permita la mejor experiencia de usuario posible. Esto ´ultimo implica que la interfaz con un mejor impacto visual y que puede gozar por tanto de una mejor aceptaci´on por el p´ublico general, puede no ser la interfaz que mejor presente la informaci´on. Cuando se aplican ´estos conceptos al sector de la aeron´autica, la prioridad deja de ser la experiencia de usuario y pasa a ser la seguridad operacional. Una buena interfaz gr´afica para ser implementada en un cockpit debe de cumplir con una serie de requisitos que garanticen que su uso no va a interferir negativamente en la seguridad. El estudio de c´omo puede afectar el dise˜no de una interfaz gr´afica a la seguridad operacional se engloba dentro de la disciplina de factores humanos (human factors). En el cap´ıtulo 1 de [29] se define a los factores humanos como: “Un amplio campo que examina la interacci´on entre personas, m´aquinas y el ambiente con el prop´osito de mejorar las prestaciones y reducir errores”. Los factores humanos se centran en una gran cantidad de factores que pueden alterar la seguridad y las prestaciones, donde el desarrollo de interfaces gr´aficas coherentes, ordenadas y Master Universitario en Ingenier´ıa Aeron´autica 7 CAP´ ITULO 1. INTRODUCCI ´ ON seguras es clave en las aeronaves de hoy en d´ıa. En la literatura se pueden encontrar diversos ejemplos del inter´es que suscitas estos temas en las entidades reguladoras de aviaci´on civil, tanto en conferencias ( [30]), como en la literatura ( [29, 31]). Adem´as, la comunidad cient´ıfica tambi´en est´a interesada en profundizar en los desarrollos de las denominadas interfaces hombre-m´aquina (Human-Machine Interface, HMI). En [32] se muestra una introducci´on a los nuevos conceptos utilizados en factores humanos as´ı como importancia para mejorar la seguridad en la automatizaci´on del vuelo. Sin embargo, gran parte de los estudios centrados en el desarrollo de interfaces hombre-m´aquina se centran hoy en d´ıa en las aeronaves no tripuladas. En [33] se estudian los problemas a resolver en las interfaces hombre-m´aquina de los sistemas FMS para posibilitar la inclusi´on de UAVs en el espacio a´ereo no segregado. Mientras que en [34] se muestran una serie de recomendaciones para el desarrollo de una estaci´on de tierra de control de UAVs de forma que se cumplan los requisitos de seguridad desde el punto de vista de factores humanos. 3.5. Simulaci´on de vuelo El desarrollo plataformas de simulaci´on de vuelo fiables y completas se justifica en la gran cantidad de aplicaciones que pueden tener, desde entrenamiento de pilotos u operadores, hasta la validaci´on de misiones en UAVs, llegando incluso a conectar autopilotos reales a un simulador de vuelo. El uso de simuladores como plataforma de entrenamiento de pilotos es una actividad muy extendida hoy en d´ıa, ya que permite abaratar en gran medida el entrenamiento de los pilotos y mejorar al mismo tiempo la seguridad en el mismo. Actualmente todos los pilotos de aerol´ıneas comerciales pasan en alg´un momento de su entrenamiento por sesiones de pilotaje en el simulador. Entre las ventajas de estos simuladores se encuentran la versatilidad y la gran cantidad de situaciones que se pueden simular sin riesgo alguno: p´erdida de un motor, condiciones de viento cruzado, mala visibilidad, etc. En la actualidad son muchas las compa˜n´ıas que se dedican al desarrollo de software o hardware para este tipo de simuladores, donde FlightSafety International (fabricante de simuladores para el Airbus A320 y Boeing 737, entre otros modelos [35]) o Aerosim (fabricante de simuladores para el Airbus A320 y Boeing 767 entre otros [36]) son algunos ejemplos. En los ´ultimos a˜nos, la combinaci´on de simuladores de vuelo con el hardware de los autopilotos se ha convertido un recurso muy utilizado, sobretodo en el sector de los UAVs. Este tipo de t´ecnicas se denominan Hardware-in-the-Loop (HIL). El inter´es en realizar t´ecnicas de simulaci´on se remonta a˜nos atr´as, si bien hasta la proliferaci´on de las aeronaves no tripuladas, no se hab´ıa extendido tanto su uso para realizar ensayos 8 Master Universitario en Ingenier´ıa Aeron´autica 4. ESTRUCTURA DE LA MEMORIA sobre autopilotos completos. Entre las ventajas del HIL se encuentran la facilidad con la que se pueden replicar condiciones de vuelo sobre hardware real, permitiendo as´ı que se pueda ensayar tanto el mismo hardware como el software implementado. Esto permite obtener ventajas potenciales para los largos y complejos procesos de certificaci´on. En [37] se realiza una introducci´on al concepto HIL y se comparan los resultados obtenidos en ensayos HIL utilizando un peque˜no UAV y el simulador de c´odigo abierto FlightGear 1. En [38] su utiliza X-Plane como simulador (el mismo simulador utilizado en el presente trabajo) se realzan las capacidades de dicha t´ecnica para minimizar los riesgos intr´ınsecos a los test de vuelo de los UAV. Esto permite tener una mayor confianza en la configuraci´on de la aeronave antes de volar, lo que permite aumentar considerablemente la seguridad y facilita enormemente el desarrollo de aeronaves no tripuladas, permitiendo realizar multitud de ensayos con HIL sin riesgo alguno. Esta l´ınea de acci´on est´a siendo adoptada por las empresas del sector de las aeronaves no tripuladas, donde se encuentran incluso empresas espa˜nolas como Embention, quien realiz´o sus primeros tests HIL con X-Plane en 2014 y viene utilizando dicha t´ecnica de forma ininterrumpida desde entonces [39]. 4. Estructura de la memoria Una vez introducido el trabajo, se procede a definir la estructura del proyecto en los cap´ıtulos siguientes. El Cap´ıtulo 2 se centrar´a en el proceso de dise˜no seguido en este proyecto. Para ello se realizar´a primero una descripci´on del proyecto y de la arquitectura implementada en el sistema. Posteriormente se hablar´a de la metodolog´ıa seguida en el dise˜no, tanto de desarrollo de software como de la propia implementaci´on gr´afica del cockpit. A continuaci´on se describir´a el modelo seguido para la realizaci´on del dise˜no y la gesti´on del proyecto. Seguidamente se definir´an los requisitos del sistema, dividi´endolos seg´un la naturaleza de los mismos (funcionales, no funcionales y caracter´ısticas deseables). Finalmente se enumerar´an las principales herramientas utilizadas en el desarrollo del proyecto. El Cap´ıtulo 3 se describir´a todo lo relativo a la implementaci´on de los elementos gr´aficos de la interfaz, donde se har´a una menci´on mucho m´as detallada de los instrumentos implementados. Para cada uno de los instrumentos implementados se realizar´a una descripci´on del mismo, de su utilidad y de su funcionamiento. Adem´as, se hablar´a de la implementaci´on del c´odigo de cada uno de los instrumentos que se incluyen en este trabajo. El Cap´ıtulo 4 habla de las interfaces con los perif´ericos que se han implementado. 1http://www.flightgear.org/ Master Universitario en Ingenier´ıa Aeron´autica 9 CAP´ ITULO 1. INTRODUCCI ´ ON Se han implementado dos interfaces con perif´ericos: la interfaz con el simulador de vuelo X-Plane y la interfaz con la antena de tr´afico a´ereo. En este cap´ıtulo se procede a describir primero la interfaz y la raz´on por la que se ha implementado para, posteriormente, describir en mayor detalle c´omo se ha implementado la interfaz. El Cap´ıtulo 5 trata sobre el autopiloto implementado en este trabajo. Primero se describir´a la arquitectura de dicho autopiloto para, posteriormente, pasar a definir los algoritmos de guiado y control que se han implementado. Finalmente se muestra la interfaz realizada para la gesti´on del autopiloto, describiendo sus principales funcionalidades. El Cap´ıtulo 6 se analizar´an los resultados obtenidos para ver cu´ales han sido los requisitos que se han cumplido de forma satisfactoria y cu´ales no se han podido cumplir o que son sensibles a mejora. Se identificar´an las ´areas de mejora del proyecto y se tratar´a de aportar posibles soluciones a las mismas. Por ´ultimo, en el Cap´ıtulo 7 se mostrar´an las conclusiones extra´ıdas durante la realizaci´on del presente proyecto. Analizando las mismas y proponiendo una serie de trabajos futuros que puedan complementar al proyecto. 10 Master Universitario en Ingenier´ıa Aeron´autica Cap´ıtulo 2 Dise˜no del sistema 1. Descripci´on del proyecto Tal y como se ha comentado en secciones anteriores (Secci´on 2 del Cap´ıtulo 1), la intenci´on del presente trabajo es la de crear una plataforma integral de simulaci´on que permita afianzar conceptos relacionados con multitud de contenidos ´ıntimamente relacionados al sector aeron´autico. El principal fin de este trabajo es el de crear una plataforma que sea ´util desde un punto de vista did´actico para poder ser utilizada en cursos de Ingenier´ıa Aeron´autica. La intenci´on es que la plataforma sea ´util para la ense˜nanza de temas tan variados como la programaci´on orientada a objetos, la instrumentaci´on aeron´autica o conceptos de navegaci´on, guiado y control. Con lo objetivos planteados en mente, se decide crear dicha plataforma asumiendo que ya se tiene un motor de simulaci´on ya que el desarrollo del mismo ser´ıa una tarea que exceder´ıa con creces el objetivo de este proyecto y para la que no se dispone de medios suficientes. Puesto que se va a crear una interfaz gr´afica, es deseable que el motor de simulaci´on utilizado carezca de interfaz gr´afica o que, al menos, permita que ´esta sea desactivada. En este sentido, se ha realizado un estudio de alternativas (Secci´on 1.1 del Cap´ıtulo 4) para elegir de forma razonada el motor de simulaci´on que m´as se adapte a las necesidades de este trabajo. Con esto, se procede a describir de forma general la arquitectura del sistema implementado. 1.1. Detalles y estructura El presente proyecto consiste en la implementaci´on de un panel de instrumentos gr´afico, dotado de cierto realismo gracias al aspecto de cabina. Adem´as, el sistema es capaz de interaccionar con un motor de simulaci´on de vuelo (X-Plane en este caso) y con una antena que lee datos de tr´afico a´ereo en tiempo real. Esto, unido a la implementaci´on de un autopiloto permite conseguir una plataforma integral de 11 CAP´ ITULO 2. DISE ˜ NO DEL SISTEMA 4.1. Nomenclatura de los requisitos Para dotar de una mayor claridad al an´alisis de requisitos que se realizar´a en las secciones finales del presente proyecto, se ha decidido implementar una nomenclatura espec´ıfica y ´unica para distinguir a cada requisito de forma un´ıvoca. Los requisitos presentados se engloban en dos categor´ıas distintas (funcionales y no funcionales) a las que hay que a˜nadir una categor´ıa extra compuesta por las caracter´ısticas deseables del sistema (nice to have). Para poder distinguir de forma r´apida y eficaz, los requisitos se enumerar´an siguiendo la nomenclatura descrita en las siguientes l´ıneas: Requisitos funcionales: Se definir´an mediante el indicador FR-x, donde FR son las siglas de Functional Requirement y “x” es un n´umero identificador ´unico para cada requisito. Requisitos no funcionales: En este caso se utilizar´a el identificador NFR-x, donde NFR son las siglas de Non-Functional Requirement y “x” es nuevamente un n´umero identificador ´unico. Caracter´ısticas deseables o “nice to have”: Se utilizar´a la nomenclatura NTH-x, donde NTH son las siglas de Nice To Have y “x” es el n´umero identificador. 4.2. Requisitos funcionales El sistema debe cumplir los requisitos funcionales mostrados a continuaci´on: FR-1 El sistema ha de poder ser ejecutado en distintas plataformas y sistemas operativos. FR-2 El sistema ha de tener una interfaz gr´afica que permita su manejo. FR-3 El sistema ha de incluir los siguientes instrumentos de forma funcional: ASI ADI ALT T/S HI VSI TCAS FR-4 Los instrumentos del sistema deben de alimentarse de datos simulados para su funcionamiento. 18 Master Universitario en Ingenier´ıa Aeron´autica 4. REQUERIMIENTOS DEL SISTEMA FR-5 Los datos simulados han de obtenerse en tiempo real de un simulador de vuelo. FR-6 El sistema ha de poder enviar acciones de control al simulador y actuar sobre el mismo. FR-7 El TCAS debe de ser capaz de nutrirse de datos de tr´afico a´ereo real. FR-8 El TCAS debe de poder estimar el riesgo de colisi´on siguiendo la metodolog´ıa usada en instrumentos reales. FR-9 El TCAS debe de ser, como m´ınimo, de tipo I. FR-10 El sistema ha de implementar un autopiloto. FR-11 El autopiloto debe de ser capaz de controlar, como m´ınimo un modelo de aeronave. FR-12 El autopiloto debe de ser capaz, como m´ınimo, de controlar una aeronave desde la carrera de despegue hasta la de crucero. FR-13 El autopiloto ha de ser configurable en sus distintas fases. FR-14 La configuraci´on del autopiloto ha de permitir la inclusi´on de salidas est´andar tipo SID. FR-15 El sistema debe permitir el control manual de la aeronave en vuelo sin necesidad de que el usuario interact´ue con el simulador de vuelo. 4.3. Requisitos no funcionales Los requisitos no funcionales del sistema se muestran a continuaci´on: NFR-1 El sistema ha de ser de utilidad para la docencia de dise˜no de software orientado a objetos en aplicaciones de ingenier´ıa aeron´autica. NFR-2 El c´odigo ha de implementarse mediante un lenguaje orientado a objetos. NFR-3 El c´odigo se ha de implementar de forma modular. NFR-4 El sistema debe permitir la mejora de sus funcionalidades o la inclusi´on de nuevas caracter´ısticas de forma sencilla. NFR-5 El sistema debe de ser sencillo de utilizar. NFR-6 La configuraci´on de la antena o el autopiloto debe de ser simple y debe requerir una una acci´on m´ınima por parte del usuario. Master Universitario en Ingenier´ıa Aeron´autica 19 CAP´ ITULO 2. DISE ˜ NO DEL SISTEMA 4.4. Caracter´ısticas deseables o “nice to have” A continuaci´on se enumeran las caracter´ısticas deseables del sistema. Como se ha comentado con anterioridad, dichas caracter´ısticas presentan un car´acter optativo en cuanto su implementaci´on, sin embargo, conviene mencionarlas e intentar conseguir, en la medida de lo posible, cumplir con la mayor´ıa de ellas. NTH-1 El sistema debe de poder ejecutarse en un ordenador con recursos limitados. NTH-2 El c´odigo Java debe de estar lo m´as optimizado posible. NTH-3 El simulador de vuelo debe de consumir el m´ınimo de recursos posible. A ser posible se utilizar´a un motor de simulaci´on sin interfaz gr´afica. NTH-4 A ser posible, se dotar´a al autopiloto de la capacidad de controlar distintos modelos de aeronaves. NTH-5 El autopiloto debe de poder configurarse mediante archivos de configuraci´on generados con anterioridad. NTH-6 Los datos de tr´afico a´ereo deben de poder simularse mediante un archivo de trazas generado con anterioridad para casos en los que no est´e disponible la antena. NTH-7 Los tipos de misi´on han de ser configurables en el autopiloto. NTH-8 El autopiloto debe de poder gestionar una misi´on completa, desde el despegue hasta el aterrizaje. 5. Herramientas utilizadas en el desarrollo En esta secci´on se procede a describir las herramientas inform´aticas necesarias para el desarrollo del presente proyecto. Cabe destacar que el razonamiento seguido en la elecci´on de ciertas herramientas software ser´a descrito en los siguientes cap´ıtulos. 5.1. JavaTM - Entorno NetBeans El lenguaje de programaci´on JavaTM en el entorno NetBeans es la competencia instrumental espec´ıfica de la asignatura que enmarca el presente proyecto, por lo que compone la herramienta principal utilizada en el presente proyecto. JavaTM es un lenguaje de programaci´on de prop´osito general, concurrente, orientado a objetos que fue dise˜nado espec´ıficamente para tener tan pocas dependencias de implementaci´on como fuera posible. Su intenci´on es permitir que los desarrolladores de aplicaciones escriban el programa una vez y lo ejecuten en cualquier dispositivo (conocido en ingl´es como WORA, o write once, run anywhere), lo que quiere decir que el c´odigo que es ejecutado en una plataforma no tiene que ser 20 Master Universitario en Ingenier´ıa Aeron´autica 5. HERRAMIENTAS UTILIZADAS EN EL DESARROLLO recompilado para correr en otra. JavaTM es, a partir de 2012, uno de los lenguajes de programaci´on m´as populares en uso, particularmente para aplicaciones de cliente-servidor de web, con unos 10 millones de usuarios reportados. El lenguaje de programaci´on JavaTM fue originalmente desarrollado por James Gosling de SunrMicrosystems (la cual fue adquirida por la compa˜n´ıa Oracler) y publicado en 1995 como un componente fundamental de la plataforma JavaTM de Sunr Microsystems. Su sintaxis deriva en gran medida de C y C++, pero tiene menos utilidades de bajo nivel que cualquiera de ellos. Las aplicaciones de Java son generalmente compiladas a bytecode (clase Java) que puede ejecutarse en cualquier m´aquina virtual JavaTM (JVM) sin importar la arquitectura de la computadora subyacente. La interfaz del entorno NetBeans se muestra en la Figura 2.4. NetBeans es un entorno de desarrollo integrado libre, desarrollado principalmente para el lenguaje de programaci´on JavaTM. Existe adem´as un n´umero importante de m´odulos para extenderlo. NetBeans IDE es un producto libre y gratuito sin restricciones de uso fundado por SunrMicroSystems. Figura 2.4: Entorno gr´afico de NetBeans 5.2. Motor de simulaci´on - X-Plane Otra de las grandes herramientas necesarias para el desarrollo del proyecto es un motor de simulaci´on de vuelo. Existen numerosas alternativas disponibles y que cumplen con los requisitos impuestos en este proyecto. La intenci´on inicial era la de elegir un motor de simulaci´on sin interfaz gr´afica, sin embargo, existen otras variables que pueden afectar a la elecci´on del mejor motor de simulaci´on para este trabajo. Es Master Universitario en Ingenier´ıa Aeron´autica 21 CAP´ ITULO 2. DISE ˜ NO DEL SISTEMA por esto que se ha realizado un an´alisis de dichas alternativas en la Secci´on 1.1 del Cap´ıtulo 4. El motor de simulaci´on elegido en dicho tras la realizaci´on de dicho estudio es el simulador de vuelo X-Plane, con el cual se establece conexi´on para la recepci´on y env´ıo de informaci´on desde la interfaz implementada en el proyecto. A continuaci´on se procede a describir brevemente las principales caracter´ısticas de dicho simulador. X-Plane, creado por Austin Meyer, es un simulador de vuelo de aeronaves civiles. Se ha establecido como uno de los principales simuladores de vuelo que son capaces de competir el simulador Flight Simulator de Microsoftr. Seg´un Austin Meyer, el simulador est´a dotado de una gran precisi´on, ya que se basa en calcular el efecto del flujo de aire sobre las superficies de los aviones simulados. La clave del realismo de la f´ısica de vuelo de X-Plane es la creaci´on de un t´unel de viento virtual alrededor del avi´on, consiguiendo as´ı efectos parecidos a los reales. Dado que el prop´osito de este simulador es ofrecer una experiencia de vuelo lo m´as realista posible, cuenta con una amplia gama de aviones simulados, desde los m´as sencillos hasta los grandes reactores. Adem´as, es capaz de generar una recreaci´on del planeta tierra con sus accidentes geogr´aficos y alrededor de 18.000 aeropuertos, aer´odromos y helipuertos, as´ı como portaaviones en los que realizar sus pr´acticas de vuelo. Todas estas caracter´ısticas le han servido para que la Administraci´on Federal de Aviaci´on (FAA) de Estados Unidos autorice su uso, junto con hardware espec´ıfico, para el entrenamiento de pilotos de vuelo instrumental. 5.3. Otro software Adem´as, para la consecuci´on de este proyecto, se ha hecho uso de otro software como: Matlabr AdobeTM Photoshopr AutoCADr 22 Master Universitario en Ingenier´ıa Aeron´autica Cap´ıtulo 3 Implementaci´on de la interfaz gr´afica y los instrumentos 1. Interfaz gr´afica: cockpit. Generaci´on de instrumentos La interfaz gr´afica consta de cuatro grandes elementos: Panel de instrumentos Instrumentos Fondo Controles: Mandos de vuelo y palanca de gases Como ya se ha comentado, en este proyecto se decidi´o exprimir toda la capacidad de dos herramientas muy simples: los iconos de la clase swing JLabel y el m´etodo rotateIcon, que consiste en re-ubicar los p´ıxeles de una imagen, uno a uno, para rotar la misma. Esta forma de implementaci´on requiere un esfuerzo computacional grande y es posible que la implementaci´on con la librer´ıa Graphics2D de JavaTM diese mejor resultado, sin embargo, gran parte del m´erito de este proyecto reside en la sencillez de las herramientas utilizadas en la implementaci´on. Todos estos elementos se cargan por medio del uso del c´odigo puro de JavaTM. Se ha generado un layeredPane sobre el que se van creando diversas capas en las que se insertan los distintos elementos gr´aficos. 1.1. Panel de instrumentos El panel de instrumentos se extrajo del cockpit original de la Cessna C-172 de X-Plane y se realizaron algunas modificaciones para mejorar la visualizaci´on de los 23 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS instrumentos que se van a implementar. Con este fondo, se le consigue dar un aspecto m´as realista a la aplicaci´on. La Figura 3.1 muestra dicha imagen. Figura 3.1: Panel de instrumentos Como se puede observar hay 6 huecos circulares, donde se situar´an los instrumentos, que de izquierda a derecha y de arriba a abajo son: ASI, ADI, ALT, T/S, HI y VSI. El hueco cuadrado corresponde al panel del TCAS. 1.1.1. Localizaci´on de los instrumentos Con el objetivo de promover la modularidad del c´odigo y facilitar su adaptabilidad a nuevas disposiciones de la cabina o a nuevas implementaciones de instrumentos, se ha decidido no incluir directamente en el c´odigo los par´ametros utilizados para la generaci´on del cockpit. De esta forma, se ha optado por crear un archivo de configuraci´on, llamado guiDataFile.txt, donde se guardar´a toda la informaci´on relevante para la distribuci´on de los objetos de la cabina. Los instrumentos se a˜naden al layeredPane mediante el m´etodo loadInstruments(String file), el cual lee el archivo guiDataFile.txt. Este archivo de texto est´a escrito de una forma interpretable por ese m´etodo, de forma que genera el instrumento en la localizaci´on indicada, un instrumento que a su vez ser´a de la clase creada Instrument, y que estar´a compuesto de las distintas im´agenes cuyas rutas se indican. 24 Master Universitario en Ingenier´ıa Aeron´autica 1. INTERFAZ GR ´ AFICA: COCKPIT. GENERACI ´ ON DE INSTRUMENTOS El formato se puede ver en la Figura 3.2, donde por ejemplo, en la l´ınea 19 se crea el nuevo instrumento NewInstrument ASI, en la localizaci´on {x, y}={167,323}y se compone de los 3 JLabels asi face, asi hand yasi case, cuyos respectivos iconos o im´agenes se encuentran en las rutas images/asi/asi face.png etc´etera. Figura 3.2: Aspecto del fichero guiDataFile.txt Se ha tomado esta decisi´on ya que es una manera f´acil de generar otros paneles de instrumentos en otro orden o con otra geometr´ıa o incluso otros instrumentos, todo ello sin necesidad de alterar el c´odigo fuente del programa, ya que solo es necesario modificar el fichero guiDataFile.txt. El aspecto final del panel de instrumentos con todos los elementos cargados es el que muestra la Figura 3.3. Como se puede observar incluye el stick oyoke y la palanca de gases o throttle, y ambos permiten la interacci´on con el usuario y se mueven de una forma bastante realista, incluso el stick, con el que se visualiza bastante bien la sensaci´on de aplicar roll e incluso pitch. Master Universitario en Ingenier´ıa Aeron´autica 25 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS Figura 3.3: Panel de instrumentos Cockpit Hay que recalcar que todos los elementos de los instrumentos son funcionales: desde las distintas agujas, reglas e incluso el regulador de la presi´on del alt´ımetro y la peque˜na esfera del coordinador de giro. 1.2. Fondo Tambi´en se ha querido mencionar por separado el fondo, el cual consiste en una imagen panor´amica de 360o. Se ha querido implementar para dar sensaci´on de movimiento a la cabina, ya que este fondo se desplazar´a de acuerdo a la actitud que tenga el avi´on en cada momento. La imagen utilizada para el fondo se muestra en la Figura 3.4. Figura 3.4: Imagen utilizada para el fondo de la interfaz gr´afica. 1.3. Controles: Mandos de vuelo y palanca de gases A pesar de que se ha incluido un autopiloto capaz de despegar la aeronave desde la pista y llevarlo hasta la fase de crucero, se se ha considerado ´util a˜nadir la capacidad 26 Master Universitario en Ingenier´ıa Aeron´autica 1. INTERFAZ GR ´ AFICA: COCKPIT. GENERACI ´ ON DE INSTRUMENTOS de controlar de forma manual la aeronave mediante la interfaz. Debido a la simplicidad de la aeronave elegida, es posible controlar la misma ´unicamente mediante los mandos de vuelo b´asicos (conocido como yoke) y una palanca de gases. Con estos dos instrumentos es posible controlar la aeronave en vuelo sin problema alguno. Cabe destacar que debido a que la imagen de fondo es siempre la misma, no se ha considerado ´util implementar un control manual del rudder, ya que no ser´ıa posible despegar la aeronave desde la pista de forma manual utilizando ´unicamente la interfaz presentada en este proyecto. Adem´as, el uso del rudder en vuelo para coordinar el giro no ser´ıa posible, ya que con el rat´on ´unicamente podr´ıamos actuar sobre un instrumento a la vez, que en este caso ser´ıa el del yoke. Los controles implementados se pueden observar en la Figura 3.5. Figura 3.5: Controles implementados en la interfaz gr´afica. 1.3.1. Uso de los mandos de vuelo (yoke) Los mandos de vuelo implementados est´an basados en los mandos reales de la aeronave Cessna 175 Skyhawk. El control de los mismos utiliza el mismo mecanismo que el utilizado en el simulador X-Plane. Dicho control se basa en el utilizado por otros simuladores como X-Plane o Microsoft Flight Simulator. Para actuar sobre los controles, es suficiente con hacer click en la zona en la que se Master Universitario en Ingenier´ıa Aeron´autica 27 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS posible mover cada una de la forma adecuada para simular el funcionamiento real del instrumento. Figura 3.9: Descomposici´on del ADI en capas Las capas se han superpuesto siguiendo el siguiente orden, donde la numeraci´on ascendente implica que la capa con el n´umero m´as alto se trata de la capa m´as superficial. Adem´as, se ha seguido la notaci´on de la Figura 3.9 para una mayor claridad: 1. adi back 2. adi face 3. adi ring 4. adi case 2.2.3. Implementaci´on del c´odigo El horizonte artificial es sin duda el instrumento m´as complejo mec´anicamente del grupo denominado como standard six. Esto conlleva que su implementaci´on sea tambi´en algo m´as compleja que la de otros instrumentos. Pese a su complejidad, el horizonte artificial tiene ´unicamente dos capas m´oviles, dichas capas, siguiendo la notaci´on de la Figura 3.9, son: adi face: Esta pieza m´ovil es la encargada de dar informaci´on acerca del ´angulo de pitch de la aeronave. adi ring: Esta capa es la encargada de dar informaci´on acerca del ´angulo de roll de la aeronave. 34 Master Universitario en Ingenier´ıa Aeron´autica 2. IMPLEMENTACI ´ ON DE LOS INSTRUMENTOS Por tanto, en el c´odigo implementado se deber´an de tener en cuenta tanto el ´angulo de pitch como el de roll. Representaci´on del ´angulo de pitch: Para ser capaces de representar el ´angulo de pitch de forma correcta, se han tenido que contar los p´ıxeles a los que corresponden las marcas de +10oy -10ode la imagen adi face. Una vez calibrado correctamente, se ha simplemente se llama al m´etodo translateLabel con el n´umero de p´ıxeles correspondiente. Representaci´on del ´angulo de roll: El procedimiento seguido para la representaci´on del ´angulo de roll m´as sencillo que en el caso anterior. En este caso, simplemente se ha de rotar la imagen adi ring el ´angulo correspondiente llamando al m´etodo rotateLabel. 2.3. ALT - Alt´ımetro: Indicador de altitud 2.3.1. Descripci´on El alt´ımetro es un instrumento indispensable para garantizar una vuelo seguro. La funci´on del alt´ımetro no es otra que la de indicar al piloto la altura a la que se est´a volando. Los alt´ımetros utilizados en aviaci´on basan su medici´on en la presi´on est´atica. A partir de la presi´on est´atica se puede obtener la altura a la que se encuentra la aeronave mediante el uso de modelos de atm´osfera est´andar (ISA). El principio de operaci´on de un alt´ımetro barom´etrico se basa en la compresi´on de una serie de cilindros en cuyo interior se ha realizado un vac´ıo parcial. La presi´on atmosf´erica a la que est´an sometidas las caras del cilindro deforman al mismo y esta deformaci´on es la que mueve a la aguja del alt´ımetro en mayor o menor medida. La morfolog´ıa del mecanismo que compone el alt´ımetro se puede ver en la Figura 3.10. En este caso, el alt´ımetro implementado es el conocido como alt´ımetro de tres agujas, el mismo tipo que se muestra en la Figura 3.10. En este tipo de alt´ımetros, la aguja de grosor intermedio usa una escala de 100 pies en la esfera. La aguja gruesa y corta utiliza una escala de 1000 pies, mientras que la aguja larga y m´as fina (terminada en un triangulo invertido) tiene una escala de 10000 pies. La suma de la lectura de las tres agujas ser´a la lectura de altura total. El alt´ımetro utilizado implementa tambi´en una rueda de regulaci´on de la presi´on de referencia, para ajustar as´ı la altura mostrada por el alt´ımetro en funci´on de la presi´on. Master Universitario en Ingenier´ıa Aeron´autica 35 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS Figura 3.10: Esquema del mecanismo de un alt´ımetro barom´etrico. Fuente: [29] 2.3.2. Generaci´on por capas Las im´agenes utilizadas en el layeredPane para la recreaci´on gr´afica del alt´ımetro se muestran en la Figura 3.11. En este caso se puede observar c´omo, debido a la multitud de escalas presentes en este instrumento, el n´umero de im´agenes superpuestas necesarias es mayor que en otros instrumentos. Figura 3.11: Descomposici´on del Alt´ımetro (ALT) en capas Las capas se han superpuesto siguiendo el siguiente orden, donde la numeraci´on ascendente implica que la capa con el n´umero m´as alto se trata de la capa m´as superficial. 36 Master Universitario en Ingenier´ıa Aeron´autica 2. IMPLEMENTACI ´ ON DE LOS INSTRUMENTOS Adem´as, se ha seguido la notaci´on de la Figura 3.11 para una mayor claridad: 1. alt face 1 2. alt face 2 3. alt face 3 4. alt hand 1 5. alt hand 2 6. alt hand 3 2.3.3. Implementaci´on del c´odigo En este caso, las piezas m´oviles son las siguientes Labels: alt hand 1: Indica las d´ecimas de millar de pies. Cada marca del instrumento equivale a 10000 pies. En este caso, el ´angulo de rotaci´on de la aguja ser´a: θhand1=360 10000Altitud = 0,0036Altitud (3.1) alt hand 2: Esta aguja indica los millares de pies, por lo que el ´angulo que se deber´a de rotar ser´a una d´ecima parte de la aguja anterior: θhand2=360 1000Altitud = 0,036Altitud (3.2) alt hand 3: Indica los centenares de pies. Para escalar el ´angulo que se debe de rotar esta aguja es suficiente con aplicar el factor de conversi´on mostrado en (3.3): θhand3=360 100Altitud = 0,36Altitud (3.3) Por tanto, para mover las distintas agujas del alt´ımetro, se deber´a de llamar al m´etodo rotateLabel tres veces (una para cada aguja), con los valores obtenidos seg´un las expresiones (3.1), (3.3) y (3.3). 2.4. ASI - Airspeed Indicator: Indicador de velocidad 2.4.1. Descripci´on El Airspeed Indicator o ASI es un instrumento fundamental para la garantizar la seguridad en el vuelo. La necesidad de obtener una medida real de la velocidad del viento en la aeronave reside en el hecho de que el piloto debe garantizar en todo momento que est´a volando a la velocidad adecuada para la maniobra que est´e Master Universitario en Ingenier´ıa Aeron´autica 37 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS realizando. El ASI basa su medici´on en la comparaci´on entre la presi´on de parada y la presi´on est´atica para obtener la presi´on din´amica, para lo que se utiliza un tubo de Pitot. El funcionamiento del tubo de pitot se basa en la ecuaci´on de Bernouilli: pt=ps+q=ps+1 2ρu2(3.4) Donde, conociendo la presi´on de parada (pt) y la presi´on est´atica (ps) gracias a las mediciones del tubo de Pitot, se puede obtener f´acilmente el valor de la velocidad en funci´on de dichas presiones y de la densidad del aire: u=s2(pt−ps) ρ(3.5) Sin embargo, esto implica que se debe conocer la densidad del aire en cada instante para poder obtener el valor de la velocidad. Dicha densidad se puede obtener en funci´on de la altura de vuelo, utilizando el modelo de atm´osfera est´andar ISA. Sin embargo, dependiendo de la desviaci´on de la temperatura y de la presi´on del momento en concreto con la temperatura y presi´on del modelo est´andar, la velocidad medida deber´a ser corregida para obtener un valor real. Existen por tanto los siguientes tipos de velocidad aerodin´amica: IAS - Indicated Airspeed: Velocidad Indicada La velocidad indicada es la que se obtiene aplicando la Ecuaci´on (3.5) directamente con el valor de densidad correspondiente a nivel del mar de la atm´osfera est´andar ISA, sin correcciones de ning´un tipo. CAS - Calibrated Airspeed: Velocidad Calibrada La velocidad calibrada es una velocidad corregida a partir de la IAS. En este caso se realizan correcciones tanto por posici´on (altura) como por posibles errores del instrumento. Normalmente los instrumentos que muestran la CAS tienen una serie de tablas que les permiten corregir la velocidad seg´un los par´ametros que apliquen en cada momento. EAS - Equivalent Airspeed: Velocidad Equivalente La velocidad equivalente se obtiene al corregir la velocidad calibrada (CAS) por los efectos de la compresi´on del aire dentro del tubo de Pitot. A nivel del mar, CAS y EAS son id´enticas, sin embargo, a medida que aumenta la altura la velocidad CAS se vuelve mayor de lo que la EAS, raz´on por la que se aplica la correcci´on. TAS - True Airspeed: Velocidad Verdadera La velocidad verdadera se obtiene al corregir la velocidad calibrada (CAS) por las diferencias de presi´on y temperatura con respecto a la atm´osfera est´andar ISA. La velocidad TAS ser´a por tanto la velocidad aerodin´amica real de la aeronave. 38 Master Universitario en Ingenier´ıa Aeron´autica 2. IMPLEMENTACI ´ ON DE LOS INSTRUMENTOS En el caso del Airspeed Indicator, ´este muestra datos de velocidad indicada (IAS), esto se debe a que las actuaciones de la aeronave dependen en gran medida de la densidad del aire. Por tanto, la IAS es mucho m´as relevante que la TAS a la hora de pilotar una aeronave, ya que par´ametros como la velocidad de entrada en p´erdida ser´an constantes a cualquier altura siempre que se utilice en t´erminos de velocidad indicada (IAS). En el caso de utilizar la velocidad verdadera, la entrada en p´erdida se producir´ıa a distintas velocidades en funci´on de la altura. La Figura 3.12 muestra la estructura conceptual de un indicador de velocidad. En ella se puede observar c´omo el ASI requiere de dos valores de entrada: la presi´on total y la presi´on est´atica. Figura 3.12: Estructura conceptual de un indicador de velocidad. Fuente: [29] 2.4.2. Generaci´on por capas El ASI implementado en este proyecto, con sus correspondientes capas, se puede observar en la Figura 3.13. Se puede ver que en este caso se trata de un instrumento muy sencillo a nivel visual, raz´on por la que el n´umero de capas necesario para su representaci´on es muy reducido. En la Figura 3.14 se pueden observar distintas zonas delimitadas con colores en la circunferencia del ASI. ´ Estos arcos corresponden a zonas de operaci´on de la aeronave y se explican a continuaci´on: Arco blanco: Se trata del rango de operaci´on de la aeronave con flaps extendidos. Su l´ımite inferior marca la velocidad de entrada en p´erdida con flaps extendidos, mientras que su l´ımite superior indica la m´axima velocidad permitida con flaps Master Universitario en Ingenier´ıa Aeron´autica 39 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS Figura 3.13: Descomposici´on del Airspeed Indicator (ASI) en capas extendidos. Arco verde: Se trata del rango normal de operaci´on de la aeronave. Su l´ımite inferior marca la velocidad de entrada en p´erdida sin flaps, mientras que su l´ımite superior indica la m´axima velocidad recomendada en casos de viento turbulento. Arco amarillo: Se trata del rango de operaci´on en el que hay peligro de da˜no estructural. Su l´ımite inferior marca la m´axima velocidad recomendada en casos de viento turbulento mientras que su l´ımite superior marca la velocidad m´axima que nunca deber´ıa de ser rebasada (Never-exceed airspeed. L´ınea roja: La l´ınea roja situada en el l´ımite superior del arco amarillo indica a velocidad m´axima que nunca deber´ıa de ser rebasada (Never-exceed airspeed. Figura 3.14: Rangos de velocidad del Airspeed Indicator (ASI) Las capas se han superpuesto siguiendo el siguiente orden, donde, como en casos anteriores, la numeraci´on ascendente implica que la capa con el n´umero m´as alto se trata de la capa m´as superficial. Adem´as, se ha seguido la notaci´on de la Figura 3.13 para una mayor claridad: 40 Master Universitario en Ingenier´ıa Aeron´autica 2. IMPLEMENTACI ´ ON DE LOS INSTRUMENTOS 1. asi face 2. asi hand 3. asi case 2.4.3. Implementaci´on del c´odigo Para mostrar correctamente la velocidad en el ASI es suficiente con rotar la aguja los grados pertinentes (que en este caso se corresponde con la capa asi face). Sin embargo, en este caso en concreto, se puede observar que la escala del instrumento var´ıa seg´un la velocidad. Esto se puede observar f´acilmente en la Figura 3.15, donde se ha importado la imagen del instrumento a Autocadry se ha medido el ´angulo que define cada una de las tres escalas del instrumento. Figura 3.15: Obtenci´on de las escalas del Airspeed Indicator mediante Autocadr Tal y como se puede ver en la Figura 3.15, existen tres escalas distintas en el instrumento. Por tanto, la l´ogica que se debe de seguir para obtener el ´angulo de rotaci´on de la aguja es la siguiente: Master Universitario en Ingenier´ıa Aeron´autica 41 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS θrot =35 40V si V ≤40 KIAS θrot = 35 + 18 10(V−40) si 40 ≤V≤160 KIAS θrot = 35 + 18 10(160 −40) + 12 10(V−160) si V ≤160 KIAS                            (3.6) Por tanto, para mostrar de forma gr´afica la velocidad indicada, se llamar´a al m´etodo rotateLabel con el ´angulo obtenido de (3.6). 2.5. HI - Heading Indicator: Indicador del heading de la aeronave 2.5.1. Descripci´on El indicador del heading de la aeronave es un instrumento b´asico para la orientaci´on del piloto, sobretodo si no se dispone de radio-ayudas cercanas que nos permitan utilizarlas para seguir una ruta. Este tipo de instrumento basa su funcionamiento en la utilizaci´on de un giroscopio. El mecanismo interno es similar al visto en el ADI, sin embargo, en este caso lo que se mide es la rotaci´on sobre el eje vertical de la aeronave. Cabe destacar que la mayor´ıa de indicadores de heading no tienen capacidad para saber d´onde se encuentra el norte, ya que su funcionamiento se basa ´unicamente en el giroscopio. Es por esto que el piloto debe ayudarse de la rueda de calibraci´on para hacer coincidir el norte del HI con el norte magn´etico, para lo que se necesitar´a la ayuda de una br´ujula. La rueda de calibraci´on as´ı como el mecanismo girosc´opico de un HI se pueden observar en la Figura 3.16. 42 Master Universitario en Ingenier´ıa Aeron´autica 2. IMPLEMENTACI ´ ON DE LOS INSTRUMENTOS Figura 3.16: Estructura conceptual de un Heading Indicator (HI). Fuente: [44] 2.5.2. Generaci´on por capas La descomposici´on por capas del Heading Indicator implementado se muestra en la Figura 3.17. Cabe destacar que en este caso el instrumento implementado no tiene rueda de calibraci´on. Esto no es un problema ya que las medidas simuladas de lo sensores se obtienen directamente desde el simulador X-Plane, por lo que el instrumento indicar´a el heading de forma correcta. De la misma forma que en el caso de indicador de velocidad (ASI), el HI es un instrumento sencillo en cuanto a su representaci´on gr´afica. Esto es por lo que tres capas son suficientes para representar de forma correcta todas las funcionalidades del instrumento. Figura 3.17: Descomposici´on del Heading Indicator (HI) en capas En este caso, el orden de las capas, siguiendo la notaci´on de la Figura 3.17, ser´a el siguiente: Master Universitario en Ingenier´ıa Aeron´autica 43 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS X-Planercon el ´angulo de sideslip en cada momento. Despu´es de estos vuelos en los que se han recopilado datos sobre el comportamiento de la bola, se ha podido determinar que su movimiento se puede modelar de una forma razonablemente precisa asumiendo que la bola se mueve de forma proporcional al cambio del ´angulo de sideslip. El autor es consciente de que no se trata de la forma m´as exacta, sin embargo, teniendo en cuenta la poca exactitud del instrumento, se ha considerado que no era necesario optar por realizar un desarrollo te´orico. Esto, unido a la falta de par´ametros disponibles para medir correctamente los esfuerzos laterales desde X-Plane (los datos que X-Plane env´ıa por el protocolo UDP son limitados), justifica la aproximaci´on emp´ırica por la que se ha optado en este trabajo. Durante los vuelos realizados con el Simulador X-Plane, se ha observado que la esfera del coordinador de giro llega al extremo del instrumento aproximadamente a ±7ode sideslip. De esta forma, se ha obtenido la siguiente f´ormula emp´ırica para obtener el desplazamiento horizontal de la esfera en funci´on del ´angulo de sideslip (β): x=Round −Min  β 733 ,33·β |β|(3.7) Donde x es el n´umero de p´ıxeles de desplazamiento en la direcci´on horizontal y el signo negativo dentro del redondeo y la fracci´on final tienen la funci´on de garantizar que el movimiento de la esfera se realiza siguiendo el criterio de signos asociado al sistema de referencia de la interfaz gr´afica. El redondeo realizado se debe al hecho de que los desplazamientos que se pueden aplicar son p´ıxeles y por tanto se han de obtener desplazamientos con n´umeros enteros. Adem´as, la inclusi´on del m´ınimo es debido a que el m´aximo desplazamiento lateral de la esfera es de 33 p´ıxeles en la interfaz implementada. Obviamente, este valor variar´a si se altera la interfaz, por lo que en realidad se debe de implementar como un valor proporcional al tama˜no en p´ıxeles del instrumento. La Ecuaci´on (3.7) muestra el desplazamiento horizontal de la esfera. Sin embargo, a medida que se desplaza en horizontal, la esfera tambi´en se desplaza en la direcci´on vertical. Este desplazamiento se ha modelado mediante la ecuaci´on (3.8), bas´andose en la geometr´ıa del instrumento implementado. 50 Master Universitario en Ingenier´ıa Aeron´autica 2. IMPLEMENTACI ´ ON DE LOS INSTRUMENTOS y= 0 si |x| ≤ 15 y=−1si 15 ≤x≤22 y=−2si 22 ≤x≤25 y=−3si 25 ≤x≤31 y=−4si x ≥31                                                      (3.8) Una vez obtenidos los desplazamientos horizontal y vertical en p´ıxeles, se llama al m´etodo translateLabel con estos valores para mover la esfera a la posici´on deseada. Movimiento del indicador de ratio de giro (capa tc mark) El movimiento del indicador de ratio de giro es mucho m´as sencillo de modelar que el de la esfera del coordinador de giro. En este caso, es suficiente con rotar el label tc mark un determinado ´angulo, proporcional al ratio de giro. Desgraciadamente, el simulador de vuelo X-Plane no exporta el ratio de giro de la aeronave mediante su interfaz UDP. Debido a esta limitaci´on, el ratio de giro (ω) se ha tenido de calcular como la derivada discreta del ´angulo de track de la aeronave. ωn+ 1 = trkn+1 −trkn tn+1 −tn(3.9) Donde el ratio de giro obtenido anteriormente tendr´a las unidades de grado por segundo (o/s). Una vez calculado el ratio de giro instant´aneo de la aeronave, se debe escalar dicho ratio para obtener el ´angulo de rotaci´on de la capa correspondiente. Esto, como en otros instrumentos, se ha realizado mediante el uso del software Autocadry el resultado se muestra en la Figura 3.23. Master Universitario en Ingenier´ıa Aeron´autica 51 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS Figura 3.23: Obtenci´on de la escala del indicador de ratio de giro mediante Autocadr Con esto se puede calcular el ´angulo de rotaci´on de la capa tc mark teniendo en cuenta que las marcas de la Figura 3.23 delimitan un giro de 2 minutos, o lo que es lo mismo, un giro con un ratio de giro de ω= 3o/s. El ´angulo de rotaci´on del Label se calcula seg´un la expresi´on (3.10). Con dicho valor se llamar´a al m´etodo rotateLabel para que el instrumento indique correctamente el ratio de giro. θrot =21 3ω(3.10) 2.7. VSI - Vertical Speed Indicator: Indicador de la velocidad vertical 2.7.1. Descripci´on El indicador de velocidad vertical es un instrumento de gran utilidad en ascensos y en descensos, ya que permite al piloto tener una noci´on de su velocidad vertical en dichas maniobras. De esta forma se consigue que el piloto realice ascensos y descensos mucho m´as controlados y, por tanto, seguros. Sin embargo, la utilidad de un VSI no se limita ´unicamente a maniobras de ascenso y descenso. El VSI es tambi´en un instrumento de gran utilidad para mantener una altitud constante, debido a que su precisi´on es mucho mayor que la de un alt´ımetro. Si un piloto de sirve ´unicamente de un alt´ımetro para mantener su altura, es posible que su altura se reduzca m´as de un centenar de pies sin que el piloto se d´e cuenta. Por el contrario, sirvi´endose de un VSI, el piloto puede controlar su velocidad vertical f´acilmente y conseguir mantener su altura con pocos pies de error. El funcionamiento de un VSI es similar al de un indicador de velocidad (ASI). Sin embargo, en este caso no se comparan valores de presi´on de parada y presi´on est´atica, sino que se implementa una orificio de entrada de presi´on est´atica y un peque˜no orificio 52 Master Universitario en Ingenier´ıa Aeron´autica 2. IMPLEMENTACI ´ ON DE LOS INSTRUMENTOS de salida. Lo que se pretende medir con el VSI son los cambios de presi´on est´atica, lo que puede extrapolarse a cambios de altura. En este caso, al existir un peque˜no orificio de salida, cuando se produce un cambio de presi´on est´atica, ´esta termina por igualarse dentro del instrumento gracias al orificio de salida. Sin embargo, debido al reducido tama˜no del orificio, la presi´on tardar´a unos instantes en igualarse, por lo que se puede obtener una medida de la derivada de la presi´on atmosf´erica y con ello el ratio de cambio de altura (es decir, la velocidad vertical). En la Figura 3.24 se muestra la estructura interna que compone el VSI, la cual se basa en la deformaci´on de un cilindro debido a la presi´on aplicada en sus caras, algo que es com´un a otros instrumentos como el alt´ımetro o el indicador de velocidad. Figura 3.24: Estructura conceptual de un indicador de velocidad vertical (VSI). Fuente: [47] Uno de los inconvenientes del uso de los VSI tradicionales como el de la Figura 3.24 es el retraso existente entre el instante en el que se produce un cambio de velocidad vertical y el instante en el que se muestra dicho cambio en el instrumento. Esto es debido al tiempo que se tarda en que se modifiquen las presiones dentro del instrumento lo suficiente como para que se deformen los cilindros internos. Para resolver este problema, existen otro tipo de indicadores de velocidad vertical, m´as complejos y precisos; son los denominados: indicadores de velocidad vertical instant´aneos (Instantaneous Vertical Speed Indicators, IVSI). En este caso se a˜naden dos aceler´ometros que se activan por el cambio de pitch de la aeronave y mueven al mecanismo hacia la posici´on indicada. Una vez han dejado de actuar los aceler´ometros y el pitch ha dejado de variar, el tiempo de retraso de la medida del VSI tradicional ya ha pasado, por lo que el instrumento ya es capaz de medir los cambios de presi´on correctamente. Master Universitario en Ingenier´ıa Aeron´autica 53 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS En el instrumento que ocupa a este trabajo, el retraso en la medida de la velocidad vertical no existe debido a que dicha velocidad se toma directamente de los valores dados por el simulador X-Plane. Por tanto, el ´unico retraso existente es el producido por la frecuencia de adquisici´on de datos del simulador: 0,05 segundos (la adquisici´on de datos se realiza a 20 Hz). 2.7.2. Generaci´on por capas En la Figura 3.25 se muestra la descomposici´on por capas del VSI implementado. Debido a que el instrumento posee ´unicamente una parte m´ovil en su exterior (la aguja), 3 capas son suficientes para su representaci´on gr´afica. Figura 3.25: Descomposici´on por capas del indicador de velocidad vertical (VSI) Las capas se han superpuesto siguiendo el siguiente orden, donde, como en casos anteriores, la numeraci´on ascendente implica que la capa con el n´umero m´as alto se trata de la capa m´as superficial. 1. vsi face 2. vsi hand 3. vsi case 2.7.3. Implementaci´on del c´odigo La implementaci´on de este instrumento es sencilla en comparaci´on con otros m´as complejos como el coordinador de giro. Para implementar el indicador de velocidad vertical es suficiente rotar la aguja el ´angulo correspondiente, midiendo el ´angulo mediante Autocadr, de la misma forma que en instrumentos comentados anteriormente. En este caso, cada una de las marcas de 500 pies/minuto se encuentran a 43ocon respecto a la horizontal. Por tanto es inmediato ver que el ´angulo que se debe de rotar la aguja se obtendr´a seg´un la Ecuaci´on (3.11). 54 Master Universitario en Ingenier´ıa Aeron´autica 2. IMPLEMENTACI ´ ON DE LOS INSTRUMENTOS θrot =43 500V S (3.11) Donde V S es la velocidad vertical en pies por minuto. El ´unico requisito adicional es el de impedir que la aguja se mueva m´as all´a de las marcas de 2000 y -2000 ft/min. Algo trivial en este caso. Con el valor del ´angulo obtenido se llama al m´etodo rotateLabel para girar la aguja y que ´esta apunte en la direcci´on adecuada. 2.8. TCAS 2.8.1. Descripci´on El TCAS (Traffic Alert and Collision Avoidance System) se ha descrito anteriormente en la Secci´on 3.3 del Cap´ıtulo 1. Como se ha comentado anteriormente, el TCAS es un instrumento fundamental para la navegaci´on a´erea a d´ıa de hoy. Debido a la gran densidad de tr´afico a´ereo que circula por ciertas zonas del mundo, el uso del TCAS se ha vuelto indispensable para garantizar la seguridad a´erea y ayudar a los controladores de tr´afico a´ereo en su labor. Esta congesti´on de los espacios a´ereos ha llegado al punto en el que en zonas de Europa central es obligatoria la inclusi´on de un sistema TCAS para el vuelo de aeronaves de m´as de 5700 Kg y 19 pasajeros [48]. La importancia de este instrumento en la navegaci´on actual, as´ı como la complejidad de su implementaci´on son los dos aspectos clave por los que se ha decidido incluir este instrumento en el presente proyecto. 2.8.2. Generaci´on por capas El TCAS merece una menci´on a parte ya que es el ´unico elemento que utiliza una mezcla de implementaciones: por un lado el fondo y la regla m´ovil que indica el heading que lleva el avi´on consiste en un JLabel, mientras que sobre ellos se define un panel de dibujo sobre el que se utiliza la librer´ıa Graphics2D con la que se pintan los elementos. El TCAS est´a compuesto de un fondo negro con tres reglas fijas y una regla m´ovil, cuyo centro es la posici´on del avi´on, representado con forma de flecha. Las reglas indican radio de distancia a la aeronave de 10, 20, 30 y 40 Millas N´auticas, de menor a mayor distancia, siendo la ´ultima la regla m´ovil que indica el heading de la aeronave. Master Universitario en Ingenier´ıa Aeron´autica 55 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS 2.8.3. Closest Point of Approach (CPA) Antes de proceder a explicar el funcionamiento del TCAS conviene introducir el concepto del Closest Point of Approach o CPA por sus siglas en ingl´es. El CPA se define como la distancia m´ınima a la que se encontrar´an dos cuerpos al seguir sus respectivas trayectorias. Por tanto, en el contexto de la navegaci´on a´erea, se puede definir el CPA como la distancia m´ınima a la que se encontrar´an dos aeronaves. Este concepto es de gran ayuda para evaluar el peligro de colisi´on entre dos aeronaves. Debido a la gran velocidad a la que se mueven los aviones, imponer un sistema de alerta que se base ´unicamente en la distancia entre dos cuerpos no ser´ıa seguro ni eficiente. La importancia en la detecci´on reside en ser capaz de saber si en el punto de distancia m´ınima (CPA) la distancia entre los dos aviones ser´a suficientemente grande como para que no haya riesgo de colisi´on. Aunque hay distintas formas de calcular la distancia del CPA, una de las formas m´as comunes y sencillas de hacerlo es mediante la utilizaci´on de un doble producto vectorial. Tomando r1como el vector posici´on de la aeronave 1 (en 3 dimensiones), y c2como la velocidad relativa de la aeronave 2 con respecto a la aeronave 1, el CPA se puede calcular como sigue: 1. Primero se normaliza el vector posici´on de la aeronave 1: −→ uc2= −→ c2 |−→ c2|(3.12) 2. Seguidamente se calcula el siguiente doble producto vectorial: −→ rm=−→ uc2×(−→ r1×−→ uc2) (3.13) 3. Por ´ultimo, la distancia del CPA se calcula como el m´odulo del vector rm: DCP A =|−→ rm|(3.14) Esta distancia del CPA se puede observar de forma gr´afica en la Figura 3.26. 56 Master Universitario en Ingenier´ıa Aeron´autica 2. IMPLEMENTACI ´ ON DE LOS INSTRUMENTOS Figura 3.26: Representaci´on gr´afica del Closest Point of Approach La distancia m´ınima a la que se encontrar´an dos aeronaves es un par´ametro cr´ıtico, pero en s´ı misma no es suficiente para evaluar el riesgo de colisi´on, ya que dos aeronaves con un CPA muy peque˜no y situadas en dos puntos muy lejanos pueden cambiar de trayectoria en un momento determinado y aumentar notablemente su CPA. Es por esto que adem´as de la distancia m´ınima se utiliza tambi´en el par´ametro τ, que mide el tiempo restante para que se alcance la condici´on del Closest Point of Approach. En la Figura 3.26 se muestra tambi´en el par´ametro τ(TCPA en la imagen). Por tanto, los par´ametros utilizados en los algoritmos de detecci´on de amenazas de tr´afico a´ereo son tanto el CPA como el tiempo τ. Para un mayor detalle en cuanto a la utilizaci´on de estos dos par´ametros, se insta al lector a consultar la referencia [49]. En la Figura 3.27 se muestra un esquema de las zonas de distintos niveles de alerta del TCAS, basadas en el tiempo de colisi´on τ. Master Universitario en Ingenier´ıa Aeron´autica 57 CAP´ ITULO 3. IMPLEMENTACI ´ ON DE LA INTERFAZ GR ´ AFICA Y LOS INSTRUMENTOS Figura 3.27: Niveles de alerta del TCAS en funci´on del tiempo τ. Fuente: [49] 2.8.4. Funcionamiento del TCAS En el presente proyecto se ha optado por implementar un sistema TCAS de tipo I, un sistema de TCAS que, si bien es uno de los m´as b´asicos que existen, es el que se suele montar en aeronaves de aviaci´on general, como es el caso del cockpit que ocupa este proyecto. El TCAS de tipo I da la informaci´on sobre las aeronaves que se encuentran en las inmediaciones y eval´ua el peligro de colisi´on con cada una de dichas aeronaves. Adem´as, este tipo de TCAS suele tener un rango de operaci´on de alrededor de 40 millas n´auticas. Cabe destacar que al contrario que en sistemas TCAS m´as avanzados como el TCAS II, III o IV, el TCAS de tipo I no da sugerencias u ´ordenes al piloto sobre c´omo actuar cuando hay peligro de colisi´on. En este caso el TCAS simplemente se limita a evaluar el peligro de colisi´on y en caso de haberlo muestra la aeronave de un color distinto en el radar y hace saltar una se˜nal sonora diciendo: “traffic, traffic”. En este caso el sistema simplemente avisa de un posible riesgo de colisi´on y queda al criterio del piloto decidir c´omo evitarla (normalmente asistido por los controladores de tr´afico a´ereo. Como se ha comentado anteriormente,se ha querido dotar al sistema TCAS del mayor realismo posible, por lo que se ha implementado tambi´en una interconexi´on entre el sistema TCAS y los datos de tr´afico a´ereo real que provienen de la antena SACTA3.Debido a que el uso de la antena SACTA est´a restringido por la disponibilidad de una conexi´on de internet y de una conexi´on VPN en caso de encontrarse el ordenador fuera de la red de la UPV, se ha decidido implementar tambi´en la posibilidad de utilizar un archivo de trazas reales para leer el tr´afico a´ereo. 3La interfaz de comunicaci´on con la antena SACTA ser´a tratada en la Secci´on 2 del Cap´ıtulo 4 58 Master Universitario en Ingenier´ıa Aeron´autica 2. IMPLEMENTACI ´ ON DE LOS INSTRUMENTOS Hay que se˜nalar que los datos referentes a los vuelos est´an limitados en este caso al ´area circundante de Valencia que es capaz de leer la antena SACTA, si bien siempre se podr´ıa utilizar un archivo de trazas de otra zona geogr´afica utilizando el mismo formato. Se ha de aclarar que el TCAS es un instrumento que no se incluye en la configuraci´on del cockpit real de la Cessna 172S. Se trata por tanto de un instrumento extra en la aeronave, ya que en el panel de instrumentos original no est´a inclu´ıdo. Con el objetivo de implementar un sistema TCAS de tipo I que sea lo m´as fiel posible a la realidad, se ha consultado la gu´ıa de uso de un TCAS real, utilizado en aeronaves de aviaci´on general. Dicho TCAS es el denominado como CAS 66A, desarrollado por Honeywell Inc [50]. En las siguientes l´ıneas de procede a describir de forma resumida el comportamiento del TCAS CAS 66A: Tr´afico sin riesgo: Cuando una aeronave se encuentra en un rango mayor o igual a 5 NM, o con una diferencia de altitud mayor o igual a ±1500 ft, el TCAS muestra el icono de dicho avi´on con un rombo blanco y hueco. Una ilustraci´on se muestra en la Figura 3.28. (a) Vista en planta (b) Vista en perspectiva Figura 3.28: Representaci´on de una situaci´on de tr´afico sin riesgo. Fuente: [50] Tr´afico con proximidad de intrusi´on: Cuando una aeronave se encuentra en un rango menor o igual a 5 NM, o con una diferencia de altitud que se encuentra dentro de ±1500 ft, el TCAS muestra el icono de dicho avi´on con un rombo relleno amarillo. Un ejemplo de este tipo de tr´afico se muestra en la Figura 3.29. Master Universitario en Ingenier´ıa Aeron´autica 59 CAP´ ITULO 4. IMPLEMENTACI ´ ON DE INTERFACES CON PERIF ´ ERICOS han convertido a este simulador en la opci´on preferida para multitud de aplicaciones profesionales relacionadas con autopilotos, UAVs e investigaci´on. FlightGearr:Se trata de una opci´on de c´odigo libre multiplataforma muy completa y que utiliza el motor de simulaci´on JSBSim. Los gr´aficos generados en FlightGear no gozan de la misma calidad que en los simuladores anteriores. Aunque a priori puede parecer una buena opci´on debido a su naturaleza de c´odigo abierto, la posibilidad de utilizar ´unicamente su motor de simulaci´on sin necesidad de utilizar los recursos gr´aficos del simulador parece una opci´on mejor, tal y como se describe en el siguiente ´ıtem. JSBSimr:Este motor de simulaci´on de c´odigo libre es capaz de correr en multitud de sistemas operativos (Windows, Macintosh OS X y Linux, entre otros). La principal ventaja de la utilizaci´on de este motor de simulaci´on es la eliminaci´on de la capa gr´afica presente en los simuladores presentados anteriormente. Con ello se puede conseguir un comportamiento m´as fluido de la interfaz implementada en el presente proyecto, as´ı como reducir los requerimientos de hardware m´ınimos para la ejecuci´on de la aplicaci´on. En la Tabla 4.1 se presenta un resumen de las principales virtudes y defectos de cada uno de los simuladores enumerados anteriormente con respecto al proyecto que ocupa esta memoria: Tabla 4.1: Resumen de las caracter´ısticas de los simuladores evaluados Simulador Plataformas Interfaz gr´afica Interfaz UDP FSX S´olo Windows Siempre activa Dificultad moderada X-Plane 10 Windows, Mac OS, Linux Siempre activa Menor dificultad FlightGear Windows, Mac OS, Linux Siempre activa Dificultad moderada JSBSim Windows, Mac OS, Linux Inactiva Mayor dificultad En la tabla anterior se puede observar que hay dos claros candidatos para la implementaci´on de la interfaz con el simulador, ´estos son X-Plane y JSBSim. La opci´on m´as eficiente y ´optima es sin duda la utilizaci´on del motor de simulaci´on JSBSim, puesto que se prescinde de la interfaz gr´afica y se reducen dr´asticamente los 66 Master Universitario en Ingenier´ıa Aeron´autica 1. INTERFAZ DE COMUNICACI ´ ON CON X-PLANE requisitos de hardware de la aplicaci´on creada en este proyecto. Sin embargo, la mayor complejidad de la implementaci´on de una interfaz UDP unido a la gran cantidad de desarrollos ya implementados con licencia GNU ha decantado la balanza en favor de la implementaci´on de una interfaz de comunicaci´on UDP con el simulador de vuelo X-Plane. 1.2. Desarrollo de la interfaz de comunicaci´on con X-Plane Antes de realizar un desarrollo completo de una interfaz de comunicaci´on UDP con el simulador X-Plane, se ha realizado una b´usqueda de alternativas ya implementadas disponibles en la red y en los desarrollos realizados anteriormente en el departamento de Inform´atica de Sistemas y Computadores de la UPV. En el trabajo final de carrera Banco de pruebas para el dise˜no de autpilotos [51] se implement´o en Matlabruna interfaz que permit´ıa obtener los datos de vuelo del simulador X-Plane para poder utilizarlos en el desarrollo de autopilotos. Si bien el c´odigo de dicho trabajo se podr´ıa portar al lenguaje de programaci´on Java, se opt´o por intentar buscar herramientas ya implementadas en el lenguaje utilizado en el proyecto que ocupa esta memoria. Tras una b´usqueda en la red, se encontr´o una alternativa ya implementada en Java. Esta librer´ıa fue desarrollada por el Dr. Luiz Cantoni en su tesis doctoral: Avalia¸cao do uso da linguagem pddl no planejamento de missoes para robˆos a´ereos [52]. El c´odigo se encuentra publicado en GitHub 1bajo licencia GNU, lo que permite la utilizaci´on y modificaci´on del c´odigo en este trabajo. Puesto que la interfaz desarrollada por en [52] cumple con todos los requerimientos impuestos en este trabajo, se ha optado por utilizar dicha interfaz, implementando las correcciones necesarias para su correcta integraci´on en la plataforma desarrollada en este proyecto. Con esto se consigue dedicar una mayor cantidad de tiempo al desarrollo de los instrumentos, la interfaz gr´afica y el TCAS, elementos que diferencian a este proyecto de otros realizados en el pasado. 1.3. Implementaci´on del c´odigo En este apartado se trata con m´as detalle la implementaci´on seguida en el proceso de comunicaci´on con X-Plane. Implementaci´on, que tal y como se ha comentado con anterioridad, est´a basada en los trabajos presentados en [52], sobre los que se han 1C´odigo disponible en: https://github.com/luizcantoni/x-pi Master Universitario en Ingenier´ıa Aeron´autica 67 CAP´ ITULO 4. IMPLEMENTACI ´ ON DE INTERFACES CON PERIF ´ ERICOS realizado una serie de modificaciones. La comunicaci´on con X-Plane en tiempo real se realiza mediante la clase XPlaneInterface, la cual necesita la informaci´on de la IP, los puertos de env´ıo y recepci´on de informaci´on por UDP y una hoja de informaci´on DATAGroupConfig.xml. Este documento contiene la informaci´on necesaria para extraer o enviar la informaci´on que X-Plane puede comunicar mediante UDP, y tiene el aspecto que muestra la Figura 4.1. Figura 4.1: Aspecto del fichero DATAGroupConfig.xml La clase XPlaneInterface arranca dos threads, uno para env´ıo y otro para recepci´on de informaci´on, entre otros muchos procesos, que permiten con ´exito la comunicaci´on por UDP. Por otro lado, las clases que permiten interpretar la informaci´on UDP procedente de X-Plane y cuantificarla en un valor num´erico, y viceversa, son las clases XPlaneReader yXPlaneSender. La clase XPlaneReader consiste en un thread que lee la informaci´on de X-Plane mediante el m´etodo getValue de la interfaz XPlaneInterface. Desde este thread es desde donde se llaman a los distintos m´etodos implementados en la clase Instrument que permiten animar los instrumentos, el fondo, el stick y el throttle con la informaci´on procedente de X-Plane. Por otro lado, la clase XPlaneSender es la que usa los m´etodos implementados en la clase Instrument para el yoke y para el throttle e interpreta la informaci´on seg´un la interacci´on gr´afica del usuario con estos elementos, para posteriormente enviarla por UDP al simulador. 68 Master Universitario en Ingenier´ıa Aeron´autica 2. INTERFAZ DE COMUNICACI ´ ON CON LA ANTENA DE TR ´ AFICO A´ EREO 2. Interfaz de comunicaci´on con la antena de tr´afico a´ereo Un instrumento como el TCAS solo tiene sentido con la presencia de m´as tr´afico a´ereo a parte de la aeronave que se est´a manejando, y de ah´ı que se haya implementado una comunicaci´on con la una antena capaz de leer datos del transpondedor de las aeronaves. Dicha antena ser´a la encargada de generar tr´afico alrededor del avi´on manejado en el simulador. 2.1. Descripci´on La antena de tr´afico a´ereo utilizada en el presente proyecto basa su funcionamiento en el uso de los datos enviados por el transpondedor que equipan las aeronaves que sobrevuelan el espacio a´ereo. El transpondedor es un equipo que se encarga de difundir datos de inter´es de la aeronave, tales como su posici´on (latitud y longitud), altitud, velocidad, rumbo, etc. Los transpondedores son un sistema fundamental para la gesti´on del tr´afico a´ereo por parte de los ATCs [53], y adem´as son indispensables tambi´en para el correcto funcionamiento de sistemas de evitaci´on de colisiones como el TCAS. Con el objetivo de ser capaces de obtener datos en tiempo real sobre el tr´afico a´ereo en el ´area de Valencia, la Escuela T´ecnica Superior de Ingenier´ıa del Dise˜no de la Universidad Polit´ecnica de Valencia ha instalado una antena capaz de leer los datos difundidos por los transpondedores de las aeronaves. La utilizaci´on de los datos reales de tr´afico a´ereo que se obtienen tiene multitud de aplicaciones, siendo una de ellas la que ocupa el presente proyecto: la obtenci´on de tr´afico real para la implementaci´on de un sistema de evitaci´on de colisiones TCAS. Puesto que la antena se encuentra en la Escuela T´ecnica Superior de Ingenier´ıa del Dise˜no de la Universidad Polit´ecnica de Valencia, hay que se˜nalar que el rango del tr´afico a´ereo que detecta est´a centrado en esa zona, por lo que para que usar X-Plane junto con la lectura de la antena y tener algo de informaci´on en el TCAS es necesario que la simulaci´on del vuelo en X-Plane se lleve a cabo dentro del rango de cobertura de la antena. Dicha antena est´a conectada a un equipo que comparte la informaci´on que recibe dentro de la red UPVNET, tambi´en accesible mediante VPN. 2.2. Men´u de configuraci´on Para permitir la correcta configuraci´on de la antena, se ha decidido implementar un men´u gr´afico de configuraci´on. En la interfaz principal Cockpit se ha incluido el men´u Setup Select Antenna , el cu´al abre el panel de selecci´on de la antena como muestra la Master Universitario en Ingenier´ıa Aeron´autica 69 CAP´ ITULO 4. IMPLEMENTACI ´ ON DE INTERFACES CON PERIF ´ ERICOS Figura 4.2. Este panel es la interfaz AntennaChooser. En dicho panel se presentan dos opciones: Elegir la antena real, para lo que hay que introducir la IP y el Puerto. Leer una traza de archivos, para lo que hay un selector de archivos y una casilla en la que introducir el tiempo de intervalo de lectura. Figura 4.2: Panel de selecci´on de la antena Seleccionada la antena se puede hacer clic en el bot´on Start Antenna, el panel se cierra y se inicia la lectura de la antena. 2.3. Implementaci´on del c´odigo La interfaz con la antena de tr´afico a´ereo se ha implementado siguiendo las directrices indicadas en la asignatura de Sistemas de Gesti´on de Vuelo por Computador [42], se ha implementado un c´odigo capaz de conectarse a la antena e interpretar los mensajes recibidos por ´esta. En el presente proyecto se ha utilizado un c´odigo basado en el que se pone a disposici´on de los alumnos en [42], al que se le han aplicado diversos cambios para optimizarlo. El c´odigo de la antena se basa en la implementaci´on de un Listener que lee los datos de los vuelos. Los vuelos y sus datos se guardan en un HashMap utilizando el n´umero del vuelo como identificador. Por cada vuelo le´ıdo, se analiza si dicho vuelo se encuentra ya en el HashMap y en caso afirmativo, se procede a sobrescribir ´unicamente aquella informaci´on que ha sufrido cambios. En caso de que el vuelo no se encuentre en la base de datos, se procede a incluirlo en la misma. El programa es capaz de saber los datos que han variado en un vuelo gracias al Label del tipo de mensaje que se recibe. En cuanto a la estructura de los datos le´ıdos por la antena, es relativamente sencillo de analizar. Los datos enviados por el transpondedor de una aeronave siguen una estructura estandarizada. Esta estructura se puede encontrar en diversos ejemplos en la literatura, sin embargo, el presente proyecto se ha basado en los datos presentados en [54] para que el c´odigo sea capaz de interpretar los datos le´ıdos por la 70 Master Universitario en Ingenier´ıa Aeron´autica 2. INTERFAZ DE COMUNICACI ´ ON CON LA ANTENA DE TR ´ AFICO A´ EREO antena de tr´afico a´ereo. Las Figuras 4.3, 4.4 y 4.5 muestran parte de la estructura de datos seguida en el env´ıo de datos mediante el transpondedor. Estas figuras se muestran a modo de ejemplo y no contienen todo lo necesario para interpretar la estrucutra completa de los datos, si bien son ´utiles para ilustrar al lector el proceso seguido en este proyecto. Para ver la estructura completa de los datos del transpondedor, se insta al lector a consultar la referencia [54]. Figura 4.3: Tipos de mensajes recibidos. Fuente [54]. Figura 4.4: Mensajes est´andar, incluidos en todos los tipos de mensajes. Fuente [54]. Master Universitario en Ingenier´ıa Aeron´autica 71 CAP´ ITULO 4. IMPLEMENTACI ´ ON DE INTERFACES CON PERIF ´ ERICOS Figura 4.5: Mensajes con informaci´on espec´ıfica de la aeronave. Fuente [54] 72 Master Universitario en Ingenier´ıa Aeron´autica Cap´ıtulo 5 Implementaci´on del autopiloto 1. Descripci´on El autopiloto es uno de los pilares b´asicos de la implementaci´on del presente proyecto debido tanto a desarrollo como a su capacidad de crecimiento y su importancia en posibles trabajos futuros. Hoy en d´ıa las t´ecnicas de control y guiado aplicadas a las aeronaves est´an al orden del d´ıa, no s´olo en aplicaciones aut´onomas como los UAVs, sino en la pr´actica totalidad de aeronaves modernas. El nivel de automatizaci´on de las aeronaves va constantemente en aumento y como se ha comentado con anterioridad, el desarrollo de aeronaves no tripuladas no hace m´as que recalcar la importancia que tiene un sistema de autopiloto hoy en d´ıa. El dise˜no de un autopiloto ser´ıa un tema que podr´ıa ocupar perfectamente la longitud de un proyecto como el que se expone, es por esta raz´on que el autopiloto implementado en este trabajo tiene un importante margen de mejora. Si bien es cierto que se consiguen cumplir de forma exitosa las funciones deseadas y que se plantearon durante la fase de dise˜no conceptual del proyecto. 2. Arquitectura del autopiloto Este autopiloto estar´a basado en la utilizaci´on de controladores PID en cascada. Esta forma de afrontar el problema es muy com´un en la industria, siendo utilizada en numerosas aplicaciones de UAVs. El uso de controladores en cascada permite ajustar de forma independiente los bucles de guiado y de control de la aeronave, lo que facilita sobremanera la obtenci´on de una ley de guiado ´optima. Un controlador en cascada no es m´as que la inclusi´on de distintos controladores PID en serie, tal y como se muestra en la Figura 5.1. 73 CAP´ ITULO 5. IMPLEMENTACI ´ ON DEL AUTOPILOTO Figura 5.1: Topolog´ıa de un esquema de control en cascada. El guiado de la aeronave se realiza de forma distinta seg´un la fase de vuelo de la aeronave; por ejemplo, durante fases de rodadura en tierra no se pueden utilizar los alerones para girar la aeronave, sino que se utiliza el tim´on de profundidad y la rueda delantera. Es por esto que el autopiloto implementado cambia su funcionamiento en funci´on de la fase de vuelo a la que se encuentre la aeronave. De esta forma la l´ogica de guiado ser´a distinta para cada fase de vuelo, as´ı como los controladores PID utilizados. Por simplicidad y para permitir la finalizaci´on del proyecto en los plazos de tiempo establecidos, se ha decidido implementar controladores lo m´as simples posibles ya que de esta forma se disminuyen las probabilidades de fallo, consiguiendo as´ı un sistema m´as seguro. Sin embargo, no es menos cierto que con una l´ogica de control m´as compleja se podr´ıa conseguir un comportamiento m´as preciso de la aeronave, aunque esto se deja para trabajos futuros. 3. Implementaci´on de los algoritmos de guiado y control Tal y como se ha comentado en la introducci´on, el objetivo principal de este proyecto es la implementaci´on de los distintos algoritmos de guiado y control que permitan operar de forma segura la aeronave Cessna C-172 Skyhawk en el simulador de vuelo X-Plane. Con la intenci´on de dotar de un mayor realismo al trabajo y siguiendo las directrices del profesorado, se han implementado los algoritmos de guiado y control correspondientes a las siguientes fases de vuelo: Rollout o fase de rodadura en pista de despegue Rotaci´on en pista hasta elevar la aeronave del suelo Fase de ascenso (Climbing) Fase de vuelo en crucero 74 Master Universitario en Ingenier´ıa Aeron´autica 3. IMPLEMENTACI ´ ON DE LOS ALGORITMOS DE GUIADO Y CONTROL Cada una de las fases expuestas anteriormente tendr´a asociadas unas acciones de control sobre los siguientes sistemas de la aeronave: Palanca de gases o Throttle Tim´on de cola o Rudder Alerones Tim´on de profundidad o elevador Frenos Flaps En las siguientes p´aginas se proceder´a a detallar tanto la l´ogica de fases y transiciones entre fases como la filosof´ıa de guiado y control utilizada en cada una de las fases para cada uno de los canales de control de la aeronave. A modo de ejemplo, se procede a detallar la logica implementada utilizando como referencia el procedimiento de salida por instrumentos SID de la pista 12 del aeropuerto de Valencia. La ruta a seguir por la aeronave en el presente proyecto se muestra resaltada en rojo en la Figura 5.2. Como se puede ver, dicha ruta se corresponde con el procedimiento de salida est´andar SID desde la pista 12 del aeropuerto de Valencia (LEVC). Por tanto la ruta consistir´a de una fase de rollout y de rotaci´on siguiendo el rumbo de la pista (119o) para posteriormente variar el rumbo a 124oal entrar en la fase de climbing. Una vez alcanzada una altura sobre le nivel del mar de 2000 pies se transicionar´a hacia la fase de crucero, donde en este caso se continuar´a con un rumbo de 124o. Master Universitario en Ingenier´ıa Aeron´autica 75 CAP´ ITULO 5. IMPLEMENTACI ´ ON DEL AUTOPILOTO Al tratarse de una fase en vuelo, es obvio que los freno se econtrar´an inutilizados en este caso. Flaps La deflexi´on de los flaps en ascenso ser´a nula en este caso, ya que como se ha comentado con anterioridad, no se han utilizado en este proyecto. 3.4. Fase de crucero La transici´on a la fase de crucero se realizar´a al llegar a una altura sobre el nivel del mar de 2000 pies. En este caso, la fase de crucero permite la inclusi´on de distintos par´ametros tales como la velocidad de vuelo (que en este caso es V= 100KTAS), el rumbo a seguir y la altura del waypoint de destino. Cabe destacar que en esta fase se han desacoplado el control de velocidad y el control de altura, siendo el primero llevado a cabo por el motor y el segundo por el elevador. El autor es plenamente consciente de que existen diversas filosof´ıas de control m´as eficientes que acoplan el control de la velocidad y la altura y que se basan en un balance energ´etico. Sin embargo, debido a las limitaciones de tiempo y a la mayor complejidad de dicho modelo energ´etico, se ha optado por realizar una aproximaci´on m´as simple que consiste en el desacople del control de velocidad y altura. 3.4.1. Guiado y control La l´ogica de control utilizada en la fase de crucero es la siguiente: Throttle En este caso, tal y como se ha comentado, el control sobre la palanca de gases permitir´a controlar la velocidad de la aeronave. Dicho control se puede realizar f´acilmente mediante un controlador proporcional al que se le ha inclu´ıdo un offset, ya que la posici´on requerida en la palanca de gases para una velocidad de V= 100KTAS ser´a del orden del 60-70 % del total. De esta forma se consigue un buena respuesta din´amica a los cambios en la velocidad comandada. Rudder Del mismo modo que en el caso de la fase de ascenso, no se ha implementado control alguno sobre la superf´ıcie del tim´on de cola por los motivos expuestos anteriormente. 82 Master Universitario en Ingenier´ıa Aeron´autica 3. IMPLEMENTACI ´ ON DE LOS ALGORITMOS DE GUIADO Y CONTROL Alerones El control de alerones en la fase de crucero es totalmente an´alogo al control de los mismos en la fase de ascenso. Elevador El control sobre el elevador se utiliza en este caso para conseguir que la aeronave sea capaz de controlar su altura de vuelo. En este caso, el sistema de guiado mide el error de altura y comanda un ´angulo de cabeceo proporcional a dicho error. El bucle de control se encarga de dar el input de aler´on necesario para alcanzar el ´angulo de cabeceo deseado. En este caso se ha querido aportar una implementaci´on algo distinta a lo visto anteriormente y se ha optado por utilizar un control Proporcional-Integral (control PI) que permite un mejor ajuste del bucle de control. Dicho controlador PI se ha implementado en el bucle de control, ya que en los casos en los que se comandan ´angulos de cabeceo grandes, la din´amica del sistema deja de ser lineal, lo que dificulta el ajuste del controlador proporcional. La ventaja del uso de un controlador PI reside en le hecho de que el error acumulado en el tiempo (la integral del error cometido) se multiplica por una segunda ganancia Kiy su efecto se suma al del controlador proporcional. De esta forma se ha conseguido eliminar el error de altura en el estacionario sin necesidad de recurrir a esquemas m´as complejos como los basados en un alance de energ´ıa. La integral del error se puede realizar num´ericamente de forma bastante sencilla mediante el uso del m´etodo Newton-Cotes, donde ´unicamente es necesario saber el paso temporal en cada iteraci´on del bucle de control, el estado anterior de la variable y su estado actual. Dicho m´etodo de c´alculo de las integrales se puede ver en la Figura 5.4 Sin embargo, cabe destacar que ´esta forma de calcular las integrales, si bien es r´apida y sencilla, es menos exacta que otras, por lo que se remarca que en un futuro podr´ıa ser interesante sustituir dicho c´alculo por la regla trapezoidal o mejor a´un, por la regla se Simpson. Master Universitario en Ingenier´ıa Aeron´autica 83 CAP´ ITULO 5. IMPLEMENTACI ´ ON DEL AUTOPILOTO Figura 5.4: M´etodo de integraci´on de Newton-Cotes La inclusi´on del controlador PI en el bucle de control ha permitido ajustar razonablemente bien el control de altura, sin embargo, dicho control no es lo suficientemente fino como para poder llegar a implementarlo en un caso real y deber´ıa de trabajarse en mayor profundidad para reducir su tiempo de estabilizaci´on y a la vez conseguir un comportamiento m´as suave. Frenos En la fase de crucero, los frenos est´an desactivados al igual que en fases anteriores. Flaps En las fases anteriores se ha indicado que los flaps no se han utulizado pero que se podr´ıa haber hecho. En la fase de crucero, sin embargo, nunca se llegar´ıa a utilizar los flaps y ´estos deber´ıan de desactivarse de forma progresiva bien al entrar en la fase de crucero, o bien a partir de un cierto punto en la fase de ascenso. 4. Men´u de configuraci´on Para facilitar la configuraci´on del autopiloto y poder configurar f´acilmente el mismo para la realizaci´on de distintos procedimientos SID, se ha implementado un men´u gr´afico de configuraci´on similar al implementado en la antena. El men´u se encuentra en la pesta˜na Setup Set Autopilot y al acceder al mismo se muestra la ventana que aparece en la Figura 5.5. 84 Master Universitario en Ingenier´ıa Aeron´autica 4. MEN ´ U DE CONFIGURACI ´ ON Figura 5.5: Men´u de configuraci´on del autopiloto 4.1. Par´ametros de configuraci´on En la parte central del men´u mostrado en la Figura 5.5 se encuentran los datos relativos al control de las distintas fases de vuelo, ordenados de la siguiente forma: General •RWY Heading: Se trata del rumbo de la pista desde la que se va a iniciar el despegue •TO Throttle Setting: Se trata del setting de la palanca de gases que se va a utilizar durante el despegue hasta llegar a la fase de crucero. •TO Flaps Setting: Se trata del setting de flaps que se utilizar´a durante el despegue. Climb •Desired Track: Es el ´angulo de track que debe seguir la aeronave al iniciar la fase de ascenso. •Vclimb: Es la velocidad verdadera (True Airspeed) a la que se pretende que la aeronave realice el ascenso (en nudos). Cruise •Desired Track: Es el ´angulo de track que debe seguir la aeronave al iniciar la fase de crucero (en nudos). Master Universitario en Ingenier´ıa Aeron´autica 85 CAP´ ITULO 5. IMPLEMENTACI ´ ON DEL AUTOPILOTO •Vcruise: Es la velocidad verdadera (True Airspeed) a la que se pretende que la aeronave viaje en su fase de crucero. •Cruise MSL: Es la altura sobre el nivel del mar a la que se debe de realizar el vuelo de crucero (en pies) Adem´as de dichos par´ametros, se incluyen los valores utilizados para las transiciones entre fases, situados en la parte inferior del men´u mostrado en la Figura 5.5.Dichos par´ametros se muestran con el siguiente orden: Rollout →Rotation •Vrot: Velocidad de rotaci´on; es la velocidad a la que se inicia la maniobra de rotaci´on y se utiliza el valor de la velocidad indicada en nudos. Rotation →Climb •AGL: Es la altura sobre el nivel de pista a la que se transiciona desde la fase de rotaci´on a la fase de ascenso. Climb →Cruise •MSL: Es la altitud sobre el nivel del mar a la que se realiza la transici´on entre la fase de ascenso y la fase de crucero. Para una transici´on m´as suave se recomienda utilizar un valor cercano a la altitud de crucero, aunque ligeramente inferior. 4.2. Indicador de estado y bot´on Engage/Disengage En la parte inferior del men´u mostrado en la Figura 5.5 se pueden ver dos elementos: el indicador de estado (parte inferior izquierda de la imagen) y un bot´on de paro o de puesta en marcha. El indicador de estado tiene como funci´on mostrar al usuario el estado del autopiloto. El indicador muestra uno de los dos estados disponibles: AP Status: Disengaged AP Status: Engaged La funci´on del bot´on Engage/Disengage es justamente la de ejecutar o detener el autopiloto. El bot´on implementado cambia el mensaje impreso sobre el mismo seg´un el estado actual del autopiloto, tal y como se puede observar en la Figura 5.6 86 Master Universitario en Ingenier´ıa Aeron´autica 4. MEN ´ U DE CONFIGURACI ´ ON Figura 5.7: Selector de archivos de configuraci´on del autopiloto (a) Autopiloto sin ejecutar (b) Autopiloto en funcionamiento Figura 5.6: Indicador de estado y bot´on Engage/Disengage del autopiloto seg´un el estado del mismo 4.3. Archivos de configuraci´on del autopiloto Para facilitar la utilizaci´on del autopiloto y para permitir que un usuario poco experimentado sea capaz de ejecutar el autopiloto de forma satisfactoria se ha decidido incluir la opci´on de cargar la configuraci´on del autopiloto mediante un archivo. Este archivo de configuraci´on contiene en su interior todos los par´ametros significativos para la puesta en marcha del autopiloto. Para cargar el archivo de configuraci´on se puede escribir directamente la ruta al mismo o bien se puede presionar sobre el bot´on ... . En este caso se abrir´a una ventana con un selector de archivos, tal y como se puede ver en la Figura 5.7. La ruta por defecto en la que se abrir´a este selector de archivos es la correspondiente al directorio APConfig, que es la carpeta por defecto en la que se guardan los archivos de configuraci´on del autopiloto. El tipo de archivo utilizado en este caso es un archivo con la extensi´on *.apconf. Como se puede ver la Figura 5.5, se ha seleccionado por defecto dicha extensi´on en el selector de archivos, para que ´unicamente se muestren los archivos v´alidos para ser Master Universitario en Ingenier´ıa Aeron´autica 87 CAP´ ITULO 5. IMPLEMENTACI ´ ON DEL AUTOPILOTO utilizados en la configuraci´on del autopiloto. 4.3.1. Formato del fichero de configuraci´on El formato del fichero *.apconf es el que se muestra en la Figura 5.8. Todas las l´ıneas precedidas por “//” ser´an ignoradas por el lector de archivos de configuraci´on, al ser consideradas como comentarios. Adem´as, para el corrector funcionamiento del autopiloto es esencial que se incluyan los datos en el orden descrito en la Figura 5.8. Figura 5.8: Ejemplo de un fichero de configuraci´on *.apconf El requerimiento de la inclusi´on de la palabra “value” antes de cada valor obedece a 88 Master Universitario en Ingenier´ıa Aeron´autica 4. MEN ´ U DE CONFIGURACI ´ ON razones de capacidad de crecimiento. Si en un futuro se plantea el redise˜no de la interfaz de configuraci´on del autopiloto, se puede querer incluir cadenas de texto en el archivo de configuraci´on. Esto permitir´ıa indicar en el men´u de configuraci´on el nombre de la salida SID cuya configuraci´on se ha cargado, entre otras cosas. Con la inclusi´on de la palabra “value” se especifica que los d´ıgitos siguientes corresponden a un valor num´erico y no a una cadena de caracteres. 4.4. Mensajes de aviso y error En el men´u de configuraci´on se han a˜nadido distintos mensajes de aviso y error para prevenir posibles fallos del programa debido a una mala adici´on de datos. Los tipos de error contemplados en la ventana de configuraci´on del autopiloto son: Errores en la escritura de los datos. Errores en el formato del archivo de configuraci´on. 4.4.1. Errores en la escritura de los datos Esta categor´ıa engloba todos los errores debidos bien a la falta de datos o bien a la una inclusi´on err´onea de los mismos (valores negativos, letras, caracteres extra˜nos, etc). El aviso de error se muestra al pulsar el bot´on de Engage AP y su aspecto es el que se muestra en la Figura 5.9. Figura 5.9: Ventana de error en la escritura de datos de configuraci´on del autopiloto 4.4.2. Errores en el formato del archivo de configuraci´on Esta categor´ıa engloba todos los errores derivados de la selecci´on de un archivo de configuraci´on corrupto o con un formato err´oneo. El aviso saltar´a al seleccionar el archivo en cuesti´on. Cuando se da este error, el men´u de configuraci´on del autopiloto no carga ning´un valor en las casillas correspondientes a los datos de entrada del autopiloto. El aviso que se muestra es el que se puede ver en la Figura 5.10. Master Universitario en Ingenier´ıa Aeron´autica 89 CAP´ ITULO 5. IMPLEMENTACI ´ ON DEL AUTOPILOTO Figura 5.10: Ventana de error en el formato de archivo de configuraci´on del autopiloto 90 Master Universitario en Ingenier´ıa Aeron´autica Cap´ıtulo 6 Resultados 1. Procedimiento de an´alisis de los resultados En un proyecto de desarrollo de software como el que ocupa el presente trabajo, los resultados obtenidos se consideran satisfactorios en mayor o menor medida seg´un el cumplimiento de los requisitos. Esta es una forma objetiva de analizar si el software cumple con los objetivos marcados en las fases iniciales del desarrollo. De esta forma, se pretende analizar qu´e requisitos se han cumplido de forma total, cu´ales se han cumplido parcialmente y cu´ales no se han podido cumplir. Para demostrar el cumplimiento de los requisitos, se propondr´an una serie de casos de prueba (Test Cases), los cuales se trazar´an a cada uno de los requisitos correspondientes. Una vez realizado en an´alisis de cumplimiento de requisitos y trazados los mismos a los Test Case correspondientes, se realizar´a un resumen de los resultados, analizando de forma general el grado de cumplimiento del proyecto y sus ´areas susceptibles a mejoras. 2. Dise˜no de los casos de prueba o Test Cases El dise˜no de los casos de prueba es una parte fundamental del desarrollo de un dise˜no. Se debe de dise˜nar una serie de Test Case que sea capaz de demostrar de forma objetiva el cumplimiento de los requisitos del sistema. Si bien esto puede parecer simple, es en realidad una de las tareas m´as complejas del proceso de desarrollo. Un buen programa de Test debe de tener en cuenta una gran cantidad de casos posibles en los que podr´ıan dejar de cumplirse ciertos requisitos. Adem´as, es importante realizar una planificaci´on ´optima de la campa˜na de Tests, de forma que se minimicen los recursos necesarios para acometerla, as´ı como los test a realizar. Para m´as informaci´on sobre qu´e son los casos de prueba y c´omo se deben realizar de forma correcta, se insta al lector a consultar las referencias [38,55] 91 CAP´ ITULO 6. RESULTADOS Figura 6.1: Datos de configuraci´on del autopiloto para el Test TC-4 98 Master Universitario en Ingenier´ıa Aeron´autica 2. DISE ˜ NO DE LOS CASOS DE PRUEBA O TEST CASES TC-5. Archivos de configuraci´on del autopiloto Entorno de test Ver Secci´on 2.1 Requisitos cubiertos NTH-5 Pre-requisitos El ordenador debe de estar encendido y con una sesi´on de usuario iniciada. El simulador debe de estar iniciado, con la aeronave Cessna 172SP en la pista 12 del aeropuerto de Valencia (LEVC). Paso Acci´on a realizar Respuesta esperada 1 Abrir la aplicaci´on Java mediante Netbeans o mediante el ejecutable *.jar. La aplicaci´on se abre correctamente y toma los datos del simulador. 2 Abrir el men´u del autopiloto en Setup Set Autopilot . Se abre el men´u de configuraci´on del autopiloto. 3 Seleccionar el archivo de configuraci´on SID 12 LEVC.apconf(*) Los datos se quedan rellenados en el men´u de configuraci´on. 4 Cerrar el men´u del autopiloto. Se cierra el men´u. 5 Abrir el men´u de la antena en Setup Set Antenna Los datos son representativos del tr´afico real. Comentarios: (*): El archivo SID 12 LEVC.apconf se encuentra en la carpeta APConfig del directorio ra´ız de la aplicaci´on. Master Universitario en Ingenier´ıa Aeron´autica 99 CAP´ ITULO 6. RESULTADOS TC-6. Archivos de trazas de tr´afico a´ereo Entorno de test Ver Secci´on 2.1 Requisitos cubiertos NTH-6 Pre-requisitos El ordenador debe de estar encendido y con una sesi´on de usuario iniciada. El simulador debe de estar iniciado, con la aeronave Cessna 172SP en la pista 12 del aeropuerto de Valencia (LEVC). Paso Acci´on a realizar Respuesta esperada 1 Abrir la aplicaci´on Java mediante Netbeans o mediante el ejecutable *.jar. La aplicaci´on se abre correctamente y toma los datos del simulador. 2 Abrir el men´u del autopiloto en Setup Select Antenna . Se abre el men´u de configuraci´on de la antena. 3 Seleccionar la opci´on: Emulate antenna from track file Se habilita el selector de archivos. 4 Seleccionar el archivo de trazas 29-01-15 05.44.ssrtrk(*) El archivo se carga satisfactoriamente. 5 Pulsar el bot´on Start Antenna La antena empieza a funcionar. 6 Comprobar que el TCAS empieza a mostrar el tr´afico del archivo de trazas. El tr´afico se muestra correctamente en el TCAS. Comentarios: (*): El archivo 29-01-15 05.44.ssrtrk se encuentra en la carpeta SSRTracks del directorio ra´ız de la aplicaci´on. 100 Master Universitario en Ingenier´ıa Aeron´autica 2. DISE ˜ NO DE LOS CASOS DE PRUEBA O TEST CASES TC-7. Ordenador con recursos limitados Entorno de test Ver Secci´on 2.1 Requisitos cubiertos NTH-1 Pre-requisitos Se debe de utilizar un ordenador con recursos limitados, menores de los requisitos m´ınimos de X-Plane. El ordenador debe de estar encendido y con una sesi´on de usuario iniciada. El simulador debe de estar iniciado, con la aeronave Cessna 172SP en la pista 12 del aeropuerto de Valencia (LEVC). Paso Acci´on a realizar Respuesta esperada 1 Abrir la aplicaci´on Java. La aplicaci´on se abre correctamente y se conecta con el simulador. 2 Abrir el men´u del autopiloto en Setup Select Antenna . Se abre el men´u de configuraci´on de la antena. 3 Conectar la aplicaci´on Java a la antena de tr´afico a´ereo. La conexi´on se realiza de forma satisfactoria. 4 Abrir el men´u del autopiloto en Setup Set Autopilot . Se abre el men´u de configuraci´on. 5 Seleccionar el archivo de configuraci´on SID 12 LEVC.apconf(*) Los datos se quedan rellenados en el men´u. 6 Pulsar el bot´on AP Engage . El autopiloto se activa. 7 Comprobar que el sistema funciona de forma aceptable. El sistema funciona correctamente. Comentarios: (*): El archivo SID 12 LEVC.apconf se encuentra en la carpeta APConfig del directorio ra´ız de la aplicaci´on. Master Universitario en Ingenier´ıa Aeron´autica 101 CAP´ ITULO 6. RESULTADOS TC-8. Arquitectura Entorno de test Ver Secci´on 2.1 Requisitos cubiertos NFR-2, NFR-3, NFR-4 Pre-requisitos El ordenador debe de estar encendido y con una sesi´on de usuario iniciada. Paso Acci´on a realizar Respuesta esperada 1 Abrir el c´odigo de la aplicaci´on Java mediante Netbeans. Netbeans muestra el c´odigo. 2 Comprobar que el c´odigo se ha realizado siguiendo la filosof´ıa de programaci´on orientada a objetos. El c´odigo est´a orientado a objetos. 3 Verificar que el existen distintos m´odulos en el c´odigo fuente como: Antenna oAutopilot El c´odigo implementa distintos m´odulos. Comentarios: El hecho de implementar el c´odigo de con la filosof´ıa de programaci´on orientada a objetos y de forma modular facilita enormemente la ampliaci´on y mejora de funcionalidades. Por tanto si el resultado de este test es satisfactorio, se valida el requisito NFR-4. 102 Master Universitario en Ingenier´ıa Aeron´autica 2. DISE ˜ NO DE LOS CASOS DE PRUEBA O TEST CASES TC-9. Usabilidad Entorno de test Ver Secci´on 2.1 Requisitos cubiertos NFR-1, NFR-5, NFR-6 Pre-requisitos El ordenador debe de estar encendido y con una sesi´on de usuario iniciada. El simulador debe de estar iniciado, con la aeronave Cessna 172SP en la pista 12 del aeropuerto de Valencia (LEVC). Un grupo representativo de personas debe estar disponible para evaluar el programa. Paso Acci´on a realizar Respuesta esperada 1 Realizar distintas pruebas de usabilidad con un grupo de gente representativo El grupo utiliza la aplicaci´on y la eval´ua en t´erminos de facilidad de uso, utilidad did´actica y capacidad de mejora. 2 Analizar las evaluaciones realizadas por los usuarios y verificar el cumplimiento de los requisitos. Las evaluaciones verifican los requisitos. Comentarios: Master Universitario en Ingenier´ıa Aeron´autica 103 CAP´ ITULO 6. RESULTADOS 3. Resultados de los casos de prueba Los test descritos en los casos de prueba del Apartado 2.2 se han realizado siguiendo el procedimiento indicado en los mismos. La Tabla 6.1 resume los resultados obtenidos en cada uno de ellos. En este caso se puede observar que el resultado global de la ejecuci´on de los casos de prueba es muy satisfactorio, con apenas dos tests que se han pasado de forma parcial debido a ciertos matices. Tabla 6.1: Resultado de la ejecuci´on de los casos de prueba Caso de prueba Resultado del test TC-1 Pasado TC-2 Pasado TC-3 Pasado TC-4 Pasado TC-5 Pasado TC-6 Pasado TC-7 Pasado parcialmente (*) TC-8 Pasado TC-9 Pasado parcialmente (**) Comentarios: (*): El test se considera como pasado parcialmente ya que el sistema se ejecuta de forma satisfactoria ´unicamente para trabajos de desarrollo. Sin embargo, la experiencia de usuario mejorable. (**): El test se ha pasado de forma parcial debido a que el n´umero de usuarios que lo han realizado no es suficientemente significativo. En un futuro se deber´an realizar tests m´as exhaustivos para verificar los requisitos de forma definitiva. 4. Trazabilidad de los requisitos Para demostrar el cumplimiento de los requisitos, se procede a trazar los mismos con los casos de prueba que se han utilizado para validarlos mediante el uso de la matriz de trazabilidad mostrada en la Tabla 6.2. Esta es una forma de proveer al lector de una visi´on general del procedimiento de test. As´ı se puede ver de forma visual cu´ales son los requisitos validados y cu´ales son los que no se han podido cumplir. 104 Master Universitario en Ingenier´ıa Aeron´autica 5. AN ´ ALISIS DE LOS RESULTADOS Tabla 6.2: Matriz de trazabilidad de los requisitos FR-1 FR-2 FR-3 FR-4 FR-5 FR-6 FR-7 FR-8 FR-9 FR-10 FR-11 FR-12 FR-13 FR-14 FR-15 NFR-1 NFR-2 NFR-3 NFR-4 NFR-5 NFR-6 NTH-1 NTH-2 NTH-3 NTH-4 NTH-5 NTH-6 NTH-7 NTH-8 TC-1 X X X X X X TC-2 X X TC-3 X X X X TC-4 X X X X X X TC-5 X TC-6 X TC-7 X TC-8 X X X TC-9 X X X Master Universitario en Ingenier´ıa Aeron´autica 105 CAP´ ITULO 6. RESULTADOS 5. An´alisis de los resultados Tal y como se ha podido comprobar mediante los casos de prueba y la matriz de trazabilidad de la Tabla 6.2, los resultados obtenidos en el presente proyecto son muy satisfactorios en cuanto al cumplimiento de requisitos. Todos los requisitos funcionales presentados en la Secci´on 4 del Cap´ıtulo 2 se han cumplido de forma inequ´ıvoca. Esto se ha podido demostrar de forma objetiva mediante la realizaci´on de los casos de prueba expuestos anteriormente. En cuanto a los requisitos no funcionales, ´estos se han cumplido tambi´en en su totalidad. Sin embargo, debido a la dificultad de dise˜nar pruebas objetivas que validen requisitos muy subjetivos como NFR-1, NFR-5 y NFR-6. Estos tres requisitos se han validado mediante el an´alisis de las opiniones de distintos usuarios a los que se ha mostrado la aplicaci´on y que se les ha permitido interactuar con la misma. Sin embargo, debido a los recursos limitados de los que se dispone en este proyecto, no ha sido posible realizar un an´alisis sobre una poblaci´on mayor. A pesar de ello, se consideran validados los requisitos, ya que si bien es dif´ıcil validarlos de forma totalmente objetiva, parece claro que la aplicaci´on cumple sobradamente dichos requisitos. Adem´as del cumplimiento total de los requisitos de car´acter obligatorio, se ha conseguido tambi´en cumplir algunos de los objetivos no obligatorios, denominados como funcionalidades deseables o “nice to have”. Entre los mismos destacan la capacidad de utilizar archivos de configuraci´on para el autopiloto y de archivos de trazas de tr´afico a´ereo para emular la antena en casos en los que no se disponga de conexi´on. Sin embargo, es conveniente destacar la gran capacidad de crecimiento que tiene la plataforma implementada. Esto se hace patente en las funcionalidades deseables que han quedado por implementar (NTH-2, NTH-3, NTH-5, NTH-7 y NTH-8). En las secciones siguientes se profundizar´a en los trabajos futuros y los principales aspectos a mejorar del trabajo realizado. 106 Master Universitario en Ingenier´ıa Aeron´autica Cap´ıtulo 7 Conclusiones y trabajos futuros 1. Conclusiones El presente proyecto ha tratado el proceso de desarrollo de software aeron´autico mediante una filosof´ıa orientada a objetos. La plataforma desarrollada se ha centrado en la vertiente m´as acad´emica, con el principal objetivo de servir como plataforma educativa para el aprendizaje de programaci´on orientada a objetos en aplicaciones aeron´auticas. Con este fin se ha desarrollado una plataforma integral que engloba una interfaz gr´afica conectada a distintos m´odulos como son un simulador, un autopiloto, un TCAS con datos de tr´afico real y distintos instrumentos de navegaci´on. El c´odigo desarrollado se ha realizado teniendo en mente la necesidad de que sea modular y f´acilmente ampliable, con el fin de permitir que los alumnos sean capaces de editarlo en un futuro. Para dotar al proyecto de una mayor entidad, se ha realizado siguiendo una metodolog´ıa de gesti´on de proyectos t´ıpica en el desarrollo de software, basada en la ingenier´ıa de requisitos. De esta forma, el proyecto se ha centrado primero en la definici´on de los requisitos antes de realizar la implementaci´on. Una vez implementado el c´odigo, se ha procedido a la fase de verificaci´on, donde se han generado distintos casos de prueba y se han validado los requisitos. Finalmente se ha realizado una matriz de trazabilidad que relacione cada requisito con el caso de prueba que lo valida. Con esto, se han podido extraer las siguientes conclusiones: Dise˜no del sistema Se ha realizado un dise˜no del sistema siguiendo la metodolog´ıa empleada por grandes empresas del sector de la aviaci´on como Airbus Group. Para ello se han enumerado una serie de requisitos funcionales, no funcionales y caracter´ısticas deseables. 107 CAP´ ITULO 7. CONCLUSIONES Y TRABAJOS FUTUROS 114 Master Universitario en Ingenier´ıa Aeron´autica Bibliograf´ıa [1] Wilson J Rugh and Jeff S Shamma. Research on gain scheduling. Automatica, 36(10):1401–1425, 2000. [2] Michael Athans. Nonlinear and adaptive control. Technical report, Massachussets Institute of Technology & Nasa, 1989. [3] Fany Mendez-Vergara, Ilse Cervantes, and Angelica Mendoza-Torres. Stability of gain scheduling control for aircraft with highly nonlinear behavior. Mathematical Problems in Engineering, 2014, 2014. [4] Bryan P Rasmussen and Young Joon Chang. Stable controller interpolation and controller switching for lpv systems. Journal of dynamic systems, measurement, and control, 132(1):011007, 2010. [5] Wei Guo. Gain scheduling for a passenger aircraft control system to satisfy handling qualities, 2010. [6] Jianying Gao. Robust control design of gain-scheduled controllers for nonlinear processes, 2004. [7] Vojtech Vesel`y and Adrian Ilka. Gain-scheduled pid controller design. Journal of process control, 23(8):1141–1148, 2013. [8] KJ Astrom and Bj¨orn Wittenmark. Self-tuning controllers based on pole-zero placement. In IEE Proceedings D (Control Theory and Applications), volume 127, pages 120–130. IET, 1980. [9] Karim Nassiri-Toussi and Wei Ren. Indirect adaptive pole-placement control of mimo stochastic systems: self-tuning results. Automatic Control, IEEE Transactions on, 42(1):38–52, 1997. [10] Francisco C Silva Jr and Aldayr D Ara´ujo. Variable structure adaptive pole placement control. In Decision and Control, 2005 and 2005 European Control Conference. CDC-ECC’05. 44th IEEE Conference on, pages 2859–2864. IEEE, 2005. 115 [11] M Zamurad Shah, Raza Samar, and Aamer I Bhatti. Cross-track control of uavs during circular and straight path following using sliding mode approach. In Control, Automation and Systems (ICCAS), 2012 12th International Conference on, pages 185–190. IEEE, 2012. [12] Pong-in Pipatpaibul and PR Ouyang. Application of online iterative learning tracking control for quadrotor uavs. ISRN robotics, 2013, 2013. [13] Oliver Purwin and Raffaello D Andrea. Performing aggressive maneuvers using iterative learning control. In Robotics and Automation, 2009. ICRA’09. IEEE International Conference on, pages 1731–1736. IEEE, 2009. [14] Yuriy Brun, Giovanna Di Marzo Serugendo, Cristina Gacek, Holger Giese, Holger Kienle, Marin Litoiu, Hausi M¨uller, Mauro Pezz`e, and Mary Shaw. Engineering selfadaptive systems through feedback loops. In Software engineering for self-adaptive systems, pages 48–70. Springer, 2009. [15] Matthias Schreier. Modeling and adaptive control of a quadrotor. In Mechatronics and Automation (ICMA), 2012 International Conference on, pages 383–390. IEEE, 2012. [16] Siddhartha Bhattacharyya, Darren Cofer, D Musliner, Joseph Mueller, and Eric Engstrom. Certification considerations for adaptive systems. In 2015 International Conference on Unmanned Aircraft Systems (ICUAS), pages 270–279. IEEE, 2015. [17] Daniel B Wilson, Ali H G¨oktogan, and Salah Sukkarieh. Guidance and navigation for uav airborne docking. [18] Reuben Strydom, Saul Thurrowgood, Aymeric Denuelle, and Mandyam V Srinivasan. Uav guidance: A stereo-based technique for interception of stationary or moving targets. In Towards Autonomous Robotic Systems, pages 258–269. Springer, 2015. [19] Jack W Langelaan, Nicholas Alley, and James Neidhoefer. Wind field estimation for small unmanned aerial vehicles. Journal of Guidance, Control, and Dynamics, 34(4):1016–1030, 2011. [20] Ferit C¸akıcı, Halit Ergezer, Ufuk Irmak, and M Kemal Leblebicio˘glu. Coordinated guidance for multiple uavs. Transactions of the Institute of Measurement and Control, 2015. [21] UK Civil Aviation Authority. Unmanned aircraft system operations in uk airspace– guidance, 2012. [22] International Civil Aviation Organization (ICAO). Performance based navigation (PBN) manual, 4th edition edition, 2013. [23] H`ector Usach Molina. Integridad y tolerancia a fallos en sistemas de avi´onica. Universitat Polit`ecnica de Val`encia, 2015-2016. [24] United States Department of Transportation. Federal Aviation Administration. Introduction to tcas-ii. version 7.1, February 2011. [25] International Civil Aviation Organization (ICAO). Tcas ii version 7.1. an overview on the pilots and atc on the tcas ii 7.1 euro version. In Seventh Meeting of the Asia Pacific Regional Aviation Safety Team (APRAST/7), 2015. [26] Edward A Lester. Benefits and incentives for ADS-B equipage in the national airspace system. PhD thesis, Massachusetts Institute of Technology, 2007. [27] United States Department of Transportation. Federal Aviation Administration. 14 cfr part 91 automatic dependent surveillance— broadcast (ads–b) out performance requirements to support air traffic control (atc) service; final rule, May 2010. [28] Surveillance and Broadcast Services (SBS) Program Office. Automatic dependent surveillance - broadcast in-trail procedures (ads-b itp) operational flight evaluation. Technical report, Federal Aviation Administraton (FAA), 2015. [29] United States Department of Transportation. Federal Aviation Administration. Instrument flying handbook, 2008. [30] Civil Aerospace Medical Institute Melchor J. Antu˜nano. Human factors in cockpit automation, 2011. [31] United States Department of Transportation. Federal Aviation Administration. Aviation maintenance technician handbook - general, 2008. [32] Joan Cahill and Tiziana C Callari. A novel human machine interaction (hmi) design/evaluation approach supporting the advancement of improved automation concepts to enhance flight safety. [33] Luca Damilano, Giorgio Guglieri, Fulvia Quagliotti, and Ilaria Sale. Fms for unmanned aerial systems: Hmi issues and new interface solutions. Journal of Intelligent & Robotic Systems, 65(1-4):27–42, 2012. [34] Alan Hobbs and R Jay Shively. Human factor challenges of remotely piloted aircraft, 2014. [35] FlightSafety International. Flight simulation training systems. Disponible en: https://www.flightsafety.com/html/pdf/3739_comm%20sim_bro_pgxpg_ final.pdf. [36] Aerosim Technologies. Aerosim training centers, 2016. Disponible en: http://www. aerosim.com/trainingsolutions/trainingcenters.aspx. [37] Dongwon Jung and Panagiotis Tsiotras. Modeling and hardware-in-the-loop simulation for a small unmanned aerial vehicle. AIAA Infotech at Aerospace, AIAA, pages 07–2763, 2007. [38] Widyawardana Adiprawita, Adang Suwandi Ahmad, and Jaka Semibiring. Hardware in the loop simulator in uav rapid development life cycle. arXiv preprint arXiv:0804.3874, 2008. [39] Embention Sistemas Inteligentes. Hardware-in-the-loop. hil broadcast. Disponible en: http://www.embention.com/en/hil-broadcast.htm. [40] Radio Technical Commission for Aeronautics (RTCA). Do-178c. software considerations in airborne systems and equipment certification, January 2012. [41] TutorialsPoint. Software engineering tutorial, 2014. Disponible en: http://www.tutorialspoint.com/software_engineering/software_ engineering_tutorial.pdf. [42] ´ Angel Rodas Joan Vila. Flight Management Systems - Apuntes de la asignatura. Universitat Polit`ecnica de Val`encia, 2015-2016. [43] Ralph Graves. Adi. attitude directional indicator. Avionics News, pages 52–56, September 2005. [44] CFI-Wiki. Flight Instructor Wiki. Gyroscopic instruments. Disponible en: http: //cfi-wiki.net/w/Gyroscopic_Instruments. [45] DUTCHOPS.COM Ground School Articles. Gyroscopic instruments - turn coordinator, 2009. Disponible en: http://www.dutchops.com/Portfolio_ Marcel/Articles/Instruments/Gyroscopic_Instruments/Turn_Coordinator. htm. [46] Rod Machado krepelka.com. Lesson 2: How airplanes turn. Disponible en: http: //krepelka.com/fsweb/lessons/student/studentlessons02.htm. [47] Hersch Logbook. Aircraft instruments, 2012. Disponible en: http:// herschlogbook.blogspot.com.es/2012/08/aircraft-instruments.html. [48] Eurocontrol. Tcas ii version 7.1. Disponible en: http://www.eurocontrol.int/ articles/tcas-ii-version-71. [49] Eurocontrol. Acas guide - airborne collision avoidance systems (incorporating tcas ii version 7.0 & 7.1 and introduction to acas x), December 2015. Disponible en: https://www.eurocontrol.int/sites/default/files/content/ documents/nm/safety/ACAS/safety-acas-II-guide.pdf. [50] Honeywell International Inc. CAS 66A Pilot’s Guide - Bendix/KingrTCAS I Collision Avoidance System, 2006. [51] H`ector Usach Molina. Banco de pruebas para el dise˜no de autpilotos. Master’s thesis, Universitat Polit`ecnica de Valencia, 2012. [52] Luiz Fernando Abras Cantoni. Avalia¸cao do uso da linguagem pddl no planejamento de missoes para robˆos a´ereos. PhD thesis, Universidade General de Minas Gerais, 2010. [53] Eurocontrol. Transponders in aviation. NETALERT - the Safety Nets newsletter, (19), May 2014. Disponible en: https://www.eurocontrol.int/sites/default/ files/publication/files/NetAlert-19.pdf. [54] Bones Aviation Page. Sbs basestation. Disponible en: http://woodair.net/SBS/ Article/Barebones42_Socket_Data.htm. [55] Cem Kaner. What is a good test case. In Software Testing Analysis & Review Conference (STAR) East, 2003. [56] David Allerton. Principles of flight simulation. John Wiley & Sons, 2009. [57] Alessandro Astolfi, Dimitrios Karagiannis, and Romeo Ortega. Nonlinear and adaptive control with applications. Springer Science & Business Media, 2007. [58] Richard PG Collinson. Introduction to avionics systems. Springer Science & Business Media, 2013. [59] Guillaume JJ Ducard. Fault-tolerant flight control and guidance systems: Practical methods for small unmanned aerial vehicles. Springer Science & Business Media, 2009. [60] Alexander Fradkov and Boris Andrievsky. Combined adaptive controller for uav guidance. European Journal of Control, 11(1):71–79, 2005. [61] C Kaner and REBECCA L Fiedler. Black box software testing. introduction to test design. a survey of test techniques. BBST Test Design, 2011. [62] Mangal Kothari. Algorithms for Motion Planning and Target Capturing. PhD thesis, University of Leicester, 2011. [63] C´esar Munoz, Anthony Narkawicz, and James Chamberlain. A tcas-ii resolution advisory detection algorithm. In Proceedings of the AIAA Guidance Navigation, and Control Conference and Exhibit, 2013. [64] Cary R Spitzer and Cary Spitzer. Digital Avionics Handbook. CRC Press, 2000. [65] Borja Fons Albert. Plataforma para dise˜no y ejecuci´on de aplicaciones de avi´onica. Universitat Polit`ecnica de Val`encia, 2013.