4. ARQUITECTURA DE LA APLICACIÓN
Transcript of 4. ARQUITECTURA DE LA APLICACIÓN
8
4. ARQUITECTURA DE LA APLICACIÓN
Como se mencionó anteriormente, la aplicación se ha desarrollado por completo en el
entorno MATLAB, y programada en el lenguaje M. El conjunto de la aplicación se ha
compuesto por varias funciones (en adelante módulos) con una filosofía de programación
estructurada.
Los módulos en sí se han programado de forma orientada a objetos con una
subherramienta de MATLAB llamada GUIDE, que funciona de manera muy similar a los
compiladores de lenguajes visuales como Visual Basic.
Hay varias razones para la elección del entorno MATLAB. La principal es que ésta es la
herramienta de cálculo que más se ha utilizado a lo largo de toda la carrera, habiendo
incluso varias asignaturas que apoyan su contenido específicamente en la programación en
lenguaje M. Pero no es la única: la aplicación a desarrollar necesita que algunos
fragmentos de código se repitan muchos millones de veces (tanto las tareas de traducción
como las de detección de eventos), y a la vez requiere rutinas de muy alto nivel como todas
las relacionadas con la representación gráfica. El lenguaje M permite por un lado
programar a un nivel tan bajo como se puede conseguir con el lenguaje C o Fortran (de
hecho se admite la ejecución de código C) y por otro, gracias a GUIDE, nos permite el
embebido de subrutinas programadas en Java.
En la Figura 4-1 se representa un diagrama con la estructura general de la aplicación y
el intercambio de datos entre los diferentes módulos.
9
Figura 4-1: Arquitectura de IADV
La aplicación IADV cuenta con cuatro módulos: la Interfaz Principal, el cargador CSV,
el Gestor de Eventos (en adelante GE) y el Gestor de Variables (en adelante GV). El
elemento Diccionario no es un módulo (ni siquiera es un programa) pero es completamente
independiente de los módulos mencionados, por lo que se ha separado en el diagrama y se
tratará en un subapartado propio.
El Cargador CSV no es más que la vía de entrada de la información en el software
realizando la traducción a un formato de trabajo, y la compilación de operaciones. Lee del
diccionario los nombres de las variables, entre otras cosas, para poder hacer la traducción
(codificación).
Las operaciones de detección y análisis se realizan en el conjunto Interfaz Principal-GV-
GE, constituyen por tanto el “punto de salida” de la información hacia el usuario o front-
end.
10
Los tres módulos leen del diccionario toda la información de las variables que necesita
ser mostrada en la interfaz (decodificación).
En el apartado 4.1 se detallarán las salidas, entradas y funcionamiento de cada uno de
los elementos.
4.1. MÓDULOS
DICCIONARIO 4.1.1.
El elemento Diccionario es una lista de variables por filas con diferentes propiedades
por columnas. Puede decirse que es el código necesario para la traducción en ambos
sentidos de los datos entre el lenguaje “externo” (cadenas de caracteres, como en los datos
de ADRAS/ROSE, y como pueden ser comprendidos por el usuario), y el lenguaje “interno”
(numérico).
En los datos de vuelo se distinguen dos tipos de variables: aquellas cuyo valor es
numérico, y aquellas que en cada segundo tienen un estado entre un número limitado de
posibilidades. Nos referiremos al primer grupo como variables analógicas (pues pueden
tomar cualquier valor en un intervalo continuo) y al segundo como variables discretas
(pues solo pueden tomar un valor de entre un conjunto reducido). La presión de altímetro,
ángulo de ataque, torque del motor etc son variables analógicas, mientras que hay muchos
otros sensores que solo devuelven una señal que puede ser “on” o “off”.
Como se explicó en el punto 3.1, el archivo proveniente de ADRAS/ROSE es
completamente texto. Incluso los números que forman parte del archivo son en principio
solo caracteres. La interpretación de la cadena “66456” como el número 66456 es una
operación inmediata para MATLAB y muy rápida. Sin embargo, el requisito R1 (Creación
de un traductor de los datos CSV) hace referencia a que el producto del Cargador CSV ha
de ser una matriz completamente numérica. Existen varias razones por la que esto es
provechoso. Trabajar con las cadenas de caracteres en la aplicación es costoso en términos
de:
Tiempo de cálculo: pues cada vez que se ha de realizar alguna actividad con el
“significado” del valor de la variable es necesario ejecutar una rutina de reconocimiento de
caracteres. Es decir, si por ejemplo necesitamos que en una gráfica se represente el estado
11
de la variable discreta a lo largo de un intervalo de tiempo tenemos que definir dichos
estados y asignar a cada uno de ellos una posición (valor) en la gráfica. Es conveniente que
los datos de partida ya estén de una forma que se puedan representar sin realizar tareas de
reconocimiento. Igualmente conveniente es en el caso de que queramos detectar los
momentos de un vuelo en los que un conjunto de variables discretas se encuentran en un
estado determinado (combinación de valores).
Memoria de trabajo (RAM): pues un número ocupa en general mucho menos espacio
en memoria que una cadena.
Memoria física: pues la matriz ha de ser almacenada en el disco duro.
Por lo tanto, para cada variable discreta de cada modelo de avión hay que hacer una
asignación Cadena - Valor numérico. Por simplicidad, se han tomado números enteros
empezando en 1. Por ejemplo, si las posibilidades son ON/OFF se ha asignado:
1 – ON
2 – OFF
Estas equivalencias se recogen en un diccionario por cada modelo de avión (los
nombres de variables abreviadas y las cadenas posibles asociadas a las variables varían
entre los diferentes modelos). El diccionario se ha organizado en forma de tabla donde las
variables se distribuyen por columnas y en la fila se da información sobre dicha variable. A
saber:
- Columna 1: Número entero comenzando en 1 para la fila 1. Solo es una
numeración de las variables. La numeración es unívoca y permanente siempre y
cuando no se edite el diccionario a propósito para cambiar esta ordenación.
- Columna 2: Nombre abreviado de la variable, tal y como aparece en la primera
fila de los datos de entrada. Por ejemplo LOCP.
- Columna 3: Nombre completo de la variable. En nuestro ejemplo: Loss of cabin
pres.
- Columna 4: Capítulo ATA asociado a la variable. En nuestro caso 21.
- Columna 5: Tipo de variable: numérica (Unsigned analog, Signed analog, o
BCD) o discreta (DISCRETE).
- Columna 6: Unidades, si aplica.
12
- Columna 7: En el caso de las variables numéricas esta columna contiene la
siguiente cadena:
“Min: x. Max: y”
Donde x e y son el valor máximo y mínimo respectivamente que se puede esperar que
tome la variable.
En el caso de variables discretas contiene la cadena:
“Posibilidad1/Posibilidad2/Posibilidad3/Posibilidad4…”
Donde Posibilidad1, Posibilidad 2,…, indican los posibles valores de la
variable discreta y a los que se les asignan los números enteros 1, 2,…
- Columna 8: Nombre abreviado de la variable, armonizado con el resto de los
modelos de avión.
La relación de abreviaturas, nombres completos, capítulos ATA, tipos de variable,
valores máximo y mínimo, y estados posibles para las variables discretas ha sido
proporcionada por el Departamento de Sistemas de la FAL.
La tabla del diccionario ha de ser legible por todos los módulos principales (ver Figura
4-1) de IADV de forma automatizada. La importación de tablas de EXCEL en MATLAB
no es especialmente estable en cuanto al formato de los datos de salida por lo que se ha
optado por el formato CSV, necesitando una pequeña aplicación de lectura. A continuación
se muestra un extracto del diccionario:
187;FLAG2;DFDR Main Flag 2;31;DISCRETE;;off/ON;FLAG2
188;HR;Time (Hours);31;Unsigned Analog;hrs;Min: 0. Max: 24.;HR
189;MEM;Memory Erase ;31;DISCRETE;;erase/NOT ERASE;MEM
190;MIN;Time (Minutes) ;31;Unsigned Analog;mins;Min: 0. Max: 60.;MIN
191;MON;Date (Month) ;31;BCD;months; Min: 1. Max: 12.;MON
13
Que interpretado como tabla queda:
187 FLAG2 DFDR Main Flag
2 31 DISCRETE off/ON FLAG2
188 HR Time (Hours) 31 Unsigned Analog hrs Min: 0. Max: 24. HR
189 MEM Memory Erase 31 DISCRETE erase/NOT ERASE MEM
190 MIN Time (Minutes) 31 Unsigned Analog mins Min: 0. Max: 60. MIN
191 MON Date (Month) 31 BCD months Min: 1. Max: 12. MON
Para las variables mostradas no ha habido trabajo de armonización con otros modelos de
avión, por lo que la columna 2 y la 8 coinciden.
CARGADOR CSV 4.1.2.
El cargador CSV es el punto de introducción de los datos de vuelo en el resto de la
aplicación. Responde al requisito R1 (Creación de un traductor de los datos CSV a matriz
numérica), y a sus subrequisitos derivados. No tiene ninguna función de análisis, sino de
traductor de datos de vuelo según los principios desarrollados en el apartado 4.1.1.
En base al subrequisito R1.3 (Información sobre el vuelo de aceptación debe ser
asociada a la matriz numérica de salida) se define la salida del módulo como:
Operación: Datos de vuelo + Campos asociados.
Siendo los campos asociados información adicional sobre el vuelo de prueba del que
provienen los datos.
Se ha de ejecutar solo una vez por cada archivo de datos proveniente de ADRAS/ROSE,
no es necesario en el caso de análisis repetidos sobre los mismos datos de vuelo.
14
En la Figura 4-2 se muestran sus entradas y salidas:
Figura 4-2: Arquitectura del Cargador CSV
4.1.2.1. Datos de entrada
La naturaleza de los datos de entrada al Cargador CSV se ha descrito en buena medida
en el apartado 4.1.1. Pero hay algunos problemas adicionales en la importación de datos a
parte de la conversión a valor numérico de los estados de las variables discretas.
La aplicaciones ADRAS/ROSE producen por cada descarga de datos de la FDR uno o
varios archivos CSV según se requiera. Por ejemplo, como no se permite incluir más de
201 parámetros por archivo, se pueden separar entre dos o más.
Además, algunas características en la traducción dependen de la configuración del
programa. Por ejemplo, el separador utilizado o el uso de comillas para las cadenas de
caracteres. No existe un procedimiento específico para el operario que realiza la traducción
que regule estos parámetros, por lo que no hay un formato normalizado para el archivo
CSV que se introduce en el módulo Cargador CSV.
15
A continuación se reproduce un fragmento de un archivo real:
…""HR""$""MIN""$""SEC""$""AASF1-dig""$""AASF2-ana""…
…9$52$0$""off""$""on""…
…9$52$1$""off""$""on""…
…9$52$2$""off""$""on""…
…9$52$3$""off""$""on""…
Interpretando el símbolo “$” como separación de celdas en la misma fila, y el salto de
línea como salto a la siguiente fila, e ignorando las comillas, llegamos a la siguiente tabla:
HR MIN SEC AASF1-dig AASF2-ana
9 52 0 off on
9 52 1 off on
9 52 2 off on
9 52 3 off on
Es común en todos los archivos CSV el hecho de que las variables se ordenan por
columnas, y el tiempo por filas (una toma de datos se almacena en una fila en el archivo, o
sea que hay una fila por segundo). Otra característica común es que la primera fila indica el
nombre abreviado de la variable asignada a cada columna en forma de cadena de
caracteres.
Podemos decir entonces que, para satisfacer sus requisitos en lo que concierne a los
datos de vuelo, el módulo Cargador CSV ha de ser capaz de aceptar una cierta variedad de
formatos en lo que concierne a la separación entre valores, ha de tener la funcionalidad de
leer varios archivos de origen e interpretarlos como pertenecientes a un solo vuelo, y ha de
ser capaz de interpretar cadenas de caracteres como posibles estados en los que se
encuentra una variable discreta, para todas las variables discretas de todos los modelos de
aeronave utilizando el diccionario adecuado a cada modelo como código de traducción.
Por último, dado el requisito R1.3 (Asociación de los datos de salida a cierta
información sobre el vuelo), no bastará con introducir los datos de vuelo como entrada; los
campos asociados deberán ser introducidos manualmente por el usuario. Los campos son
los siguientes:
16
1. Modelo de avión
2. Nombre de la operación
3. MSN
4. Nombre del piloto
5. Fecha y hora de la operación
6. Punto de comienzo de la traducción
7. Punto de fin de traducción
8. Versión del diccionario utilizado para la traducción
De ellos, solo el primero es obligatorio. Una vez introducidos el cargador tiene la
información necesaria para compilar los datos de operación. Sobre ellos se volverá a hablar
en el apartado 4.1.2.4.
Figura 4-3: Entradas y salidas del Cargador CSV
4.1.2.2. La traducción
Hemos definido los datos de entrada y de salida (aunque estos últimos se describirán
con más profusión en el apartado 4.1.2.4.), y hemos creado un código para la traducción de
un archivo de texto a una matriz numérica. Ahora describiremos la traducción en sí,
realizada por la función importer.m.
El primer paso en la traducción es la importación del diccionario, para lo que se llama a
la función importdic.m. Recordemos que en realidad el diccionario es también un archivo
CSV y necesita ser transformado a un formato de trabajo de MATLAB. La función
17
importdic.m lee el archivo del diccionario y crea un array (ordenación de datos en forma
de matriz) con la información del mismo.
El siguiente paso que realiza importer.m es leer el contenido de la columna 7 del
diccionario importado (posibles estados de las variables discretas separados por barras) y
reconocer las diferentes cadenas de caracteres posibles. Esos estados posibles almacena en
un nuevo array llamado matriz de posibilidades que tiene el siguiente aspecto:
… … …
HR Numero
MIN Numero
SEC Numero
AASF1-dig off ON
AASF2-ana on OFF
ACB1S not active ACTIVE
ACES no voice VOICE ENABL
… … …
La columna uno contiene el nombre abreviado de la variable, y el resto de columnas
contienen los diferentes estados.
A continuación se comienza la lectura de los datos de vuelo. Primero se lee la primera
fila, y se coteja con la columna 2 del diccionario (nombres abreviados). Cuando se
encuentra la coincidencia se rellena el elemento correspondiente en la primera fila de la
matriz de operación. Por ejemplo, si leemos en la primera variable de los datos la cadena
“Sample” y buscamos en el diccionario (columna 2) encontramos que coincide con la
variable abreviada de la fila 195 en el caso del modelo C-295. Entonces almacenamos en la
posición (1,1) de la matriz numérica de salida el valor 195. Así, todos los datos que llenen
la columna 1 de la matriz de operación harán referencia a la variable “Sample”. Esta
variable, por cierto, es el número de muestra (toma de datos) en los datos de vuelo, y
siempre es la primera en aparecer en los archivos CSV.
Con esta lógica, se rellena completamente la primera fila de la matriz de operación.
Después se continúa con la segunda fila del archivo CSV, donde empiezan los datos de
vuelo en sí mismos. Cuando se trata de una variable numérica (ahora ya podemos
reconocerlo, porque tenemos la entrada en el diccionario asociada) se hace una sencilla
conversión str2double (cadena a número de precisión doble). Cuando por el contrario
tenemos una cadena que indica el estado de una variable discreta utilizaremos la función
18
cual.m que nos devolverá el número a asociar en la matriz numérica, tal y como se ha
descrito en el apartado 4.1.1.
A la función cual.m se le pasan como argumento una sola cadena de caracteres de los
datos, y la fila de la matriz de posibilidades asociada a la variable en cuestión. Devuelve un
número entero: el asociado al estado de la variable. Es una función extremadamente
sencilla, pero a cuya optimización se dedicado mucho trabajo, dada la cantidad de veces
que tiene que ejecutarse.
En la siguiente figura se representa un sencillo ejemplo de funcionamiento para la
variable ACB1S que tiene dos estados posibles:
Figura 4-4: Funcionamiento de cual.m
En el caso de un fallo de reconocimiento, se traduce como el valor 0 (siendo 1, 2, 3…
las posibilidades reconocidas con éxito).
En el caso de un fallo de reconocimiento en la fila uno (el nombre de la variable no se
encuentra en el diccionario) el programa da un mensaje de aviso el la línea de órdenes, y
esa columna completa no es traducida.
19
A continuación se representa un ejemplo del proceso completo de traducción:
Figura 4-5: Proceso de traducción
En la primera fase (lectura del CSV) se emplea aproximadamente un 0,1% del tiempo
total. El 99,9% restante se emplea en la traducción (45% en la función cual.m, 30% en la
función str2double.m, y el resto repartido entre funciones menores).
4.1.2.3. Traducción múltiple
El requisito R1.4 exige la posibilidad de carga de datos de vuelos separados en varios
archivos. La razón es, como ya se comentó en el apartado 4.1.2.1., que ADRAS/ROSE
permite el fraccionamiento de datos de vuelo entre varios ficheros. A veces es incluso
necesario dada la limitación de dichas aplicaciones a 201 parámetros por archivo.
20
La carencia de un procedimiento que estandarice la forma de fraccionamiento (número
de partes, número de parámetros y duración) obliga al Cargador CSV a ser capaz de aceptar
como entrada cuantas más combinaciones de tamaños y distribución como sean posibles.
La solución alcanzada consiste en permitir al usuario introducir hasta 15 archivos
clasificados con un código de letra y número, que deben cumplir ciertas relaciones de
coherencia para poder ser unidos al final. La distribución de los archivos es como sigue:
El usuario puede elegir qué archivo asignar a cada “hueco”. No es necesario ocupar
todos los huecos. La fusión de los datos se hará tal y como se representa en la tabla, para
formar una gran matriz compuesta por hasta 15 submatrices.
Las condiciones de coherencia son:
- En cada fila, todos los elementos no vacíos han de tener la misma duración (número
de filas).
- En cada columna, todos los elementos no vacíos han de tener el mismo número de
parámetros (número de columnas).
- Un elemento vacío debe pertenecer a una fila completamente vacía, una columna
completamente vacía, o ambas cosas. Expresado de otro modo: eliminando filas y
columnas completamente vacías debemos poder llegar a una matriz completamente
llena.
La función (con interfaz propio) csvmulti.m chequea la coherencia una vez introducidos
los datos. En el caso de que se cumplan las condiciones, los archivos serán traducidos uno
tras otro con la rutina de traducción simple.
Finalmente, las matrices numéricas individuales se unen una global y se almacenan
como una sola matriz de datos de vuelo, perdiendo la información de su fraccionamiento
original.
A1 A2 A3 A4 A5
B1 B2 B3 B4 B5
C1 C2 C3 C4 C5
21
4.1.2.4. Datos de salida
La salida del Cargador CSV se basa en el concepto de operación. Una operación se
corresponde con un único vuelo de aceptación, y desde el punto de vista de IADV se
compone de:
- Una matriz numérica (formato .mat) con los datos del vuelo traducidos por el
Cargador CSV.
- Un archivo de texto con los campos asociados al vuelo, introducidos manualmente
en la interfaz del cargador
Los campos asociados fueron definidos en el apartado 4.1.2.1.
INTERFAZ PRINCIPAL 4.1.3.
La Interfaz Principal es el componente central del Front-end de la herramienta de
análisis. En ella se pueden representar y analizar los datos de vuelo. El análisis en sí se
basa en la visualización simultánea de las gráficas de varias variables respecto al tiempo,
así como en la representación de eventos en un eje temporal. Las funciones del módulo se
corresponden con el requisito R2 (creación de una interfaz de representación gráfica) y sus
subrequisitos R2.x.
Para cumplir estas funciones, la Interfaz Principal utiliza la información proporcionada
por los otros dos módulos que componen el Front-end, cuya misión no es otra que la
preparación de esta información.
Del Gestor de variables recibe la lista de cuáles son las variables de trabajo de entre
todas las contenidas en los datos.
Del Gestor de Eventos recibe una lista de instantes en los datos y eventos asociados a
dichos instantes.
La descripción de la interfaz en sí, de su funcionalidad, y la justificación de su diseño
pueden encontrarse en el apartado 5.4.1.
22
Figura 4-6: El Front-end de IADV
4.1.3.1. Datos de entrada
La interfaz toma como entrada una única operación en cada sesión de análisis, es decir,
los datos correspondientes a un solo vuelo. No solo lee la matriz numérica de la operación,
sino también el archivo de texto para, por ejemplo, conocer el modelo de avión del que
provienen los datos.
Además, la interfaz requiere del diccionario de variables para hacer la información
contenida en la matriz de datos comprensible de cara al usuario. Sin el diccionario solo se
tienen una serie de variables numeradas, con valores en un intervalo de tiempo. Para la
interacción con el usuario es necesario leer del mismo:
- Nombre abreviado (armonizado) y completo de las variables.
- Tipo de cada variable (analógica o digital) para decidir en qué parte del área de
gráficas se representa.
23
- Valores máximo y mínimo de las variables analógicas, para la función de zoom Y
por defecto.
- Estados de las variables discretas, para mostrarlos en las gráficas. El número
asociado a cada estado no tiene, por regla general, significado alguno para el
usuario.
4.1.3.2. Variables de trabajo
La Interfaz Principal tiene acceso a todos los datos traducidos en la matriz de operación.
En los primeros bocetos sobre la arquitectura del programa se planeó un sencillo
módulo llamado Selector de datos situado entre el cargador CSV y la Interfaz Principal.
Este módulo tendría la función de cargar en memoria solamente una parte de la matriz
numérica de datos de vuelo, y proveer esta matriz reducida o filtrada a la Interfaz Principal.
Esto se haría a través del Gestor de Variables. El objetivo era reducir la cantidad de datos
en la memoria de trabajo (RAM) para aumentar el rendimiento. Sin embargo, tras algunas
pruebas se determinó que el módulo es innecesario, ya que las matrices numéricas en el
espacio de trabajo de MATLAB tienen un tamaño despreciable con respecto a la cantidad
de memoria RAM disponible en los equipos de hoy en día.
Aunque no exista la necesidad de un selector de datos en memoria sería incómodo no
hacer una selección de variables de cara al usuario para el trabajo de análisis (aunque todas
las variables estén en memoria). Si en la Interfaz Principal tuviéramos que buscar entre la
totalidad de las variables cada vez que queremos seleccionar una para ser representada,
sería mucho más costoso en términos de tiempo que hacer el esfuerzo una vez por análisis
de elegir un grupo de variables de interés.
A raíz del anterior motivo, y del requisito R2.10 (Creación, modificación y eliminación
de sets de variables) surge la necesidad de crear un módulo separado, que se dedique
específicamente a la gestión de variables. La Interfaz Principal recibe de este módulo
(Gestor de variables) la información de cuáles son las variables de trabajo.
GESTOR DE VARIABLES 4.1.4.
El Gestor de Variables es un módulo con interfaz propia que forma junto al Gestor de
eventos y a la Interfaz principal el Front-end de la herramienta IADV.
24
Solo puede ser llamado desde la Interfaz Principal y su función es exclusivamente
seleccionar las variables de trabajo. Responde al requisito R2.10 (Creación, modificación y
eliminación de sets de variables).
Esto se hace sin ningún argumento de entrada a parte de los propios datos de vuelo, no
hay ningún elemento de la interfaz principal que afecte al módulo GV.
Desde el punto de vista de la arquitectura de la aplicación, el GV no es más que un filtro
de variables. De entre todas las disponibles en los datos de vuelo proporciona un grupo que
serán el material de trabajo en la operación de análisis. La selección es controlada por el
usuario en la interfaz del GV que será descrita en el apartado 5.4.2.
GESTOR DE EVENTOS 4.1.5.
El Gestor de Eventos es el último módulo a tratar en el conjunto que forma el Front-end
de la herramienta de análisis.
Responde a los requisitos del grupo R3.x (Detección de eventos y cargado y guardado
de eventos programados) y cuenta con interfaz propia. Su función principal es la detección
de eventos.
Definimos evento como instante o intervalo de tiempo en el que se cumple una
condición o una combinación lógica de condiciones sobre los datos de vuelo.
Al igual que el GV, solo toma como entrada los datos de vuelo (la matriz de datos
traducida y cargada en la interfaz principal) y el diccionario importado. Como salida
proporciona una lista de resultados positivos (intervalos con condiciones cumplidas).
Podemos distinguir dos formas de presentación de los resultados según desde qué interfaz
los consultemos:
- En la propia interfaz del GE: se representa una lista por evento detectado, donde
para cada uno de los resultados positivos se dan tanto el instante inicial como la
duración (quedando definido completamente el intervalo).
- Exportados a la Interfaz Principal: solo se muestran los instantes iniciales en la línea
de eventos, sobre la que se volverá a hablar en el apartado 5.4.4.
25
4.1.5.1. Lógica de evento
En los requisitos se habla de condiciones lógicas que conforman eventos y combinación
lógica de eventos que forma una fase de vuelo. En el desarrollo de la herramienta se ha
adoptado otra nomenclatura por simplificación, pero sin dejar de satisfacer los requisitos.
En IADV existe solo el concepto de evento, y no el de fase de vuelo. Sin embargo, los
eventos tienen mucha flexibilidad y pueden llegar a ser tan complejos como se requiera.
Además, si distinguiéramos en la interfaz principal entre la representación de eventos y de
fases de vuelo, el resultado global sería probablemente más confuso de cara al usuario.
Desde el punto de vista de la herramienta, la detección de un evento es positiva cuando
se cumple una combinación lógica de condiciones sobre las variables de los datos durante
un lapso de tiempo mínimo (duración mínima). Las condiciones en sí no tienen limitación
de complejidad, por lo que pueden ser pequeños eventos en sí mismas. Por limitaciones de
espacio en la interfaz del GE se permite la programación de hasta ocho condiciones por
evento denominadas C1, C2, C3,…, C8.
Podemos tomar como ejemplo un evento sencillo de entrada en pérdida:
- C1 es que la altitud sea decreciente
- C2 que el ángulo de ataque sea positivo
- C3 que la velocidad vertical sea negativa
- La duración mínima es 5
- La combinación es (C1 o C3) y C2
Los resultados nos mostrarán los momentos (intervalos) del vuelo en los que durante al
menos 5 segundos se ha cumplido que el ángulo de ataque es positivo y, o la señal del
altímetro decrece, o la velocidad vertical medida es negativa.
4.1.5.2. Parámetros de un evento
En consecuencia, de cara a la detección de eventos los parámetros relevantes son:
- Comienzo: Instante de los datos entre 1 y N en el que se inicia la búsqueda.
- Final: Instante de los datos entre 1 y N en el que se termina la búsqueda.
26
- Duración mínima de resultado combinado positivo, para que se considere en el
resultado final.
- Condiciones C1, C2, … C8.
- Combinación lógica de las condiciones para que el evento sea positivo.
Y por razones prácticas, existen para el software otros dos parámetros que deben ser
asociados al evento:
- Modelo del avión. No hay que especificarlo, pues para acceder al GE ya se ha
seleccionado uno.
- Nombre del evento, con el que se mostrará en la lista de resultados.
4.1.5.3. Proceso de detección
En la interfaz se hace referencia al proceso de detección de eventos con el término
búsqueda. Dadas las condiciones, combinación y duración mínima, el programa recorrerá
los datos segundo a segundo, y en cada uno se evaluarán las condiciones introducidas. Por
cada condición se crea un vector lógico de longitud N (una componente por segundo en los
datos) que indica en cada segundo si la condición se cumple o no. Finalmente la
combinación realiza operaciones lógicas con los vectores individuales para dar un vector
resultado final de la búsqueda que nos indica cuándo el evento se da y cuándo no.
Figura 4-7: Detección de eventos
27
Una vez obtenido el resultado combinado (rescomb en el diagrama) se aplica por último
el filtro de la duración mínima: Si rescomb no es positivo durante un número mínimo de
segundos no se mostrará en la lista de resultados de la detección.
4.1.5.4. Lenguaje de programación de eventos
En este apartado nos centraremos en la formulación de las condiciones y la combinación
del evento.
- Sintaxis de las condiciones
La forma de introducir las condiciones en el gestor de eventos de IADV es utilizando el
lenguaje matemático (operaciones habituales de MATLAB) con algunas reglas sintácticas
adicionales.
Para comprender mejor el funcionamiento de este lenguaje es conveniente entender
cómo funciona la búsqueda del evento (ver apartado 4.1.5.3). Como se mencionó
anteriormente, para cada segundo de los datos se evaluará cada una de las condiciones.
Éstas pueden hacer referencia al valor de cualquier variable (contenida en los datos) en el
segundo analizado, y en cualquier segundo anterior o posterior.
Usando el nombre abreviado de la variable seguido de un número entre paréntesis
hacemos referencia al valor de la variable en un instante referenciado al tiempo que se está
chequeando. Para una variable hipotética VAR:
VAR() indica el valor de la variable en el segundo analizado
VAR(+z) indica el valor de la variable z segundos después del analizado
VAR(-z) indica el valor de la variable z segundos antes del analizado
Por ejemplo SEC(-1) es el valor de la variable segundos de reloj un segundo antes del
que se está analizando. Los paréntesis son necesarios, y el valor 0 no se acepta. Si
introducimos la condición:
C1: SEC()>SEC(-1)
El programa recorrerá los datos segundo a segundo y dará positivo cuando un valor sea
mayor que el anterior.
En cada condición se admiten los símbolos y expresiones siguientes:
28
Forma 1 Forma 2
Igualdad =
Conjunción & and
Disyunción | or
Negación ~ not
Disyunción exclusiva* xor
La disyunción exclusiva tiene una sintaxis diferente a los demás operadores. Se ha de
utilizar siguiendo la forma: xor(afirmación1,afirmación2). Tendremos un resultado
positivo (se cumple la condición) cuando se cumple afirmación1 o afirmación 2 pero no
ambas.
El uso de paréntesis y corchetes también está permitido. Asimismo, la mayoría de las
funciones de MATLAB, como valor absoluto (abs) funcionan en la forma en que cabría
esperar.
- Sintaxis de la combinación
En el caso de la combinación la sintaxis es casi idéntica, solo que a cada condición se
hace referencia mediante C1,C2,…,C8. En este casos no es necesario (ni está permitido) el
uso de paréntesis. Se pueden usar las mismas operaciones lógicas que para las condiciones.
4.2. ARCHIVOS DE LA HERRAMIENTA
ESTRUCTURA DE ARCHIVOS 4.2.1.
El programa IADV no consiste de un solo archivo, sino que está formado por un grupo
de ellos:
- Funciones de MATLAB, tanto con interfaz (archivo m + archivo fig) como sin ella
(solo archivo m)
29
- Diccionarios de cada una de las aeronaves (formato csv)
- Archivos de ayuda (en formato html)
Adicionalmente, a través de las funciones del programa se pueden crear archivos de
distintos tipos:
- Matrices de operación
- Archivos de información de operación
- Archivos de análisis
- Archivos de evento
- Archivos de perfil de análisis
- Archivos de sets de variables
Todos los archivos del primer grupo deben estar contenidos en la misma carpeta
(aquella en la cuál se encuentre el ejecutable de inicio) para que el programa pueda
funcionar correctamente. A esta carpeta se la llamará carpeta raíz del programa.
Todos los archivos del segundo grupo pueden localizarse en cualquier dirección. Sin
embargo, para facilitar el trabajo, se guardan y cargan por defecto de carpetas contenidas
dentro de la carpeta raíz del programa. En la figura se muestra la estructura por defecto:
Figura 4-8: Estructura de archivos
Además de las carpetas de ayuda e imágenes para la interfaz, hay una carpeta para cada
modelo de aeronave. Dentro de cada una de ellas hay cinco carpetas como las mostradas en
el ejemplo. En ellas se guardan por defecto los archivos del segundo grupo según su tipo.
30
Al intentar abrir estos archivos desde la interfaz, el programa mostrará siempre
inicialmente la carpeta correspondiente. Si se desea abrir un archivo situado en otra
localización, no hay más que viajar hasta ella a través del explorador.
ARCHIVOS GENERADOS 4.2.2.
4.2.2.1. Archivos de operación
Constan de la matriz de operación y el archivo de información de operación. La primera
se crea automáticamente por MATLAB al utilizar el comando save. El segundo es un
archivo de texto con una sucesión de campos de información. A continuación se muestra
un ejemplo:
Múltiple,C-295,Operación4,456,Pepe
Pérez,14,10,10,11,2012,0,0,DiccionarioC295v06.csv
Se almacena la información sobre: archivo de datos de origen (o la palabra múltiple en
caso de ser una carga múltiple), modelo de aeronave, nombre de operación, MSN, piloto,
fecha, hora, y diccionario utilizado para su traducción.
El nombre de los archivos de operación se genera automáticamente al final de la
traducción del archivo CSV y se compone de: MSN-Nombre de operación-fecha. Por
ejemplo: MSN1321-Operación2-24112012
4.2.2.2. Archivos de análisis
Se componen también de dos archivos: un archivo mat donde se almacena el espacio de
trabajo completo de MATLAB tal y como está en el momento de guardar el análisis, y un
archivo de texto (con extensión ana) que da información sobre el análisis. Mostramos un
ejemplo del segundo:
dat-ana-prueba,C:\Users\hp\Documents\MATLAB\PFC\IADVv1.1\C-
295\Operaciones\MSN1321-Operación2-24112012,C-295,10,12,2012,
La información almacenada es: nombre del archivo mat donde se guarda el espacio de
trabajo, dirección de los datos de operación, modelo de aeronave y fecha de guardado del
análisis.
31
4.2.2.3. Archivos de evento
En el caso de los eventos se salva un único archivo de texto (con extensión eve) que
contiene información sobre los parámetros de evento, sin especificar modelo de aeronave.
En principio, si los nombres de las variables (armonizadas, recordemos) coinciden, se
pueden utilizar independientemente de la aeronave. Un ejemplo de archivo de evento es el
siguiente:
Perdida,C-295,auto,auto,0,AOA1(-2)>10,AOA2(-2)>10,VAC()<0.6,PA1()<PA1(-
2),,,,,(C1orC2)andC3andC4,
Donde vemos que los siguientes campos son almacenados: Nombre del evento, modelo
de aeronave, comienzo, final, duración mínima, C1, C2, C3, C4, C5, C6, C7, C8,
combinación.
4.2.2.4. Archivos de perfil de análisis
Al igual que en el caso de los eventos, se trata de un único archivo de texto (formato
per) del cual mostramos un ejemplo:
Ejemplo 1 (motor),C-295,Set ejemplo 2,Arranque motor,Parada motor,Fallo
motor,,,1,5,5,1,4,5,1,3,1,0,1,1,0,1,1,
La información almacenada es la siguiente: nombre del perfil de análisis, modelo de
aeronave, set de variables a cargar, Evento1, Evento2, Evento3, Evento4, Evento5, códigos
de representación. Estos últimos indican con qué formas y colores se representan los
eventos 1 al 5 en la línea de eventos de la Interfaz principal (más detalles sobre la
representación de eventos en la Interfaz Principal se darán en el apartado 5.4.4).
4.2.2.5. Archivos de sets de variables
Los archivos de sets de variables son también archivos de texto (extensión set). A
continuación mostramos un ejemplo:
C-295,Variables,75,130,211,230,237,238,321,322,360,485,486,580,607,608,611,612,
La sintaxis es muy sencilla: modelo de aeronave, cadena de caracteres “Variables”, lista
de variables. Los números almacenados son las posiciones de las variables del set en el
diccionario del modelo dado.