Terminology as the Basis for Building Engineering Feature-based Models

186 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models doi.org/10.35321/term27-08 Terminology as the Basis for Building Engineering Feature-based Models RicaRdo Eito BRun Universidad Carlos III de Madrid ABSTRACT Satellite operations require the combined use of different tools to support engineering activities and to control the spacecraft. This communication is managed by the Monitoring and Control System (MCS) that receives telemetry data from the spacecraft and releases telecommands to keep the satellite’s attitude and flight path. These complex systems are developed as open platforms that can be extended and customised to support mission-specific requirements and objectives. As a general rule, it can be stated that these software applications are good candidates for implementing variability mechanisms in a structured, planned way and that their functionality is a good candidate to analyse the feasibility of applying feature-based modelling techniques. This paper describes the use of terminology analysis to build a feature model to support requirements analysis for this type of software-based systems. KEYWORDS: Technical terminology, Feature-based models, Aerospace engineering, Terminology extraction ANOTACIJA Palydovų operacijoms reikalingi įvairūs įrankiai, skirti užtikrinti sklandų inžinerinį darbą ir valdyti erdvėlaivį. Šį 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ą. Šios sudėtingos sistemos yra sukurtos kaip atviros platformos, kurias galima išplėsti ir pritaikyti pagal konkrečios misijos reikalavimus ir tikslus. Galime teigti, kad paprastai šios taikomosios programos gali būti naudojamos norint struktūruotai ir planuotai įdiegti variantiškumo mechanizmus, o jų funkcionalumas leidžia analizuoti požymių modeliavimo metodikų pritaikymo galimybes. Šiame straipsnyje aprašomas terminologinės analizės panaudojimas požymių modeliui, palaikančiam reikalavimų analizę šio tipo programinėms sistemoms, sukurti. ESMINIAI ŽODŽIAI: techninė terminologija, požymių modeliai, aviacijos inžinerija, terminų atpažinimas 187Terminologija | 2020 | 27 1. INTROduCTION NASA glossary defines satellites as: “a free-flying object that orbits the Earth, another planet, or the sun.1” Satellites are a type of spacecraft that travels in a regular, clearly defined orbit around the centre of gravity of another celestial body (Garner 1996: 4). Since the launch of the first artificial satellites – Sputnik 1 on October 4th, 1957 and Explorer 1 on January 31st, 1958, a large number of satellite missions have been launched with different purposes: astronomical exploration, provision of communication and navigation services, earth observation, reconnaissance, and scientific missions. Satellites are complex aerospace systems made up of groundand space-based elements: the spacecraft must be operated by a controlling element on Earth and remain in contact with it. Today, scientific progress and services for users depend on satellites and satellite constellations. Relevant examples include the Hubble Space Telescope (HST), navigation systems like GPS (Global Positioning System), GLONASS and the European Galileo, UARS (Upper Atmosphere Research Satellite) or GOES (Geostationary Operational Environment Satellite). The total number of satellites launched since 1957 – according to the US SSN2 catalogue – Is close to 18200; uNOOSA’s 2017 Index of Objects Launched into Outer Space reports 4635 satellites currently orbiting the planet, with an increment of 357 satellites (8.95%) concerning the previous year3. The purpose of this article is to demonstrate the need of applying terminology management and extraction to support the development of featurebased models to organize the concepts that describe the functions of the software applications used for satellite monitoring and control. Satellites are classified by purpose and type of orbit. The purpose refers to the services the satellite is intended to provide. Regarding the orbit, a distinction is made between Low Earth Orbit (LEO), Medium Earth Orbit (MEO), and Geostationary Orbit (GEO). LEO satellites – used for science and Earth observation – follow an elliptical orbit; as their visibility from ground stations is limited, data are stored on-board and sent to the ground 1 See https://www.grc.nasa.gov/www/k-12/TRC/laefs/laefs_s.html#satellite [accessed 2020-08-01]. 2 The US Space Surveillance Network is in charge of the detection, tracking, cataloguing and identification of artificial objects orbiting the earth. The catalogue is available at: https://www.space-track.org/#/ssr [accessed 2020-08-01]. 3 United Nations Office for Outer Space Affairs. See https://www.pixalytics.com/sats-orbiting-earth-2017/ 188 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models stations when the aircraft becomes visible. GEO satellites are used for telecommunication and meteorological purposes; telecommunication satellites receive radio frequency (RF) signals from the Earth, amplify them, shift their frequency, and transmit them back to the Earth. They orbit 36000 km above the Equator (in the same plane), and their rotation is synchronous with the rotation of the Earth, staying above the same point at the Equator all the time)4. Similar to satellites, deep space scientific missions also need similar monitoring and control for telecommand, and telemetry reception. Satellite missions require dedicated staff to complete real-time, continuous monitoring of the status and position of the satellite. Mission control is the set of tasks executed after launch by operation engineers with the help of software applications, and involves the exchange of data between the ground and space segments for monitoring and control the status of the satellite’s onboard subsystems. In scientific missions, it is also necessary to receive the information from the satellite payload and deliver it to the end-users (scientific community). Typical functions executed during mission control include the reception and analysis of telemetry, telecommanding, and tracking. Telemetry is the data transmitted from the satellite to the Earth informing of the status and conditions of the satellite and its subsystems. Telecommands are the orders transmitted from the ground to the spacecraft to configure and operate it. (uhlig, Sellmaier, and Schmidhuber 2015: 232). Tracking and station keeping, also known as ranging, consists of the monitoring and determination of the flight path and position using RF techniques and signals. From a software engineering perspective, satellite control requires different applications and tools for flight dynamics, mission planning, telemetry and telecommanding, network control and routing, as well as interfaces between them. This complexity has led to the provision of different solutions by space agencies. One of the most relevant milestones in the development of MCS software was the decision of the ESA Ground Systems Engineering department to develop and license to the European industry a set of software applications distributed under the name MICONYS® 4 GEO satellites are distributed in a limited area in space. Orbit slots are assigned by the International Telecommunication Union (ITu) to avoid collisions, a risk related to the space debris topic that is receiving greater attention today. 189Terminologija | 2020 | 27 (Mission Control System). MICONYS and its SCOS-2000® component are probably the best-known examples of this ESA’s policy for software development and innovation and technology transfer (Kaufeler, Jones and Karl 2001). SCOS-2000 supports telecommanding, telemetry reception, display, and archival. SCOS-2000 was the result of the experience acquired by ESA in the development and operation of previous similar systems: MSSS, SCOS-1, and SCOS-2. Today, ESA is developing the new MCS system, aimed to replace SCOS-2000 in the future. Its name is European Ground Systems – Common Core (EGS-CC). Similar to SCOS, the project has the purpose of developing a common infrastructure to support the monitoring and control of space missions in the preand post-launch phases, using modern technologies and service-oriented architectures (Pecchioli et al. 2012). The development of EGS-CC is not only under ESA responsibility: European national space agencies (CNES, UK Space Agency, and DLR) and industrial companies (AIRBUS Defence and Space, Thales Alenia Space and OHB Systems) are part of the project. Besides ESA projects, there are other initiatives aimed to develop a generic MCS software system. NASA has completed similar projects, most of them in-house developments. The Goddard Space Flight Centre developed two systems, ITOS and ASIST, for managing missions like WMAP (Wilkinson Microware Anisotropy Probe), IMAGE (Imager for Magnetopauseto-Aurora Global Exploration), EO-1 (Earth Observing 1), ST-5 (Space Technology 5), SdO (Solar Dynamics Observatory) or LRO (Lunar Reconnaissance Orbiter) (Pfarr et al. 2007). In all these cases, we are dealing with a complex system that needs to implement different functions that can be activated or not depending on the satellite and the mission’s characteristics. due to that, these softwareintensive systems are good candidates to be developed using product-lines and feature-based modelling techniques, which rely on a clear and wellorganised organization of concepts to understand the domain and system needed capabilities. 2. FEATURE-bASED MODELLING AS AN ORGANIzATION OF CONCEPTS Feature-based modelling is one of the techniques applied in software product-line engineering, a discipline for building reusable software programs that became popular at the end of the nineties. SPLE intends to 190 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models build reusable components and artefacts that can be later combined to build products suited to the needs of a specific client and context. Experiences in SPLE are widely documented in the professional and academic literature. Capilla (2013) included several case studies where SPLE was applied with success: Boeing’s operational, mission-critical flight programs for avionics and cockpit functions, Bosch’s engine-control software for gasoline systems, Hewlett Packard’s printer software, Toshiba’s power generation, and transmission equipment and General Motors’ control software for powertrains. The benefits of software product lines (SPL), according to Apel et al. (2013: 9), include the tailoring of software products to the specific needs of the clients, reduced cost – as a set of reusable assets can be combined in different ways to generate new products -, improved quality and time-to-market. Features and feature-based modelling are relevant concepts in the development of SPL. ISO/IEC/IEEE 24765:2010, Systems and software engineering — Vocabulary, offers a general definition of features, taken from IEEE Std 829:2008 IEEE Standard for Software and System Test Documentation: “A distinguishing characteristic of a system item. NOTE: includes both functional and non-functional attributes such as performance and reusability.” Kang and Lee (2013, 28) define features as “abstract concepts effectively supporting communication among diverse stakeholders of a product line, and therefore, it is natural and intuitive for people to express commonality and variability of product lines in terms of features.” Features serve different purposes in the product ideation and development process. They are means to communicate the product characteristics and support the identification of requirements; they are also the concepts that guide design and implementation decisions. The development of a product-line comprises two complementary life cycles: • domain engineering, and • Application engineering. IEEE 1517-2010 standard defines domain engineering as: “Life cycle consisting of a set of processes for specifying and managing the commonality and variability of a product line. domain engineering analyses the domain of a product line and develops a set of reusable artefacts. These artefacts include software requirements, design elements, test cases and 191Terminologija | 2020 | 27 procedures, user documentation, etc. domain analysis can be seen as a sort of requirements engineering for the whole product line, including the identification of anticipated variability. The main artefact generated by domain analysis is the feature model that will specify and describe the products within the line. Feature modelling is a diagramming technique that was introduced in the nineties with the FOdA (Feature-Oriented Domain Analysis) methodology. FOdA provided primitives for representing structural relations (composition, generalization, and specialization), optionality, alternativeness, and mutual dependencies. It was later reviewed by different authors (Kang and Lee 2013: 30–31). Feature diagrams are the visual representation of feature models, where features are represented as boxes in a hierarchical tree. Each node has an attached label with the name of the feature. The hierarchical arrangement of the features creates parent-child relationships. If a child feature is selected, its parent must also be selected. diagrams can make a distinction between mandatory and optional features, and identify the combinations of features that are valid. In particular, feature diagrams can represent: • Abstract features, which are used to organise the features in the tree but are not bound to implementation artefacts. They are represented with grey boxes. • Concrete features, which correspond to implementation artefacts and are represented with white boxes. • Mandatory features, which have a filled bullet on top of the upper border of their box. • Optional features, which have a non-filled bullet on top of the upper border of their box. • The need of selecting just one of the child features of a specific parent (exclusive OR, XOR, or one-out-of-many). It is represented with an empty arc at the lower border of the parent feature’s box. • The possibility of selecting more than one child features of a specific parent (OR or some-out-of-many). It is represented with a filled arc at the lower border of the parent feature’s box. • dependencies between features, represented by arrows with textual annotations. 192 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models The diagram below shows a typical feature diagram with the conventions described above: Fig. 1. Feature diagramming example (Source: Gargantini 2015) A feature model should include information additional to the diagram. Apel et al. (2013: 27) indicate the possibility of adding these data: • “Description of a feature and its corresponding set of requirements. • Relationship to other features, especially hierarchy, order, and grouping. • External dependencies, such as required hardware resources. • Interested stakeholders. • Estimated or measured cost of realizing a feature. • Etc.” The development of a feature model to represent the functional characteristics of software applications for satellite control must start from a clear understanding and modelling of the concepts that make up the domain. To this end, activities related to terminology and terminography, the identification of terms, concepts, and their relationships provide the basis to build the target model. 193Terminologija | 2020 | 27 3. WORK METHODOLOGy The proposed feature-model has been completed following these steps: • Identification and review of professional and academic literature published in this area. This involves searching for information about the approach followed in aerospace projects led by entities like ESA (European Space Agency) or NASA (National Aeronautics and Space Administration). • development of a glossary based on the analysed literature, applying terminology management techniques to record information about terms, relationships between them, definitions identified in the documents, and the context where the terms are used. • Creation of a feature-based model that represents the functions offered by satellite monitoring and control software applications, using the glossary as a basis. The inputs used to identify terms included a subset of technical documents that describe the selected product: operation manuals, white papers, and training materials. The feature model is a hierarchical tree of features marked as mandatory or optional, with dependencies between them. In the case of the software application under analysis, besides the identification of optional and mandatory features, additional product line variability requirements were identified. In particular, some of the functions supported by the software under analysis require overwriting or customizing existing code. The identification of these variability cases was made with the support of experts who develop their activity in the development and customization of this type of software application. Personal interviews were made to collect that information. The tool selected to create the feature model and diagrams is FeatureIDE5. This is an open-source tool based on Java and Eclipse, developed by staff at the Otto-von-Guericke-Universität Magdeburg. With FeatureIDE, it is possible to create a feature model using a graphical editor, mark features as mandatory, optional, or abstract, and build the hierarchical tree. Once the feature model is built, you can create different configurations: selections of features that will be used to generate the target software applica5 See https://FeatureIdE.github.io/. Last checked: 01-03-2018. 194 Ricardo Eito Brun Terminology as the Basis for Building Engineering Feature-based Models tion source code. unfortunately, the tool does not provide capabilities to manage terms or terminology units, which makes necessary the use of complementary tools. Fig. 2. FeatureIDE (created by the author) 4. PRESENTATION OF RESULTS AND DISCUSSIONS This section summarizes one section of the feature model for Mission Control Systems (MCS) software applications. The analysis of the concepts extracted from the documents led to an organization of the system functionalities into these areas: • Desktop and Session Management, which provides the functions to log in, start a session, and launch the different applications. In the case of managing multiple satellites, the user will be able of switching between satellites’ workspaces. • Telemetry chain, which includes Telemetry processing, Alarm Manager, and Telemetry display.