DESARROLLO DE UN NODO DE
CONTROL PARA LA INTERACCIÓN CON
VEHÍCULOS Y EQUIPOS REMOTOS EN
MISIONES AEROESPACIALES C3-PUA.
AUTOR:
Santiago Felipe Arteaga Martín
ASESOR:
Ing. Sist. M. Sc. Ph. D.
Dario Ernesto Correal Torres
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN
BOGOTÁ D.C. COLOMBIA.
DESARROLLO DE UN NODO DE
CONTROL PARA LA INTERACCIÓN CON
VEHÍCULOS Y EQUIPOS REMOTOS EN
MISIONES AEROESPACIALES C3-PUA
AUTOR:
Santiago Felipe Arteaga Martín
ASESOR:
Ing. Sist. M. Sc. Ph. D.
Dario Ernesto Correal Torres
Proyecto de grado para optar por el titulo de Ingeniero de
Sistemas y Computación.
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN
BOGOTÁ D.C. COLOMBIA.
本
当
に
あ
り
が
と
う
、
母
上
さ
ま
。
産
ち
ゃ
ん
よ
り
AGRADECIMIENTOS
Este proyecto no podría haber culminado con éxito sin la guía, apoyo, conocimiento y esfuerzo de varias personas.
. Dario Ernesto Correal Torres. . Néstor Andreas Arteaga Martin.
. Juan Sebastian Urrego Escobar. . Rolando Andres Amarillo Perez. . Viviana Paola Salcedo Saavedra.
. Luis Carlos Longas Lalinde.
Índice general
1. Motivación 1
2. Objetivos 3
2.1. General . . . 3
2.2. Especícos . . . 3
3. Alcance 4 4. Antecedentes 5 4.1. Estado del arte . . . 5
4.1.1. En el mundo . . . 5
4.1.2. En la Universidad . . . 8
4.2. Marco Teórico . . . 10
4.2.1. Buenas Practicas . . . 10
4.2.2. Flexibilidad de Intra-misión e Inter-misión . . . 13
4.2.3. Control en Tiempo Real . . . 15
4.2.4. De Componentes a Agentes . . . 19
4.2.5. Eciencia y Robustez . . . 19
4.2.6. Requerimientos Arquitecturales . . . 22
4.2.7. Comunicación y Protocolo IP . . . 24
4.2.8. Organización y Control de Misión . . . 27
5. Diseño 32 5.1. Funcionalidades . . . 32
5.1.1. Interesados y Usuarios . . . 34
5.1.2. Restricciones . . . 34
5.1.3. Actores . . . 39
5.1.5. Historias de Usuario . . . 43
5.2. Calidad . . . 47
5.2.1. Árbol de Utilidad . . . 47
5.2.2. Escenarios Especícos . . . 52
5.2.3. Estrategias Propuestas . . . 56
5.3. Diagramas de Arquitectura . . . 57
5.3.1. Casos de Uso . . . 58
5.3.2. Despliegue . . . 60
5.3.3. Componentes . . . 62
5.3.4. Entidades . . . 62
5.3.5. Actividades . . . 63
5.3.6. Ejecución . . . 69
6. Implementación 73 6.1. Programación . . . 73
6.1.1. Uso de Diccionarios . . . 73
6.1.2. Traductor y Procesamiento . . . 74
6.1.3. Interfaz Graca . . . 75
6.1.4. Manejo de Threads . . . 76
6.1.5. Sockets de Comunicación . . . 78
6.2. Artefactos . . . 80
6.2.1. Archivos de Conguración . . . 80
6.2.2. Formatos de Comunicación . . . 82
6.3. Pruebas Funcionales . . . 82
6.3.1. Conguración de Parámetros de una Misión . . . 85
6.3.2. Ejecución de una Misión . . . 85
6.3.3. Consultar de la Información de una Misión . . . 87
7. Resultados 91 7.1. Implementación . . . 91
7.2. Validación Funcional . . . 98
7.2.1. Congurar Misión . . . 100
7.2.2. Ejecutar Misión . . . 104
7.2.3. Consultar Misión . . . 108
8. Conclusiones 111 8.1. Trabajo Futuro . . . 112
Appendices 119
A. Manual Arduino UNO 120
B. Manual Banco de Pruebas PUA 135
Índice de guras
4.1. Cambio en la tasa de retorno de información del telescopio Hubble [21]. . . 6 4.2. Ilustración básica de la distribución del C3 y su ejecución
den-tro de una misión aeroespacial [24]. . . 9 4.3. Arquitectura de cinco procesadores que provee funciones
par-ticionadas, una capa común de ejecución y un margen de cre-cimiento especíco, la partición del software en diferentes pro-cesadores mejora el desempeño, los márgenes de crecimiento y la prevención de fallas. [35]. . . 12 4.4. Designación de tipos de misión para el proyecto Apollo [21]. . 14 4.5. La plataforma está integrada por varios controladores
inde-pendientes interconectados mediante un bus. Cada CPU em-plea una arquitectura de 2 capas. La capa inferior se llama el sistema ejecutivo y controla los recursos de hardware, las apli-caciones y componentes, interactúa con el sistema de ejecución y las librerías de interfaz apropiadas [36]. . . 16 4.6. Diseño robusto tipo II: desarrollando una solución exible,
variaciones del parámetro de diseño µ_opt causa
variacio-nes grandes en el desempeño comparado con el parámetro de desempeño µ_robust [11]. . . 20
4.7. Fases de desarrollo y pilares asociados al programa aeroespa-cial de la NASA [11]. . . 22 4.8. Características arquitecturales según misiones especícas [16]. 23 4.9. Topología de la red para comunicación aeroespacial [10]. . . . 25 4.10. Esquema de acceso del canal con límite de bloques variables
[10]. . . 27 4.11. Tipos de arquitecturas de control [29]. . . 27 4.12. Tipos de arquitecturas de control [29]. . . 28
4.13. Arquitectura de control tipo Broker [29]. . . 29
4.14. Arquitectura de control tipo Matchmaking [29]. . . 29
4.15. Estructura de control holónica [29]. . . 30
5.1. Árbol de utilidad con atributos de calidad relevantes. . . 48
5.2. Árbol de utilidad con atributos de calidad calicados y prio-rizados. . . 49
5.3. Diagrama de casos de uso general para el C3-NC. . . 59
5.4. Diagrama de despliegue del C3-NC. . . 61
5.5. Diagrama de despliegue del C3-NC. . . 64
5.6. Diagrama de entidades del C3-NC. . . 65
5.7. Diagrama de actividad para congurar los parámetros de eje-cución de una misión del C3-NC. . . 66
5.8. Diagrama de actividad para la ejecución de una misión del C3-NC. . . 67
5.9. Diagrama de actividad para la consultar la información de una misión del C3-NC. . . 68
5.10. Diagrama de ejecución para el Thread de manejo información en modo lectura dentro una misión del C3-NC. . . 70
5.11. iagrama de ejecución para el Thread de manejo información en modo escritura dentro una misión del C3-NC. . . 71
5.12. Diagrama de ejecución para el Thread de manejo información en modo lectura-escritura dentro una misión del C3-NC. . . . 72
6.1. Interfaces principales implementadas para el Nodo de control. 77 6.2. Sección del archivo de conguración por defecto del Nodo de Control. . . 81
6.3. Sección del archivo de conguración para los Flags de los Ca-nales de trabajo del Nodo de Control. . . 82
6.4. Formato para trama de información telemétrica sistema C3. . 83
6.5. Formato para trama de información de estado sistema C3. . . 83
6.6. Formato para trama de información de control sistema C3. . . 84
6.7. Formato para trama de información multimedia sistema C3. . 84
6.8. Instrumento Virtual implementado en NI Labview (Interfaz). . 87
6.9. Instrumento Virtual implementado en NI Labview (Diagrama de Bloques). . . 88 6.10. Tarjeta de procesamiento de datos Arduino UNO. para el NC-C3 88
6.11. Conguración del servicio de base de datos no relacional db-mongo para el NC-C3. . . 90 6.12. Ejecución del servicio de base de datos no relacional dbmongo
para el NC-C3. . . 90 7.1. Registro visual la validación del Nodo de Control en las
insta-laciones de la universidad. . . 98 7.2. Registro visual la validación de la Plataforma de Control y
Core-C3 en las instalaciones de la universidad. . . 99 7.3. Registro visual del Nodo de Control en el campo de
experi-mentación para la conguración de la conexión satelital. . . . 99 7.4. Resultados de la creación de los archivos de conguración del
C3-NC. . . 100 7.5. Resultados del tiempo de conguración de una misión del
C3-NC. . . 101 7.6. Interfaz gráca del Nodo de Control implementada para el
Ciclo Uno. . . 102 7.7. Interfaz gráca del Nodo de Control implementada para el
Ciclo Dos. . . 103 7.8. Comparación entre los formatos de archivos de conguración
implementados del Ciclo Uno y Dos. . . 103 7.9. Resultados de la tasa de éxito de una misión ejecutada en el
C3-NC. . . 104 7.10. Resultados de la tasa de errores de una misión ejecutada en el
C3-NC. . . 105 7.11. Resultados del tiempo de procesamiento para una misión
eje-cutada en el C3-NC. . . 105 7.12. Resultados del tiempo de procesamiento según el número de
variables manejadas en el C3-NC. . . 106 7.13. Aplicación mongoVUE para la consulta de la información
per-sistente en la base de datos mongodb, perspectiva de texto. . . 109 7.14. Aplicación mongoVUE para la consulta de la información
per-sistente en la base de datos mongodb, perspectiva de tabla. . . 109 7.15. Aplicación mongoVUE para la consulta de la información
per-sistente en la base de datos mongodb, perspectiva de árbol. . . 110 7.16. Resultados de la tasa de persistencia de información durante
Índice de cuadros
4.1. Tiempos de envió y recepción de información en un IPC común
[36]. . . 18
5.1. Resumen de grupos interesados en el mundo de negocio del sistema. . . 35
5.2. Resumen de las expectativas de grupos interesados en el mun-do de negocio del sistema . . . 36
5.3. Especicación y resumen de la Restricción Arquitectural RA-01. 37 5.4. Especicación y resumen de la Restricción Arquitectural RA-02. 38 5.5. Especicación y resumen de la Restricción Arquitectural RA-03. 38 5.6. Especicación y resumen del Escenario Operacional EO-01. . . 40
5.7. Especicación y resumen del Escenario Operacional EO-02. . . 41
5.8. Especicación y resumen del Escenario Operacional EO-03. . . 42
5.9. Narrativa y especicación de Historias de Usuario Épicas para el Nodo de Control. . . 44
5.10. Narrativa y especicación de Historias de Usuario Misceláneas para el Nodo de Control. . . 46
5.11. Especicación del escenario de calidad ES-01. . . 53
5.12. Especicación del escenario de calidad ES-02. . . 53
5.13. Especicación del escenario de calidad ES-03. . . 54
5.14. Especicación del escenario de calidad ES-04. . . 54
5.15. Especicación del escenario de calidad ES-05. . . 55
5.16. Especicación del escenario de calidad ES-06. . . 55
5.17. Especicación del escenario de calidad ES-07. . . 56
7.1. Estado de las Historias de Usuario Épicas después de los Ciclos de Implementación. . . 93
7.2. Estado de las Historias de Usuario Misceláneas después de los Ciclos de Implementación. . . 97
C.1. Datos recuperados de las pruebas para los archivos de con-guraciones. . . 150 C.2. Datos recuperados de las pruebas del tiempo para la
congu-ración de archivos. . . 150 C.3. Datos recuperados sobre las pruebas de tasa éxito del
proce-samiento de información. . . 150 C.4. Datos recuperados sobre las pruebas de tiempo de
procesa-miento de la información. . . 151 C.5. Datos recuperados sobre las pruebas de tasa falla del
procesa-miento de información. . . 151 C.6. Datos recuperados sobre las pruebas de tiempo de
procesa-miento de las variables. . . 152 C.7. Datos recuperados sobre las pruebas de la tasa de persistencia
Bloques de Codigo
6.1. Ejemplo de manejo de diccionarios. . . 74
6.2. Ejemplo de traducción de tramas a formato canónico. . . 75
6.3. Ejemplo de código de las interfaces implementadas. . . 76
6.4. Ejemplo de Threads de bajo nivel. . . 78
Capítulo 1
Motivación
Hoy en día la exploración espacial provee a varias áreas del conoci-miento (ingenierías y ciencias) diversas oportunidades de investiga-ción, experimentación y de realización de retos únicos; el desarrollo y arquitectura de software es una de estas disciplinas [2]. Debido a que los lanzamientos, misiones y operaciones aeroespaciales de-ben soportados por distintos sistemas tecnológicos y procesos de información con requerimientos especializados y altos estándares de calidad [9], [3].
El Proyecto PUA (Proyecto Uniandino Aeroespacial) [20], fue una iniciativa estudiantil de pregrado en Ingeniería Mecánica que pre-tende abordar el tema de la exploración aeroespacial y abrir puer-tas hacia un área donde la Ingeniería Colombiana tenga un espacio de aprendizaje e innovación [6], [8]. Hasta ahora las misiones rea-lizadas han retornado resultados prometedores, pero a su vez han evidenciado nuevos retos y áreas de desarrollo inicialmente inex-ploradas dentro del proyecto [5], [37].
Necesidades tales como la sistematización de etapas de operación, tales como la ignición de motores en el lanzamiento, la adquisición en tiempo real de datos telemétricos para el cálculo y toma de decisiones conables, el control de vuelo y más, abren una gama de temas que requieren un análisis y respuesta a nivel tecnológico y cientíco distinto al inicialmente considerado [4], [7].
Dicho esto, se observa que PUA no obstante de ser iniciativa del programa de Ingeniería Mecánica de la Universidad de los An-des, presenta problemáticas de carácter informático y sistemático [11]. Retos tales como la sistematización de técnicas y procesos de trabajo [15], la automatización de toma de decisiones de ma-nera inteligente y eciente [17], [19], el análisis de grandes ujos de información, la coordinación y seguimiento de tareas críticas y peligrosas [14], La comunicación de nodos heterogéneos en una red de trabajo integrada [10], estos son algunos de los ejemplos de los retos que se pueden abordar y solucionar desde la perspectiva de la ingeniería de sistemas y computación [16].
Para dar solución a estos retos, el grupo MOOSAS lanzó el proyecto C3 (Centro de Comando y Control) [23] en el año 2012, el cual pretende proveer de una plataforma tecnológica capaz de soportar los procesos de investigación y experimentación que se realizan en el proyecto. El proyecto presentado en este documento, es un paso más en el proceso de desarrollar de un sistema capaz de soportar las misiones aeroespaciales dentro de la Universidad de los Andes [22], [24], [26], [25].
Capítulo 2
Objetivos
2.1. General
Desarrollar una aplicación intermediaria entre el sistema C3 y sis-temas informáticos o tecnológicos externos del proyecto PUA, tales como equipos informáticos de otras instituciones, distintos tipos de dispositivos de adquisición de datos para permitir el desarrollo de misiones aeroespaciales.
2.2. Especícos
Modelar el problema y el ambiente en el cual la aplicación pla-nea ejecutarse teniendo en cuenta las condiciones de trabajo real dentro de la investigación aeroespacial.
Implementar un prototipo funcional basado en las decisiones de diseño que solucionen la interpretación de formatos de in-formación y protocolos de misión PUA.
Diseñar, especicar y ejecutar experimentos tecnológicos va-liden la solución implementada con respecto a las funcionali-dades del sistema C3 y las misiones PUA.
Generar un documento de arquitectura que resuma los pasos y decisiones tomadas en la conceptualización, diseño, especi-cación, implementación y pruebas de la solución.
Capítulo 3
Alcance
Este proyecto pretende enfocarse en la dicultad de interpretar distintos dispositivos y sistemas de adquisición de datos que son desplegados en la zona de lanzamiento de los vehículos aeroespa-ciales con el n de recopilar y guardar la información relevante durante todo el lanzamiento y ejecución de las pruebas.
Para ello se pretende desarrollar un software que permita la tra-ducción de distintos formatos de adquisición de datos desarrollados dentro o fuera de la universidad de los Andes y la utilización de un formato único de transmisión de datos para el resto de los compo-nentes que conforman el C3 [23], [24], [26], [25]. Se prevé la necesi-dad de interpretar formatos propietarios de distintos proveedores como NI (National Instruments) y el uso de distintas tecnologías tales como Arduino y Labview [4], [7], además se deben tener en cuenta los protocolos desarrollados por los grupos de trabajo de los departamentos de ingeniería mecánica y electrónica [38], [22].
El principal propósito de la aplicación es ser capaz de congurarse e interpretar basado en por lo menos los protocolos, tecnologías y formatos ya conocidos por los grupos.
Capítulo 4
Antecedentes
4.1. Estado del arte
Esta sección presenta el conocimiento previo, conceptos relevantes y el avance de la comunidad con respecto a los temas anes al objetivo principal de proyecto dentro y fuera de la institución.
4.1.1. En el mundo
Para llevar a cabo las misiones aeroespaciales propuestas alrede-dor del mundo en las últimas décadas, la automatización de la ad-quisición y procesamiento de la información (sea de investigación, soporte, monitoreo o control) es un aspecto crítico de misión que comúnmente es manejado por un sistema complejo de información [2]; para solucionar la complejidad del trabajo la arquitectura de software identica las necesidad operacionales (requerimientos fun-cionales) y atributos de calidad (atributos no funfun-cionales) necesa-rios en un sistema de esta envergadura pueda responder y satisfacer a las necesidades de los usuarios [3], [13], [30].
Las soluciones actuales para el manejo de información en las dife-rentes etapas de la misiones aeroespaciales (pre-vuelo, vuelo y pos-vuelo) son sistemas que combinan equipos físicos en los vehículos y fuera de ellos como también diversos componentes lógicos im-plementados dentro de computadores y controladores electrónicos
[19], [17] generando así una gran heterogeneidad de elementos que deben interactuar y cooperar de manera precisa para cumplir con el propósito de la misión [21].
Figura 4.1: Cambio en la tasa de retorno de información del telescopio Hubble [21].
Una solución a este escenario, es el diseño, especicación y creación de arquitecturas especializadas y únicas para cada misión realizable dentro de la investigación espacial (Apolo, Mercury, Seneca, ect.) [7], [12], [13]. Esto es realizable solo en gran medida gracias a la dis-ponibilidad económica y laboral de gobiernos en ciertos momentos de la historia que estaban dispuestos a nanciar estos proyectos; sin embargo este enfoque tiene el inconveniente de la baja capaci-dad de reutilización, actualización y manutención de los distintos componentes (físicos o lógicos) debido a la alta especicidad y par-ticularidad de cada uno de los componentes que conforma el siste-ma, aumentando así los costos de operación y mantenimiento. Esto unido a los grandes requerimientos sobre los recursos disponibles
(sea monetario o capital humano) presionan a las organizaciones privadas o gubernamentales el iniciar un sistema nuevo casi desde cero al emprender algún tipo de misión aeroespacial [11], [13], [13].
Hoy en día, gracias el advenimiento de los componentes electróni-cos de relativo bajo electróni-costo, el aumento del ujo de información y la cantidad de datos a procesar en cada una de las misiones [21] (Ver Figura 4.1) y el interés del sector privado por el sector ae-roespacial, existen nuevos componentes desarrollados y utilizados en las misiones espaciales, algunos ejemplos son: son los paquetes de computación utilizados para el control de micro satélites o con-troladores de un vehículo espacial o de exploración planetaria no tripulado [31], [34], la reducción de costos, el aumento de la diversi-dad del ecosistema tecnológico y el aceleramiento del ciclo de vida de los proyectos son factores claves que alteran el enfoque con que se da solución al reto del sector aeroespacial [10], [11], [12], [13], [14].
Este nuevo enfoque, el cual se concentra en la reutilización y Man-tenibilidad de los elementos del sistema tiene el propósito de gene-rar un programa aeroespacial sostenible a largo plazo [21]. Y aun-que ayuda a minimiza costos y reduce el trabajo entre misiones, genera nuevos retos de diseño y operación, tales como el manejo de la heterogeneidad del sistema [13], una infraestructura de tele-comunicaciones conable y segura a largas distancias (ej.: hasta la luna, marte o más lejos) [10], [33], procedimientos y métodos de ga-rantizar la disponibilidad y operatividad del sistema con un mínimo riesgo a fallas, pues cualquier tipo de error llevaría a una perdida gigantesca de capital o pérdida de vidas humanas (operaciones de ayuda o reparación imposibles de ejecutar) [28],[27], por lo tanto los nuevos diseños ya no solo se enfocan en la reutilización y reducción de costos de las misiones sino también en la conabilidad y auto-nomía de los mismos, utilizando componentes redundantes, redes de control y monitoreo tanto internos como externos, algoritmos de toma de decisión, análisis de riesgos, algoritmos y estrategias de respuesta inteligentes, los cuales en conjunto permiten al sistema
reaccionar de manera rápida y ecaz frente a cualquier eventuali-dad que ponga en riesgo la misión o alguno de sus miembros [36], [9], [11], [12], [14], [16], [17].
La NASA y otras organizaciones gubernamentales en el mundo ofrecen asesoría y bases de datos conables sobre las técnicas, tec-nologías y métodos utilizados a lo largo de las misiones espaciales como también información sobre avances en el campo aeroespacial [17], [18], lo cual ofrece una ayuda para aquellas instituciones que deseen incursionar en el sector aeroespacial, sin embargo muchos aspectos técnicos especícos siguen siendo restringidos al público debido a contenido sensible y de importancia para la seguridad de países y entidades que los desarrollan [9], [2], [29].
4.1.2. En la Universidad
Dentro de la universidad de los Andes el proyecto C3 [23] fue lanza-do dentro del marco de un proyecto de gralanza-do asocialanza-do al Proyecto Uniandino Aeroespacial, PUA, el cual realizó una primera aproxi-mación a una arquitectura prototipo de un centro de comando y control o C3. El cual permite denir el sistema de manera rudi-mentaria segun la Figura 4.2).
La sección de principal o servidores C3 recibe la información del sistema y la despliega a diferentes controladores de misión en el Co-re central, el CoCo-re C3 funciona como distribuidor de información para invitados y otras entidades como también de centro de pro-cesamiento principal para la información proveniente de la misión [23], [25].
La siguiente sección es la plataforma en tierra o PT que se ubica en el sitio de lanzamiento y es usada como intermediara entre el C3 y los vehículos en vuelo, Su principal funcionalidad es la de monitorear, procesar y emitir al C3 la información recibida desde los demás puntos dentro de la zona de lanzamiento (C3 Móvil y PC) [24], [26].
Figura 4.2: Ilustración básica de la distribución del C3 y su ejecución dentro de una misión aeroespacial [24].
La tercera sección es el denominado PC o Plataforma de Control que tiene como papel principal traducir la información proveniente de los vehículos a través de las antenas de recepción ubicadas en la zona de lanzamiento y trasmitirlos a la PT [24].
Actualmente el Core C3 está en su segunda etapa de desarrollo, la primera etapa se enfocó en la denición de su arquitectura y la implementación de los procesos principales que permiten su fun-cionamiento, su segunda etapa se concentró en el mejoramiento del despliegue de información provisto por sus agentes de procesamien-to, llevándolo a un ambiente WEB y ampliando las funcionalidades de interfaz y manejo por parte de los usuarios [23], [25].
La PT por su parte está en una etapa de desarrollo en la cual toda-vía no posee interfaz gráca que le permita un uso fácil y sencillo dentro del campo de pruebas [24], para compensar este aspecto se creó el C3 móvil o C3M, el cual en un dispositivo con plataforma Android pretende mantener informado al personal desplegado en
del lanzamiento a los miembros del equipo [26].
Por su parte los PC poseen ciertas funcionalidades de procesamien-to. Las cuales solo les permiten interpretar un número limitado de dispositivos de adquisición de datos y ejecutarse con conguracio-nes limitadas mediante el uso de consola y archivos de conguración [24], es en esta aspecto del C3 que el presente proyecto de grado actual pretende enfocarse al generar una aplicación interactiva que le permita el personal desplegado en tierra trabajar de manera más cómoda sobre distintos dispositivos de adquisición de datos y aco-modarse a los distintos protocolos usados por los demás miembros del grupo [4], [7], [22]. Esta aplicación por lo tanto será denomina-da Nodo de Control o NC pues extenderá las funcionalidenomina-dades ya existentes del componente PC.
4.2. Marco Teórico
Esta sección resume los metodologías, teorías, consideraciones, as-pectos y demás conceptos relevantes para el desarrollo de una apli-cación o paquete computacional con un enfoque aeroespacial, pri-mero se describen los principios de diseño básico con ejemplos en la industria aeroespacial, y segundo resume los conceptos de diseño utilizados para llegar al producto nal.
4.2.1. Buenas Practicas
Dentro de la investigación aeronáutica algunas prácticas son co-múnmente utilizadas para proteger la integridad de la misión y de las personas que trabajan y están involucrados en ellas, entre ellas está la distribución de sistemas de apoyo y la redundancia de sistemas críticos como también el uso de múltiples procedimientos de activación y restauración de subsistemas y componentes (sean lógicos o físicos), también existen factores de seguridad en los dise-ños que sobredimensionan las necesidades operacionales para una mayor robustez y seguridad en el mismo.
Desde el punto de la ingeniería y arquitectura de software existen buenas prácticas para diseñar un sistema distribuido (dentro de un vehículo o entre muchas locaciones), algunas de estas son: (Ver Figura 4.3)
Partición de las funciones en una arquitectura de multiprocesador ej: vuelo, ciencia, datos, etc.) para distribuir el desempeño alocar márgenes de crecimiento y prevenir la expansión de errores [35].
Denir una capa de mundo o ejecución común para los multiprocesa-dores para permitir la reusabilidad y exibilidad del sistema [35]. Mantener la simplicidad de la arquitectura, con diseño controlado por tablas, comportamientos determinísticos e interfaces comunes y están-dares para permitir la vericabilidad y la predictibilidad del sistema [35].
Adoptar macro lenguajes de alto nivel para el personal en general con tablas, protocolos y variables de comando bien estructuradas para me-jorar la especicidad y vericabilidad del sistema [35].
Denir lazos simples de control determinísticos diseñados con una bue-na estructura de tareas (3 o 4 capas), rutas de alocución de recursos estáticas (sin uso de memoria dinámica o caminos repetibles) y tiem-pos predecibles (minimizando las interrupciones del procesador) para mejorar la legibilidad y vericabilidad del sistema [35].
Centralizar un sistema de autonomía y protección de fallas y distribuir la autonomía de bajo nivel y protección a los puntos apropiados de control para orquestar la conguración del sistema. Esto asegura un eciente aislamiento y respuesta, además que soporta la seguridad. [35]. Dedicar caminos para transito de datos a alta velocidad (como por ejemplo instrumentos de abordo con gran memoria de almacenamiento) para separar los proceso especializados y las fallas de los dispositivos y funcionalidades clave del sistema (diferencia entre carga útil y vehículo) [35].
Adoptar márgenes de crecimiento grandes (para procesadores, memo-ria, almacenamiento, buses, etc.) para acomodar planes de contingencia y cambios pos lanzamiento [35].
Figura 4.3: Arquitectura de cinco procesadores que provee funciones particio-nadas, una capa común de ejecución y un margen de crecimiento especíco, la partición del software en diferentes procesadores mejora el desempeño, los márgenes de crecimiento y la prevención de fallas. [35].
Otras recomendaciones a tener en cuenta para el modelamiento de estos sistemas son:
Identicar los requerimientos sistemáticamente desde el proyecto o sis-tema (en el espacio, lanzamiento, en tierra, etc.), modulo (nave, misión, plataforma, etc.) segmento (bus, software, controlador, etc.) subsiste-mas/construcciones, ensambles, etc. Para claricar la funcionalidad y seguimiento [35].
Identicar un número manejable de requerimientos guías claves"donde los claves indican un análisis top-Down del éxito de la misión y los guías los Bottom-up de las limitantes de diseño, analizar, priorizar y enfocar [35].
Denir desde la perspectiva del usuario "threads de misión"para enfo-car el modelo, la prueba de concepto, la construcción de prototipo y la validación [35].
Especicar la .abstracción de comandos"que dena primitivas de
recursos y postcondiciones que permitan un buen análisis y predicción de comportamientos [35].
Denir e implementar "puntos de control", como una secuencia de co-mandos serializada y explicita con graca de dependencia para lectura y escritura, ujo de información entre comandos y secuencias para así facilitar el análisis y aislamiento de fallas [35].
Construir dispositivos de auto-diagnostico y prueba, invariantes y re-dundancias en implementación que ayuden a procesar y aislar fallas [35].
Comparar ejecuciones de modelos de sistema e implementaciones de software automáticos mediante diferentes herramientas para mejorar la vericabilidad del mismo [35].
Aplicar tablas de ujo de trabajo, listas de chequeo, analizadores esta-dísticos, analizadores de causas (depuradores) e indicadores de métricas para mejorar la visibilidad, la repetitividad y la prevención contra fallas [35].
4.2.2. Flexibilidad de Intra-misión e Inter-misión
El concepto de exibilidad clásico para los sistemas aeroespaciales se enfoca en la capacidad de fácilmente modicar unos sistemas después que se ha desplegado en el campo respondiendo a los cam-bios de ambiente o a los camcam-bios de requerimientos [21].
La exibilidad intra-misión se utiliza para denir los cambios a los cuales se debe adaptar un sistema o misión en curso frente al cam-bio de escenario o requerimientos en el momento de cumplir con sus objetivos (ej: los robots exploradores de Marte) mantenien-do el marco temporal y las restricciones de recursos dadas en el lanzamiento de la misma [21].
Por su parte la exibilidad inter-misión hace referencia a la capa-cidad de los sistemas y equipos ya utilizados en una misión previa en ser modicados y desplegados en una nueva misión con un
míni-Figura 4.4: Designación de tipos de misión para el proyecto Apollo [21].
requerimientos (ej: las misiones Apollo y los transbordadores es-paciales) [21] permitiendo así la expansión de sus funcionalidades o el rehusó de las mismas para el futuro (ver Figura 4.4).
También cabe diferenciar dos tipos de exibilidad dentro de las ya mencionadas, la exibilidad de conguración, enfocada principal-mente a los equipos, dispositivos y hardware de las misiones y la exibilidad de no conguración que se reere a los componentes lógicos, código de computador y software instalado en los compu-tadores, equipos y hardware de una misión ya desplegada o en curso [21] lo cual puede permitir nuevas misiones o parámetros de misión de una manera más fácil que la reconguración completa del equi-po, o la utilización del equipo de una manera diferente. Por último la exibilidad de trayectoria está asociada más a como se dene el proyecto y la capacidad de utilizar lo ya realizado en respuesta a los ambientes políticos, económicos y tecnológicos externos aso-ciados al desarrollo de la misión (perdida de proveedor, cambio de gerencia, imposibilidad de reparación) [21].
Para concluir se resalta el uso de la modularidad en los distintos proyectos (Hubble, Mirk, transbordador, Apollo, etc.) en el diseño de software y hardware por igual, permitiendo una reconguración rápida y respuesta notablemente buena ante cambios no previstos (métricas utilizadas para este análisis también son diversas y en muchos casos únicas), sin embargo la dicultad de planear para lo imprevisto deja la difícil decisión en manos de los diseñadores para la utilización de la modularidad, la capacidad de recongu-ración (en hardware y software) y la aceptación del cambio en el transcurso del tiempo como elementos a tener en cuenta durante el desarrollo de una misión pero no como imperativos a cumplir cabalmente, pues se podría perder el objetivo del mismo.
4.2.3. Control en Tiempo Real
En décadas recientes la explosión de los recursos computacionales y la miniaturización de los componentes electrónicos han permitido la creación de máquinas más versátiles y poderosas que remplazan las tareas de muchas distintas maquinas más antiguas, el manejo, procesamiento y tiempo real ante el ambiente es esencial en distin-tos ámbidistin-tos, como la aviónica, procesos de producción en masa y telemetría medica [36].
El problema hoy en día radica en la integración de tantos nuevos sistemas y aplicaciones, la reusabilidad de los equipos ya en ope-ración (muchas veces es imposible cambiarlos) y la prevención de fallas. La reutilización de código de aplicaciones con mínimas mo-dicaciones es entonces lo deseable para mantener el costo de la aplicación debido a que reescritura esta muchas veces prohibida o es imposible, de la misma manera el compartir recursos compu-tacionales entre distintas aplicaciones es algo a tener en cuenta para asegurar la efectividad de la aplicación sistema en desarrollo [36].
Algunos ejemplos son los sistemas modulares integrados en avió-nica (IMA − Integrated Modular Avionics), los cuales pretenden
Figura 4.5: La plataforma está integrada por varios controladores indepen-dientes interconectados mediante un bus. Cada CPU emplea una arquitectura de 2 capas. La capa inferior se llama el sistema ejecutivo y controla los recur-sos de hardware, las aplicaciones y componentes, interactúa con el sistema de ejecución y las librerías de interfaz apropiadas [36].
componentes comunes lo cual reduce costos de desarrollo y manu-tención, otros ejemplo de sistemas integrados son el IHAS y el IECS (Integrated Hazard Avoidance System & Integrated Enviromental Control System respectivamente) [36].
La habilidad de poder crear y seguir utilizando sistemas bajo la pre-sencia de fallas de hardware, componentes o librerías que son de uso exclusivo de la aplicación individual.
Aumentar la reusabilidad de los módulos existentes que pueden ser creados por agentes heterogéneos externos para distintos propósitos. Mantener la simplicidad de la aplicación y reducir la necesidad de prue-bas del sistema completo cuando algún modulo es adicionado, mejorado o removido del sistema.
Esta arquitectura promueve en pocas palabras una fuerte partición del software, deniendo fronteras entre las diferentes aplicaciones
que previenen la alteración o intervención externa de otros mó-dulos. Impidiendo la propagación de errores y fallas por todo el sistema y aislando los componentes [36].
Rehuso de sistemas legados de control: la mayoría de los sistemas de control legado son diseñados sin pensar en su reusabilidad y adapta-bilidad a futuros requerimientos o sin utilizar interfaces estándares de comunicación con sistemas o componentes externos la creación de inter-mediarios para la integración a un sistema mayor es laboriosa y com-plicada, sin embargo indispensable para mantener los requerimientos funcionales en rango de aceptación [36].
Aislar las fallas de los controladores: de esta manera no afecten los otros controladores y el comportamiento del sistema en general es indispen-sable, esto se puede hacer mediante software o hardware, la imple-mentación de centinelas y la determinación de parámetros de trabajo normal, la comunicación debe ser independiente para que así el siste-ma no propague el error y se genere una falla en cascada, así que solo los componentes directamente relacionados con el controlador fallido deben saber de su estado [36].
La arquitectura tiene los siguientes componentes:
El sistema ejecutable: La parte baja de la arquitectura (System Execu-tive - SE) provee a cada módulo de aplicación una máquina virtual, protege la partición en la cual la aplicación puede ejecutarse de manera segura y con las condicionales de tiempo real [36].
La aplicación ejecutable: Cada aplicación ejecutable (Aplication execu-tive − AE) que consiste en múltiples tareas, asignación de memoria
por partición que previene la propagación de errores y permite al SE orquestar los recursos y solo se comunican mediante la librería de in-terfaz esta AE representa la capa superior de la arquitectura y permite la realización de las tareas especícas necesarias de la aplicación, pero nada que tenga que ver con el manejo de recursos, interrupciones o similares [36].
Las librerías de interfaz: El sistema operativo se usa de manera general con acceso privilegiado al hardware y dispositivos se crea la librería
de interfaces (Interface Library − IL) pues él SE necesita exportar e
importar las instrucciones e información a cada uno de los AE emulando de esta manera instrucciones privilegiadas, la IL encapsula todos estos servicio necesarios para soportar desde el sistema operativo todos los AE congurados [36].
Los controladores de dispositivos: Cada dispositivo requiere de un ma-nejo de entradas y salidas único debido a su diseño y manufactura especializada, por lo tanto, aunque las EA tienen internamente estos componentes, el SE requiere de estos recursos para poder validar, mo-nitorear y controlar los distintos dispositivos a su cargo y permitir la comunicación entre las particiones creadas [36].
Cuadro 4.1: Tiempos de envió y recepción de información en un IPC común [36].
Messege type/size 8 bytes 64 bytes 512 bytes Client-server IPC send 16.75 µs 35.375 µs 215.75 µs
Cliente-server IPC receive 18.625 µs 48.25µs 211.5 µs
Stream IPC send 14.125µs 31.875 µs 203.375 µs
Stream IPC receive 15.375µs 32.875 µs 214.25 µs
La integración en tiempo real propuesta de los módulos de control puede ayudar a disminuir el hardware, los costos y dispositivos físicos necesarios para la instrumentación y monitoreo de algún dispositivo generando unidades federadas que compartan recursos físicos, sin embargo se requiere una partición fuerte para poder soportar esto, que por su parte previene la propagación de error de los componentes y dispositivos en caso de falla o defecto, las dos capas de la arquitectura propuesta promueven una integra-ción general, rápida y sencilla de los sistemas legados a un sistema más grande, desacoplando en gran medida las aplicaciones de los módulos y componentes utilizados y disminuyendo el impacto en caso de remplazo, daño o cambio del dispositivo, también propone un sistema de comunicación entre aplicaciones mediante el bus de
conexión que requiere un mínimo soporte por parte del SE per-mitiendo un I/O de información robusto entre componentes, los resultados de los experimentos muestran un desempeño compara-ble al de utilizar Sistemas operativos centralizados directamente sobre los dispositivos [36]. (Ver Figura 4.1)
4.2.4. De Componentes a Agentes
Las tecnologías distribuidas están limitadas en términos de las ar-quitecturas que soportan, debido a la multiplicidad de plataformas, recursos, lenguajes de programación e implementaciones altamente distribuida todo el conjunto termina siendo un sistema altamente acoplado de objetos, métodos y codicación que requiere ser co-nocida con antelación y donde se conocen todos los estados nales del mismo [16].
Los nuevos retos de la exploración espacial implican un cambio en la planeación, diseño y construcción de sistemas complejos (dis-tribuidos o en plataforma) debido a la necesidad de automatiza-ción e independencia de los mismos, requiriendo sistemas y aplica-ciones congurables, arreglables, protectoras, auto-optimizadores, aparte de ser conscientes de sí mismas y el ambiente como también auto-monitoreadles y auto-ajustables. Para ello se propone una nueva denición denominada como agente, que en conjunto con la implementación de enjambres, inteligencias arti-ciales y algoritmos complejos, pueden llegar a una opción a largo plazo para el desarrollo de sistemas complejos de misión autónoma, exible y eciente [16].
4.2.5. Eciencia y Robustez
El diseño robusto por su parte es una metodología que responde al desempeño de productos sensibles a las variaciones de materias primas y procesos de manufacturas inventadas por el ingeniero Ge-nishi Tagushi en 1950 y plantea un análisis experimental ideal para el diseño. Por lo tanto productos hechos con diseños robustos fun-cionan bien y sin problema sin importar que sean hechos en
fábri-Figura 4.6: Diseño robusto tipo II: desarrollando una solución exible, va-riaciones del parámetro de diseño µ_opt causa variaciones grandes en el
desempeño comparado con el parámetro de desempeño µ_robust [11].
sistema, producto o componente es sobredimensionado de manera inteligente teniendo en cuenta unas variaciones de las condiciones de uso, el deterioro o variación de las condiciones con el uso a lo largo del tiempo y las variaciones de inherentes a la producción y manufactura [11].
En la Figura 4.6 se muestra el efecto de un diseño robusto enfoca-da a la exibilienfoca-dad de la solución, pues el concepto de del diseño robusto tipo II permite encontrar una solución exible reducien-do las variaciones en la respuesta si se altera la variable de diseño (método de Taguchi). Pues la exibilidad se vuelve un subproducto del enfoque robusto de la solución [11].
El control robusto ha sido diseñado por la ingeniería de control y electrónica enfocándose en el carácter real de los controladores y permitiéndole a los diseños ser utilizados dentro del mundo sin temor a fallas o errores internos por parte de los cambios exter-nos del ambiente, para ello el diseño debe incluir un sinnúmero de variables que incluyan cualquier fuente de ruido o interferen-cia en el desarrollo de las tareas del controlador, ser incluidas en el modelo matemático y por ultimo ser resuelto con estas variables in-cluidas, asegurando así que la respuesta del controlador no cambie
sin importar su operación. Esto implica tener en cuenta todo tipo de variables, atmosféricas, de posición, potencia, geográcas, tipos de actuadores, equipos utilizados, variaciones de voltaje, corriente, frecuencias de muestreo, fenómenos lineales, no lineales, aproxima-ciones, etc. Todo esto genera una respuesta uniforme e invariante frente a las interferencias que son denominadas mediante el nombre de control robusto [11].
La denición de exibilidad en el diseño robusto dene este concep-to como la capacidad de un sistema para responder efectivamente a cambios en los objetivos y requerimientos iniciales, todo en tér-minos de los atributos y capacidades iniciales de manera efectiva y económicamente viable [11].
La IEEE en su estándar 1233 de 1998 dene los requerimientos, las capacidades y los atributos como:
Un requerimiento es una condición o capacidad requerida por el usuario para resolver un problema o cumplir un objetivo [11].
Una condición o capacidad que debe ser cumplida o poseída por el sistema o algún componente del mismo que satisfaga un estándar, es-pecicación o restricción formalmente denida en un documento [11]. Un atributo es una representación de una condición o capacidad de-nida en los dos puntos anteriores [11].
Para cumplir con lo anterior la NASA ha implementado una meto-dología de desarrollo y análisis de sistemas están resumidos en la 4.7.
Por otra parte los sistemas de control robusto y los diseños robustos de sistemas computacionales, los cuales hacen parte del concepto general del diseño robusto (incluyendo el tipo II ilustrado anterior-mente) permiten tener una aproximación diferente al atributo de calidad de robustez y el subproducto de exibilidad [11].
Figura 4.7: Fases de desarrollo y pilares asociados al programa aeroespacial de la NASA [11].
4.2.6. Requerimientos Arquitecturales
las comunicaciones entre la torre de control y la misión en el espa-cio o n curso es importante debido al manejo en tiempo real de la información y el estatus de la misión, por lo tanto para diferentes misiones se requiere considerar diferentes características arquitec-turales que permitan la comunicación e interacción ecaz de los elementos involucrados [16].
La Figura 4.8 resume algunos de las características importantes de las arquitecturas implementadas según os objetivos de misión planteados por la NASA, para ello se tienen en cuenta lo siguiente:
Ambiente espacial: los componentes deben sobrevivir a una gran gamma de eventos que cambien el ambiente, errores, colisiones, cortos, descone-xiones, sobrecargas, etc. Los equipos capaces de lograr esto son costosos y limitados, así que esto limita su capacidad [16].
Recursos de vehículos: tamaño, peso y potencia (SWaP − Size, Weight
and Power) son recursos escasos en el espacio y de alta importancia, mantener estos recursos dentro de los parámetros de misión es esencial para la arquitectura de comunicación [16].
Figura 4.8: Características arquitecturales según misiones especícas [16].
Conabilidad y disponibilidad: los equipos en órbita o desplegados (ló-gicos y físicos) deben seguir altos estándares de conabilidad y dispo-nibilidad especialmente cuando se utiliza equipo sensible, costoso o se tiene una tripulación humana abordo [16].
Despliegue de onda estáticos: el despliegue y comunicación entre los equi-pos en órbita, tierra y espacio debe ser altamente predecible y controla-ble basado en una rigurosa experimentación y diseño de los componen-tes de misión asociados durante la fase de diseño e implementación. Lo cual permitirá una secuencia de comando solida desde cualquier punto del despliegue [16].
Tiempos largos de misión: las comunicaciones espaciales toman más tiem-po que las interplanetarias, su adquisición y conguración es más com-pleja, así que se debe aislar este componente para mantener el equipo lo más estático posible durante el ciclo de vida de la misión (no se permiten actualizaciones o reparaciones) [16].
Una arquitectura estándar de telecomunicaciones y sistemas de ra-dio ayuda a la NASA en reducir la dependencia de sistemas legados y actores externos, previniendo la implementación riesgosa de los SDR, proviniendo conabilidad, exibilidad y un sistema exten-sible que puede ser reprogramado con nuevo software a futuro y toma en cuenta posibles cambios económicos y políticos futuros, la
arquitectura abierta propuesta desacopla sistemas lógicos de com-ponentes físicos mediante interface4s estándares de comunicación aumentando la reusabilidad y minimizando el impacto por cambio de componentes obsoletos [16].
La arquitectura propuesta permite a la NASA lo siguientes:
Mantener el enfoque propietario de los diseños detrás de las interfaces. Reusar las arquitecturas desarrolladas en diferentes ambientes y por diferentes proveedores.
Preservar un marco común de diseño, desarrollo, pruebas y actividades de clasicación.
Proveer exibilidad a los distintos proveedores de radiocomunicaciones y la habilidad de ajustar los diseños a distintos parámetros de misión.
4.2.7. Comunicación y Protocolo IP
Dentro de las misiones aeroespaciales actualmente existe un cambio de paradigma en la transmisión de operaciones desde lo planeado a lo en demanda que soporten las topologías de nuevas redes median-te la implementación de nuevas median-tecnologías de acceso, esto debido a que existen limitantes de recursos computacionales, de potencia y límite de tiempo en que los vehículos pueden tener acceso a la red de información tierra (usualmente desde una única platafor-ma), esto hace que la distribución dinámica de recursos sea difícil y la cantidad de trabajo realizado tenga límites. Para ello se plan-tea el desarrollo de una infraestructura y arquitectura que soporte múltiples nodos de acceso en distintos momentos de ejecución de la misión [10].
Actualmente la alocación de ancho de banda se sigue basando en llamados programados durante ciertas posiciones en órbita, sin em-bargo existen las opciones de alocar dinámicamente este ancho de banda mediante una planeación a priori más pequeña o mediante el análisis de demanda en el instante, un protocolo de múltiples
puntos de acceso de este estilo debería satisfacer los siguientes re-querimientos:
Proveer, asegurar y garantizar diferentes clases de traco de informa-ción (TT&C, Datos cientícos, mensajes de prioridad, etc.) [10].
Soportar la conexión entre diferentes tipos de vehículos y estaciones en tierra [10].
Permitir la multiplicación de distintos tipos de información a bordo para distintos destinatarios (distintos tripulantes) [10].
Acomodar comandos de envió de peticiones a los distintos instrumentos del vehículo [10].
No imponer costos signicativos o complejidad en los equipos de abordo [10].
Figura 4.9: Topología de la red para comunicación aeroespacial [10].
Para poder cumplir con los requerimientos de los usuarios se de-be pasar de la estructura actual de la red de telecomunicaciones espaciales a una similar en principio a la red de telecomunicación móviles terrestre, actualmente los usuarios (naves, satélites y es-tación espacial) deben utilizar un acceso a los canales de
comuni-satélites LEO, quienes se encargan de retransmitir la información una única estación en tierra (TDRS/NCC) que a su vez solo pue-de enviar información a los usuarios en el momento en que este se ubique dentro del rango de visión (Ver Figura 4.9). La aloca-ción de recursos de la red es realizada mediante una conguraaloca-ción estática o basada en un análisis estadístico del uso del canal, con una limitada línea de visión de las estaciones en tierra y de los usuarios, el tiempo en que se puede realizar una transmisión de información eciente es reducido. Para mitigar esto los satélites LEO aumentan la cobertura de la red y permiten que un objeto en órbita realice transmisiones un 85 % del tiempo mediante servicios de banda S/Ku, sin embargo esta solución a la cobertura genera un
gran desaprovechamiento de los recursos y con la creciente deman-da en servicios de comunicación para objetos en órbita, el antiguo esquema de uso de telecomunicaciones aeroespaciales se ve incapaz de suplir la futura demanda [10].
Para solucionar esto se planea aumentar la cobertura mediante la colocación de más TDRS/NCC y más satélites LEO que permita tener a la red una cobertura cercana al 100 %. Ademas de esto se pretende generar un nuevo esquema y protocolos de uso del canal que soporten los QoS de las misiones aeroespaciales, tales como garantizar diferentes prioridades en el tráco, garantizar un míni-mo de tiempo con una conexión inhabilitada, manejo de cambio de posición y de orbita, pues inherentemente casi todos los elementos de la red están en movimiento o podrían cambiar su posición física dentro de la red, manejo de la gran cantidad de información y por último el manejo del alto retraso y la variabilidad del mismo que existe entre los distintos nodos de la red (orbita y tierra) [10].
Como parte de este manejo se pretende utilizar un canal con sec-ciones de transmisión jas y variables, es decir que el canal de comunicación tendrá secciones que garanticen un mínimo de infor-mación transmitida, tales como la posición y el ping/echo necesario para actualizar el estado de los nodos, a parte de esto, se manejara la información de control de cada nodo (telemetría del estado del satélite) con una capacidad asegurada para cada nodo, los cuales
Figura 4.10: Esquema de acceso del canal con límite de bloques variables [10].
serán de capacidad ja y soportaran el básico de información que se requiere para la ejecución de las misiones aeroespaciales, posterior a esta sección ja del canal esta la sección variable que acomodara su capacidad de acuerdo con la demanda de los nodos y la dispo-nibilidad de recursos de la red, lo cual generara retrasos más bajos y un mejor aprovechamiento del canal según se den las condicio-nes; lo importante de este esquema para su adecuada utilización es descubrir y optimizar las fronteras de las diferentes secciones del canal para asegurar una buena conectividad y calidad del servicio (Ver Figura 4.10) [10].
4.2.8. Organización y Control de Misión
El primer sistema de control a considerar se basa en una arquitec-tura completamente descentralizada conocida como heterárquica 4.11. Esta arquitectura aunque es considerada bastante robusta gracias a su falta de estructura, lo que permite que ésta sea to-lerable a falla y posea exibilidad ] de sus elementos; al mismo tiempo resulta en una arquitectura difícil de controlar y coordinar, generando comportamientos caóticos y no deseables [29].
Figura 4.12: Tipo de arquitecturas de control mediante facilitador.[29].
En segundo y tercer lugar, están los sistemas de control centrali-zado y de arquitectura jerárquica 4.11, los cual se basan en una descomposición top-down de tareas y divisiones. Al utilizar éste ti-po de sistemas se asegura un comti-portamiento deseado, sin embargo si un elemento intermediario es incapacitado (ó falla) el sistema se vuelve incontrolable. A comparación del primer sistema descrito, las arquitecturas jerárquicas y centralizadas poseen una estructu-ra rígida, lo que provoca un gestructu-rado de autonomía limitada de los elementos; adicionalmente, en caso de que sea necesario un cambio signicativo se deberá generar todo el sistema top-down de nuevo. Teniendo en cuentas estas dos arquitecturas se ha considerado un sistema de control intermediario utilizado particularmente en áreas de sistemas de control a gran escala, conocido como la arquitectura Federada [29].
Por último, una arquitectura federada se basa en una estructura en donde los mensajes se envían entre agentes y agentes medios (ó
agentes especializados) 4.11, por lo cual no existe una forma expli-cita de almacenar los datos. Son conocidas cinco formas de abarcar una arquitectura federada, la primer es a través de un facilitador el cual coordina grupos de controladores o agentes 4.12. Esta for-ma de comunicación permite que un agente se comunique con otro por medio de un facilitador y no directamente, permitiendo que el facilitador realice funcionalidades que involucran la traducción del mensaje, la descomposición de problemas y el manejo de sub-problemas [29].
Figura 4.13: Arquitectura de control tipo Broker [29].
Figura 4.14: Arquitectura de control tipo Matchmaking [29].
La siguiente forma de abarcar una arquitectura federada, se basa en un mediador, este mediador utiliza mecanismos de brokering y matchmaking para establecer subsistemas de agentes. Al estable-cer estos subsistemas o clusters de agentes, el mediador expande su rol para mediar comportamientos basados en políticas de alto nivel (Ver Figura 4.13 y 4.14). Por último se describe la arquitec-tura holónica, que al basarse en algunas ventajas de los sistemas
clásicos de multi-agente (MAS) e incorporar una estructura jerár-quica, la cual está orientada a solucionar metas, se convierte en una arquitectura híbrida robusta y fácilmente adaptable a cambios en recursos y metas. Similar al mediador, en una arquitectura ho-lónica se dene una capa mediadora o holoarquía, en la cual un agente de una capa actúa como mediador para agentes de capas inferiores. En general, una capa implementa una meta particular de modo que se descomponen controles complicados de gran escala en vario controles más sencillos; además, a medida que se tiene una capa superior se incrementa el nivel de abstracción del agente per-mitiendo que estas capas se enfoquen en retos a largo plazo [29].
Figura 4.15: Estructura de control holónica [29].
El acercamiento dado por la arquitectura holónica se basa en un concepto utilizado por Arthur Koestler para explicar complejos sis-temas biológicos y sociales a los cuales denominó holón (Ver Figura 4.15). Según Koestler un sistema holónico se basa en (1)la autono-mía sobre la cual un holón posee la capacidad de crear y controlar estrategias y/o planes, (2)la cooperación, (3) la auto-organización que es la habilidad de los holónes de agruparse entre ellos para lograr una meta del sistema completo, y (4) la recongurabilidad. Otro concepto importante dentro de esta arquitectura se basa en
la noción de descomposición funcional, es decir, la complejidad de sistemas dinámicos puede ser atacada por medio de la descomposi-ción del sistema en pequeñas partes, esto genera recursividad pues un holón puede contener a otros holónes [29].
En resumen, la holoarquía consiste en una arquitectura jerárquica con enlaces dinámicos lo que permite obtener las siguientes venta-jas:
1. Organización funcional, pues cada holón en una capa, actúa como un agente independiente en donde las responsabilidades son divididas y distribuidas en holónes de capas inferiores. Una vez un holón completa su responsabilidad, reporta los resultados a las jerarquías superiores [29].
2. Autonomía, esto involucra que la cooperación y coordinación entre los agentes no requiera un control centralizado pues cada agente actúa de manera autónoma para completar sus responsabilidades [29].
3. Recongurable, como se mencionó anteriormente la arquitectura con-siste en enlaces dinámicos en cada capa jerárquica conformando un sistema adaptable que evoluciones según la situación [29].
4. Eciencia, el hecho de que cada tarea o responsabilidad sea manejada de manera autónoma por los holónes admite que las entradas de un humano se enfoquen en decisiones de alto nivel [29].
5. Flexibilidad, ya que la arquitectura se adapta a la intervención humana sin interrumpir la operación autónoma de los holónes [29].
Todas estas ventajas identican a la arquitectura holónica como potencial para operaciones militares donde la naturaleza de eventos altamente dinámicos e impredecibles requiera de la intervención humana para controlar el sistema frente a cambios en las misiones. En síntesis, el principal benecio de un control holónico se centra en la habilidad de formar estructuras localizadas o holarquías que atiendan las necesidades que se presenten [29].
Capítulo 5
Diseño
Este capítulo detalla y explica el trabajo realizado en la etapa de di-seño de la aplicación para la culminación satisfactoria del proyecto y el alcance de los objetivos propuestos.
5.1. Funcionalidades
Para completar los objetivos planteados en este trabajo, se especi-can las funcionalidades principales requeridas por los usuarios e interesados de la aplicación, esta sección recopila y explica todos los aspectos generales de la especicación de funcionalidades del proyecto.
Inicialmente se propone una solución que pueda administrar múl-tiples tipos y fuentes de información, se reconocen estas fuentes como locales o remotas, las fuentes locales son todos los procesos o aplicaciones en el mismo nodo de ejecución que provean al NC de datos, por su parte las fuentes remotas son todas aquellas externas al nodo de ejecución del NC tales como cámaras IP, tarjetas de adquisición de datos, servidores y similares.
También como parte del diseño se identicaron cuatro tipos de in-formación consistentes y de uso común en los sistemas de comando y control aeroespacial, estos son la información telemétrica, la de estado, la de control y la audiovisual.
En primer lugar la información telemétrica se reere a la infor-mación relacionada con la misión a realizar y usualmente tiene un propósito misional, tal como: mapear el estado de una estre-lla o recopilar información del desempeño del motor-cohete, esta información puede tener un ujo de doble sentido, es decir que la información entrante al NC de una misión puede ser: presión de la cámara de combustión, estabilidad de vuelo del vehículo, tem-peratura de la atmosfera, entre muchas otras. Y la información saliente del NC puede ser ajuste de dirección en grados, punto focal del telescopio y similares. Segundo, la información de estado se reere a toda la información relacionada con el estado actual del NC, del vehículo o equipo que está ejecutando la misión, es-ta información puede ser porcenes-taje de recursos usados, energía disponible, entre muchos otros, y también puede tener un doble en el sentido en el momento que sea necesario orquestar distintos nodos de ejecución de la misión o múltiples equipos remotos de recolección de información telemétrica.
En tercer lugar está la información de control, la cual se utiliza para alterar los parámetros de operación de los nodos de ejecución del sistema C3 (tales como los NC, PT, Core, Instrumentación de abordo, etc.), esta información permite cambiar los parámetros y protocolos de procesamiento de la información telemétrica y per-mite poseer un control de alto nivel por parte de los usuarios y ajustar en ejecución distintos aspectos de los nodos de control que están realizando el trabajo, esta información también puede poseer un ujo de doble sentido en el momento de orquestar operaciones y misiones con equipos distribuidos.
Por ultimo esta la información multimedia, tal como audio y video proveniente de los periféricos habilitados de los nodos de ejecución o de los equipos remotos de recolección de información, esta divi-sión de la información se realiza debido a la diferencia que existe en el momento de procesar formatos de adquisición de datos te-lemétricos (usualmente texto plano) y la adquisición de video o audio (∗.mp4, ∗.avi, ∗.mp3, etc.) y se aísla este tipo de
telemetría y la información multimedia. El ujo de este tipo de información también puede ser en doble sentido pues puede faci-litar la comunicación entre personal separado geográcamente yo equipos de adquisición de datos remotos tales como telescopios.
Teniendo esto en cuenta y las necesidades de los miembros de in-vestigación de ingeniería mecánica se complementan y especican los escenarios operacionales del NC y se genera un grupo de casos de uso omplementarios.
5.1.1. Interesados y Usuarios
En esta sección se especican las fuerzas externas interesadas en el proyecto y su posible intervención en el desarrollo y resultado del mismo (Ver Tabla 5.1) y Tabla 5.2.
5.1.2. Restricciones
Las restricciones de la arquitectura a diseñar se clasican en dos, restricciones tecnológicas y de negocio, las primeras son denidas por la disponibilidad tecnológica o de conocimiento técnico (ej.: compiladores, especicaciones de equipos, lenguajes de programa-ción, etc.) y las segundas son denidas por el ambiente de negocio en el que se desenvuelve el grupo de trabajo del proyecto PUA (Ver Tablas 5.3, 5.4, 5.5).
Cuadro 5.1: Resumen de grupos interesados en el mundo de negocio del sistema.
Interesados Descripción
Depto. Ingeniería Mecánica
Entidad interna de la Universidad de los Andes, la cual desarrollo y avances en el ámbito aeroespacial, con lan-zamientos, experimentos y pruebas de campo con la ayu-da de entiayu-dades gubernamentales tales como la FAC y la Aerocivil. Actualmente desea aumentar la complejidad y alcance de sus proyectos y ha buscado ayuda especia-lizada en otros departamentos.
Depto. Ingeniería de Sistemas
Entidad interna de la Universidad de los Andes, la cual desarrolla sistemas informáticos de alto desempeño y disponibilidad, proponiendo arquitecturas y desarrollan-do paquetes computacionales para el Proyecto PUA y el Departamento de Ingeniería Mecánica.
Depto. Ingeniería Electrónica
Entidad interna de la Universidad de los Andes, que actualmente desarrolla dispositivo electrónico de toma de datos, procesamiento y comunicación de información telemétrica basado en los requerimientos del proyecto PUA y el departamento de Ingeniería Mecánica.
Sector privado
Distintas empresas del sector industrial colombiano que en algunas ocasiones donan su experticia, recursos y tiempo al proyecto de investigación aeroespacial (ta-les como: Grupo Linde Colombia, Randal, Indumil, BT Inc.).
Cuadro 5.2: Resumen de las expectativas de grupos interesados en el mundo de negocio del sistema
Interesados Expectativa
Depto. Ingeniería Mecánica
El Departamento espera completar experimentos, lan-zamientos de mayor envergadura y espera que los desa-rrollos realizados por los departamentos de Ingeniería de Sistemas y Electrónica le ayuden a cumplir con este ob-jetivo para seguir liderando la investigación aeroespacial a nivel nacional.
Depto. Ingeniería de Sistemas
El Departamento espera realizar con éxito distintas so-luciones computacionales para el procesamiento de in-formación experimental y de lanzamiento del proyecto PUA, de esta manera el Departamento ingresa a los ám-bitos aeroespaciales y lideraría la investigación a nivel nacional.
Depto. Ingeniería Electrónica
El Departamento espera realizar con éxito distintas so-luciones basado en dispositivos electrónicos para la re-colección de información experimental y de lanzamien-to del proyeclanzamien-to PUA, de esta manera el Departamenlanzamien-to ingresa a los ámbitos aeroespaciales y lideraría la inves-tigación a nivel nacional.
Sector privado
Distintas empresas del sector privado ven la investiga-ción aeroespacial como una oportunidad de distinguirse en el mercado y desean estar involucradas en el desarro-llo de misiones y experimentos del grupo PUA, pues esto les daría renombre y prestigio ante sus clientes regulares.
Cuadro 5.3: Especicación y resumen de la Restricción Arquitectural RA-01.
ID Nombre Tipo
RA-01 Instrumentación electrónica periférica tipo caja negra
• Tecnológica: X • De Negocio:
Descripción
Los periféricos de instrumentación y sensores están en constante cambio y avance de la tecnología, por esta razón la mayoría de las empresas de ins-trumentación construyen sus controladores e instrumentos de manera cerrada, convirtiéndolos en cajas negras heterogéneas. El sistema debe ser capaz de adaptarse a cualquiera de dichos dispositivos.
Alternativas
Existe la posibilidad de interactuar con otros proveedores de dispositivos elec-trónicos o desarrollar dispositivos propios elecelec-trónicos.
Observaciones Establecida Por
En esta ocasión el quipo PUA SA-TURN es el encargado de desarrollar los dispositivos electrónicos a bordo de los vehículos.
Depto. Ingeniería Mecánica y Depto. Ingeniería Electrónica.
Cuadro 5.4: Especicación y resumen de la Restricción Arquitectural RA-02.
ID Nombre Tipo
RA-02 Protocolo de comunicación con organizaciones externas
• Tecnológica: X • De Negocio:
Descripción
Las instituciones gubernamentales y privadas (Aerocivil, FAC, el IDEAM, Lin-de, Randal, BT, NI, y similares) proveen de servicios en tecnológicos que le permiten a los usuarios acceder a cierta información relevante dependiendo de su uso.
Alternativas
Ninguna alternativa en este aspecto.
Observaciones Establecida por
Los servicios tecnológicos de las diver-sas organizaciones están implementa-dos sobre algunos estándares y protoco-los, siguen siendo particulares de cada entidad.
Depto. Ingeniería Mecánica, Depto. In-geniería Electrónica y Sector Privado.
Cuadro 5.5: Especicación y resumen de la Restricción Arquitectural RA-03.
ID Nombre Tipo
RA-03 Tiempo de desarrollo de prototipo ••De Negocio:Tecnológica:
X
Descripción
El tiempo de desarrollo de un prototipo funcional está limitado a las 16 semanas ociales que tiene un semestre académico normal. También es necesaria una etapa de pruebas e integración con los otros componentes antes de la fecha de lanzamientos.
Alternativas
Ninguna alternativa en este aspecto.
Observaciones Establecida por
Se estima que la fecha de lanzamiento
5.1.3. Actores
Los actores son los posibles usuarios denidos que utilizaran los recursos del Nodo de Control para completar misiones aeroespa-ciales.
Director de Misión: Es el Líder de un equipo de investigación encargado de generar misiones relacionadas con su área de conocimiento y que contribuyan al cumplimiento de los objetivos del proyecto aeroespacial. Líder de Misión: Es el investigador encargado de desarrollar los objetivos de una misión especíca, responsable por la conabilidad de la misma y la seguridad del resto de los investigadores.
Líder de Equipo: Es el investigador encargado de desarrollar los objetivos de una misión y la coordinación de las actividades de varios investiga-dores.
Ingeniero Investigador: Es el investigador encargado de desarrollar los objetivos de una misión especíca.
5.1.4. Escenarios de operación
Todos los escenarios de operación tienen un identicador con códi-go y nombre, un Stakeholders asociado, descripción general, actores que intervienen en el proceso, visión y expectativa del actor sobre la actividad de la aplicación, estado y contexto en el que opera, las variables entradas necesarias para realizar la operación, las varia-bles de salida después de la operación y la respuesta del sistema (Ver Tablas 5.6, 5.7, 5.8). La siguiente lista enuncia en lenguaje natural los escenarios operacionales básicos de la aplicación.
