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.