Autonomic systems are systems that are aware of their behavior and can modify it to reflect changes in the operating environment. An autonomic system must be designed with both an understanding of the need for self-adaptation and monitoring as well as of the system’s inability to monitor everything. Developers initially tackle such issues with requirements engineering, which focuses on what a system should do and the constraints under which it must do it.

Autonomy requirements engineering (ARE) addresses what adaptations are possible in a system and, ultimately, how to realize those adaptations. In a joint project with the European Space Agency (ESA), and as part of the ASCENS FP7 Project, Lero - the Irish Software Research Center, is working on an ARE approach that combines generic autonomy requirements (GAR) with goal-oriented requirements engineering (GORE). Using this approach, soft-ware engineers can determine what autonomic features to develop for a particular software-intensive system as well as what artifacts that process might generate.

GENERIC AUTONOMY REQUIREMENTS

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 performance, along with any constraints under which the system must operate.

Despite differences in application domain and functionality, all autonomic systems also have self-managing objectives (self-*objectives). A system’s ability to automatically discover, diagnose, and cope with various problems de-pends on its degree of autonomicity, quality and quantity of knowledge, awareness and monitoring capabilities, and quality characteristics such as adaptability, dynamicity, robustness, resilience, and mobility.

Autonomicity

Autonomic systems are designed to free human operators from complex tasks that often require a lot of decision making. Developers can adjust self-* objectives to provide complete, partial, or no autonomy depending on circumstances or the level of interaction or control required. For example, in some situations an autonomous spacecraft might be required to ask mission control for instructions or revert control to a human operator.

Challenges in designing adjust-able autonomy systems include knowing whether and when to make the transition between levels of autonomy. Often the system will perform a task’s low-level functions, such as preparing the spacecraft for landing, whereas a human will perform the higher-level functions, such as directing the actual landing.

Knowledge

Well-structured knowledge and reasoning capabilities are the basis of awareness in autonomic systems. Developers can consider different kinds of knowledge for specific application domains of interest, including:

· domain knowledge — domain facts, theories, and heuristics;

· control knowledge — problem-solving strategies and functional models;

· explanatory knowledge — rules and explanations of the system’s reasoning process, as well as how they’re generated;

· system knowledge — data con-tent and structure, pointers to the implementation of useful algorithms needed to process both data and knowledge, and user models and strategies for communication with users.

Awareness and monitoring

An autonomous system should be able to notice a change and under-stand its implications. This involves self-awareness about the system’s internal world as well as context awareness about the external world. Therefore, both self-monitoring and monitoring of the environment through sensors are required. An aware system should be able to apply pattern analysis and pattern recognition to determine normal and abnormal states.

One of the main challenges of monitoring is determining which data are most crucial for analysis of the system’s behavior and changes in the environment. Such information is key to determining when a certain adaptation is necessary.

Quality requirements

Adaptability is the system’s ability to modify its behavior or structure, which can involve changes in functionality, algorithms, system parameters, and so on. Adaptability requires a model of the system’s environment. A key challenge with this requirement is how to measure it.

Dynamicity refers to the ability to perform a change at runtime, such as removing, adding, or exchanging services and components.

Robustness is the ability to cope with errors during execution.

Resilience is a prerequisite for system agility and safety, and enables systems to recover from unanticipated disruptions.

Mobility indicates system re-configurability at both design time and runtime and often enables dynamic discovery and usage of new resources. Examples of mobility can be related to code mobility, service mobility, component mobility, resource mobility, and so on.

GOAL-ORIENTED REQUIREMENTS ENGINEERING

GORE makes software development more efficient by adding a new phase called early requirements analysis. To help engineers analyze the space of alternatives and make the process of generating functional and non-functional requirements more systematic, it produces goal models that represent system objectives and their interrelationships.

ARE goals are generally modeled with intrinsic features such as type, actor, and target, with links to other goals and constraints in the requirements model. These models provide a means to represent alternative ways to meet the self-* objectives, and to analyze and rank these alternatives with respect to the GAR quality requirements.

Whereas ARE relies on the GAR model to derive and define assistive and alternative goals in autonomic systems, GORE is used to define the core system goals. In the presence of factors inhibiting achievement of these initial system goals, developers could identify with GAR and further specify autonomy requirements including the self-* objectives with GAR-compliant languages.

Figure 1. Partial autonomy requirements engineering (ARE) model for the European Space Agency’s BepiColombo mission. Dashed curve lines link the main goals with assisting and alternative self-* objectives, to which the system switches in response to specified changes in the environment or in the system itself.

The left side of Figure 1 shows a partial ARE goals model for the ESA’s BepiColombo mission, with dashed curved lines indicating relationships between the main goals—scientific objectives, orbit placement, transfer, and launch—and various supplementary self-* objectives

The right side of Figure 1 shows a detailed extraction of the transfer goal and assistive self-* objectives, most of which inherit the transfer objective. The mission switches to one of these self-* objectives when alternative autonomic behavior is required due to changes in the environment, such as high radiation emitted by the sun, or in the system itself.

Designing and implementing autonomic systems is extremely challenging due to the need for such systems to support self-adaptation, which impacts system behavior. The ARE approach helps developers meet these challenges by merging goals with generic autonomy requirements, including self-* objectives to deal with factors threatening initial system goals.