Terminology as the Basis for Building Engineering Feature-based Models

doi.org/10.35321/term27-08 A terminologia como base para a construção de modelos de engenharia baseados em características RICARDO EITO BRUN Universidad Carlos III de Madrid RESUMO As operações de satélites exigem o uso combinado de diferentes ferramentas para apoiar as atividades de engenharia e controlar a nave espacial. Essa comunicação é gerida pelo Sistema de Monitoramento e Controle (MCS), que recebe dados de telemetria da nave espacial e emite telecomandos para manter a atitude e a trajetória de voo do satélite. Esses sistemas complexos são desenvolvidos como plataformas abertas, que podem ser ampliadas e personalizadas para atender aos requisitos e objetivos específicos da missão. Em geral, pode-se afirmar que essas aplicações de software são boas candidatas à implementação de mecanismos de variabilidade de forma estruturada e planejada, e que sua funcionalidade é adequada para analisar a viabilidade da aplicação de técnicas de modelagem baseada em características. Este artigo descreve o uso da análise terminológica para construir um modelo de características que apoie a análise de requisitos desse tipo de sistema baseado em software. PALAVRAS-CHAVE: terminologia técnica, modelos baseados em características, engenharia aeroespacial, extração de terminologia RESUMO As operações de satélites exigem diversas ferramentas para garantir o bom andamento das atividades de engenharia e controlar a nave espacial. Essa comunicação é gerida pelo Sistema de Monitoramento e Controle (SKS), que recebe dados de telemetria da nave espacial e emite telecomandos para manter a atitude e a trajetória orbital do satélite. Esses sistemas complexos são desenvolvidos como plataformas abertas, que podem ser ampliadas e adaptadas aos requisitos e objetivos específicos da missão. Em geral, pode-se afirmar que essas aplicações podem ser usadas para implementar mecanismos de variabilidade de maneira estruturada e planejada, e que sua funcionalidade permite analisar a viabilidade da aplicação de métodos de modelagem de características. Este artigo descreve o uso da análise terminológica para criar um modelo de características que apoie a análise de requisitos desse tipo de sistema de software. PALAVRAS-CHAVE: terminologia técnica, modelos de características, engenharia aeroespacial, reconhecimento de termos 186 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models 1. INTRODUÇÃO O glossário da NASA define satélites como: “um objeto não tripulado que orbita a Terra, outro planeta ou o Sol.” Satélites são um tipo de espaçonave que percorre uma órbita regular e claramente definida ao redor do centro de gravidade de outro corpo celeste (Garner 1996: 4). Desde o lançamento dos primeiros satélites artificiais – Sputnik 1, em 4 de outubroth de 1957, e Explorer 1, em 31 de janeirost de 1958 – foram lançadas numerosas missões de satélite com diferentes objetivos: exploração astronômica, prestação de serviços de comunicação e navegação, observação da Terra, reconhecimento e missões científicas. Os satélites são sistemas aeroespaciais complexos, compostos por elementos terrestres e espaciais: a espaçonave deve ser operada por um elemento de controle na Terra e manter contato com ele. Atualmente, o progresso científico e os serviços aos usuários dependem de satélites e constelações de satélites. Entre os exemplos relevantes estão o Telescópio Espacial Hubble (HST), sistemas de navegação como o GPS (Sistema de Posicionamento Global), o GLONASS e o Galileo europeu, o UARS (Satélite de Pesquisa da Alta Atmosfera) ou o GOES (Satélite Geoestacionário Operacional de Meio Ambiente). O número total de satélites lançados desde 1957 – de acordo com o catálogo da US SSN2 – aproxima-se de 18.200; o Índice de Objetos Lançados ao Espaço Exterior de 2017 da UNOOSA informa que há 4.635 satélites orbitando atualmente o planeta, um aumento de 357 satélites (8,95%) em relação ao ano anterior3. O objetivo deste artigo é demonstrar a necessidade de aplicar a gestão e a extração de terminologia para apoiar o desenvolvimento de modelos baseados em características que organizem os conceitos que descrevem as funções dos aplicativos de software usados no monitoramento e controle de satélites. Os satélites são classificados de acordo com a finalidade e o tipo de órbita. A finalidade diz respeito aos serviços que o satélite se destina a fornecer. Quanto à órbita, distingue-se entre órbita terrestre baixa (LEO), órbita terrestre média (MEO) e órbita geoestacionária (GEO). Os satélites LEO – usados para ciência e observação da Terra – seguem uma órbita elíptica; como sua visibilidade a partir das estações terrestres é limitada, os dados são armazenados a bordo e enviados para o solo 1 Ver https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [acessado em 2020-08-01]. 2 A Rede de Vigilância Espacial dos EUA é responsável pela detecção, rastreamento, catalogação e identificação de objetos artificiais que orbitam a Terra. O catálogo está disponível em: https://www.space-track.org/#/ssr [acessado em 2020-08-01]. 3 Escritório das Nações Unidas para Assuntos do Espaço Exterior. Ver https://www.pixalytics.com/sats-orbiting-earth-2017/ Terminologija | 2020 | 27 187 estações quando a espaçonave se torna visível. Os satélites GEO são utilizados para fins de telecomunicação e meteorologia; os satélites de telecomunicações recebem sinais de radiofrequência (RF) da Terra, amplificam-nos, alteram sua frequência e os transmitem de volta à Terra. Eles orbitam a 36.000 km acima do Equador (no mesmo plano), e sua rotação é síncrona com a rotação da Terra, permanecendo sempre acima do mesmo ponto no Equador)4. Assim como os satélites, as missões científicas ao espaço profundo também necessitam de monitoramento e controle semelhantes para o envio de telecomandos e a recepção de telemetria. As missões de satélite exigem uma equipe dedicada para realizar o monitoramento contínuo, em tempo real, do estado e da posição do satélite. O controle da missão consiste no conjunto de tarefas executadas após o lançamento por engenheiros de operações com o auxílio de aplicativos de software e envolve a troca de dados entre os segmentos terrestre e espacial para monitorar e controlar o estado dos subsistemas de bordo do satélite. Nas missões científicas, também é necessário receber as informações da carga útil do satélite e encaminhá-las aos usuários finais (a comunidade científica). As funções típicas executadas durante o controle da missão incluem a recepção e análise de telemetria, o envio de telecomandos e o rastreamento. Telemetria são os dados transmitidos do satélite para a Terra que informam sobre o estado e as condições do satélite e de seus subsistemas. Telecomandos são as ordens transmitidas do solo para a espaçonave para configurá-la e operá-la. (Uhlig, Sellmaier, and Schmidhuber 2015: 232). O rastreamento e a manutenção da estação, também conhecidos como medição de distância, consistem no monitoramento e na determinação da trajetória de voo e da posição por meio de técnicas e sinais de RF. Do ponto de vista da engenharia de software, o controle de satélites requer diferentes aplicativos e ferramentas para dinâmica de voo, planejamento de missão, telemetria e envio de telecomandos, controle e roteamento de rede, bem como interfaces entre eles. Essa complexidade levou as agências espaciais a oferecer diferentes soluções. Um dos marcos mais relevantes no desenvolvimento de software MCS foi a decisão do departamento de Engenharia de Sistemas Terrestres da ESA de desenvolver e licenciar para a indústria europeia um conjunto de aplicativos de software distribuídos sob o nome MICONYS® 4 Os satélites GEO estão distribuídos por uma área limitada do espaço. As posições orbitais são atribuídas pela União Internacional de Telecomunicações (UIT) para evitar colisões, risco relacionado à questão dos detritos espaciais, que hoje recebe cada vez mais atenção. 188 Ricardo Eito Brun │ Terminology as the Basis for Building Engineering Feature-based Models (Sistema de Controle de Missão). MICONYS e seu componente SCOS-2000® são provavelmente os exemplos mais conhecidos dessa política da ESA para o desenvolvimento de software, a inovação e a transferência de tecnologia (Kaufeler, Jones and Karl 2001). O SCOS-2000 oferece suporte a telecomandos, recepção de telemetria, exibição e arquivamento. O SCOS-2000 foi resultado da experiência adquirida pela ESA no desenvolvimento e na operação de sistemas semelhantes anteriores: MSSS, SCOS-1 e SCOS-2. Atualmente, a ESA está desenvolvendo o novo sistema MCS, destinado a substituir o SCOS-2000 no futuro. Seu nome é European Ground Systems – Common Core (EGS-CC). Assim como o SCOS, o projeto tem como objetivo desenvolver uma infraestrutura comum para dar suporte ao monitoramento e ao controle de missões espaciais nas fases pré e pós-lançamento, utilizando tecnologias modernas e arquiteturas orientadas a serviços (Peccioli et al. 2012). O desenvolvimento do EGS-CC não está sob a responsabilidade exclusiva da ESA: agências espaciais nacionais europeias (CNES, UK Space Agency e DLR) e empresas industriais (AIRBUS Defence and Space, Thales Alenia Space e OHB Systems) também fazem parte do projeto. Além dos projetos da ESA, há outras iniciativas destinadas a desenvolver um sistema de software MCS genérico. A NASA concluiu projetos semelhantes, a maioria deles desenvolvimentos internos. O Goddard Space Flight Centre desenvolveu dois sistemas, ITOS e ASIST, para gerenciar missões 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) ou LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007). Em todos esses casos, lidamos com um sistema complexo que precisa implementar diferentes funções, as quais podem ser ativadas ou não dependendo das características do satélite e da missão. Por isso, esses sistemas intensivos em software são bons candidatos ao desenvolvimento com técnicas de linhas de produtos e de modelagem baseada em funcionalidades, que dependem de uma organização clara e bem estruturada dos conceitos para compreender o domínio e as capacidades necessárias do sistema. 2. MODELAGEM BASEADA EM FUNCIONALIDADES COMO ORGANIZAÇÃO DE CONCEITOS A modelagem baseada em funcionalidades é uma das técnicas aplicadas na engenharia de linhas de produtos de software, uma disciplina voltada à criação de programas de software reutilizáveis que se tornou popular no final da década de 1990. A SPLE pretende Terminologija | 2020 | 27 189 criar componentes e artefatos reutilizáveis que possam ser posteriormente combinados para desenvolver produtos adequados às necessidades de um cliente e contexto específicos. As experiências em SPLE estão amplamente documentadas na literatura profissional e acadêmica. Capilla (2013) incluiu vários estudos de caso nos quais a SPLE foi aplicada com sucesso: programas de voo operacionais e críticos para a missão da Boeing’s para funções de aviônica e cockpit, software de controle de motores para sistemas a gasolina da Bosch’s, software para impressoras da Hewlett Packard’s, equipamentos de geração e transmissão de energia da Toshiba’s e software de controle de sistemas de propulsão da General Motors’. Os benefícios das linhas de produtos de software (SPL), segundo Apel et al. (2013: 9), incluem a adaptação dos produtos de software às necessidades específicas dos clientes, a redução de custos — pois um conjunto de ativos reutilizáveis pode ser combinado de diferentes maneiras para gerar novos produtos —, a melhoria da qualidade e a redução do tempo de comercialização. Funcionalidades e modelagem baseada em funcionalidades são conceitos relevantes no desenvolvimento de SPL. A ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, oferece uma definição geral de funcionalidades, extraída da IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: “Uma característica distintiva de um item de sistema. NOTA: inclui atributos funcionais e não funcionais, como desempenho e reutilização.” Kang and Lee (2013, 28) definem funcionalidades como “conceitos abstratos que dão suporte eficaz à comunicação entre as diversas partes interessadas de uma linha de produtos e, portanto, é natural e intuitivo que as pessoas expressem a comunalidade e a variabilidade das linhas de produtos em termos de funcionalidades.” As funcionalidades servem a diferentes propósitos no processo de concepção e desenvolvimento de produtos. Elas são meios de comunicar as características do produto e dão suporte à identificação de requisitos; também são os conceitos que orientam as decisões de projeto e implementação. O desenvolvimento de uma linha de produtos compreende dois ciclos de vida complementares: • Engenharia de domínio, e • Engenharia de aplicações. A norma IEEE 1517-2010 define engenharia de domínio como: “Ciclo de vida constituído por um conjunto de processos para especificar e gerenciar a comunalidade e a variabilidade de uma linha de produtos. A engenharia de domínio analisa o domínio de uma linha de produtos e desenvolve um conjunto de artefatos reutilizáveis. Esses artefatos incluem requisitos de software, elementos de projeto, casos de teste e 190 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models procedimentos, documentação do utilizador, etc. A análise do domínio pode ser vista como uma espécie de engenharia de requisitos para toda a linha de produtos, incluindo a identificação da variabilidade prevista. O principal artefacto gerado pela análise do domínio é o modelo de funcionalidades, que especificará e descreverá os produtos da linha. A modelação de funcionalidades é uma técnica de representação gráfica introduzida nos anos noventa com a metodologia FODA (Análise de Domínio Orientada a Funcionalidades). A FODA disponibilizou primitivas para representar relações estruturais (composição, generalização e especialização), opcionalidade, alternativas e dependências mútuas. Mais tarde, foi revista por diferentes autores (Kang e Lee 2013: 30–31). Os diagramas de funcionalidades são a representação visual dos modelos de funcionalidades, nos quais as funcionalidades são representadas por caixas numa árvore hierárquica. Cada nó tem um rótulo associado com o nome da funcionalidade. A disposição hierárquica das funcionalidades cria relações entre pais e filhos. Se uma funcionalidade filha for selecionada, a funcionalidade-pai também tem de ser selecionada. Os diagramas podem distinguir entre funcionalidades obrigatórias e opcionais e identificar as combinações válidas de funcionalidades. Em particular, os diagramas de funcionalidades podem representar: Funcionalidades abstratas, utilizadas para organizar as funcionalidades na árvore, mas não associadas a artefactos de implementação. São representadas por caixas cinzentas. Funcionalidades concretas, que correspondem a artefactos de implementação e são representadas por caixas brancas. Funcionalidades obrigatórias, que têm um marcador preenchido no topo da margem superior da respetiva caixa. Funcionalidades opcionais, que têm um marcador não preenchido no topo da margem superior da respetiva caixa. A necessidade de selecionar apenas uma das funcionalidades filhas de um determinado pai (OR exclusivo, XOR ou uma entre várias). É representada por um arco vazio na margem inferior da caixa da funcionalidade-pai. A possibilidade de selecionar mais de uma funcionalidade filha de um determinado pai (OR ou algumas entre várias). É representada por um arco preenchido na margem inferior da caixa da funcionalidade-pai. Dependências entre funcionalidades, representadas por setas com anotações textuais. Terminologija | 2020 | 27 191 O diagrama abaixo apresenta um diagrama de características típico, com as convenções descritas acima: Fig. 1. Exemplo de diagrama de características (Fonte: Gargantini 2015) Um modelo de características deve incluir informações adicionais ao diagrama. Apel et al. (2013: 27) indicam a possibilidade de acrescentar estes dados: “Descrição de uma característica e do conjunto de requisitos correspondente. Relação com outras características, especialmente hierarquia, ordem e agrupamento. Dependências externas, como os recursos de hardware necessários. Partes interessadas. Custo estimado ou medido de implementação de uma característica. Etc.” O desenvolvimento de um modelo de características para representar as características funcionais de aplicações de software destinadas ao controlo de satélites deve partir de uma compreensão e modelação claras dos conceitos que compõem o domínio. Para esse fim, as atividades relacionadas com a terminologia e a terminografia, a identificação de termos, conceitos e das suas relações fornecem a base para construir o modelo pretendido. 192 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models 3. METODOLOGIA DE TRABALHO O modelo de funcionalidades proposto foi concluído seguindo estas etapas: Identificação e revisão da literatura profissional e acadêmica publicada nesta área. Isso envolve buscar informações sobre a abordagem seguida em projetos aeroespaciais liderados por entidades como a ESA (European Space Agency) ou a NASA (National Aeronautics and Space Administration). Desenvolvimento de um glossário com base na literatura analisada, aplicando técnicas de gestão terminológica para registrar informações sobre os termos, as relações entre eles, as definições identificadas nos documentos e o contexto em que os termos são usados. Criação de um modelo baseado em funcionalidades que representa as funções oferecidas pelos aplicativos de software de monitoramento e controle de satélites, usando o glossário como base. As entradas usadas para identificar os termos incluíram um subconjunto de documentos técnicos que descrevem o produto selecionado: manuais de operação, documentos técnicos e materiais de treinamento. O modelo de funcionalidades é uma árvore hierárquica de funcionalidades assinaladas como obrigatórias ou opcionais, com dependências entre elas. No caso do aplicativo de software em análise, além da identificação de funcionalidades opcionais e obrigatórias, foram identificados requisitos adicionais de variabilidade da linha de produtos. Em particular, algumas das funções oferecidas pelo software em análise exigem a sobrescrita ou a personalização do código existente. A identificação desses casos de variabilidade foi realizada com o apoio de especialistas que atuam no desenvolvimento e na personalização desse tipo de aplicativo de software. Foram realizadas entrevistas pessoais para coletar essas informações. A ferramenta selecionada para criar o modelo de funcionalidades e os diagramas é FeatureIDE5. Trata-se de uma ferramenta de código aberto baseada em Java e Eclipse, desenvolvida por funcionários da Otto-von-Guericke-Universität Magdeburg. Com FeatureIDE, é possível criar um modelo de funcionalidades usando um editor gráfico, marcar funcionalidades como obrigatórias, opcionais ou abstratas e construir a árvore hierárquica. Depois que o modelo de funcionalidades é construído, é possível criar diferentes configurations: seleções de funcionalidades que serão usadas para gerar o aplicativo de software de destino 5 Consulte https://FeatureIDE.github.io/. Última consulta: 01-03-2018. Terminologija | 2020 | 27 193 código-fonte. Infelizmente, a ferramenta não oferece recursos para gerir termos ou unidades terminológicas, o que torna necessário recorrer a ferramentas complementares. Fig. 2. FeatureIDE (criado pelo autor) 4. APRESENTAÇÃO DOS RESULTADOS E DISCUSSÃO Esta seção resume uma parte do modelo de características para aplicações de software de Sistemas de Controle de Missão (MCS). A análise dos conceitos extraídos dos documentos levou à organização das funcionalidades do sistema nas seguintes áreas: Gestão da área de trabalho e das sessões, que fornece as funções para iniciar sessão, abrir uma sessão e executar as diferentes aplicações. No caso da gestão de vários satélites, o usuário poderá alternar entre os espaços de trabalho dos satélites. Cadeia de telemetria, que inclui processamento de telemetria, gestor de alarmes e apresentação da telemetria. 194 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models Cadeia de telecomandos, que inclui uplink de telecomandos, fila manual, fila programada e histórico de telecomandos. Ponte TT&C/TCR, que proporciona visibilidade e controle da interface com a estação terrestre para os fluxos de dados de telemetria, comando, rastreamento (TCR) e apontamento de antena. Registro de eventos, que registra os eventos identificados durante as operações do sistema e permite que os operadores naveguem e pesquisem todo o histórico de eventos. Gestão da memória de bordo, que fornece recursos para gerir (baixar, editar e enviar por uplink) a imagem da memória da nave espacial. A análise da documentação e dos termos levou à criação de modelos de características para essas funções do sistema. O caso específico da gestão da telemetria é resumido como exemplo. Pode-se observar como são apresentadas definições baseadas na literatura existente e na documentação técnica para as características identificadas: O termo cadeia de telemetria refere-se aos diferentes processos envolvidos no processamento da telemetria: recepção do TT&C, empacotamento, arquivamento e distribuição às aplicações consumidoras: Empacotamento de pacotes de telemetria. O MCS recebe os pacotes de origem da telemetria com base no padrão de pacotes de telemetria, adiciona metadados (por exemplo, a qualidade do fluxo de telemétrico) e converte-os em um ou mais pacotes internos de telemetria do MCS. Os critérios para gerar pacotes a partir dos dados recebidos podem variar conforme o satélite, a missão e os protocolos BBE. Verificação da qualidade dos pacotes. O MCS verifica continuamente a qualidade da telemetria por meio de verificações realizadas pelo TT&C ou pelo próprio MCS. Os metadados de qualidade da telemetria são anexados a cada pacote interno. Dependendo do resultado dessas verificações, o pacote pode ser classificado como adequado para processamento (GOOD) ou inadequado para processamento (BAD). As perdas de telemetria também devem ser identificadas durante o processo. Uma verificação de qualidade típica é a verificação da sequência de quadros, que avalia se os quadros são recebidos em sequência ou não. Terminologija | 2020 | 27 195 São gerados eventos caso essas verificações não sejam satisfeitas. O operador pode selecionar o comportamento a aplicar quando forem identificados quadros de telemetria BAD (processá-los ou descartá-los). • Verificações da qualidade do tempo. Estas verificações confirmam se o tempo indicado pelo TT&C para cada fluxo de telemetria e os tempos locais do MCS não diferem demasiado. A diferença entre a hora atual do MCS e a marca temporal no quadro de telemetria (definida pela estação terrestre aquando da receção do quadro) está dentro de uma janela de tempo configurável. São geradas mensagens de evento se estas verificações falharem. As verificações da qualidade do tempo requerem a marcação temporal dos pacotes de telemetria. • Descomutação da telemetria, que extrai amostras dos parâmetros de telemetria dos pacotes6. Envolve a extração de parâmetros, a descodificação de bits, a calibração, a verificação de valores fora do intervalo, a verificação da validade e a datação dos parâmetros. ○ Extração de parâmetros de telemetria localiza e extrai os valores brutos dos parâmetros de telemetria dos pacotes. Os valores brutos são normalmente números inteiros com ou sem sinal, ou números de vírgula flutuante. Este processo é simples para a telemetria fixa, uma vez que todas as informações necessárias sobre a localização do parâmetro estão disponíveis na MIB do satélite, mas é mais complexo no caso da telemetria programável. ○ Descodificação de bits obtém o valor bruto a partir do valor codificado no pacote de telemetria. Numa situação típica, o valor bruto corresponde ao valor codificado no pacote, mas há casos em que é necessária uma transformação baseada em bits (como a inversão de bits ou o complemento para dois) ou em bytes. ○ Parâmetros derivados ou sintéticos. Não são obtidos da nave espacial, mas derivados algoritmicamente em terra, usando como operandos parâmetros de telemetria adquiridos. São calculados com fórmulas escritas em linguagens de scripting. São calculados antes da calibração, das verificações de validade e da datação dos parâmetros. Um tipo especial de parâmetro derivado são os parâmetros derivados codificados diretamente no código (HCDP), escritos em linguagens de programação de baixo nível 6 Os parâmetros podem ser síncronos (transmitidos por telemetria assim que são amostrados a bordo) ou assíncronos (não transmitidos por telemetria assim que são amostrados a bordo, mas armazenados na memória de bordo e transmitidos posteriormente). Os parâmetros são normalmente amostrados e codificados uma ou várias vezes por formato, com exceção dos parâmetros subcomutados, que não são amostrados nem codificados em todos os formatos, e dos parâmetros supercomutados, que são amostrados e codificados várias vezes. 196 Ricardo Eito Brun | Terminology as the Basis for Building Engineering Feature-based Models como C++, Fortran ou C. Sua modificação requer a recompilação do código-fonte. o Datação dos parâmetros de Telemetria atribui uma data às amostras dos parâmetros, usando o horário do pacote que as contém e adicionando um deslocamento conforme especificado no MIB do satélite. o Controle de valores fora do intervalo (OOR) analisa se o valor bruto de um parâmetro de telemetria está fora do intervalo de calibração definido. Os parâmetros de telemetria fora do intervalo são considerados inválidos com a categoria OOR. OOR é usado para avaliar a validade do parâmetro de telemetria e indicar se seu valor é útil ou sem significado. Além disso, os parâmetros fora do intervalo devem ser exibidos e reconhecidos pelos operadores. Outras condições para declarar um parâmetro inválido incluem: o parâmetro está expirado ou, no caso de parâmetros derivados, foi calculado usando parâmetros inválidos. Seja qual for o caso, os metadados de invalidade do parâmetro de telemetria devem detalhar o motivo desse estado. • Calibração de parâmetros de telemetria transforma seus valores brutos em uma forma legível por humanos (valores de engenharia ou calibrados, com as unidades correspondentes à grandeza física). A calibração pode ser realizada por diferentes métodos: o Calibração numérica ou linear discreta: usa-se interpolação linear a partir de uma curva de calibração composta por pares (X, Y), em que X representa o valor bruto e Y, o valor de engenharia. o Calibração textual, digital ou de estado: associa cadeias de texto a intervalos de valores brutos dos parâmetros. Os valores textuais podem ser obtidos de valores discretos ou de um intervalo deles. Um exemplo simples é o estado LIGADO / DESLIGADO das unidades a bordo, que poderia ser obtido a partir de um parâmetro de um bit, em que 0 significa DESLIGADO e 1 significa LIGADO. o Calibração polinomial: utiliza um polinômio de até quinto grau para converter valores brutos em valores de engenharia. Sem entrar em mais detalhes sobre as funcionalidades extraídas (apenas um subconjunto é descrito para mostrar como sua identificação requer um trabalho terminológico rigoroso), o diagrama a seguir apresenta as principais funcionalidades identificadas para esta área funcional: Terminologija | 2020 | 27 197 Fig. 3. Processamento de TM – Funcionalidades Fig 1: FeatureIDE (criado pelo autor) 5. CONCLUSÕES Este artigo descreve o desenvolvimento de um modelo de funcionalidades para aplicações de software de controlo de satélites, utilizando como entradas documentos técnicos (manuais de operação, documentos técnicos e materiais de formação) que descrevem as funcionalidades do tipo de sistema em estudo. O primeiro passo é a 198 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models identificação e extração de termos através da análise dos documentos, identificando as respetivas definições por meio do contexto em que são aplicados. Esta coleção de termos é posteriormente analisada para identificar funcionalidades, que foram organizadas no modelo e no diagrama de funcionalidades de acordo com critérios funcionais, em doze categorias principais: gestão de sessões, gestão da ligação à estação terrestre, processamento de telemetria, apresentação de dados de telemetria, processamento de telecomandos, arquivo da missão, etc. Para cada área funcional, a descrição dos principais conceitos e das características que um sistema de software deve suportar foi resumida e representada em diagramas de funcionalidades criados com a ferramenta FeatureIDE. As definições e o contexto de utilização também serviram de base para estabelecer a relação entre as funcionalidades e identificar oportunidades de variabilidade. Foram identificadas três razões principais para a variabilidade: Parâmetros de configuração específicos da missão, geralmente geridos por ficheiros de configuração públicos. Seleção de funcionalidades opcionais, dependendo do tipo de missão: por exemplo, telecomandos baseados na posição, característicos dos satélites LEO para observação da Terra. Personalização dos serviços específicos da missão que ampliam os serviços e as funções básicos definidos nas normas de telemetria e telecomandos, como a PUS. Este trabalho demonstra a necessidade de aplicar técnicas relacionadas com a terminologia para recolher, analisar e documentar o significado dos termos e extrair relações que possam ser posteriormente utilizadas para diferentes fins. No caso dos modelos de engenharia baseados em funcionalidades, os termos constituem a base para descrever inequivocamente as funções do software e dos sistemas e identificar as características de sistemas complexos. A consistência no uso dos termos também é necessária para garantir que os diferentes agentes envolvidos nas tarefas de engenharia subsequentes (conceção, implementação, testes, etc.) partilhem uma compreensão comum das funcionalidades do sistema, evitando erros causados por uma definição insuficiente do domínio que o sistema se destina a suportar. 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