Terminology as the Basis for Building Engineering Feature-based Models

doi.org/10.35321/term27-08 La terminologie comme fondement de la construction de modèles d’ingénierie fondés sur les caractéristiques RICARDO EITO BRUN Universidad Carlos III de Madrid RÉSUMÉ Les opérations satellitaires nécessitent l’utilisation combinée de différents outils pour soutenir les activités d’ingénierie et contrôler le véhicule spatial. Ces communications sont gérées par le Système de surveillance et de contrôle (MCS), qui reçoit les données de télémétrie du véhicule spatial et émet des télécommandes afin de maintenir l’attitude et la trajectoire de vol du satellite. Ces systèmes complexes sont développés sous forme de plateformes ouvertes, extensibles et personnalisables pour répondre aux exigences et aux objectifs propres à chaque mission. De manière générale, on peut affirmer que ces applications logicielles se prêtent bien à la mise en œuvre structurée et planifiée de mécanismes de variabilité, et que leurs fonctionnalités constituent un bon terrain pour analyser la faisabilité de l’application de techniques de modélisation fondées sur les caractéristiques. Cet article décrit l’utilisation de l’analyse terminologique pour élaborer un modèle de caractéristiques destiné à soutenir l’analyse des exigences de ce type de systèmes logiciels. MOTS-CLÉS: terminologie technique, modèles fondés sur les caractéristiques, ingénierie aérospatiale, extraction terminologique RÉSUMÉ Les opérations satellitaires nécessitent divers outils pour assurer le bon déroulement des activités d’ingénierie et contrôler le véhicule spatial. Ces communications sont gérées par le Système de surveillance et de contrôle (SKS), qui reçoit les données de télémétrie du véhicule spatial et émet des télécommandes afin de maintenir l’attitude et la trajectoire orbitale du satellite. Ces systèmes complexes sont conçus comme des plateformes ouvertes, qui peuvent être étendues et adaptées aux exigences et aux objectifs propres à chaque mission. En règle générale, on peut affirmer que ces applications logicielles se prêtent à la mise en œuvre structurée et planifiée de mécanismes de variabilité, et que leurs fonctionnalités permettent d’analyser les possibilités d’application des méthodes de modélisation par caractéristiques. Cet article décrit l’utilisation de l’analyse terminologique pour élaborer un modèle de caractéristiques destiné à soutenir l’analyse des exigences de ce type de systèmes logiciels. MOTS-CLÉS: terminologie technique, modèles de caractéristiques, ingénierie aéronautique, extraction de termes 186 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models 1. INTRODUCTION Le glossaire de la NASA définit les satellites comme suit: « un objet volant librement qui orbite autour de la Terre, d’une autre planète ou du Soleil. » Les satellites sont un type de véhicule spatial qui suit une orbite régulière et clairement définie autour du centre de gravité d’un autre corps céleste (Garner 1996: 4). Depuis le lancement des premiers satellites artificiels – Sputnik 1 le 4 octobreth 1957 et Explorer 1 le 31 janvierst 1958, un grand nombre de missions satellitaires ont été lancées à des fins diverses: exploration astronomique, fourniture de services de communication et de navigation, observation de la Terre, reconnaissance et missions scientifiques. Les satellites sont des systèmes aérospatiaux complexes composés d’éléments au sol et dans l’espace: le véhicule spatial doit être exploité par un élément de contrôle sur Terre et rester en contact avec celui-ci. Aujourd’hui, les progrès scientifiques et les services destinés aux utilisateurs dépendent des satellites et des constellations de satellites. Parmi les exemples notables figurent le télescope spatial Hubble (HST), des systèmes de navigation comme le GPS (Global Positioning System), GLONASS et le Galileo européen, UARS (Upper Atmosphere Research Satellite) ou GOES (Geostationary Operational Environment Satellite). Le nombre total de satellites lancés depuis 1957 – selon le catalogue de l’US SSN2 – est proche de 18 200; l’Index of Objects Launched into Outer Space 2017 de l’UNOOSA recense 4 635 satellites actuellement en orbite autour de la planète, soit une augmentation de 357 satellites (8,95%) par rapport à l’année précédente3. Cet article vise à démontrer la nécessité d’appliquer la gestion et l’extraction terminologiques pour soutenir le développement de modèles fondés sur les caractéristiques, afin d’organiser les concepts décrivant les fonctions des applications logicielles utilisées pour la surveillance et le contrôle des satellites. Les satellites sont classés selon leur fonction et leur type d’orbite. La fonction renvoie aux services que le satellite est destiné à fournir. En ce qui concerne l’orbite, on distingue l’orbite terrestre basse (LEO), l’orbite terrestre moyenne (MEO) et l’orbite géostationnaire (GEO). Les satellites LEO – utilisés à des fins scientifiques et pour l’observation de la Terre – suivent une orbite elliptique; comme leur visibilité depuis les stations au sol est limitée, les données sont stockées à bord et transmises au sol 1 Voir https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [consulté le 2020-08-01]. 2 Le réseau de surveillance spatiale des États-Unis est chargé de la détection, du suivi, du catalogage et de l’identification des objets artificiels en orbite autour de la Terre. Le catalogue est disponible à l’adresse suivante: https://www.space-track.org/#/ssr [consulté le 2020-08-01]. 3 Bureau des Nations Unies pour les affaires spatiales. Voir https://www.pixalytics.com/sats-orbiting-earth-2017/ Terminologija | 2020 | 27 187 lorsque l’engin devient visible depuis les stations. Les satellites GEO sont utilisés à des fins de télécommunication et de météorologie; les satellites de télécommunication reçoivent des signaux de radiofréquence (RF) depuis la Terre, les amplifient, décalent leur fréquence et les retransmettent vers la Terre. Ils orbitent à 36 000 km au-dessus de l’équateur (dans le même plan), et leur rotation est synchronisée avec celle de la Terre, de sorte qu’ils restent en permanence au-dessus du même point de l’équateur)4. À l’instar des satellites, les missions scientifiques dans l’espace lointain nécessitent également une surveillance et un contrôle similaires pour l’envoi de télécommandes et la réception de télémesures. Les missions satellitaires nécessitent du personnel spécialisé pour assurer une surveillance continue en temps réel de l’état et de la position du satellite. Le contrôle de mission regroupe les tâches effectuées après le lancement par les ingénieurs d’exploitation à l’aide d’applications logicielles; il implique l’échange de données entre les segments sol et spatial afin de surveiller et de contrôler l’état des sous-systèmes embarqués du satellite. Dans les missions scientifiques, il est également nécessaire de recevoir les informations de la charge utile du satellite et de les transmettre aux utilisateurs finaux (la communauté scientifique). Les fonctions typiques exécutées pendant le contrôle de mission comprennent la réception et l’analyse des télémesures, l’envoi de télécommandes et le suivi. La télémétrie correspond aux données transmises par le satellite vers la Terre pour renseigner sur son état et les conditions de fonctionnement de ses sous-systèmes. Les télécommandes sont les ordres transmis depuis le sol au véhicule spatial pour le configurer et le faire fonctionner. (Uhlig, Sellmaier, and Schmidhuber 2015: 232). Le suivi et le maintien à poste, également appelés télémétrie de distance, consistent à surveiller et à déterminer la trajectoire et la position à l’aide de techniques et de signaux RF. Du point de vue du génie logiciel, le contrôle des satellites nécessite différentes applications et différents outils pour la dynamique de vol, la planification de mission, la télémétrie et l’envoi de télécommandes, le contrôle et le routage du réseau, ainsi que des interfaces entre ces éléments. Cette complexité a conduit les agences spatiales à proposer différentes solutions. L’une des étapes les plus marquantes dans le développement des logiciels MCS a été la décision du département d’ingénierie des systèmes au sol de l’ESA de développer et d’accorder sous licence à l’industrie européenne un ensemble d’applications logicielles distribuées sous le nom de MICONYS® 4 Les satellites GEO sont répartis dans une zone limitée de l’espace. Les positions orbitales sont attribuées par l’Union internationale des télécommunications (UIT) afin d’éviter les collisions, un risque associé à la question des débris spatiaux, qui retient aujourd’hui une attention croissante. 188 Ricardo Eito Brun │ Terminology as the Basis for Building Engineering Feature-based Models (Mission Control System). MICONYS et son composant SCOS-2000® sont probablement les exemples les plus connus de cette politique de l’ESA en matière de développement logiciel, d’innovation et de transfert technologique (Kaufeler, Jones and Karl 2001). SCOS-2000 prend en charge l’envoi de télécommandes, la réception de télémétrie, l’affichage et l’archivage. SCOS-2000 est le fruit de l’expérience acquise par l’ESA dans le développement et l’exploitation de systèmes antérieurs similaires: MSSS, SCOS-1 et SCOS-2. Aujourd’hui, l’ESA développe le nouveau système MCS, destiné à remplacer SCOS-2000 à l’avenir. Son nom est European Ground Systems – Common Core (EGS-CC). Comme SCOS, le projet vise à développer une infrastructure commune pour prendre en charge la surveillance et le contrôle des missions spatiales dans les phases précédant et suivant le lancement, au moyen de technologies modernes et d’architectures orientées services (Peccioli et al. 2012). Le développement d’EGS-CC n’est pas placé sous la seule responsabilité de l’ESA: des agences spatiales nationales européennes (CNES, UK Space Agency et DLR) ainsi que des entreprises industrielles (AIRBUS Defence and Space, Thales Alenia Space et OHB Systems) participent au projet. Outre les projets de l’ESA, d’autres initiatives visent à développer un système logiciel MCS générique. La NASA a mené à bien des projets similaires, dont la plupart ont été développés en interne. Le Goddard Space Flight Centre a développé deux systèmes, ITOS et ASIST, pour gérer des missions telles que 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). Dans tous ces cas, il s’agit d’un système complexe qui doit mettre en œuvre différentes fonctions, susceptibles d’être activées ou non selon les caractéristiques du satellite et de la mission. Par conséquent, ces systèmes à forte composante logicielle se prêtent bien au développement selon les approches de lignes de produits et de modélisation fondée sur les fonctionnalités, qui reposent sur une organisation claire et structurée des concepts afin de comprendre le domaine et les capacités requises du système. 2. MODÉLISATION FONDÉE SUR LES FONCTIONNALITÉS COMME ORGANISATION DES CONCEPTS La modélisation fondée sur les fonctionnalités est l’une des techniques appliquées à l’ingénierie des lignes de produits logiciels, discipline visant à créer des programmes logiciels réutilisables, devenue populaire à la fin des années 1990. SPLE vise à Terminologija | 2020 | 27 189 créer des composants et des artefacts réutilisables pouvant ensuite être combinés pour concevoir des produits répondant aux besoins d’un client et d’un contexte spécifiques. Les expériences en SPLE sont largement documentées dans la littérature professionnelle et universitaire. Capilla (2013) présente plusieurs études de cas dans lesquelles la SPLE a été appliquée avec succès: les programmes de vol opérationnels critiques pour les missions de Boeing’s pour l’avionique et les fonctions du poste de pilotage, les logiciels de commande moteur de Bosch’s pour les systèmes à essence, les logiciels d’imprimante de Hewlett Packard’s, les équipements de production et de transmission d’énergie de Toshiba’s, ainsi que les logiciels de commande des groupes motopropulseurs de General Motors’. Selon Apel et al. (2013: 9), les avantages des lignes de produits logiciels (SPL) comprennent l’adaptation des produits logiciels aux besoins spécifiques des clients, la réduction des coûts — puisqu’un ensemble de ressources réutilisables peut être combiné de différentes manières pour générer de nouveaux produits —, l’amélioration de la qualité et la réduction du délai de mise sur le marché. Les fonctionnalités et la modélisation fondée sur les fonctionnalités sont des concepts importants pour le développement des SPL. La norme ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, propose une définition générale des features, tirée de la norme IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: « Une caractéristique distinctive d’un élément de système. NOTE: comprend les attributs fonctionnels et non fonctionnels, tels que les performances et la réutilisabilité. » Kang and Lee (2013, 28) définissent les fonctionnalités comme « des concepts abstraits qui facilitent efficacement la communication entre les diverses parties prenantes d’une ligne de produits; il est donc naturel et intuitif d’exprimer les points communs et la variabilité des lignes de produits en termes de fonctionnalités. » Les fonctionnalités remplissent différents rôles dans le processus de conception et de développement des produits. Elles permettent de communiquer les caractéristiques du produit et facilitent l’identification des exigences; elles constituent également les concepts qui orientent les décisions de conception et de mise en œuvre. Le développement d’une ligne de produits comprend deux cycles de vie complémentaires: • Ingénierie du domaine, et • Ingénierie des applications. La norme IEEE 1517-2010 définit l’ingénierie du domaine comme suit: « Cycle de vie comprenant un ensemble de processus visant à spécifier et à gérer les points communs et la variabilité d’une ligne de produits. L’ingénierie du domaine analyse le domaine d’une ligne de produits et développe un ensemble d’artefacts réutilisables. Ces artefacts comprennent les exigences logicielles, les éléments de conception, les cas de test et 190 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models procédures, documentation utilisateur, etc. L’analyse de domaine peut être considérée comme une forme d’ingénierie des exigences pour l’ensemble de la ligne de produits, y compris l’identification de la variabilité anticipée. Le principal artefact produit par l’analyse de domaine est le modèle de fonctionnalités, qui spécifiera et décrira les produits de la ligne. La modélisation des fonctionnalités est une technique de représentation graphique introduite dans les années 1990 avec la méthodologie FODA (Feature-Oriented Domain Analysis). FODA a fourni des primitives pour représenter les relations structurelles (composition, généralisation et spécialisation), le caractère facultatif, les alternatives et les dépendances mutuelles. Elle a ensuite été révisée par différents auteurs (Kang et Lee 2013: 30–31). Les diagrammes de fonctionnalités sont la représentation visuelle des modèles de fonctionnalités, dans lesquels les fonctionnalités sont représentées par des boîtes disposées en arbre hiérarchique. Chaque nœud porte une étiquette indiquant le nom de la fonctionnalité. La disposition hiérarchique des fonctionnalités crée des relations parent-enfant. Si une fonctionnalité enfant est sélectionnée, son parent doit également l’être. Les diagrammes peuvent distinguer les fonctionnalités obligatoires des fonctionnalités facultatives, et indiquer les combinaisons de fonctionnalités valides. En particulier, les diagrammes de fonctionnalités peuvent représenter: Les fonctionnalités abstraites, qui servent à organiser les fonctionnalités dans l’arbre, mais ne sont pas liées à des artefacts d’implémentation. Elles sont représentées par des boîtes grises. Les fonctionnalités concrètes, qui correspondent à des artefacts d’implémentation et sont représentées par des boîtes blanches. Les fonctionnalités obligatoires, marquées par un point plein au-dessus de la bordure supérieure de leur boîte. Les fonctionnalités facultatives, marquées par un point non rempli au-dessus de la bordure supérieure de leur boîte. La nécessité de sélectionner une seule fonctionnalité enfant parmi celles d’un parent donné (OU exclusif, XOR, ou one-out-of-many). Elle est représentée par un arc vide sur la bordure inférieure de la boîte de la fonctionnalité parent. La possibilité de sélectionner plusieurs fonctionnalités enfants parmi celles d’un parent donné (OU ou some-out-of-many). Elle est représentée par un arc plein sur la bordure inférieure de la boîte de la fonctionnalité parent. Les dépendances entre fonctionnalités, représentées par des flèches accompagnées d’annotations textuelles. Terminologija | 2020 | 27 191 Le diagramme ci-dessous présente un diagramme de caractéristiques type, selon les conventions décrites ci-dessus: Fig. 1. Exemple de diagramme de caractéristiques (Source: Gargantini 2015) Un modèle de caractéristiques devrait comporter des informations allant au-delà du diagramme. Apel et al. (2013: 27) indiquent la possibilité d’ajouter les données suivantes: « Description d’une caractéristique et de l’ensemble d’exigences qui lui correspond. Relation avec les autres caractéristiques, notamment leur hiérarchie, leur ordre et leur regroupement. Dépendances externes, telles que les ressources matérielles requises. Parties prenantes concernées. Coût estimé ou mesuré de la réalisation d’une caractéristique. Etc. » L’élaboration d’un modèle de caractéristiques destiné à représenter les propriétés fonctionnelles des applications logicielles de contrôle des satellites doit commencer par une compréhension claire et une modélisation des concepts qui constituent le domaine. À cette fin, les activités liées à la terminologie et à la terminographie, ainsi qu’à l’identification des termes, des concepts et de leurs relations, constituent le fondement de l’élaboration du modèle visé. 192 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models 3. MÉTHODOLOGIE DE TRAVAIL Le modèle de fonctionnalités proposé a été élaboré en suivant les étapes suivantes: Identification et examen de la littérature professionnelle et universitaire publiée dans ce domaine. Cela implique de rechercher des informations sur l’approche suivie dans les projets aérospatiaux menés par des organismes tels que l’ESA (European Space Agency) ou la NASA (National Aeronautics and Space Administration). Élaboration d’un glossaire fondé sur la littérature analysée, en appliquant des techniques de gestion terminologique pour consigner des informations sur les termes, les relations entre ceux-ci, les définitions relevées dans les documents et le contexte dans lequel les termes sont utilisés. Création, à partir du glossaire, d’un modèle fondé sur les fonctionnalités qui représente les fonctions offertes par les applications logicielles de surveillance et de contrôle des satellites. Les données utilisées pour identifier les termes comprenaient un sous-ensemble de documents techniques décrivant le produit sélectionné: manuels d’exploitation, livres blancs et supports de formation. Le modèle de fonctionnalités est un arbre hiérarchique de fonctionnalités marquées comme obligatoires ou facultatives, avec des dépendances entre elles. Dans le cas de l’application logicielle analysée, outre l’identification des fonctionnalités facultatives et obligatoires, des exigences supplémentaires de variabilité de ligne de produits ont été identifiées. En particulier, certaines des fonctions prises en charge par le logiciel analysé nécessitent le remplacement ou la personnalisation du code existant. Ces cas de variabilité ont été identifiés avec l’aide d’experts qui travaillent au développement et à la personnalisation de ce type d’application logicielle. Des entretiens individuels ont été menés pour recueillir ces informations. L’outil choisi pour créer le modèle de fonctionnalités et les diagrammes est FeatureIDE5. Il s’agit d’un outil open source fondé sur Java et Eclipse, développé par le personnel de l’Otto-von-Guericke-Universität Magdeburg. Avec FeatureIDE, il est possible de créer un modèle de fonctionnalités à l’aide d’un éditeur graphique, de marquer les fonctionnalités comme obligatoires, facultatives ou abstraites, et de construire l’arbre hiérarchique. Une fois le modèle de fonctionnalités créé, il est possible de créer différentes configurations: des sélections de fonctionnalités qui seront utilisées pour générer l’application logicielle cible 5 Voir https://FeatureIDE.github.io/. Dernière vérification: 01-03-2018. Terminologija | 2020 | 27 193 du code source. Malheureusement, l’outil ne permet pas de gérer les termes ou les unités terminologiques, ce qui rend nécessaire l’utilisation d’outils complémentaires. Fig. 2. FeatureIDE (créé par l’auteur) 4. PRÉSENTATION DES RÉSULTATS ET DISCUSSION Cette section résume une partie du modèle de fonctionnalités des applications logicielles de systèmes de contrôle de mission (MCS). L’analyse des concepts extraits des documents a conduit à organiser les fonctionnalités du système dans les domaines suivants: Gestion du bureau et des sessions, qui fournit les fonctions permettant de se connecter, de démarrer une session et de lancer les différentes applications. Lorsqu’il s’agit de gérer plusieurs satellites, l’utilisateur peut passer d’un espace de travail à l’autre. Chaîne de télémétrie, qui comprend le traitement de la télémétrie, le gestionnaire d’alarmes et l’affichage de la télémétrie. 194 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models Chaîne de télécommandes, qui comprend la liaison montante des télécommandes, la pile manuelle, la pile planifiée et l’historique des télécommandes. Passerelle TT&C/TCR, qui offre une visibilité et un contrôle de l’interface avec la station au sol pour les flux de données de télémétrie, de commande, de télémesure de distance (TCR) et de pointage d’antenne. Journal des événements, qui consigne les événements identifiés pendant le fonctionnement du système et permet aux opérateurs de parcourir et de rechercher l’historique complet des événements. Gestion de la mémoire de bord, qui fournit des outils pour gérer (télécharger, modifier et transmettre par liaison montante) l’image mémoire du véhicule spatial. L’analyse de la documentation et des termes a conduit à la création de modèles de fonctionnalités pour ces fonctions du système. Le cas particulier de la gestion de la télémétrie est résumé à titre d’exemple. On peut constater que des définitions fondées sur la littérature existante et la documentation technique sont fournies pour les fonctionnalités identifiées: Le terme chaîne de télémétrie désigne les différents processus intervenant dans le traitement de la télémétrie: réception depuis le TT&C, mise en paquets, archivage et distribution aux applications clientes: Mise en paquets de la télémétrie. Le MCS reçoit les paquets source de télémétrie conformes à la norme de paquets de télémétrie, leur ajoute des métadonnées (par exemple, la qualité du flux de télémétrie) et les convertit en un ou plusieurs paquets internes de télémétrie du MCS. Les critères de génération de paquets à partir des données entrantes peuvent varier selon le satellite, la mission et les protocoles BBE. Contrôle de la qualité des paquets. Le MCS contrôle en continu la qualité de la télémétrie au moyen de vérifications effectuées soit par le TT&C, soit par le MCS lui-même. Des métadonnées relatives à la qualité de la télémétrie sont ajoutées à chaque paquet interne. Selon le résultat de ces vérifications, le paquet peut être classé comme apte au traitement (GOOD) ou inapte au traitement (BAD). Les pertes de télémétrie doivent également être identifiées au cours du processus. Un contrôle de qualité typique est la vérification de la séquence des trames, qui détermine si les trames sont reçues dans l’ordre ou non. Terminologija | 2020 | 27 195 Des événements sont déclenchés lorsque ces vérifications ne sont pas satisfaites. L’opérateur peut sélectionner le comportement à appliquer lorsque des trames de télémétrie BAD sont identifiées (les traiter ou les éliminer). • Vérifications de la qualité temporelle. Ces vérifications déterminent si l’heure indiquée par le TT&C pour chaque flux de télémétrie et les heures locales du MCS sont suffisamment proches. L’écart entre l’heure courante du MCS et l’horodatage de la trame de télémétrie (défini par la station sol lors de la réception de la trame) se situe dans une fenêtre temporelle configurable. Des messages d’événement sont générés si ces vérifications échouent. Les vérifications de la qualité temporelle nécessitent l’horodatage des paquets de télémétrie. • Démultiplexage de la télémétrie, qui extrait des paquets les échantillons des paramètres de télémétrie6. Il comprend l’extraction des paramètres, le décodage des bits, l’étalonnage, la vérification des valeurs hors plage, la vérification de validité et l’horodatage des paramètres. ○ Extraction des paramètres de télémétrie localise et extrait des paquets les valeurs brutes des paramètres de télémétrie. Les valeurs brutes sont généralement des entiers signés ou non signés, ou des nombres à virgule flottante. Ce processus est simple pour la télémétrie fixe, car toutes les informations nécessaires sur l’emplacement du paramètre sont disponibles dans la MIB du satellite, mais il est plus complexe pour la télémétrie programmable. ○ Décodage des bits permet d’obtenir la valeur brute à partir de la valeur encodée dans le paquet de télémétrie. Dans une situation typique, la valeur brute correspond à celle encodée dans le paquet, mais certains cas nécessitent une transformation au niveau des bits (par exemple, inversion des bits ou complément à deux) ou des octets. ○ Paramètres dérivés ou synthétiques. Ils ne sont pas acquis depuis le véhicule spatial, mais calculés algorithmiquement au sol à partir de paramètres de télémétrie acquis, utilisés comme opérandes. Ils sont calculés au moyen de formules écrites dans des langages de script. Ils sont calculés avant l’étalonnage, les vérifications de validité et l’horodatage des paramètres. Un type particulier de paramètre dérivé est constitué des paramètres dérivés codés en dur (HCDP), écrits dans des langages de programmation de bas niveau. 6 Les paramètres peuvent être synchrones (télédéchargés par télémétrie dès leur échantillonnage à bord) ou asynchrones (non télédéchargés par télémétrie dès leur échantillonnage à bord, mais stockés dans la mémoire de bord et télédéchargés ultérieurement). Les paramètres sont généralement échantillonnés et encodés une ou plusieurs fois par format, à l’exception des paramètres sous-commutés, qui ne sont pas échantillonnés ni encodés dans tous les formats, et des paramètres surcommutés, qui sont échantillonnés et encodés plusieurs fois. 196 Ricardo Eito Brun | Terminology as the Basis for Building Engineering Feature-based Models comme C++, Fortran ou C. Leur modification nécessite la recompilation du code source. o Datation des paramètres de télémétrie attribue une date aux échantillons de paramètres, en utilisant l’heure du paquet qui les contient et en ajoutant un décalage tel que spécifié dans le MIB du satellite. o Contrôle des valeurs hors plage (OOR) analyse si la valeur brute d’un paramètre de télémétrie se situe en dehors de la plage d’étalonnage définie. Les paramètres de télémétrie hors plage sont déclarés invalides avec la catégorie OOR. OOR sert à évaluer la validité du paramètre de télémétrie et à indiquer si sa valeur est utile ou dépourvue de signification. En outre, les paramètres hors plage doivent être affichés et acquittés par les opérateurs. Parmi les autres conditions permettant de déclarer un paramètre invalide figurent son expiration ou, dans le cas des paramètres dérivés, le fait qu’ils aient été calculés à partir de paramètres invalides. Dans tous les cas, les métadonnées d’invalidité du paramètre de télémétrie doivent préciser la raison de cet état. • Étalonnage des paramètres de télémétrie transforme leurs valeurs brutes en une forme lisible par l’être humain (valeurs d’ingénierie ou étalonnées, assorties des unités correspondant à la grandeur physique). L’étalonnage peut être réalisé selon différentes méthodes: o Étalonnage numérique ou linéaire discret: une interpolation linéaire est effectuée à partir d’une courbe d’étalonnage constituée de couples (X, Y), où X représente la valeur brute et Y la valeur d’ingénierie. o Étalonnage textuel, numérique ou d’état: il associe des chaînes de texte aux plages de valeurs brutes des paramètres. Les valeurs textuelles peuvent être obtenues à partir de valeurs discrètes ou d’une plage de valeurs. Un exemple simple est l’état ON / OFF des unités embarquées, qui pourrait être obtenu à partir d’un paramètre d’un bit, où 0 signifie OFF et 1 signifie ON. o Étalonnage polynomial: il utilise un polynôme de degré cinq au maximum pour convertir les valeurs brutes en valeurs d’ingénierie. Sans entrer davantage dans le détail des fonctionnalités extraites (seul un sous-ensemble est décrit afin de montrer que leur identification exige un travail terminologique rigoureux), le diagramme suivant présente les principales fonctionnalités identifiées pour ce domaine fonctionnel: Terminologija | 2020 | 27 197 Fig. 3. Traitement TM – Fonctionnalités Fig 1: FeatureIDE (créé par l’auteur) 5. CONCLUSIONS Cet article décrit l’élaboration d’un modèle de fonctionnalités pour des applications logicielles de contrôle de satellites, à partir de documents techniques (manuels d’exploitation, livres blancs et supports de formation) décrivant les fonctionnalités du type de système étudié. La première étape consiste à 198 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models identifier et extraire les termes en examinant les documents, puis à repérer leurs définitions dans les contextes où ils sont employés. Cette collection de termes fait ensuite l’objet d’une analyse visant à identifier les fonctionnalités, qui sont organisées dans le modèle et le diagramme de fonctionnalités selon des critères fonctionnels, au sein de douze catégories principales: gestion des sessions, gestion des connexions aux stations au sol, traitement de la télémétrie, affichage des données de télémétrie, traitement des télécommandes, archives de mission, etc. Pour chaque domaine fonctionnel, la description des concepts principaux et des caractéristiques qu’un système logiciel doit prendre en charge a été résumée et représentée dans des diagrammes de fonctionnalités créés avec l’outil FeatureIDE. Les définitions et le contexte d’utilisation ont également servi de base pour établir les relations entre les fonctionnalités et repérer les possibilités de variabilité. Trois principales raisons de variabilité ont été identifiées: Paramètres de configuration spécifiques à la mission, généralement gérés au moyen de fichiers de configuration publics. Sélection de fonctionnalités optionnelles en fonction du type de mission: par exemple, les télécommandes basées sur la position, caractéristiques des satellites en orbite terrestre basse (LEO) dédiés à l’observation de la Terre. Personnalisation des services propres à la mission, qui étendent les services et fonctions de base définis dans les normes de télémétrie et de télécommande telles que PUS. Ce travail démontre la nécessité d’appliquer des techniques liées à la terminologie pour collecter, analyser et documenter le sens des termes, ainsi que pour extraire des relations susceptibles d’être utilisées ultérieurement à différentes fins. Dans le cas des modèles d’ingénierie fondée sur les fonctionnalités, les termes constituent la base permettant de décrire sans ambiguïté les fonctions du logiciel et des systèmes, et de repérer les caractéristiques des systèmes complexes. La cohérence dans l’emploi des termes est également nécessaire pour garantir que les différents acteurs participant aux tâches d’ingénierie ultérieures (conception, mise en œuvre, tests, etc.) partagent une compréhension commune des fonctionnalités du système, et éviter les erreurs dues à une définition insuffisante du domaine que le système est destiné à prendre en charge. 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