doi.org/10.35321/term27-08

La terminología como base para la construcción de modelos de ingeniería basados en características

RICARDO EITO BRUN

Universidad Carlos III de Madrid

RESUMEN

Las operaciones de los satélites requieren el uso combinado de distintas herramientas para respaldar las actividades de ingeniería y controlar la nave espacial. Esta comunicación es gestionada por el Sistema de Monitorización y Control (MCS), que recibe datos de telemetría de la nave espacial y envía telecomandos para mantener la actitud y la trayectoria de vuelo del satélite. Estos complejos sistemas se desarrollan como plataformas abiertas que pueden ampliarse y personalizarse para satisfacer los requisitos y objetivos específicos de cada misión. En general, puede afirmarse que estas aplicaciones de software son buenas candidatas para implementar mecanismos de variabilidad de forma estructurada y planificada, y que su funcionalidad es adecuada para analizar la viabilidad de aplicar técnicas de modelado basadas en características. Este artículo describe el uso del análisis terminológico para construir un modelo de características que respalde el análisis de requisitos de este tipo de sistemas basados en software.

PALABRAS CLAVE: terminología técnica, modelos basados en características, ingeniería aeroespacial, extracción de terminología

RESUMEN

Las operaciones de los satélites requieren diversas herramientas para garantizar la fluidez del trabajo de ingeniería y controlar la nave espacial. Esta comunicación es gestionada por el Sistema de Monitorización y Control (SKS), que recibe datos de telemetría de la nave espacial y envía telecomandos para mantener la actitud y la trayectoria orbital del satélite. Estos complejos sistemas se desarrollan como plataformas abiertas que pueden ampliarse y adaptarse a los requisitos y objetivos específicos de cada misión. En general, puede afirmarse que estas aplicaciones de software pueden utilizarse para implementar mecanismos de variabilidad de forma estructurada y planificada, y que su funcionalidad permite analizar la viabilidad de aplicar metodologías de modelado de características. Este artículo describe el uso del análisis terminológico para construir un modelo de características que respalde el análisis de requisitos de este tipo de sistemas basados en software.

PALABRAS CLAVE: terminología técnica, modelos de características, ingeniería aeroespacial, reconocimiento de términos

186

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

1. INTRODUCCIÓN

El glosario de la NASA define los satélites como: “un objeto que vuela libremente y orbita la Tierra, otro planeta o el Sol.” Los satélites son un tipo de nave espacial que viaja en una órbita regular y claramente definida alrededor del centro de gravedad de otro cuerpo celeste (Garner 1996: 4). Desde el lanzamiento de los primeros satélites artificiales —Sputnik 1, el 4 de octubre^th de 1957, y Explorer 1, el 31 de enero^st de 1958—, se han lanzado numerosas misiones satelitales con diferentes propósitos: exploración astronómica, prestación de servicios de comunicación y navegación, observación de la Tierra, reconocimiento y misiones científicas. Los satélites son sistemas aeroespaciales complejos compuestos por elementos terrestres y espaciales: la nave espacial debe ser operada por un elemento de control en la Tierra y mantenerse en contacto con él. Hoy en día, el progreso científico y los servicios para los usuarios dependen de los satélites y las constelaciones de satélites. Entre los ejemplos pertinentes figuran el Hubble Space Telescope (HST), sistemas de navegación como GPS (Global Positioning System), GLONASS y el Galileo europeo, UARS (Upper Atmosphere Research Satellite) o GOES (Geostationary Operational Environment Satellite). El número total de satélites lanzados desde 1957 —según el catálogo de la SSN² de EE. UU.— se acerca a los 18 200; el 2017 Index of Objects Launched into Outer Space de la UNOOSA informa de que actualmente hay 4635 satélites en órbita alrededor del planeta, lo que supone un aumento de 357 satélites (8,95%) con respecto al año anterior³. El objetivo de este artículo es demostrar la necesidad de aplicar la gestión y extracción de terminología para apoyar el desarrollo de modelos basados en características que organicen los conceptos que describen las funciones de las aplicaciones de software utilizadas para el seguimiento y control de satélites.

Los satélites se clasifican según su propósito y el tipo de órbita. El propósito se refiere a los servicios que se prevé que proporcione el satélite. En cuanto a la órbita, se distingue entre órbita terrestre baja (LEO), órbita terrestre media (MEO) y órbita geoestacionaria (GEO). Los satélites LEO —utilizados para la ciencia y la observación de la Tierra— siguen una órbita elíptica; como su visibilidad desde las estaciones terrestres es limitada, los datos se almacenan a bordo y se envían a tierra

¹ Véase https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [consultado el 2020-08-01].

² La US Space Surveillance Network se encarga de la detección, el seguimiento, la catalogación y la identificación de objetos artificiales que orbitan la Tierra. El catálogo está disponible en: https://www.space-track.org/#/ssr [consultado el 2020-08-01].

³ United Nations Office for Outer Space Affairs. Véase https://www.pixalytics.com/sats-orbiting-earth-2017/

Terminologija | 2020 | 27

187

estaciones cuando la nave espacial se hace visible. Los satélites GEO se utilizan con fines de telecomunicación y meteorológicos; los satélites de telecomunicación reciben señales de radiofrecuencia (RF) de la Tierra, las amplifican, cambian su frecuencia y las transmiten de vuelta a la Tierra. Orbitan a 36 000 km sobre el ecuador (en el mismo plano), y su rotación está sincronizada con la rotación de la Tierra, por lo que permanecen siempre sobre el mismo punto del ecuador)⁴. Al igual que los satélites, las misiones científicas al espacio profundo también requieren sistemas similares de seguimiento y control para la recepción de teleórdenes y telemetría.

Las misiones satelitales requieren personal especializado que realice un seguimiento continuo y en tiempo real del estado y la posición del satélite. El control de misión es el conjunto de tareas que llevan a cabo los ingenieros de operaciones tras el lanzamiento con ayuda de aplicaciones de software, e implica el intercambio de datos entre los segmentos terrestre y espacial para supervisar y controlar el estado de los subsistemas a bordo del satélite. En las misiones científicas también es necesario recibir la información de la carga útil del satélite y entregarla a los usuarios finales (la comunidad científica). Entre las funciones típicas que se ejecutan durante el control de misión figuran la recepción y el análisis de telemetría, la emisión de teleórdenes y el seguimiento. La telemetría son los datos que se transmiten desde el satélite a la Tierra para informar sobre el estado y las condiciones del satélite y sus subsistemas. Las teleórdenes son las instrucciones que se transmiten desde tierra a la nave espacial para configurarla y operarla. (Uhlig, Sellmaier, and Schmidhuber 2015: 232). El seguimiento y el mantenimiento de la estación, también conocidos como medición de distancia, consisten en supervisar y determinar la trayectoria de vuelo y la posición mediante técnicas y señales de RF.

Desde la perspectiva de la ingeniería de software, el control de satélites requiere diferentes aplicaciones y herramientas para la dinámica de vuelo, la planificación de misiones, la telemetría y la emisión de teleórdenes, el control y enrutamiento de redes, así como interfaces entre ellas. Esta complejidad ha propiciado que las agencias espaciales ofrezcan distintas soluciones. Uno de los hitos más relevantes en el desarrollo del software MCS fue la decisión del departamento de Ground Systems Engineering de la ESA de desarrollar y licenciar a la industria europea un conjunto de aplicaciones de software distribuidas bajo el nombre MICONYS^®

⁴ Los satélites GEO se distribuyen en una zona limitada del espacio. La Unión Internacional de Telecomunicaciones (International Telecommunication Union, ITU) asigna las posiciones orbitales para evitar colisiones, un riesgo relacionado con el problema de los desechos espaciales, que hoy recibe cada vez más atención.

188 Ricardo Eito Brun │ Terminology as the Basis for Building Engineering Feature-based Models

(Sistema de Control de Misión). MICONYS y su componente SCOS-2000® son probablemente los ejemplos más conocidos de esta política de la ESA para el desarrollo de software y la transferencia de innovación y tecnología (Kaufeler, Jones and Karl 2001). SCOS-2000 permite enviar teleórdenes, recibir telemetría, visualizarla y archivarla. SCOS-2000 fue el resultado de la experiencia adquirida por la ESA en el desarrollo y la operación de sistemas similares anteriores: MSSS, SCOS-1 y SCOS-2. Actualmente, la ESA está desarrollando el nuevo sistema MCS, cuyo objetivo es sustituir a SCOS-2000 en el futuro. Su nombre es European Ground Systems – Common Core (EGS-CC). Al igual que SCOS, el proyecto tiene como propósito desarrollar una infraestructura común que permita respaldar la supervisión y el control de las misiones espaciales en las fases previas y posteriores al lanzamiento, mediante tecnologías modernas y arquitecturas orientadas a servicios (Peccioli et al. 2012). El desarrollo de EGS-CC no es responsabilidad exclusiva de la ESA: las agencias espaciales nacionales europeas (CNES, UK Space Agency y DLR) y empresas industriales (AIRBUS Defence and Space, Thales Alenia Space y OHB Systems) también forman parte del proyecto.

Además de los proyectos de la ESA, existen otras iniciativas destinadas a desarrollar un sistema de software MCS genérico. La NASA ha completado proyectos similares, la mayoría de ellos desarrollos internos. El Goddard Space Flight Centre desarrolló dos sistemas, ITOS y ASIST, para gestionar misiones como WMAP (Wilkinson Microwave Anisotropy Probe), IMAGE (Imager for Magnetopause-to-Aurora Global Exploration), EO-1 (Earth Observing 1), ST-5 (Space Technology 5), SDO (Solar Dynamics Observatory) o LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007).

En todos estos casos, nos encontramos ante un sistema complejo que debe implementar distintas funciones, que pueden activarse o no en función de las características del satélite y de la misión. Por ello, estos sistemas con gran contenido de software son buenos candidatos para desarrollarse mediante líneas de productos y técnicas de modelado basado en características, que se apoyan en una organización clara y bien estructurada de los conceptos para comprender el dominio y las capacidades necesarias del sistema.

2. MODELADO BASADO EN CARACTERÍSTICAS

COMO ORGANIZACIÓN DE CONCEPTOS

El modelado basado en características es una de las técnicas aplicadas en la ingeniería de líneas de productos de software, una disciplina para crear programas de software reutilizables que se popularizó a finales de los años noventa. SPLE se propone

Terminologija | 2020 | 27

189

crear componentes y artefactos reutilizables que posteriormente puedan combinarse para crear productos adaptados a las necesidades de un cliente y un contexto específicos. Las experiencias en SPLE están ampliamente documentadas en la literatura profesional y académica. Capilla (2013) incluyó varios estudios de caso en los que SPLE se aplicó con éxito: programas de vuelo operativos y de misión crítica de Boeing’s para funciones de aviónica y cabina, software de control del motor de Bosch’s para sistemas de gasolina, software de impresoras de Hewlett Packard’s, equipos de generación y transmisión de energía de Toshiba’s y software de control de trenes motrices de General Motors’. Entre los beneficios de las líneas de productos de software (SPL), según Apel et al. (2013: 9), se incluyen la adaptación de los productos de software a las necesidades específicas de los clientes, la reducción de costes —ya que un conjunto de activos reutilizables puede combinarse de distintas maneras para generar nuevos productos—, la mejora de la calidad y la reducción del tiempo de comercialización.

Las características y el modelado basado en características son conceptos relevantes para el desarrollo de SPL. La norma ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, ofrece una definición general de features, tomada de IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: “Una característica distintiva de un elemento del sistema. NOTA: incluye atributos tanto funcionales como no funcionales, como el rendimiento y la reutilización”. Kang y Lee (2013, 28) definen las características como “conceptos abstractos que facilitan eficazmente la comunicación entre los diversos interesados de una línea de productos y, por tanto, resulta natural e intuitivo expresar la comunalidad y la variabilidad de las líneas de productos en términos de características”.

Las características cumplen distintas funciones en los procesos de ideación y desarrollo de productos. Sirven para comunicar las características del producto y respaldar la identificación de requisitos; además, son los conceptos que orientan las decisiones de diseño e implementación.

El desarrollo de una línea de productos comprende dos ciclos de vida complementarios:

• Ingeniería de dominio, y

• Ingeniería de aplicaciones.

La norma IEEE 1517-2010 define la ingeniería de dominio como: “Ciclo de vida que consta de un conjunto de procesos para especificar y gestionar la comunalidad y la variabilidad de una línea de productos. La ingeniería de dominio analiza el dominio de una línea de productos y desarrolla un conjunto de artefactos reutilizables. Estos artefactos incluyen requisitos de software, elementos de diseño, casos de prueba y

190

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

procedimientos, documentación para usuarios, etc. El análisis del dominio puede considerarse una especie de ingeniería de requisitos para toda la línea de productos, incluida la identificación de la variabilidad prevista. El principal artefacto generado por el análisis del dominio es el modelo de características, que especificará y describirá los productos de la línea.

El modelado de características es una técnica de diagramación que se introdujo en los años noventa con la metodología FODA (Análisis de dominio orientado a características). FODA proporcionó primitivas para representar relaciones estructurales (composición, generalización y especialización), opcionalidad, alternativas y dependencias mutuas. Posteriormente, distintos autores la revisaron (Kang y Lee 2013: 30–31). Los diagramas de características son la representación visual de los modelos de características, en los que estas se representan mediante cuadros en un árbol jerárquico. Cada nodo lleva una etiqueta con el nombre de la característica. La disposición jerárquica de las características crea relaciones entre padres e hijos. Si se selecciona una característica hija, también debe seleccionarse su padre. Los diagramas pueden distinguir entre características obligatorias y opcionales, e identificar las combinaciones válidas de características.

En particular, los diagramas de características pueden representar:

Características abstractas, que se utilizan para organizar las características en el árbol, pero no están vinculadas a artefactos de implementación. Se representan con cuadros grises.

Características concretas, que corresponden a artefactos de implementación y se representan con cuadros blancos.

Características obligatorias, que tienen un punto relleno sobre el borde superior de su cuadro.

Características opcionales, que tienen un punto sin rellenar sobre el borde superior de su cuadro.

La necesidad de seleccionar solo una de las características hijas de un padre específico (OR exclusivo, XOR, o una de muchas). Se representa con un arco vacío en el borde inferior del cuadro de la característica padre.

La posibilidad de seleccionar más de una característica hija de un padre específico (OR o algunas de muchas). Se representa con un arco relleno en el borde inferior del cuadro de la característica padre.

Dependencias entre características, representadas mediante flechas con anotaciones textuales.

Terminologija | 2020 | 27

191

El diagrama siguiente muestra un diagrama de características típico con las convenciones descritas anteriormente:

Fig. 1. Ejemplo de diagramación de características (Fuente: Gargantini 2015)

Un modelo de características debe incluir información adicional al diagrama. Apel et al. (2013: 27) señalan la posibilidad de añadir estos datos:

«Descripción de una característica y del conjunto de requisitos que le corresponde.

Relación con otras características, especialmente jerarquía, orden y agrupación.

Dependencias externas, como los recursos de hardware necesarios.

Partes interesadas.

Coste estimado o medido de implementar una característica.

Etcétera.»

El desarrollo de un modelo de características para representar las características funcionales de las aplicaciones de software destinadas al control de satélites debe partir de una comprensión y modelización claras de los conceptos que conforman el dominio. Para ello, las actividades relacionadas con la terminología y la terminografía, así como la identificación de términos, conceptos y sus relaciones, proporcionan la base para construir el modelo objetivo.

192

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

3. METODOLOGÍA DE TRABAJO

El modelo de características propuesto se ha completado siguiendo estos pasos:

Identificación y revisión de la literatura profesional y académica publicada en este ámbito. Esto implica buscar información sobre el enfoque seguido en proyectos aeroespaciales dirigidos por entidades como la ESA (European Space Agency) o la NASA (National Aeronautics and Space Administration).

Elaboración de un glosario basado en la literatura analizada, aplicando técnicas de gestión terminológica para registrar información sobre los términos, las relaciones entre ellos, las definiciones identificadas en los documentos y el contexto en el que se utilizan los términos.

Creación de un modelo de características que represente las funciones ofrecidas por las aplicaciones de software de monitorización y control de satélites, utilizando el glosario como base.

Entre los datos utilizados para identificar términos se incluyó un subconjunto de documentos técnicos que describen el producto seleccionado: manuales de operación, documentos técnicos y materiales de formación. El modelo de características es un árbol jerárquico de características marcadas como obligatorias u opcionales, con dependencias entre ellas. En el caso de la aplicación de software analizada, además de identificar las características opcionales y obligatorias, se identificaron requisitos adicionales de variabilidad de la línea de productos. En particular, algunas de las funciones admitidas por el software analizado requieren sobrescribir o personalizar el código existente. La identificación de estos casos de variabilidad se realizó con el apoyo de expertos que desempeñan su actividad en el desarrollo y la personalización de este tipo de aplicaciones de software. Se realizaron entrevistas personales para recopilar esa información.

La herramienta seleccionada para crear el modelo de características y los diagramas es FeatureIDE⁵. Es una herramienta de código abierto basada en Java y Eclipse, desarrollada por el personal de la Otto-von-Guericke-Universität Magdeburg. Con FeatureIDE, es posible crear un modelo de características mediante un editor gráfico, marcar las características como obligatorias, opcionales o abstractas, y construir el árbol jerárquico. Una vez creado el modelo de características, se pueden crear distintas configurations: selecciones de características que se utilizarán para generar la aplicación de software de destino

⁵ Véase https://FeatureIDE.github.io/. Última consulta: 01-03-2018.

Terminologija | 2020 | 27

193

código fuente. Lamentablemente, la herramienta no ofrece funciones para gestionar términos o unidades terminológicas, por lo que es necesario utilizar herramientas complementarias.

Fig. 2. FeatureIDE (creado por el autor)

4. PRESENTACIÓN DE RESULTADOS Y DISCUSIÓN

Esta sección resume una parte del modelo de características para las aplicaciones de software de los Sistemas de Control de Misión (MCS). El análisis de los conceptos extraídos de los documentos condujo a organizar las funcionalidades del sistema en las siguientes áreas:

Gestión del escritorio y de la sesión, que proporciona las funciones para iniciar sesión, comenzar una sesión y ejecutar las distintas aplicaciones. En el caso de gestionar varios satélites, el usuario podrá cambiar entre los espacios de trabajo de los satélites.

Cadena de telemetría, que incluye procesamiento de telemetría, gestor de alarmas y visualización de telemetría.

194

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

Cadena de telemandos, que incluye enlace ascendente de telemandos, pila manual, pila programada e historial de telemandos.

Puente TT&C/TCR, que proporciona visibilidad y control sobre la interfaz con la estación terrestre para los flujos de datos de telemetría, comando, medición de distancia (TCR) y apuntamiento de antena.

Registro de eventos, que registra los eventos identificados durante las operaciones del sistema y permite a los operadores consultar y buscar en todo el historial de eventos.

Gestión de la memoria de a bordo, que ofrece funciones para gestionar (descargar, editar y transmitir en enlace ascendente) la imagen de memoria de la nave espacial.

El análisis de la documentación y de los términos condujo a la creación de modelos de características para estas funciones del sistema. El caso específico de la gestión de telemetría se resume a modo de ejemplo. Puede observarse que se proporcionan definiciones de las características identificadas, basadas en la bibliografía existente y en la documentación técnica:

El término cadena de telemetría se refiere a los distintos procesos que intervienen en el procesamiento de la telemetría: recepción desde TT&C, paquetización, archivado y distribución a las aplicaciones consumidoras:

Paquetización de telemetría. MCS toma los paquetes de origen de telemetría conforme al estándar de paquetes de telemetría, añade metadatos (por ejemplo, la calidad del flujo de telemétrico) y los convierte en uno o varios paquetes internos de telemetría de MCS. Los criterios para generar paquetes a partir de los datos entrantes pueden variar según el satélite, la misión y los protocolos BBE.

Comprobación de la calidad de los paquetes. MCS comprueba continuamente la calidad de la telemetría mediante verificaciones realizadas por TT&C o por el propio MCS. Se añaden metadatos sobre la calidad de la telemetría a cada paquete interno. Según el resultado de esas verificaciones, el paquete puede clasificarse como apto para el procesamiento (GOOD) o no apto para el procesamiento (BAD). También deben identificarse las pérdidas de telemetría durante el proceso.

Una comprobación de calidad típica es la comprobación de secuencia de tramas, que evalúa si las tramas se reciben o no en secuencia.

Terminologija | 2020 | 27

195

Se generan eventos cuando estas comprobaciones no se satisfacen. El operador puede seleccionar el comportamiento que se aplicará cuando se identifiquen tramas de telemetría BAD (procesarlas o descartarlas).

• Comprobaciones de calidad temporal. Estas comprobaciones verifican que la hora indicada por TT&C para cada flujo de telemetría y las horas locales del MCS no difieran demasiado. La diferencia entre la hora actual del MCS y la marca temporal de la trama de telemetría (establecida por la estación terrestre al recibir la trama) se encuentra dentro de una ventana temporal configurable. Si estas comprobaciones fallan, se generan mensajes de evento. Las comprobaciones de calidad temporal requieren que los paquetes de telemetría lleven una marca temporal.

• Desconmutación de telemetría, que extrae de los paquetes las muestras de los parámetros de telemetría⁶. Implica la extracción de parámetros, la decodificación de bits, la calibración, la comprobación de valores fuera de rango, la comprobación de validez y la asignación de fecha a los parámetros.

○ La extracción de parámetros de telemetría localiza y extrae de los paquetes los valores brutos de los parámetros de telemetría. Los valores brutos suelen ser enteros con signo o sin signo, o números de punto flotante. Este proceso es trivial para la telemetría fija, ya que toda la información necesaria sobre la ubicación de los parámetros está disponible en la MIB del satélite, pero es más complejo en el caso de la telemetría programable.

○ Decodificación de bits obtiene el valor bruto a partir del valor codificado en el paquete de telemetría. En una situación típica, el valor bruto coincide con el codificado en el paquete, pero en algunos casos se necesita una transformación basada en bits (como la inversión de bits o el complemento a dos) o en bytes.

○ Parámetros derivados o sintéticos. No se obtienen de la nave espacial, sino que se derivan algorítmicamente en tierra utilizando como operandos parámetros de telemetría adquiridos. Se calculan mediante fórmulas escritas en lenguajes de scripting. Se calculan antes de la calibración, las comprobaciones de validez y la asignación de fecha a los parámetros.

Un tipo especial de parámetro derivado son los parámetros derivados codificados directamente (HCDP), escritos en lenguajes de programación de bajo nivel

⁶ Los parámetros pueden ser síncronos (se envían por telemetría tan pronto como se muestrean a bordo) o asíncronos (no se envían por telemetría tan pronto como se muestrean a bordo, sino que se almacenan en la memoria de a bordo y se transmiten posteriormente). Por lo general, los parámetros se muestrean y codifican una o varias veces por formato, salvo los parámetros subconmutados, que no se muestrean ni codifican en todos los formatos, y los parámetros superconmutados, que se muestrean y codifican varias veces.

196 Ricardo Eito Brun | Terminology as the Basis for Building Engineering Feature-based Models

como C++, Fortran o C. Su modificación requiere la recompilación del código fuente.

o Fechado de los parámetros de telemetría asigna una fecha a las muestras de los parámetros, utilizando la hora del paquete que las contiene y añadiendo un desfase según lo especificado en la MIB del satélite.

o Control de valores fuera de rango (OOR) analiza si el valor sin procesar de un parámetro de telemetría está fuera del rango de calibración definido. Los parámetros de telemetría fuera de rango se declaran inválidos con la categoría OOR. OOR se utiliza para evaluar la validez del parámetro de telemetría y determinar si su valor es útil o carece de significado.

Además, los parámetros fuera de rango deben mostrarse y ser reconocidos por los operadores. Otras condiciones para declarar inválido un parámetro son que haya caducado o —en el caso de parámetros derivados— que se haya calculado utilizando parámetros inválidos. En cualquier caso, los metadatos de invalidez del parámetro de telemetría deben detallar el motivo de este estado.

• Calibración de los parámetros de telemetría transforma sus valores sin procesar en una forma legible para las personas (valores de ingeniería o calibrados, con las unidades correspondientes a la magnitud física). La calibración puede realizarse mediante distintos métodos:

o Calibración numérica o lineal discreta: se utiliza interpolación lineal a partir de una curva de calibración formada por pares (X, Y), donde X representa el valor sin procesar e Y el valor de ingeniería.

o Calibración textual, digital o de estado: asocia cadenas de texto a rangos de valores sin procesar de los parámetros. Los valores textuales pueden obtenerse a partir de valores discretos o de un rango de estos. Un ejemplo sencillo es el estado ON / OFF de las unidades de a bordo, que podría obtenerse de un parámetro de un bit, donde 0 significa OFF y 1 significa ON.

o Calibración polinómica: utiliza un polinomio de hasta quinto grado para convertir los valores sin procesar en valores de ingeniería.

Sin entrar en más detalles sobre las características extraídas (solo se describe un subconjunto para mostrar que su identificación requiere un trabajo terminológico riguroso), el siguiente diagrama presenta las principales características identificadas para esta área funcional:

Terminologija | 2020 | 27

197

Fig. 3. Procesamiento de TM – Características Fig. 1: FeatureIDE (creado por el autor)

5. CONCLUSIONES

Este artículo describe el desarrollo de un modelo de características para aplicaciones de software de control de satélites, utilizando como entradas documentos técnicos (manuales de operación, documentos informativos y materiales de formación) que describen las funcionalidades del tipo de sistema objeto de estudio. El primer paso consiste en la

198

Ricardo Eito Brun

Terminology as the Basis for Building Engineering Feature-based Models

identificación y extracción de términos mediante la inspección de los documentos, identificando sus definiciones a través del contexto en el que se aplican. Esta recopilación de términos se analiza posteriormente para identificar características, que se organizaron en el modelo y el diagrama de características atendiendo a criterios funcionales, dentro de doce categorías principales: gestión de sesiones, gestión de conexiones con estaciones terrestres, procesamiento de telemetría, visualización de datos de telemetría, procesamiento de telecomandos, archivo de misión, etc.

Para cada área funcional, se resumieron la descripción de los conceptos principales y las características que debe admitir un sistema de software, y se representaron en diagramas de características creados con la herramienta FeatureIDE. Las definiciones y el contexto de uso también sirvieron de base para establecer la relación entre las características e identificar oportunidades de variabilidad. Se identificaron tres razones principales para la variabilidad:

Parámetros de configuración específicos de la misión, normalmente gestionados mediante archivos de configuración públicos.

Selección de características opcionales según el tipo de misión: p. ej., telecomandos basados en la posición, característicos de los satélites LEO para la observación de la Tierra.

Personalización de los servicios específicos de la misión que amplían los servicios y funciones básicos definidos en normas de telemetría y telecomandos como PUS.

Este trabajo demuestra la necesidad de aplicar técnicas relacionadas con la terminología para recopilar, analizar y documentar el significado de los términos, así como para extraer relaciones que posteriormente puedan utilizarse con distintos fines. En el caso de los modelos de ingeniería basados en características, los términos constituyen la base para describir sin ambigüedad las funciones del software y los sistemas, y para identificar las características de sistemas complejos. También es necesario mantener la coherencia en el uso de los términos para garantizar que los distintos agentes implicados en tareas de ingeniería posteriores (diseño, implementación, pruebas, etc.) compartan una comprensión común de las características del sistema, evitando errores causados por una definición deficiente del ámbito del dominio que el sistema pretende respaldar.

REFERENCES

Apel et al. 2013: Feature-Oriented Software Product Lines: Concepts and Implementation, Berlin: Springer.

Capilla Rafael 2013: Variability Scope. – System and Software Variability Management: Concepts, Tools, and Experiences, Berlin: Springer, 43–56.

CCSDS 520.0-G-3 (Mission operations services concept), December, 2010.

Clements, Paul C. and Northrop Linda M. 2002: Software Product Lines: Practices and Patterns, Boston: Addison-Wesley Professional.

Gargantini Angelo 2015: Generating Tests for Detecting Faults in Feature Models. – 2015 IEEE 8th International Conference on Software Testing, Verification and Validation, ICST 2015 – Proceedings.

Terminologija | 2020 | 27

199

Garner John T. 1996: Satellite Control: a Comprehensive Approach, Chichester: John Wiley and sons, xv.

Jones, M.; Srensren E. M. and Wolff T. 1993: “A review of mission planning systems”. – IPL SpaceOps 1992: Proceedings of the Second International Symposium on Ground Data Systems for Space Mission Operations (SEE N94-23832 06-66), 219–224. Available at: https://ntrs.nasa.gov/search.jsp?R=19940019393

Kang Kyo-Chul and Lee H. 2013: Variability Modelling. – System and Software Variability Management: Concepts, Tools, and Experiences, eds. R. Capilla, J. Bosch and K. C. Kang, Berlin: Springer, 25–42.

Kaufeler J.-F., Jones M., Karl H.-U. 2001: Promoting ESA Software as a European Product: The SCOS-2000 Example. – ESA Bulletin 108, 72–77.

Pecchioli Mauro et al. 2012: Objectives and Concepts of the European Ground Systems Common Core (EGS-CC). – SESP 2012: Simulation and EGSE facilities for Space Programs, ESTEC Noordwijk, 25–27 September. Available at: http://www.egsc.esa.int/downloads/20120925_SESP_2012_egsc_objectives_and_concepts.pdf.

Pfarr Barbara et al. 2007: Proven and Robust Ground Support Systems – GSFC Success and Lessons Learned. (2008). – IEEE Aerospace Conference, paper # 1219, version 6. Available at: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080045437.pdf

Uhlig Thomas; Sellmaier Florian and Schmidhuber Michael 2015: Spacecraft Operations, Wien: Springer.

TERMINOLOGIJA KAIP INŽINERINIŲ POŽYMIŲ MODELIŲ KŪRIMO PAGRINDAS

S a n t r a u k a

Paly dovai yra erdvėlaiviai, kurie skrieja aplink kito dangaus kūno gravitacijos centrą pastovia, aiškiai apibrėžta orbita (Garner 1996: 4). Nuo pirmųjų dirbtinių palydovų paleidimo – „Sputnik 1“ 1957 m. spalio 4 d. ir „Explorer 1“ 1958 m. sausio 31 d. – buvo paleista daug palydovų misijų, kuriomis siekta skirtingų tikslų: astronominiai tyrimai, komunikacinių ir navigacinių paslaugų teikimas, Žemės stebėjimas, žvalgyba ir mokslinės misijos. Palydovai turi būti valdomi Žemėje esančiu valdymo elementu ir palaikyti su juo ryšį. Šį ryšį valdo Stebėjimo ir kontrolės sistema (SKS), kuri gauna telemetrinius duomenis iš erdvėlaivio ir duoda telekomandas, kad palaikytų palydovo padėtį ir skriejimo trajektoriją. Galime teigti, kad šios taikomosios programos gali būti naudojamos norint struktūruotai ir planuotai įdiegti variantškumo mechanizmus, o jų funkcionalumas leidžia analizuoti požymių modeliavimo metodikų pritaikymo galimybes.

Požymiai yra naudojami norint perduoti produkto charakteristikas ir palaikyti reikalavimų nustatymą. Jie taip pat naudojami priimant projektavimo ir įgyvendinimo sprendimus. Straipsnyje aprašomas požymių modelio sukūrimas remiantis šios srities profesinės ir akademinės literatūros apžvalga, žodynėlio, nurodančio ryšius tarp terminų, sudarymu ir požymių modelio, apimančio taikomųjų palydovų stebėjimo ir kontrolės programų funkcijas, sukūrimu. Įvesties duomenys, skirti identifikuoti terminus, apėmė techninių dokumentų, aprašančių pasirinktą produktą, pogrupį: valdymo vadovus, baltaisias knygas ir mokomąją medžiagą. Požymius nurodančios sąvokos ir terminai yra išdėstyti hierarchinės struktūros principu, o tarpusavio sąsajoms naudojamas FeatureIDE įrankis.

Gauta 2020-09-07

Ricardo Eito Brun Universidad Carlos III de Madrid Calle Madrid, 126, 28903 Getafe, Madrid, Spain E-mail [email protected]

200

Ricardo Eito Brun | Terminology as the Basis for Building Engineering Feature-based Models