Capa de abstracción de mensajes

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 10 agencias espaciales y del Grupo de Trabajo del Dominio Espacial del Grupo de Gestión de Objetos ( OMG ), está definiendo una arquitectura orientada a servicios que consiste en un conjunto de servicios estándar de extremo a extremo entre funciones que residen a bordo de una nave espacial o que tienen su base en tierra, y que son responsables de las operaciones de la misión.

La capa de abstracción de mensajes (MAL) de CCSDS proporciona abstracción de mensajes y patrones de servicio genéricos a los servicios de Operaciones de Misión (MO) definidos en el Concepto de Servicios de Operaciones de Misión de CCSDS. ^{[ 1 ]}

Una característica clave del Marco de Servicios MO ^{[ 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 MO 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 operaciones de la misión (MO)
• La capa de servicios comunes
• 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.

Para garantizar la independencia del lenguaje de implementación y del transporte de mensajes, todas las operaciones de un servicio deben definirse mediante una especificación independiente del lenguaje, la plataforma y la codificación. El MAL define este conjunto de tipos de datos básicos y cómo deben utilizarse para construir los mensajes que conforman las operaciones de un servicio. Posteriormente, esto debe asignarse una sola vez, en un estándar MO, a un lenguaje de implementación o codificación de transporte específicos para que se apliquen a todos los servicios definidos en términos del MAL. Además de los patrones de interacción y la API abstracta, el MAL ofrece soporte para lo siguiente: conceptos genéricos, como dominio, sesión y zona; y funcionalidades genéricas, como control de acceso (autenticación y autorización) y calidad de servicio.

Una operación de un servicio puede descomponerse en un conjunto de mensajes intercambiados entre un proveedor y un consumidor, formando un patrón de interacción. El análisis de los servicios descritos en la referencia ^{[ 1 ]} muestra que existe un número limitado de estos patrones de interacción que pueden aplicarse a todos los servicios identificados actualmente. La estandarización de un patrón de interacción, que define la secuencia de mensajes intercambiados entre el consumidor y el proveedor, permite definir una plantilla genérica para una operación de servicio. El MAL define este conjunto limitado de patrones de interacción genéricos (plantillas) que deben utilizar los servicios definidos en el marco de servicios MO. Cada operación de un servicio se define en términos de uno de los patrones de interacción del MAL. Al definir un patrón e indicar que una operación determinada es un ejemplo de dicho patrón, la definición de la operación puede centrarse en los detalles específicos de esa operación y basarse en el patrón estándar para facilitar esto. Por ejemplo, se puede definir una operación 'doFoo' que sea un ejemplo de un patrón llamado 'SUBMIT'. Esta operación consta de dos partes: el patrón de mensajes que se intercambian (el patrón 'SUBMIT') y el significado de dichos mensajes y la función de 'doFoo'. Al definir el patrón como estándar ('SUBMIT'), la especificación del servicio que define 'doFoo' solo necesita definir el significado de los mensajes y la función de la operación. El MAL define este conjunto de patrones.

Una ventaja de implementar múltiples servicios sobre una capa de abstracción de mensajes es que resulta más sencillo vincularlos a diferentes tecnologías subyacentes y codificaciones de protocolo. Basta con una capa adaptadora entre la capa de abstracción de mensajes y el protocolo subyacente para habilitar todos los servicios sobre dicha tecnología. Por lo tanto, el mismo servicio puede implementarse sobre tecnologías de red terrestres y middleware, o incluso transmitirse a través del enlace espacial. Los propios servicios proporcionan la interfaz "plug-and-play" para las aplicaciones, lo que permite integrarlas y desplegarlas donde sea apropiado para la misión.

No hay sobrecarga de rendimiento ya que la capa MAL es conceptual y se puede optimizar utilizando generadores de código. ^{[ 2 ]}

El MAL no admitirá características del protocolo subyacente más allá del mínimo común denominador definido en el MAL. Las características de mensajería (por ejemplo, modelo de subprocesos, QoS, etc.) se limitan a un subconjunto más simple que representa la intersección de todas las opciones de middleware subyacentes. Sin embargo, las características de un protocolo subyacente pueden seleccionarse mediante la configuración.

Aún se requiere una capa adaptadora entre MAL y el protocolo subyacente, además de especificaciones para las vinculaciones de lenguaje. Las implementaciones deben cumplir con estas especificaciones para garantizar la interoperabilidad. Por lo tanto, MAL adquiere las características de convertirse en un nuevo estándar de middleware.

Los adaptadores MAL y las especificaciones de enlace de lenguaje MAL deben mantenerse actualizados a medida que evolucionan los estándares de middleware subyacentes para los complementos. Sin embargo, el uso de MAL elimina cualquier dependencia directa de la aplicación con respecto a las tecnologías de protocolo y, por lo tanto, permite aislar cualquier evolución a las capas inferiores del adaptador.

MAL excluye el uso de contratos de servicio como elemento central que define una arquitectura de servicio basada en datos.

Los procedimientos CCSDS exigen dos implementaciones independientes, que ya han sido implementadas por la ESA y el CNES . Ambas agencias están trabajando para su publicación bajo licencias de código abierto.