Engineers Journal / Technology

The ins and outs of Autonomy Requirements Engineering

Tuesday 27 October 2015

Authors: Emil Vassev and Mike Hinchey, Lero, the Irish Software Research Centre, University of Limerick, Ireland; emil.vassev@lero.ie, mike.hinchey@lero.ie

Introduction

Traditionally, requirements engineering is concerned with what a system should do and within what constraints it must do it. Software requirements fall into two categories: functional and non-functional. Along with traditional requirements, requirements engineering for autonomous and self-adaptive systems (e.g., exploration robots) needs to address requirements related to adaptation issues, in particular: 1) what adaptations are possible; 2) under what constraints; and 3) how those adaptations are realised [1]. Note that adaptations arise when a system needs to cope with changes to ensure that the system’s objectives can be achieved. To handle autonomy requirements, Lero, the Irish Software Research Centre, has developed the Autonomy Requirements Engineering (ARE) approach. ARE converts adaptation issues into autonomy requirements where Goal-Oriented Requirements Engineering (GORE) [2] is used along with a model for Generic Autonomy Requirements (GAR) [1]. In the course of this project, ARE was applied to a proof-of-concept case study, to capture autonomy requirements of the European Space Agency’s BepiColombo Mission [3].

Autonomy Requirements Engineering

ARE is as a software engineering process helping to 1) determine what autonomic features are to be developed for a particular autonomous system; and 2) generate autonomy requirements supporting those features. Being a comprehensive and efficient approach, ARE takes into account all the autonomy aspects of the targeted system and emphasises special self-*requirements [1]. The process of capturing autonomy requirements relies on GORE [2] first, to elicit and define the system goals, and then uses a special framework called Generic Autonomy Requirements (GAR) [1, 4] to derive and define assistive and eventually alternative goals (or objectives) the system may pursue in the presence of factors threatening the achievement of the initial system goals. In addition, GAR also helps to identify goal-supporting autonomy requirements. Once identified, the autonomy requirements, including self-*objectives, can be further specified with formal languages complying with both GORE and GAR. The outcome of ARE (goals models, requirements specification, etc) is a precursor for the design of autonomic features. Figure 1 presents a high-level view of the autonomy requirements process imposed by ARE. [caption id="attachment_24808" align="alignright" width="300"]

Figure 1. The ARE Requirements Process[/caption] GAR considers that the development of autonomous systems is driven by self-adaptive objectives and adaptation-assistive attributes, which introduce special requirements termed self-*requirements [1, 4]:

Autonomicity (self-*objectives): autonomicity is one of the essential characteristics of autonomous systems. The self-*objectives provide for autonomous behaviour (e.g., self-configuring, self-healing, self-optimising, and self-protecting);
Knowledge: an autonomous system is intended to possess awareness capabilities based on well-structured knowledge and algorithms operating over the same;
Awareness: a product of knowledge representation, reasoning and monitoring;
Monitoring: the process of obtaining raw data through a collection of sensors or events;
Adaptability: the ability to achieve change in observable behaviour and/or structure. Adaptability may require changes in functionality, algorithms, system parameters, or structure. The property is amplified by self-adaptation;
Dynamicity: the technical ability to perform a change at runtime. For example, a technical ability to remove, add or exchange services and components;
Robustness: the ability to cope with errors during execution;
Resilience: a quality attribute prerequisite for resilience and system agility. Closely related to safety, resilience enables systems to bounce back from unanticipated disruptions;
Mobility: a property demonstrating what moves in the system at design time and runtime.

Note that ARE requires GAR to be put in the operational context of the system in question first, to derive context-specific GAR used by the ARE process.

The BepiColombo case study

BepiColombo is an ESA mission to Mercury [3, 6, 7, 8] (see main image) scheduled for launch in 2017. BepiColombo will perform a series of scientific experiments, tests and measures. For example, BepiColombo will make a complete map of Mercury at different wavelengths. Such a map will chart the planet's mineralogy and elemental composition. Other experiments will be to determine whether the interior of the planet is molten or not and to investigate the extent and origin of Mercury’s magnetic field. The space segment of the BepiColombo mission consists of two orbiters: a Mercury Planetary Orbiter (MPO) and a Mercury Magnetospheric Orbiter (MMO). Initially, these two orbiters will be packed together into a special composite module used to bring both orbiters into their proper orbits. Moreover, in order to transfer the orbiters to Mercury, the composite module is equipped with an extra electric propulsion module, both forming a transfer module. The transfer module is intended to do the long cruise from Earth to Mercury by using the electric propulsion engine and the gravity assists of Moon, Venus and Mercury. On arrival in January 2024, the MPO and MMO will be captured into polar orbits. When approaching Mercury in 2022, the transfer module will be separated and the composite module will use rocket engines and a technique called weak stability boundary capture to bring itself into polar orbit around the planet. When the MMO orbit is reached, the MPO will separate and lower its altitude to its own operational orbit. Note that the environment around Mercury imposes strong requirements on the spacecraft design, particularly for those parts exposed to the Sun and Mercury: solar array mechanisms, antennas, multi-layer insulation, thermal coatings and radiators.

Experiments related to planet-wide remote sensing and radio science

The Mercury Planetary Orbiter (MPO) is a three-axis-stabilised spacecraft pointing at nadir. The spacecraft will revolve around Mercury at a relatively low altitude and will perform a series of experiments related to planet-wide remote sensing and radio science. MPO will be equipped with two rocket engines nested in two propulsion modules, respectively: a solar electric propulsion module (SEPM) and a chemical propulsion module (CPM). Moreover, to perform scientific experiments, the spacecraft will carry a highly sophisticated suite of instruments [9]. By applying GORE, we built goals models that later helped us derive and organise the autonomy requirements for BepiColombo by defining 1) the objectives of the mission that must be realised in 2) the system’s operational environment (space, Mercury, proximity to the Sun, etc.), and by identifying 3) the problems that exist in this environment as well as 4) the immediate targets supporting the mission objectives and 5) constraints the system needs to address. Moreover, GORE helped us identify the mission actors (mission spacecraft, spacecraft components, environmental entities, base station, etc.). The BepiColombo mission falls in the category of interplanetary missions [4] and consequently inherits the context-specific GAR model for such missions [4]. Good practice would be to associate the autonomy requirements with each objective (or group of objectives). Thus, we could have autonomy requirements (including self-*objectives) associated with the transfer objective, the orbit-placement objective and with the group of scientific objectives [5]. For example, the orbit-placement objective is to place both MMO and MPO into their operational orbits around Mercury. When approaching Mercury, the BepiColombo transfer module will be separated by releasing the module’s SEPM. Then, the BepiColombo composite module will use the MMO’s rocket engines (mainly the CPM) and the weak stability boundary capture mechanism to move the spacecraft into polar orbit around Mercury. When the MMO orbit is reached, the MPO will separate and lower its altitude to its own operational orbit. To derive the autonomy requirements assisting that objective, we had to identify the appropriate category of GAR that can be applied. Considering the orbit-placement objective, the BepiColombo mission falls into the category of interplanetary missions using low-thrust trajectories [4]. Such missions use spacecraft for orbit control activities in geostationary orbits, drag compensation in low orbits, planetary orbit missions and missions to comets and asteroids. These missions often have a complex mission profile utilising ion propulsion in combination with multiple gravity-assist manoeuvres (similar to BepiColombo). Therefore, by considering the orbit-placement objective specifics, we derived the autonomy requirements for that objective, by applying GAR for interplanetary missions using low-thrust trajectories [4]. Following the ARE process, next we merged the self-*requirements derived by GAR with the goals models produced by GORE, to derive self-*objectives providing mission behaviour alternatives with respect to the BepiColombo mission objectives.

Summary

The ARE approach relies on the GORE technique to elicit and define the system goals, and then applies a special GAR model to derive and define assistive and often alternative goals the system may pursue in the presence of factors threatening the achievement of the initial system goals. Once identified, the autonomy requirements might be further specified with a proper formal notation. This approach has been used in a joint project with ESA on identifying the autonomy requirements for ESA’s BepiColombo mission. We presented a case study where ARE was applied by putting GAR in the context of space missions to derive autonomy requirements and goals models incorporating autonomicity via self-*objectives.

References

[1] E. Vassev and M. Hinchey, “The Challenge of Developing Autonomic Systems”, IEEE Computer, IEEE Computer Society, 43 (12), 2010, pp. 93–96. [2] A. Van Lamsweerde, “Requirements Engineering in the Year 00: A Research Perspective”, Proceedings of the 22nd IEEE International Conference on Software Engineering (ICSE-00), ACM, 2000, pp. 5–19. [3] R. Grard, M. Novara, and G. Scoon, BepiColombo - A Multidisciplinary Mission to a Hot Planet, ESA Bulletin, ESA, 103, 2000, pp. 11–19. [4] E. Vassev and M. Hinchey, “On the Autonomy Requirements for Space Missions”, Proceedings of the 16th IEEE International Symposium on Object/Component/Service-oriented Real-time Distributed Computing Workshops (ISCORCW 2013), IEEE Computer Society, 2013, to appear. [5] E. Vassev and M. Hinchey, “Autonomy Requirements Engineering: A Case Study on the BepiColombo Mission”, Proceedings of the C* Conference on Computer Science & Software Engineering (C3S2E '13), ACM, 2013, to appear.