3. simulaciones. descripción del entornobibing.us.es/proyectos/abreproy/11868/fichero... · 26...

26 Software de desarrollo de simulaciones para las pruebas funcionales del avión A400M

3. Simulaciones. Descripción del entorno

3.1. Airbus Military y el programa A400M. La FAL de San Pablo

Sur. Airbus Military es la división de aviones de transporte militar de la compañía aeronáutica

Airbus, empresa perteneciente a su vez al consorcio europeo EADS (European Aeronautic

Defense and Space Company). Antiguamente conocida como EADS-CASA hasta abril de 2009,

dispone de varios centros en España, concretamente en Sevilla dispone de tres plantas:

Tablada, San Pablo Norte y San Pablo Sur, ésta última conocida como la FAL (Final Assembly

Line – Planta de montaje final) de los aviones A400M, C-295, CN-235 y C-212.

El avión A400M es un avión de transporte militar de largo alcance cuatrimotor de hélice, con

posibilidades de avión cisterna, destinado a sustituir a los aviones usados para este fin

actualmente en Europa, como el Hércules. De capacidad incrementada de carga y radio de

alcance superior, es desarrollado por varios países europeos, de los que también son clientes.

España se dedica principalmente al ensamblaje final del avión en la FAL de San Pablo Sur,

además de la fabricación de diversas piezas. Las distintas partes del avión llegan a esta planta a

través de un avión especial de transporte llamado Beluga o Super Transporter (un Airbus A300

modificado para este fin) y van pasando por diversas estaciones de montaje, pruebas, ensayos,

pintura y acabado. Cada estación está nombrada por un número de dos cifras y las más

importantes son:

Estación 72: Aquí se ensamblan las tres partes de las que está compuesta el ala del

avión (cajón central, izquierdo y derecho).

Estación 70: Preparación del ala antes de ser ensamblada en el fuselaje. Se realizan las

primeras pruebas, algunas de ellas sobre combustible.

Estación 60: Ensamblaje del Nose (morro) del avión con el fuselaje e instalación de

diversos equipos, cableado, etc.

Estación 50: Ensamblaje del estabilizador horizontal y vertical (HTP y VTP) del avión.

Pruebas de mandos de vuelo del empenaje de cola.

Estación 40: Estación principal de ensamblaje del avión. Se monta el ala y el empenaje

de cola en el fuselaje. También se realizan diversas pruebas de sistemas esenciales,

como el llamado Power On (encendido) del sistema eléctrico, pruebas de ICPs,

pantallas, red AFDX como sistema de interconexión de equipos del avión, equipos de

navegación, etc.

Estación 35: Planta principal de pruebas en tierra. Dedicada exclusivamente a esas

pruebas (al menos a partir de la producción en serie del avión). Aquí se testean todos

los equipos, sistemas, cableado, etc.


Estación 30: Pruebas en tierra exteriores. Dedicada a todas aquellas pruebas que por

diversas razones deben hacerse en el exterior, especialmente pruebas de fuel.

Estación 20: Instalación de motores, acondicionamiento interior y preparación para

línea de vuelo. Algunas pruebas se ejecutan también debido a equipos instalados aquí.

Estación 15: Últimas pruebas (las llamadas Flight Clearance Tests) y línea de vuelo.

Estación 10: Pintura.

Flight Test Center: Una vez el avión está preparado para volar, se entrega al equipo de

pruebas en vuelo. En esta planta (separada del resto en otro edificio) el avión ya no es

responsabilidad del equipo de pruebas en tierra (al menos en la producción serie).

3.2. Filosofía de las pruebas funcionales Una parte esencial en el proceso de montaje del avión es el de las pruebas para comprobar el

funcionamiento y detectar fallos lo más pronto posible, ya que es más fácil corregir problemas

en fases tempranas en las que es fácil cualquier cambio que en fases tardías, con el avión casi

terminado. Como se ha descrito en cuanto al A400M, en varias estaciones se ejecutan las

pruebas. Las ejecutadas en la FAL son las llamadas pruebas funcionales, pruebas de

funcionamiento de sistemas (a diferencia de, por ejemplo, pruebas a equipos en concreto,

realizadas por terceras partes).

El avión está compuesto por diversos sistemas. Cada sistema está identificado por un número

llamado ATA. Por ejemplo, el ATA 24 es el sistema eléctrico, el 32 es el tren de aterrizaje, el 33

es el sistema de luces, etc. La llamada “MAP” son los diseñadores de estos sistemas y cada ATA

tiene su propia MAP.

La MAP describe el conjunto de pruebas a realizar a un sistema o un conjunto de ellos dentro

de un ATA dentro de un documento llamado Ground Test Requirements (GTR). Este

documento está dividido en secciones y requerimientos identificados por un número, en el

que se especifica una lista de acciones y comprobaciones que hay que realizar. En caso de

problemas también especifican qué planos consultar y bajo qué modificaciones sobre el diseño

del avión (las llamadas MOD/MP) se puede ejecutar dichos requerimientos. Las hay de varios

tipos (diferenciados por un número) y concretamente las pruebas funcionales son de tipo 8.

Este documento no permite la ejecución de una prueba, ya que no está adaptado a los medios

existentes en la planta de ensamblaje ni a los técnicos que las ejecutarán. De ahí que se tenga

que hacer una edición de esas pruebas a partir del GTR. Esta edición es encargada en la FAL

por el departamento de Ingeniería de Sistemas de Avión (ISA) y a los documentos resultantes

de esta edición se les conocen como Ground Test Instructions (GTI). Una vez editada, en el

momento en que se vaya a ejecutar la prueba en un avión los técnicos de Producción usarán

este documento.

Tras la ejecución, es posible que se hayan encontrado problemas. Para que puedan ser

corregidos, se abren las llamadas HNCs (no conformidades), las cuales cada una abre un

procedimiento burocrático para su corrección. Esto es gestionado con una herramienta de

planificación de recursos empresariales, el SAP. Una vez corregidos los problemas

encontrados, se hace una particularización de la GTI para que sólo se ejecuten aquello que


queda por comprobar en una prueba. Esta particularización se la conoce como RTI (Repeated

Test Instructions).

3.3. El sistema CATS

3.3.1. ¿Qué es CATS? La edición de las GTIs se realizaba en papel hasta hace unos años en la factoría de San Pablo

Norte para los aviones C-295 y CN-235. Se pensó en mejoras para esta labor de edición (y

también para su ejecución), ya que un sistema más intuitivo, de rápida edición, con

herramientas para la visualización de datos de sensores, herramientas de base de datos del

avión, gestión de pruebas, etc. sería muy beneficioso.

El resultado de estas pretensiones es el llamado CATS, que son las siglas de Computer Aided

Test System (Sistema de pruebas asistido por ordenador). Este sistema consta de cuatro

módulos diferenciados, que pasaremos a describir brevemente.

3.3.2. Módulo de Edición Este es el módulo encargado de editar las pruebas. Para esta edición se creó un nuevo lenguaje

que facilitara esta tarea: el lenguaje ATVL (Aircraft Test Visual Language). Contiene

instrucciones para el manejo de variables de tipo señal (para la lectura de datos de avión

procedentes de equipos, sensores, etc.) y auxiliar; instrucciones para el control de flujo del

código (condicionales, manejo de bucles, etc.); edición de paneles visuales y componentes

gráficos integrados, como botones, marcadores, gráficas, leds, etc. para poder visualizar

información y presentar diferentes datos; herramientas para presentar los requerimientos de

la prueba a los técnicos e ir validando dichas operaciones…

La pantalla de la prueba que se presentará a los técnicos contiene dos partes: una parte

textual, donde a modo de textos se va indicando qué operaciones, comprobaciones,

informaciones y alertas tienen que tener en cuenta para los requerimientos de la prueba

(validándolos mediante un botón como veremos en otro módulo, el de Ejecución), y una parte

visual, con los componentes visuales que se han mencionado antes. La edición de

componentes visuales en este módulo está pensada para poderse hacer de forma gráfica sin

tener que editar el texto directamente en ATVL, seleccionando a través de una barra de

herramientas aquéllos que queremos colocar, editar sus propiedades, etc.

Además de componentes visuales, contiene diversos asistentes: insertar código ATVL

predeterminado, selección de variables de señal de una base de datos para insertarlas en el

código, un árbol con la lista de requerimientos editados hasta el momento en la prueba,

cuadro de propiedades de objetos, etc.


Las pruebas son editadas en un espacio reservado para cada usuario llamado Working Area a

modo de archivos temporales. Posteriormente, una vez que la prueba está editada, se procede

a un proceso de formalización de la prueba para que pueda ser ejecutada, insertando datos

sobre descripción de la prueba, código, estación donde se pueden ejecutar, archivos

adicionales, tiempo de ejecución de la prueba y medios de prueba necesarios.

Figura 5: Ventana principal del módulo de Edición del CATS

3.3.3. Módulo de ejecución Este es el módulo que los técnicos de prueba usarán para ejecutar las pruebas ya formalizadas.

Nada más iniciarse, se muestra una ventana con un listado de ATAs y dentro de este listado

una lista de pruebas pendientes de ser ejecutadas. Se muestra además cuadros donde pueden

verse el resto de pruebas y sus estados.

Una vez seleccionada una prueba y comenzada su ejecución, la prueba seguirá todo lo

especificado en el módulo de edición. Cada requerimiento se irá mostrando en pantalla, con

los pasos que deben seguir los técnicos en cuanto a acciones, comprobaciones, información

adicional y advertencias. En caso de que en algún momento haya algo que no se rige por lo

comandado por la prueba, mediante un botón Warning se puede establecer una incidencia no

abortiva en la prueba para que quede registrado. En caso de que se produjera una incidencia

que no permitiera la continuación de la prueba, se usaría el botón Incidence, escribiendo las

causas de la incidencia abortiva.

Una vez finalizada la ejecución de la prueba, la prueba generaría un archivo Report sobre datos

recogidos en la prueba e incidencias y pasaría a un cierto estado dependiendo de si hubo

incidencias o no. Si todo se resolvió sin problemas, la prueba estaría en estado successful, si


hubo alguna el estado sería Failed. Si hay incidencias, la prueba no puede volver a ser

ejecutada hasta que la incidencia no sea cerrada (a través de este módulo antes de comenzar

la prueba o usando el módulo de gestión) o bien se cree una RTI que soporte a esta prueba. En

estos casos la prueba pasaría a estado Enabled, apareciendo de nuevo en la lista de pruebas

pendientes de ser ejecutadas.

Figura 6: El módulo de Ejecución del CATS

3.3.4. Módulo de gestión Este es el módulo de consulta y modificación general de datos, con gran cantidad de

posibilidades que cada día van siendo incrementadas. De forma muy general, se puede

nombrar algunas:

Consulta de GTIs y RTIs y sus datos de formalización, permitiendo también la

modificación de algunos de esos datos.

Visualizado de todas las ejecuciones de las pruebas y sus estados.

Consulta de incidencias, gestión y cierre.

Establecimiento de aplicabilidad de pruebas.

Herramientas administrativas sobre operaciones en el avión, como SIs (Special

Instructions), Mod/Mp…

Base de datos de limitaciones de sistemas (llamadas GTLs) y creación de Mods

domésticas asociadas a dichas limitaciones.


Figura 7: Ventana para mostrar los detalles de una prueba en el módulo de Gestión del CATS

3.3.5. Módulo de análisis Este último módulo es el encargado del análisis de datos recogidos en algunas pruebas,

posibilitando su consulta, visualización usando herramientas para la generación de gráficas,

video, etc.

Figura 8: El módulo de Análisis de CATS


3.3.6. Acceso a CATS. Citrix En un principio, los módulos de CATS debían ir instalándose en cada computador que fuera a

usarse. Esto presentaba un inconveniente ya que las sucesivas actualizaciones del sistema

haría necesario una nueva reinstalación cada cierto tiempo y el número de computadores es

muy elevado en la factoría. Para la gestión de los permisos de entrada en cada módulo se

recurría a un quinto módulo, el de acceso.

Para solucionar el problema, se pensó en que los computadores se conectaran a un servidor de

aplicaciones que gestionaría los accesos y permitiera la ejecución de los diferentes módulos de

CATS. Cada usuario dispondría de una tarjeta de acceso con un certificado con unos ciertos

permisos en función del puesto y las necesidades de la empresa. Según esos permisos, se

permitiría el acceso a sólo algunos de esos módulos.

Esta es la solución adoptada hoy en día, utilizando el software servidor de aplicaciones Citrix

Metaframe para implementarlo. Citrix Metaframe permite publicar aplicaciones para que se

muestren y ejecuten desde máquinas remotas, por lo que las convierte en terminales.

3.4. Los AIMs y SEAS

3.4.1. ¿Qué es un AIM? A la hora de editar una prueba en CATS, para obtener datos del avión se recurren a las

variables de señal. Pueden ser de tipo analógico, digital e incluso cadenas de texto, tanto de

entrada como salida. En las versiones de los aviones C-295 y CN-235, la adquisición de datos se

hacía a través del mismo CATS, ya que los ordenadores donde estaban instalados tenían

además diferentes tarjetas para la adquisición de datos de diferentes tipos y CATS disponía de

drivers y mecanismos para la captura de esos datos.

En la versión del A400M, todo estos datos son sacados de una base de datos y como se ha

dicho guardados en variables disponibles para los editores de las pruebas. Para leer datos del

avión (y actuar también sobre él) disponemos de una herramienta hardware llamado AIM.

AIM son las siglas de Aircraft Interface Module. Externamente es un armario que consta de una

fuente de alimentación, tarjetas de adquisición de datos y actuadores, la CPU, un SAI y un

módulo con pantalla LCD, teclado y ratón. Además, en la parte superior se encuentra un

instrumento parecido a un semáforo (muy identificativo de los AIMs) con tres lámparas que

indican el estado de funcionamiento del AIM y un pulsador grande rojo para parada en caso de

emergencia.

Hay múltiples AIMs en cada estación de la FAL. Cada AIM recibe nombres diferentes según su

función dentro de la estación. Por ejemplo, el FuelAIM es el destinado a adquirir datos

provenientes de los sensores del sistema de combustible del avión y el ELEC-AIM, datos y

actuadores relacionados con el sistema eléctrico.

Cada AIM se conecta al avión (o a una parte de él, dependiendo de la estación en que se

encuentre) a través de una serie de mazos eléctricos. Estos mazos están divididos en dos

partes: una parte fija, que va desde el AIM a un panel fijo cerca del avión, que está siempre


presente sin necesidad de desinstalarlo; y una parte móvil, que es la que se conecta y

desconecta cuando llega un avión o parte del avión.

La CPU se trata de una tarjeta más de expansión del AIM. Consta en la mayoría de los AIMs de

un procesador Pentium Mobile, 1 Gb de RAM y de un disco duro de 2,5 pulgadas. Está

gobernado por un sistema operativo Windows de tecnología NT (en la mayoría, se trata de

Windows 2000 professional). Se puede acceder a él usando la pantalla y dispositivos de

entrada de los que dispone o a través de una sesión remota de VNC.

Algunos AIMs son un poco más especiales, ya que incluyen pantallas adicionales, antenas, etc.

dependiendo de la aplicación que tengan. Por otro lado, en caso de avería o algún tipo de

problema, la FAL está preparada para que en un tiempo muy reducido se pueda cambiar

alguna pieza o disponer de otro AIM.

Todos los AIMs disponen de al menos un interfaz Ethernet por el que se conectan a la red CATS

y permite que los datos capturados puedan estar disponible para el sistema de pruebas (y que

el sistema pueda actuar sobre el avión).

3.4.2. SEAS. Variables de señal. La información extraída por los AIMs y sus tarjetas de adquisición debe de ser procesada por

un software para que pueda estar disponible a las pruebas de CATS. Este software debe

capturar esos datos, guardarlos como variables de señal (configurándolas en esta misma

interfaz) y posteriormente guardarlos en una base de datos a la que también tendrá acceso

CATS para uso de las pruebas. También debe permitir lo contrario, es decir, leer los datos

colocados por las pruebas de CATS en esa base de datos para actuar en el avión vía hardware.

Y para manejar esas tarjetas de adquisición, debe tener drivers para ellas y permitir

configurarlas.

Este software se llama SEAS. Además de poder realizar todo lo indicado antes, posibilita la

inclusión de módulos software integrados en su entorno, que permite ejecución de código

necesario para manejar ciertos componentes hardware que podría tener el AIM (como es el

caso del control remoto que se hace de los breakers del avión en dos AIMs llamados PDMT-

AIM y CBS-AIM) o para la ejecución de un código más cercano a nivel hardware de lo que son

las pruebas en CATS (necesario en porciones de código más críticos a nivel de seguridad). Estos

módulos software con conocidos como “simulaciones”.

SEAS está siempre ejecutándose en segundo plano dentro del sistema Windows de los AIMs, a

modo de servicio del sistema operativo. Si se quiere configurar o gestionar algo, SEAS dispone

de una interfaz gráfica donde se pueden realizar todas las tareas vistas anteriormente, llamada

SEAS MasterGUI. Se compone principalmente de cuatro pestañas:

La primera se llama Seas Node Configuration y permite la configuración de las tarjetas

de adquisición, mostrando las que están instaladas en el AIM y posibilitando cambios

en ellas.

La segunda se llama Bench Node Configuration y define las variables que SEAS creará,

dándoles nombres, tipos de señal y otras configuraciones y agrupadas en los llamados

“equipments”. Todo esto se guarda en un archivo .xml. También está disponible un


botón llamado “Simulation Tools” que permite el acceso a varias ventanas necesarias

en el proceso de creación de una simulación, como más adelante se verá.

Figura 9: Página Bench Nose Configuration de SEAS

La tercera permite controlar la ejecución de las simulaciones y visualizar en pantalla los

valores de las señales.

Figura 10: Panel de variables con sus valores durante la ejecución de una simulación

La última es una página de análisis de tests, que no se usará.

3.5. Simulaciones Dentro de SEAS, se va profundizar en el tema de la creación y prueba de simulaciones. Se

definirá en primer lugar cuál es la estructura de una simulación, se continuará con el

procedimiento para crear una en SEAS y se finalizará con el testeo de las simulaciones.

3.5.1. Estructura de una simulación Una simulación es básicamente un módulo software integrado en SEAS que tiene una cierta

estructura igual para todas las simulaciones.


Para empezar, la forma de comunicación con el exterior se hace mediante las variables de

SEAS. Estas variables pueden ser de señal, ligadas al avión, o pueden ser nuevas variables

creadas específicamente para la simulación, llamadas en este caso variables “intersim”.

Cada simulación consta esencialmente de tres partes: una primera que se ejecuta una sola vez

una vez llamada a la simulación, conocida como INIT; la segunda se va ejecutando

periódicamente una vez tras otra, parte conocida como EXECUTE y la última que se ejecuta

una vez de desee finalizar la ejecución de la simulación, parte conocida como STOP.

Las simulaciones como base están programadas en el lenguaje ADA 95, lenguaje orientado a

objetos, concurrente y fuertemente tipado diseñado para entornos en los que se necesita una

gran seguridad y fiabilidad como la defensa o la aeronáutica. Sin embargo, aunque todas las

simulaciones tienen una parte escrita en ADA común, parte a la que se conoce como “cabecera

ADA”, el código de las simulaciones puede estar compilado en una DLL a partir del código de

otro lenguaje diferente. Como los lenguajes empleados en el grupo CATS son principalmente el

C y C++ esto supone una ventaja, ya que no obligaría al aprendizaje de un nuevo lenguaje para

comenzar a desarrollar simulaciones.

3.5.2. Desarrollo de una simulación Una simulación por tanto estará contenida dentro de una DLL con tres funciones relacionadas

con las tres partes de una simulación de la que se habló antes: una función Init, otra función

Execute y la última llamada Stop. Además de la DLL se necesitará la cabecera ADA y configurar

SEAS para que tenga en cuenta esta simulación, se creen las variables que la simulación usará,

etc. La cabecera ADA la generará automáticamente SEAS a partir de la configuración que se

establezca.

En la GUI de SEAS, se accederá en primer lugar a la página Bench Node Configuration. En esta

página se pueden ver cuatro columnas, cada una con un listado de archivos .xml. Para una

simulación se necesitará un archivo de cada una de estas columnas, bien creado nuevo o bien

usando uno existente. Sólo un archivo de cada columna está activo en SEAS. En la primera

columna se encuentran los archivos de definición de señales, en la segunda archivos de

escalado de señales, en la tercera columna archivos de señales de proceso y en la última

archivos de definición de bus. Además, hay un botón llamado Simulation tools con

herramientas para las simulaciones.

El archivo de definición de señales contendrá un listado de señales que la simulación podrá

usar si no han sido ya previamente definidos. SEAS incorpora un editor de estas señales en el

que se puede especificar todos los parámetros de esas señales, como el nombre, tipo, etc. Se

le puede asignar un archivo de escalado de señal, que puede crearse nuevo y aparecerá en la

segunda columna de la pantalla principal del Bench Node Configuration.

En el archivo de definición de proceso se puede crear una nueva simulación. Al añadir un

nuevo archivo a la lista de la tercera columna, se permite especificar el nombre de una nueva

simulación. A continuación se establece el llamado “simulation rate”, que es el intervalo de

tiempo en milisegundos en que la función Execute se ejecutará de forma continuada. Una vez

hecho esto, se pueden añadir las señales definidas anteriormente para que las pueda usar la

simulación.


La siguiente acción para integrar una simulación en SEAS es enlazar las señales con los

parámetros que se van a leer, cambiar y escribir la simulación. Esto se hará mediante el botón

mencionado antes, “Simulation tools”. Al pulsarlo aparece un menú con varias opciones: una

de ellas se llama “Link Between Simparam and Bench Node”. Aquí aparecerá el conjunto de

señales elegidas anteriormente. Se pueden seleccionar las que se desee y modificar el nombre

que aparecerá como parámetro en la cabecera ADA. Se pueden modificar otras atributos,

como el de establecer si se trata de una señal que la simulación lee o sobre la que escribe o

ambas cosas.

Mediante otra de las herramientas del botón Simulation tools se puede generar finalmente la

cabecera ADA, o código de interfaz entre las señales de SEAS y las variables de simulación. Esta

cabecera consta de varios archivos .adb y .ads (equivalentes en el lenguaje C a los .c y .f).

Dentro del archivo nombresimulacion_process.adb están las tres funciones necesarias de las

simulaciones. Se podría modificar este archivo escribiendo el código requerido directamente

en ADA, pero al usar DLLs hay que hacer un cierto interfaz de unión entre este archivo y otro

ADA que enlaza a la DLL. A este nuevo archivo ADA se le llamará Binding. Éste, mediante

órdenes Import, hará de enlace con las variables y funciones exportadas de la DLL. También

para hacer de enlace entre las variables de la simulación y las de SEAS se encuentra presente

otro archivo .adb llamado nombresimulacion_Interf.adb.

Una vez hechas las modificaciones, otras de las herramientas de Simulation tools es el

compilador de ADA, que es posible gracias a que SEAS contiene el entorno de desarrollo GNAT

PRO de ADA 95. En la ventana se puede elegir la simulación a compilar y establecer opciones

de compilación. En caso de error aparecería en el cuadro inferior. Si no hay problemas, la

simulación estaría lista para ser ejecutada.

3.5.3. Ejecución y testeo de una simulación A través de la página Test Exection de SEAS se puede ejecutar y probar una simulación. Para

ello, en esta página se ha de crear un nuevo test y asociarlo a los cuatro archivos .xml y a la

simulación. Una vez hecho, se pulsará el botón Connect y todo estará listo para la ejecución.

SEAS permite la edición de paneles en los que se insertarán variables de la simulación y podrán

visualizarse sus valores mientras la simulación se ejecuta. También controles para pasar el

estado de la simulación a Init, Run (en que se harán las llamadas a la función Execute) y Stop.

Aparte de las variables que se hayan establecido para la simulación, existen algunas de ellas

que son comunes a todas las simulaciones, como la variable del estado actual de la simulación,

una variable tipo cadena de texto con errores durante la ejecución y otra para mostrar la

prioridad de la simulación.

Desde CATS se podría ejecutar también una prueba para ir leyendo esos valores de las

variables y controlar la ejecución de la simulación. Para este caso deben estar dadas de alta las

variables en la base de datos de CATS.

3. simulaciones. descripción del entornobibing.us.es/proyectos/abreproy/11868/fichero... · 26...

Documents