MATERIALS AND METHODS

Entonces tenem os que la coordinación y com unicación entre elem entos se hace de la siguiente form a:

1. Ent re SC: ut ilizando export areas

2. Ent re inst ruct or y el EH: ut ilizando la cola de event os.

3. EH y PS: ut ilizando una variable que indica el est ado general de la sim ulación

4. m aster TLS - TLS: m ecanism o de com unicación interproceso ( por ej em plo Sem áforos) .

Analizando el fluj o de cont rol, t enem os un m odelo Top- Down. Por ej em plo el TLS llam a al PS pero nunca al revés. La figura siguiente m uestra el fluj o de control durante un update periódico ( cada Subsystem controller es llam ado en paralelo, o sea representan varios procesos sim ultáneos) :

Figura 11 Flujo de Control Periódico

En la figura siguiente se m uestra el floj o de control en respuesta a un event o:

Figura 12 Flujo de Control por evento

En am bas figuras los TLS, PS y EH son instancias que corren en procesadores específicos.

4.3.5 -Uso del Modelo

Hasta aquí hem os descrito la arquitectura del sistem a, o sea un fram ework est ruct ural para el sim ulador, pero sin det alles funcionales. Es decir que la descripción del m odelo est ruct ural puede ut ilizarse para un helicóptero com o para un reactor nuclear.

El próxim o paso es darle funcionalidad a la arquit ect ura con subsistem as apropiados para cada tarea. Tenem os la arquitectura definida por 6 m ódulos: Com ponente, SC, TLS, PS, EH y Surrogat e. Est o hace una estructura com parativam ente sim ple de construir, com prender, integrar, am pliar y m odificar.

Para definir la funcionalidad y los elem ent os int ervinient es, se com ienza definiendo instancias de los SC de form a de detallar las part icularidades de la aeronave a sim ular. La part ición se hace acorde a los sistem as y com plej idad de la aeronave com o tam bién de los tipos de entrenam iento para los cuales se diseña el sim ulador. Por ej em plo típicam ente se com ienza form ando grupos, que típicam ente serán:

• Cinem át ica: elem entos que tratan con fuerzas ej ercidas sobre la

aeronave.

• Sist em as del Avión: partes realacionadas con sistem a com unes

que proveen a la aeronave de potencia o que distribuyen la energia dentro de la estructura.

• Aviónica: Cosas que proveen algún tipo de soporte a la aeronave pero no tienen que ver con la cinem ática, el control o la operación de un sistem a básico de vuelo ( ej em plo: radios) .

• Am bient e: cosas asociadas con el am biente en el cual el

vehículo opera.

Luego esos grupos se dividen en sistem as y estos en Subsistem as. Com o se puede deducir, los grupos y sistem as no se refelj an directam ente en la arquit ect ura – no hay un cont rolador de grupo – y existen para organizar la funcionalidad asignada a las varias inst ancias de los SC.

Luego part icionar los m odelos m at em áticos y físicos ( aerodinám ica) es m ucho m ás dificult oso que part icionar la est ruct ura física de la aeronave.

Entonces se dividen los grupos en sistem as, que es una solución autocontenida a problem as de sim ulación. Estos generalm ente se reflej an com o m ódulos de código im plem entados por un grupo de ingenieros. Entonces tom ando el grupo cinem ática, tendrem os los elem entos relacionados al cont rol del m ovim ient o del vehículo y la int eracción del vehículo con sus superficies de control con el am bient e. Los sistem as serían:

• Est ruct ura • Propulsión

• Tren de aterrizaj e • Cont roles de Vuelo

El paso siguiente sería tom ar cada sistem a y obtener los subsistem as correspondientes. Por ej em plo el sistem a de propulsión tratará con los m otores de la aeronave. Estos m otores serán m anej ados creando m últiples conj untos de variables de estado e instancias a obj etos que perm it an calcular los m om entos de rotación del m otor; fuerzas y m om entos causados por la distribución de la m asa de com bustible, etc. El subsistem a de com bustible se ubica aquí porque su interfaz prim aria es con los m otores y se encarga de calcular las fuerzas actuantes en la estructura proveniente del m ovim iento de com bustible dentro de los tanques, com o t am bién del efect o gravit acional de la m asa del com bustible.

Hast a aquí hem os ident ificado la división de funcionalidad, la ubicación de los subsistem as y SC, y las conexiones entre subsistem as. Para com pletar la arquitectura necesitam os lo siguiente:

• De la m ism a form a descom poner en otros grupos, sus sistem as y subsistem as.

4 .4 - DARTS

4.4.1 -Antecedentes y Contexto

I ndependiente al desarrollo del AVSM, Boeing desarrollaba el proyecto de sim ulador m odular denom inado Mod Sim . Con este antecedente y la influencia del AVSM, desarrollaron la denom inada Dom ain Archit ect ure for Reuse in Training System s ( DARTS) com o un esfuerzo de invest igación y desarrollo int erno, la cual fue ut ilizada en el program a Soft ware Technology for Adaptable, Reliable System s ( STARS) del Departm ent of Defense Advance Research Proj ect s Agency ( ARPA) .

En resum en, Boeing int ent ó unir el reuso de St ruct ural Modelling ( en particular del AVSM) y la experiencia obtenida en Mod Sim .

Figura 13 DARTS

La característica de DARTS es que representa un sim ulador genérico que puede ser adaptado a cualquier sim ulador present e o fut uro, t al cual lo ha dem ostrado en la práctica [ CRI 93] .

DARTS ha sido aplicado en el T- 34C Flight I nstrum ent Trainer y se encuentra relacionado con la teoría denom inada Megaprogram m ing que se

define com o “ la práctica de construir y evolucionar software de com putadora com ponente por com ponente” .

4.4.2 -Descripción

DARTS aplica el AVSM dentro de cada m ódulo y segm ento. Aquí, un m ódulo es un sistem a com putacional que tiene un Executive, el cual contiene todas las funciones de interrupciones, suspensión de tareas, etc. Estos se encargan de ej ecutar a los segm ent Executives.

En DARTS el Air Vehicle System , se encuentra dividido en 125 funciones, o áreas de capacidad. A su vez se encuentra dividido en doce segm entos y cada función de las anteriores es asignada a un segm ento. Por lo t anto gráficam ente se tiene:

Figura 14 Segmentos en DARTS

Cada segm ento se caracteriza por coherencia interna y poco acoplam iento externo, o sea las funciones en un segm ento se relacionan por fluj o de datos, orden de ej ecución o dependencia. Los segm entos tienen interfaces definidas y son las únicas que perm iten com unicación entre segm entos.

Entonces tenem os que el m odelo en DART está form ado por 5 com ponentes: Virtual Network ( VNET) , Module Execut ive( s) , Segm ent Execut ive, Subsyst em Cont rollers y Com ponentes. En general entonces tenem os:

Propulsión NAV/ Com m Cont roles de Vuelo Dinám ica del Vuelo Estación de Vuelo Am biente Cont rol de E/ S Sistem a Visual Radar Elect rónica Arm as Sistem as Físicos V N E T

Figura 15 Estructura de DARTS

Al igual que AVSM los com ponentes obtienen sus datos a través de llam adas a funciones en vez de leerlos desde m em oria com partida. Esto dism inuye la dependencia entre obj etos y hace m ás fácil el reuso. Cada m ensaj e se define com o un tipo de Ada y se agrupan en paquetes en concordancia al segm ento que puede em it ir ese m ensaj e. Adem ás, se definen los recept ores y em isores legales para un m ensaj e, de form a que ningún otro segm ento pueda em itir o recibir ese tipo de m ensaj es. Todos los segm ent execut ive se com unican ut ilizando la VNET, lo que hace que los elem ent os inferiores sean m ás reut ilizables.

La diferencia en el SC en DART es que los datos entre Subsistem as son t ransm it idos a t ravés de una VNET que posee la int eligencia suficient e para proveer servicios de form a tal que el com ponente que se trate no necesita conocer sobre le hardware en que corre.

Otra diferencia es el segm ent executive que agrupa com ponentes y subsistem as en com ún, generalm ente referidos a com ponentes que poseen m ucho intercam bio de datos entre ellos. Los segm ent executives se com unican ent re ellos ut ilizando la VNET, ya que es el m edio para com unicarse con otros com ponentes y subsistem as localizados en otros segm entos.

El Module executive es responsable de asignar recursos y com unicación entre procesadores. Su ej ecución puede ser por llam ada a funciones o activando procesos en pausa, dependiendo de la im plem entación.

Los applicat ion services se ocupan de los det alles de im plem ent ación ya que por ej em plo oculta detalles tales com o si la com unicación se realiza ut ilizando m em oria com part ida, una red Et hernet , et c.

Modulo Segm ento

Subsistem a Com ponent e

4.4.3 -VNET (Virtual Network)

Este com ponente ha sido incorporado por DARTS y es la m ayor diferencia con AVSM. Representa la estructura de com unicaciones entre segm entos. Se definen m ensaj es ( est ruct uras ADA) , y una t abla de receptores y em isores para ese m ensaj e.

VNET provee la int erfaz de com unicación, ocultando la im plem entación para la t ransm isión de m ensaj es, haciendo este m ecanism o independiente de la plataform a.

Com o se m enciona en [ CRI SPEN01] esta aproxim ación posee m uchas ventaj as com probadas, m ientras que la única obj eción es la perform ance frente a m em oria com partida, situación que, a m edida que crece el poder de procesam iento se hace m enos evidente.

4.4.4 -Module Executive

Un m ódulo es un sistem a com putacional con sus dispositivos asociados o bien un procesador en un sistem a m ult iprocesador. Su propósit o es ej ecutar los elem entos de m enor nivel.

Los m odule executives causan que se ej ecuten los segm ent executives, lo cual puede realizarse com o llam adas a subprogram as o bien tareas independient es, y la com unicación consist e sim plem ent e en pasar los pulsos de reloj .

4.4.5 -Segment Executive

I m plican un grupo funcional, ya que entre los com ponentes hay m ucho intercam bio de datos u orden de dependencias. Son responsables de la com unicación sobre VNET y se encargan de llam ar las ent radas de los SC ant e eventos aperiódicos. La diferencia entre DARTS y AVSM es que las funciones com o cam bio de m odo o bien fallas, se m anej an com o m ensaj es com unes procesado por el segm ent executive ( no hay event handler com o en AVSM) .

4.4.6 -Subsystem Controller

Están im plem entados com o en el AVSM. La diferencia radia en que en AVSM los datos salen del subsistem a utilizando áreas de m em oria com partida, m ientas que en DARTS, el segm ent executive provee al SC con datos y construye los m ensaj es para enviarlos a la VNET. Toda la com unicación entre

subsist em as t om a lugar ut ilizando buffers que m ant iene el segm ent executive.

El m ét odo init alize de cada com ponente provee los datos de entrada y salida, por lo cual, una vez ej ecutada puede ej ecutarse sin error aunque no haya datos provenientes de la VNET. Esto evita el problem a sobre los com ponentes o subsistem as que necesitan ej ecutarse antes que otros para evitar que datos erróneos se procesen. VNET provee inform ación en la función im port para determ inar si se han recibido datos desde la últim a it eración. DARTS copia los dat os al buffer sólo cuando dat os nuevos han sido recibidos.

4.4.7 - Component

Al igual que en AVSM, es el m enor elem ento estructural y se encuentra im plem entado de la m ism a form a, representando un elem ento físico de la aeronave o bien presiones, fluj os, etc. Por lo tanto cada com ponente puede com put ar su est ado de m anera abst ract a y por lo t ant o reut ilizable.

4 .5 - Ot ras I m plem ent aciones

SAAB posee varios sim uladores desarrollados im plem entando AVSM los cuales aplican variaciones al m odelo acorde a las necesidades particulares del caso, los cuales se describirán brevem ente a continuación.

4.5.1 -PMSIM

Se ut iliza para el desarrollo de sist em as de cont rol de vuelo; est udio de interface Hom bre- Maquina; sensores de vuelo y sistem as de arm as. Todos los sistem as son sim ulados por software.

Aquí la frecuencia que ut iliza el Execut ive se obt iene de un circuit o externo de reloj .

El Executive corre a una frecuencia de 60 HZ provenientes de hardware real de la aeronave, que se usa para sincronizar el m odelo de software con el de hardware. En realidad posee varios schedulers a 1, 7.5, 5, 15, 30 y 60 HZ que conocen el orden de ej ecución de sus m odelos, lo que asegura que cada m odelo se ej ecuta con el input correcto. Aquí se encuentra uno de los problem as de est as im plem ent aciones: ut ilizan m em oria

com partida para transm it ir datos entre los m odelos, lo cual no garant iza que cada m odelo est e ut ilizando los dat os correct os.

Figura 16 Estructura de PMSIM

4.5.2 -SYSIM

Se ut iliza para el desarrollo de incluyendo el hardware y soft ware que irá en la aeronave. En esta im plem entación tenem os una m ezcla de sistem as reales ( hardware real) y sistem as sim ulados por software. El uso de sistem as reales se vuelve m andataria cuando los m odelos de software no pueden reproducir las condiciones de tiem po necesarias.

4.5.3 -FMS (Full Mission Simulator) y MMT (Multi Mission Trainer)

Se ut ilizan para el ent renam ient o de pilot os. En est e caso const an de varios com putadoras/ procesadores com unicados por m em oria com partida y red ethernet para la consola del instructor.

Básicam ente la sincronización de datos se realiza por las etapas que contiene un ciclo de ej ecución. En la et apa export se escriben los datos, que interesan a los otros procesadores, en la m em oria global. Update procesa y escribe los datos en la m em oria local de cada procesador y Event es donde se verifica si existen eventos pendientes de ser procesados.

Figura 17 Estructura de FMS/MMT

4 .6 - Enfoque Orient ado a Obj et os

Com o se referencia en [ CRI 93] y com o se ha graficado para algunos casos en la presentación de AVSM, los com ponentes de DARTS pueden asim ilarse com o obj et os, pero com o se basa en una descom posición funcional, ocasionalm ente un com ponente es dividido en varios segm entos. Por ej em plo tenem os la bom ba de com bustible en el subsistem a Propulsión, pero para producir el sonido de la bom ba de com bustible se tiene un com ponente en el subsist em a de Audio. Por ello los creadores de DARTS han preferido ut ilizar el term ino Obj ect Abstracted Design.

Generalizando, el m odelo estructural reconoce la exist encia de obj et os, evidenciado principalm ent e en los com ponentes, pero no ha sido desarrollado ut ilizando Análisis Orient ado a Obj et os.

Para recalcar las sim ilit udes del m odelo est ruct ural con el Análisis Orientado a Obj etos, podem os m encionar que es un proceso de desarrollo iterativo e increm ental, en el cual se hace uso de la abstracción, encapsulación, m odularidad y tipos organizados en j erarquías, existiendo una correspondencia entre clases y t ipos est ruct urales.

Com o m encionam os en su m om ento, el m odelo estructural ha sido desarrollado en el contexto de Ada com o lenguaj e de im plem entación, por lo cual tiene la característica de Ada que, por lo m enos hasta ese m om ento, está basado en obj etos pero no orientado a obj etos ( la diferencia radica en el soporte de herencia) . Por otra parte en vez de tener clases abstractas, posee t ipos est ruct urales y las no exist en com o tales clases concretas que podrían capturar las propiedades com unes a los grupos de com ponentes sim ilares.

El m odelo estructural ha dem ostrado sus ventaj as y es por eso que el obj etivo de esta tesis es m antener estos beneficios pero agregando las cualidades del Análisis Orient ado a Obj et os y poder ext raer Pat rones de Diseño para docum entar el conocim iento contenido en estas soluciones de diseño. Adem ás la aplicación de Pat rones de Diseño existentes para m ej orar la est ruct ura y la reut ilización basada en soluciones probadas.

A prim era vist a los beneficios inm ediat os de ut ilizar Análisis Orient ado a Obj etos es que el polim orfism o perm it e refinar los m étodos heredados y el código cliente actúa sobre una colección de obj etos heterogéneos com o una colección de la clase base. Esto se evidencia sobre todo en la diferencia que los lenguaj es procedurales tratan los datos y funciones por separado, form ando un program a que debe tener estructurado de antem ano, cuales funciones actúan sobre que dat o y cuándo. Por lo t ant o t ienen un t ipo fij o de vehículo, en el cual se cam biarán las tablas u otros com ponentes cada vez que se quiera sim ular otro m odelo de aeronave. Con el m odelo Orientado a Obj et os se podría explot ar las funcionalidades com unes perm it iendo un m ayor reuso.

4 .7 - LaSRS+ +

Antes de continuar, harem os una breve descripción sobre Langley St andard Real- Tim e Sim ulat ion in C+ + ( LaSRS+ + ) fram ework, que es un antecedente que debe ser m encionado al trabaj ar sobre este enfoque orientado a obj etos.

LaSRS+ + , no se encuentra basado en el m odelo estructural, sino que surge com o un esfuerzo realizado en 1995 para m igrar el LaRC ( real- tim e sim ulat ion environm ent ) realizado en lenguaj e FORTRAN procedural estructurado en m ás de seis repositorios para realizar tipos específicos de invest igación ut ilizando diferent es cabinas de sim ulación.

Algunas de las m otivaciones para el cam bio a C+ + fueron, la com plej idad de la curva de aprendizaj e entre proyectos; dificultad de balancear la carga de trabaj o entre equipos de desarrollo; problem as de m odificación y pruebas para pasar una aeronave de un repositorio a otro y sólo se podía sim ular un vehículo por vez ( no era m ult i- vehículo) .

Ut ilizando los concept os de abst racción, Encapsulación, herencia y polim orfism o provistos por la tecnología Orientada a Obj etos se obtuvo el siguiente fram ework:

Figura 18 Modelo Conceptual de LaSRS++

Todas las aeronaves derivan de un conj unto de clases abstractas que proveen la interface del fram ework:

Figura 19 Vista de Nivel Superior del Framework

Las funciones de cada una de estas clases son:

• Sim ulat ion: Provee una interface abstracta para perm itir a la