Operaciones de la misión CCSDS

El Grupo de Trabajo de Monitoreo y Control de Naves Espaciales ( SM&C ) del Comité Consultivo para Sistemas de Datos Espaciales (CCSDS), que cuenta con la participación activa de las principales agencias http://www.space.bas.bg/bg/procurement/files/pravilnik%20OP.PDF , está definiendo una arquitectura orientada a servicios que consiste en un conjunto de servicios estándar de extremo a extremo entre funciones residentes a bordo de una nave espacial o basadas en tierra, que son responsables de las operaciones de la misión.

Existe una tendencia general hacia una mayor complejidad de las misiones, al mismo tiempo que aumenta la presión para reducir el costo de las operaciones, tanto en términos de despliegue inicial como de gastos recurrentes. Las arquitecturas de sistemas de operaciones de misión cerradas o «monolíticas» no permiten la redistribución de funcionalidades entre el espacio y la tierra, ni entre los nodos del sistema terrestre. Esta falta de apertura arquitectónica conlleva a:

• falta de interoperabilidad entre agencias;
• falta de reutilización entre misiones y sistemas terrestres;
• Aumento del coste de desarrollo e implementación específicos para cada misión;
• falta de disponibilidad de herramientas genéricas comerciales;
• Incapacidad para reemplazar la tecnología de implementación sin un rediseño importante del sistema;
• Falta de compatibilidad operativa entre los sistemas de misión, aumento de los costes de formación.

El resultado son numerosas infraestructuras de sistemas paralelos, específicas para una determinada familia de naves espaciales o agencia operadora, con escasas posibilidades de interacción entre ellas.

La arquitectura orientada a servicios (SOA) está reemplazando gradualmente a la arquitectura monolítica como principio de diseño principal para nuevas aplicaciones, tanto en sistemas privados como distribuidos. Es uno de los principios de diseño fundamentales para aplicaciones distribuidas en red, donde las interfaces, tanto de operaciones como de objetos de datos, deben estar bien definidas, dado que los clientes suelen ser heterogéneos. SOA es un enfoque de diseño de sistemas que no se basa en la especificación de un sistema integrado monolítico, sino en la identificación de componentes modulares más pequeños que se comunican únicamente a través de interfaces de servicio abiertas y publicadas.

El Grupo de Trabajo de SM&C está definiendo un conjunto de servicios estándar que conforman un marco que permite ensamblar sistemas similares a partir de componentes compatibles y modulares. Estos componentes pueden ubicarse en cualquier lugar, siempre que estén conectados mediante una infraestructura común. Esto permite reutilizar los componentes en diferentes despliegues específicos para cada misión: entre agencias, entre misiones y entre sistemas.

Si los servicios se especifican directamente en términos de una implementación de infraestructura específica, quedan vinculados a esa tecnología. En cambio, al superponer los servicios, las especificaciones de servicio pueden independizarse de la tecnología subyacente. Los adaptadores de tecnología específicos permiten el despliegue del marco de servicios sobre dicha tecnología. Esto, a su vez, posibilita la sustitución tanto de la implementación de infraestructura como de las implementaciones de componentes. También es posible establecer una conexión transparente entre diferentes implementaciones de infraestructura, cuando estas sean apropiadas para distintos entornos de comunicación (por ejemplo, espaciales o terrestres) o simplemente reflejen las opciones de despliegue de diferentes organismos.

NOTA: Los componentes del complemento se comunican únicamente mediante interfaces de servicio estándar a través de una infraestructura común. El marco de servicio es en sí mismo estratificado e independiente de la implementación de la infraestructura subyacente.

También es importante destacar que este enfoque no prescribe los componentes ni su implementación. Solo se estandarizan las interfaces de servicio entre los componentes. Esto permite la innovación, la especialización y la diferenciación de los componentes, al tiempo que garantiza su rápida integración en un sistema. Sin embargo, para que el marco de servicio sea eficaz, debe asegurar que se pueda intercambiar información relevante relacionada con las operaciones de la misión a través de las interfaces de servicio, no solo datos. El marco de servicio también debe respetar los sistemas heredados. Cuando un sistema heredado integrado realiza la función de varios componentes del marco de servicio, no es necesario modificar su arquitectura interna ni su implementación. Solo es necesario adaptar las interfaces que expone a otros sistemas para que sean compatibles con las interfaces de servicio correspondientes. El marco de servicio ofrece una gama de interfaces interoperables, de las cuales se puede seleccionar la más adecuada: la compatibilidad no depende de su soporte para todas. De esta forma, los sistemas heredados pueden reutilizarse junto con otros componentes compatibles para construir un sistema específico para la misión. El enfoque pretende ser evolutivo, no revolucionario.

Una característica clave del Marco de Servicio de Operaciones de Misión [1] es la estratificación de servicios. Si bien se ha identificado una gama de servicios potenciales que corresponden a diferentes tipos de información de operaciones de misión que se intercambian dentro de un sistema (parámetros de estado, acciones de control, datos orbitales, cronogramas de misión, etc.), estos servicios a nivel de aplicación se implementan en términos de un conjunto más pequeño de patrones de interacción genéricos que permiten observar el estado actual, invocar operaciones y transferir grandes cantidades de datos. Esto tiene dos ventajas clave: es inherentemente extensible, ya que se pueden superponer nuevos servicios a los servicios comunes existentes; y la inversión realizada en aplicaciones de Operaciones de Misión se aísla aún más de la tecnología de implementación. Los adaptadores de tecnología permiten cambiar (o conectar) la infraestructura de comunicaciones subyacente con un impacto mínimo en las propias aplicaciones. Esto mejora la mantenibilidad a largo plazo, ya que las misiones a menudo sobreviven a la tecnología terrestre utilizada para su despliegue inicial.

Las capas del Marco de Servicio de Operaciones de Misión [1] son:

• La capa de servicios de operaciones de misión (MO) (que incluye los servicios comunes de MO)
• La capa de abstracción de mensajes (MAL)
• una capa de transporte de mensajes

La interfaz entre cada capa está definida en los estándares CCSDS y, por lo tanto, las implementaciones de cada capa pueden reemplazarse por otro software sin necesidad de modificarlo.

La estandarización de un marco de servicio de operaciones de misión [1] ofrece una serie de beneficios potenciales para el desarrollo, despliegue y mantenimiento de la infraestructura de operaciones de misión:

• Mayor interoperabilidad entre agencias, a nivel de naves espaciales, cargas útiles o componentes de infraestructura del segmento terrestre.
• La estandarización de las interfaces de infraestructura, incluso dentro de las agencias, permite la reutilización entre misiones y la capacidad de establecer una infraestructura común para múltiples misiones, reduciendo así los costos de capacitación de los equipos operativos y el tiempo necesario para preparar nuevas misiones.
• Estandarización de las interfaces operativas para naves espaciales de diferentes fabricantes.
• Reducción del coste de despliegue específico de la misión mediante la integración de componentes reutilizables.
• capacidad de seleccionar el mejor producto para una tarea determinada de entre una gama de componentes compatibles.
• Mayor flexibilidad en los límites de despliegue: las funciones se pueden migrar más fácilmente entre sitios de segmentos terrestres o incluso de tierra al espacio.
• estandarización de un número limitado de servicios en lugar de un gran número de interfaces específicas entre componentes.
• Mayor competencia en el suministro de herramientas comerciales, lo que conlleva una reducción de costes y una mayor independencia de los proveedores.
• Mejora de la mantenibilidad a largo plazo, mediante la evolución del sistema a lo largo de la vida útil de la misión, a través de la sustitución de componentes e infraestructura.

El término operaciones de misión (OM) se utiliza para referirse al conjunto de actividades necesarias para operar las naves espaciales y sus cargas útiles. Incluye:

• Supervisión y control de los subsistemas y cargas útiles de la nave espacial.
• Análisis y presentación de informes sobre el rendimiento de las naves espaciales
• planificación, programación y ejecución de las operaciones de la misión
• Determinación de órbita y actitud, predicción y preparación de maniobras
• Gestión del software a bordo (carga y descarga)
• entrega de productos de datos de la misión.

Estas funciones suelen considerarse propias del Centro de Control de Misión (MCC) y las lleva a cabo el equipo de operaciones de la misión, con el apoyo del Sistema de Operaciones de Misión (MO). El MO incluye la capacidad de archivar y distribuir datos de operaciones de misión. Si bien esto puede abarcar el manejo de productos de datos de misión, las actividades específicamente relacionadas con la explotación de datos de misión (como el procesamiento, el archivo y la distribución de datos específicos de la misión) se consideran fuera del alcance del MO. Cada vez más, las funciones del MO pueden distribuirse entre agencias colaboradoras y sitios del segmento terrestre, o delegarse parcialmente a funciones autónomas a bordo de la propia nave espacial. El Marco de Servicios del MO se ocupa de la interacción de extremo a extremo entre el software de aplicación del MO, independientemente de su ubicación dentro del sistema espacial. No se ocupa específicamente de la prestación de servicios para el transporte o la persistencia (almacenamiento) de datos. Sin embargo, sí utiliza dichos servicios.

• Marco NanoSat MO

[1] Concepto de Servicios de Operaciones de Misión. CCSDS 520.0-G-3. Libro Verde. Edición 3. Diciembre de 2010. https://web.archive.org/web/20130531013416/http://public.ccsds.org/publications/archive/520x0g3.pdf