Authors: by Emil Vassev and Mike Hinchey, Lero – the Irish Software Engineering Research Centre The integration and promotion of autonomy in unmanned space missions is an extremely challenging task. Among the many challenges the engineers must overcome are those related to the elicitation and expression of autonomy requirements. Striving to solve this problem, Lero – the Irish Software Engineering Research Centre – has developed an autonomy requirements engineering (ARE) approach within the mandate of a joint project with the European Space Agency (ESA). The approach is intended to help engineers tackle the integration and promotion of autonomy in software-intensive systems, e.g. space-exploration robots. ARE combines generic autonomy requirements (GAR) with goal-ori­ented requirements engineering (GORE) and by using this approach, soft­ware engineers can determine what autonomic features to develop for a particular system as well as what artifacts that process might generate, e.g. goals models and requirements specification. [login type="readmore"] UNDERSTANDING ARE The first step in developing any new software-intensive system is to determine the system’s functional and non-functional requirements. The former requirements define what the system will actually do, while the latter requirements refer to its qualities, such as perfor­mance, along with any constraints under which the system must operate. Despite differences in applica­tion domain and functionality, all autonomous systems extend upstream the regular software-intensive systems with special self-managing objectives (self-* objectives). Basically, the self-* objectives provide the system’s ability to au­tomatically discover, diagnose and cope with various problems. This ability de­pends on the system’s degree of autonomicity, quality and quantity of knowl­edge, awareness and monitoring capabilities, and quality characteris­tics such as adaptability, dynamicity, robustness, resilience and mobility. Basically, this is the basis of the ARE approach (1): autonomy requirements are detected as self-objectives backed up by different capabilities and quality characteristics outlined by the GAR model. The ARE approach starts with the creation of a goals model that represents system objec­tives and their interrelationships. For this, we use GORE where ARE goals are generally modeled with intrinsic features such as type, actor and target, with links to other goals and constraints in the require­ments model. Goals models might be organised in different ways copying with the system specifics and engineers’ understanding about the system goals. Thus, we may have A) hierarchical structures where goals reside different level of granularity; and B) concurrent structures where goals are considered as concurrent. At this stage, the goals models are not formal and we use natural language along with unified modeling language-like (UML-like) diagrams to record them. The next step in the ARE approach is to work on each one of the system goals along with the elicited environmental constraints to come up with the self-* objectives providing the autonomy requirements for this particular system’s behavior. In this phase, we apply our GAR model to a system goal to derive autonomy requirements in the form of goal’s supportive and alternative self-* objectives along with the necessary capabilities and quality characteristics. In the first part of this phase, we record the GAR model in natural language. In the second part, though, we use a formal notation to express this model in a more precise way. Note that this model carries more details about the autonomy requirements and can be further used for different analysis activities, including requirements validation and verification. SYSTEM GOALS AND GOALS MODELS Goals have long been recognised to be essential components involved in the requirements engineering (RE) process. To elicit system goals, typically, the system under consideration is analysed in its organisational, operational and technical settings. Problems are pointed out and opportunities are identified. High-level goals are then identified and refined to address such problems and meet the opportunities. Requirements are then elaborated to meet those goals. Goal identification is not necessarily an easy task. Sometimes goals can be explicitly stated by stakeholders or in preliminary material available to requirements engineers. Often, however, they are implicit so that goal elicitation has to be undertaken. The preliminary analysis of the current system along with the operational environment is an important source for goal identification. Such analysis usually results in a list of problems and deficiencies that can be formulated precisely. Negating those formulations yields a first list of goals to be achieved by the system-to-be. In our experience, goals can also be identified systematically by searching for intentional keywords in the preliminary documents provided. Once a preliminary set of goals and goal-related constraints is obtained and validated with stakeholders, many other goals can be identified by refinement and by abstraction, just by asking HOW and WHY questions about the goals/constraints already available. Other goals are identified by resolving conflicts among goals or obstacles to goal achievement. Further, such goals might be eventually defined as self-* objectives. Goals are generally modeled by intrinsic features such as their type and attributes, and by their links to other goals and to other elements of a requirements model. Goals can be hierarchically organised and prioritised where high-level goals (e.g. main system objectives) might comprise related, low-level sub-goals that can be organised to provide different alternatives of achieving the high-level goals. In ARE, goals are registered in plain text with characteristics like actors, targets and rationale. Moreover, inter-goal relationships are captured by goals models, putting together all goals along with associated constraints. In that way, goals models might be used to manage conflicts among multiple goals including self-* objectives. Note that by resolving conflicts among goals or obstacles to goal achievement, new goals (or self-* objectives) may emerge. SELF-* OBJECTIVES AND AUTONOMY-ASSISTANCE REQUIREMENTS [caption id="attachment_9193" align="alignright" width="399"] Fig 1: The ARE process of deriving self-* objectives per system goal (click to enlarge)[/caption] Despite their differences in terms of application domain and functionality, all autonomous systems are capable of autonomous behaviour driven by one or more self-management objectives that drive the development process of such systems. ARE uses goals models as a basis helping to derive self-* objectives per a system goal by applying a model for GAR to any system goal. The self-* objectives represent assistive and eventually alternative goals (or objectives) the system may pursue in the presence of factors threatening the achievement of the initial system goals. The diagram presented in Figure 1 depicts the process of deriving the self-* objectives from a goals model of the system-to-be. Basically, a context-specific GAR model provides some initial self-* objectives, which should be further analysed and refined in the context of the specific system goal to see their applicability. We developed context-specific GAR models for the different classes of space missions (2) where we define a predefined set of self-* objectives for each class of space missions. These self-* objectives cope with both constraints and challenges spacecraft must overcome while performing a mission of specific class. For example, GAR defines the following self-* objectives for the class of Polar Low Earth Orbit (LEO)/Remote-Sensing Satellite Missions:

• Self-orbit (autonomously acquire the target orbit; adapt to orbit perturbations);
• Self-protection (autonomously detect the presence of radiation and move to escape);
• Self-scheduling (based on operational goals and knowledge of the system and its environment, autonomously determine what task to perform next);
• Self-reparation (implies operations re-planning based on performance degradation or failures);

As shown in Figure 1, in addition to the derived self-* objectives, the ARE process also produces autonomy assistive requirements. These requirements (also defined as adaptation-assistive attributes) are initially defined by the GAR model and are intended to support the achievements of the self-* objectives. The autonomy assistive requirements outlined by GAR might be defined as following:

• Knowledge – basically data requirements that need to be structured to allow efficient reasoning;
• Awareness – a sort of functional requirements where knowledge is used as an input along with events and/or sensor signals to derive particular system states;
• Resilience and robustness – a sort of soft-goals. For example, such requirements for Geostationary Earth Orbit (GEO) Missions are defined as “robustness: robust to communication latency” and “resilience: resilient GEO positioning”. These requirements can be specified as soft goals, leading the system towards “reducing and copying with communication latency” and “keeping GEO positioning optimal”. A soft goal is satisfied rather than achieved. Note that specifying soft goals is not an easy task. The problem is that there is no clear-cut satisfaction condition for a soft goal. Soft goals are related to the notion of satisfaction. Unlike regular goals, soft goals can seldom be accomplished or satisfied. For soft goals, eventually, we need to find solutions that are “good enough” where soft goals are satisficed to a sufficient degree. Thus, when specifying robustness and resilience autonomy requirements we need to set the desired degree of satisfaction, e.g. by using probabilities.
• Monitoring, mobility, dynamicity and adaptability – might also be defined as soft goals, but with relativelyhigh degree of satisfaction. These three types of autonomy requirements represent important quality requirements that the system in question needs to meet to provide conditions making autonomicity possible. Thus, their degree of satisfaction should be relatively high. Eventually, adaptability requirements might be treated as hard goals, because they determine what parts of the system in question can be adapted (not how).

CONCLUSION Contemporary space exploration relies on the most recent advances in automation and robotic technologies to promote autonomy and autonomic computing principles to robotised systems. The first and one of the biggest challenges in the design and implementation of such systems is how to handle requirements specifically related to the autonomy of a system. The ARE approach strives to answer this question by merging goals models with special GAR. As a proof of concept example, ARE was used to capture the autonomy requirements for the ESA’s BepiColombo Mission (3). Moreover, ARE is currently used to capture the autonomy requirements for the ASCENS FP7 Project’s (4) case studies. References: (1) Vassev, E., Hinchey, M. 2013. Autonomy Requirements Engineering. IEEE Computer, 46, 8, pp. 82–84 (2) Vassev, E., Hinchey, M. 2013. On the Autonomy Requirements for Space Missions. In Proceedings of the 16th IEEE International Symposium on Object/Component/Service-oriented Real-time Distributed Computing Workshops (ISCORCW 2013). IEEE Computer Society (3) Vassev, E., Hinchey, M. 2013. Autonomy Requirements Engineering: A Case Study on the BepiColombo Mission. In Proceedings of C* Conference on Computer Science & Software Engineering (C3S2E '13). ACM, pp. 31–41 (4) http://www.ascens-ist.eu/