Runtime Reasoning of Requirements for Self-Adaptive Systems using AI Planning Techniques

—Over the years, the domain of Self-Adaptive Systems (SAS) has gained significant importance in software engineering community. Such SAS must ensure high customizability and at the same time effective reasoning to meet their objectives by meeting end-user goals more effectively and efficiently. In this context, techniques related to Automated P lanning have acquired substantial precedence owing to their adaptability to diverse scenarios based upon their enhanced knowledge extraction from available Knowledge Base. These AI planning techniques help in supporting self-adaptation mechanism of SAS. We have investigated these techniques to perform runtime reasoning of SAS requirements. This paper proposes an architecture for implementing the reasoning component of previously proposed Continuous Adaptive Requirement Engineering (CARE) framework. The proposed architecture has been experimentally verified by implementation of a prototype application using JSHOP2 (Java implementation of SHOP2, an HTN Planner).


I. INTRODUCTION
The software systems are increasingly expected to satisfy their functional and non-functional requirements, even under changing conditions in their environments, including fluctuations in user demands (requirements), resource availability (system parameters) and the presence of cyber adversaries.Self-Adaptive Systems (SAS) address this need, since they are required to modify themselves according to the changes in the end user requirements or the environment in which they operate or the system parameters, to remain operational [2] [24].Such systems have the ability to continuously monitor their own state and the state of their environment, and to autonomously change their structure and behavior to operate as best as possible, with respect to a defined goal in the presence of run-time changing conditions.
The desired end states (goals), as defined by the user and dictated by the system itself for computational purposes, are translated in the form of explicit requirements.Requirements engineering approach provides the basic considerations for determining the performance of evolved system.However, pragmatically the existing requirements engineering (RE) techniques work well where requirements of system are well understood at design time and evolve very slowly with respect to time.These techniques fail to provide solutions in abruptly changing requirements, hence rendering them unable to support Self-Adaptive Systems (SAS) where changes in all domains are very dynamic [1].
Self-Adaptive Systems manifest themselves into uncertainty in both context and lack of knowledge thanks to the ever-changing variables [25].It leads to a scenario where system is made to take critical decisions for adapting itself with respect to set goals (whether to adapt or not, when to adapt, which adaptation technique to use, etc) in a dynamic and partially observable environment.The authors in [27] argue that contextual uncertainty in the operating environment requires to be reduced in order to improve the performance of SAS.
In the literature, a few approaches attempt to handle uncertainty merely by including it in the description; whereas some approaches rely on monitoring of context but lack the ability to alter the system.Hence, the environment remains uncontrollable and true implementation of adaptation logic [26] cannot be affected thus leading to undesired adaptation results.This paper proposes a model that enables the SAS to continuously monitor the contextual variations and is equipped with the mechanism to alter itself at runtime according to the altering requirements.
The environment modelling approach that we have adopted bears a few resemblances with the model of artifacts proposed in [28] and [29].Major dissimilarity between these two approaches is that in [29] an artifact denotes a physical or computational entity in the environment (e.g. a mouse, a sensor, a web-service etc) whereas in [28] an artifact connotes a conceptual or logical entity (e.g. a car, a house, a place etc).However, our approach is hybrid where an artifact can be physical or logical entity.
In order to effectively reason about the modelled artifacts stemming from dynamic environment, this paper expands the Continuously Adaptive Requirement Engineering (CARE) framework proposed in [3].CARE is both goal and user oriented RE framework.This paper extends the reasoning component of CARE framework, which provides effective decision making to meet the end-user preferences based on www.ijacsa.thesai.orghatched goal models, by effective use of AI planning techniques.
Rest of the paper is organized as follows.Section II presents a brief literature survey leading to the research work.It is followed by proposed architecture of reasoning component in section III.A case study is presented in section IV that demonstrates the proposed architecture along with its goal model, the planning domain description representation and its integration with Java based Self-adaptive application.A brief evaluation of proposed model through developed prototype application is presented in section V. Section VI concludes the paper.

II. LITERATURE SURVEY
This section investigates various semi-plugged in voids involved in the realization of SASs with particular focus on their implementation at runtime and their ability to meet the requirements posed by system, context and user.

A. Requirement Engineering for SAS
In software development life cycle, requirement engineering is the ground activity upon which the working of whole system depends.Work of Fickas and Feather presented in [17] on requirements monitoring is a key contribution towards run-time requirements.Continuous requirements monitoring is necessary because of the deviation of system behavior at run-time from requirements model, which ultimately triggers the demand for system moderation.Such deviations need to be agreed with the changing conditions of environment so that the reasons can be identified and suitable adaptation is achieved.This is called monitoring and switching by Salifu in [32].
Berry, Cheng, and Zhang identified four-level model for engineering requirements posed by dynamic adaptive systems [9].Level 1 includes traditional RE activities done by analyst.Level 2 includes run-time adaptive requirements.Level 3 includes requirements engineering done by analyst to determine the adaptation mechanism which actually enables the system to adapt.Level 4 includes adaptation requirements that are associated to specific adaptation solutions.
We also critically analyzed applicability of existing goaloriented RE approaches related to our work.TROPOS methodology for goal modeling is used by Penserini et al. [4] to model run-time changes in user needs and preferences.It involves BDI (Belief-Desire-Intention) agents, which may switch from one behavior to another depending upon environmental conditions and changes in user needs.Liaskos et al. [31] uses requirements driven approach to address the problem of changing requirements by configuring software using goal-oriented approach.They model user's high level preferences as goal alternatives and then match them with the system's configurations.In this way, they support reasoning about goal models to achieve automatic system configurations.This approach i.e. goal based, seems very useful to depict the behavior of autonomic elements.
Zhu et al. [30] uses goal models to derive patterns of autonomic elements.To express different autonomic patterns, goal oriented RE approach and attribute based architectural style is used.In the field of goal oriented requirements engineering, Jureta [5] redefines the concepts of core requirements ontology.The core ontology is mainly based on goal oriented concepts and also on mentalistic notions which are called modalities.KAOS [8] approach for requirements modeling focus on relating the functional and non-functional requirements to the enterprise goals because it assumes sufficient knowledge about the current organizational state.i* modeling approach [12] is used during early stages of RE when requirements are not clear enough and goals are not well defined.It focuses on understanding enterprise goals and how they affect the behaviors of actors.
The existing RE approaches discussed above anticipate run-time changes at design-time, so they are unable to accommodate new or changed requirements posed by the endusers at run-time.In this context [3,6] proposes a novel framework that captures and analyzes user requirements at run-time.This framework is called Continuous Adaptive Requirement Engineering framework.

B. Uncertainty in SASs
The systems having the capability to adapt and alter the involved players or scenario inherently require continuous interaction with the environment either to sense or to change.The continuous altering nature of environment and system thus places additional burden on system, of dealing with the introduced uncertainty as argued in [23].
An elaborate description of SASs, and evaluation of various approaches and models leading to declaration of CARE as the most effective framework for reasoning of requirements at runtime in presence of uncertainty in [22] gives a venue for further capitalization on the concept.

C. Goal Modeling and HTNs
In the field of requirements engineering (RE), goal oriented modeling approaches have acquired substantial attention as they enable the system to traverse the unexplained gap between stakeholder requirements (goals) and the instruments (actions/tasks/plans) whose manipulation ensure attainment of these goals.The presently employed goal-oriented modeling frameworks [8,12] consider goals as mandatory requirements that must be satisfied by any suitable solution.However, these frameworks are unable to satisfy the preference requirements presented by stakeholders.So a framework [10] is introduced allowing users to specify both the preference requirements and priorities, which are later utilized to select the specifications that meet the mandatory requirements while best satisfying the preference requirements as per accorded priorities.
In HTN (Hierarchical Task Network) [18] there is a provision to manage mandatory goals alongside preference goals based on evaluation of quantized criterion.This is achieved by the arrangement of tasks in a hierarchical order and their recursive mitigation into other sub tasks.www.ijacsa.thesai.orgHTN domain is composed of operators and methods that outline feasible maneuvers to achieve goals whereas HTN problem specification comprises a list of predicates and higher level tasks that are required to be completed for the attainment of goal state.HTN based planner initially scans the domain and specification of problem and then recursively performs HTN tasks to attain high level goal state.Hence, the mandatory decomposition is translated into a set of HTN operators, methods, and tasks, while the set of priorities and preference goals are converted into PDDL 3.0 preference constraints and metrics, modelled into weighted evaluation function for reasoning [21].

D. AI Planners
Planning problems are represented in PDDL, STRIPS or HTNs which are processed by AI planners to generate solutions i.e. task sequences [10].In our self-adaptive application we are using JSHOP2 planner [11] which is Java implementation of SHOP2 [16].The core functionality of JSHOP2 is constructed on planning formalism called hierarchical task network planning [15,11].
In most of the automated planning systems, planners have to strike out various possibilities prior to discovering a workable plan/solution; as they perform a trial-and error search of a large solution space.On the contrary, HTN planners conduct this same very search by firstly applying HTN methods to decompose tasks into subtasks thus creating a planning problem network [14] called hierarchical network of tasks, which in turn can be efficiently searched by planner to generate the requisite task sequence.

E. CARE Framework
CARE [7] is goal and user oriented requirement engineering framework that captures and analyzes user requirements at runtime.The main idea behind CARE is that the system itself plays the role of analyst i.e. it performs RE activities at runtime to satisfy end user preferences and adapt itself to meet changes in user goals and preferences.To achieve this adaptation, system automatically updates its knowledge about the operational environment and end user needs.The requirements captured by system at runtime are called service requests [5] in CARE which can be expressed in XML format.These service requests either consist of new requirements or refined set of requirements expressed as goals, quality constraints, preferences, priorities etc.These service requests are provided as an input to reasoning component.The reasoner performs three operations on incoming requirements data.First it evaluates the incoming data to determine which type of adaption is required [6], before activating a planner.After evaluating, the Plan activity activates the planner to generate task sequences and the selected plan is executed by Reasoner's Adapt activity [7].

III. PROPOSED ARCHITECTURE
Fig. 1 shows the revised architecture of CARE reasoning framework integrating goal modeling and automated planning techniques [12,13].The requirements are represented as goal model [10] that not only represents the functional requirements but also the user's preferences and nonfunctional requirements.In CARE, these goal trees are considered as a pool of adaptive requirements which are directly translated into planning action theory [7] by using HTN semantics.This action theory represents how user goals can be achieved in most suitable way under given conditions.The requirements which are called runtime requirements artifacts (RRA) are captured from the user through the user agent.These RRAs consist of various requirement elements e.g.user hard and soft goals (G, SG), preferences (P), quality criteria (Q) and the data received from monitors which sense the changes in environmental conditions (E).These user RRAs are transformed into a complete problem description where the values of monitored variables formulate the initial conditions, user goals formulate the goal specification, and quantitative prioritization of preference goals covers the preferences specification [7].The problem description is then input to the planning agent which first evaluates the information received from monitors and determines which type of adaptation is required.It then activates the AI Planner.As soon as the planner gets activated, the lookup agent starts searching (using A* Algorithm) for the best possible plan (sequence of tasks) in domain description that satisfies user goals defined in the given problem description.The resulting plan is displayed to the user again through the user agent.Replanning is required if some change is sensed in the environmental conditions or the prescribed plan is not executed as desired, thus warranting generation of a new plan having different initial conditions.The update agent is responsible for updating the problem description according to the new requirements.

IV. CASE STUDY
We demonstrate the reasoning architecture presented in Fig. 1 with the help of a prototype application aimed at acting as a Virtual Secretary to the user.The application covers basic daily life tasks of various professionals e.g.Lecturer, Surgeon and Businessman with the flexibility of incorporating his preferred selections and forced constraints met during plan execution.For instance, according to his preference of reaching his work place cheaply with no sense of urgency the application suggests him to move via train after evaluating the weighted preference against cost of executing the intermediate tasks in all possible cases as per defined Goal Model (see Fig. 2). Figure demonstrates the identification of set of goals, set of AND/OR decomposed tasks along with their prerequisite conditions to meet the goals, predefined methods encapsulating various tasks in order for meeting minor goals, system ground state conditions and in addition a pool of adaptive requirements.
The tasks are categorized as human and machine tasks, for example Pack Bag, Carry Wallet, Pack Laptop are the tasks performed by user but they are suggested as a reminder by application.Moreover, the application continuously senses the changes in its operational environment and re-plans according to these changes.For example, the system notifies Faulty ATM Machine and suggests user to Use Cheque to Draw Cash.Preference goals are also supported for example reaching Urgent, Enjoying Route, Cost Effective etc. by assigning weighted metrics to each preference and evaluating the core heuristic function with the actions' accumulated costs.

A. HTN based Goal Model
The prototype application based on the above mentioned scenario in order to extend the desired features of adaptability and handling of runtime requirements entails a Goal Model that encompassed a few possible eventualities and recursive corrective actions.A segment of the Goal Model is presented in Fig. 2. The given model is of transportation module which depicts the possibility of reaching the work place via three different modes i.e.By Walk, By Subway and By Car.Selection of a mode is done upon weighing the resultant of selected user preference and environmental variables like IsRaining, IsUrgent and HaveCash.Each mode of transport is further disintegrated into sub tasks through AND/OR decomposition, rendering it an HTN Model.A plan [10] is devised for root goal satisfaction.Plan is a sequence of leaf level tasks that satisfy the root goal and is acquired by employing various sorts of tree searches e.g.A* Search, Depth First and Breadth First etc.For example following sequence is a plan when user wants to reach urgent and also does not have cash in wallet and gas in car : t 21 ,t 22 ,t 23 ,t 31 ,t 32 ,t 33 ,t 132 ,t 133 .Goal model in Fig. 2 is a subset of i* Strategic Rationale Diagram [12,19] but PRECEDENCE LINKS are additional to the core concept of i*.This concept of precedence links is used for goal modeling in [10,20]

B. Mapping Goal Model to PDDL using HTN Semantics
This section explains how the above mentioned user goals, sub goals, preferences and tasks are translated to HTN and JSHOP2 compatible PDDL specifications to solve the planning problem and how action parameters and domain predicates help in richer representation of domain and its states.
1) Planning domain: Domain description is the knowledge base we prepare for the planner in order to enable it to solve the problems.The domain description, if done to the minutest details, catering for all the possible actions that might be involved in solving the possible problems enhances the planner's response in giving valid solutions.Domain is composed of various predicates, operators, axioms and methods.
JSHOP2 does not operate on standard PDDL, but a variant of it defined in LISP and dictated separately in its own grammar.A JSHOP2 compatible translation of prior mentioned scenario through its equivalent logical model is accomplished keeping in view the possible requirements that might be brought forth at runtime.
For the Transport Module of the application, the modes of transport are defined in a single category i.e. (Via ?Mode), similarly all the locations as (Present-At ?Loc) and so on.Reaching the work place via each selected mode is represented by means of methods, which are further subdivided into a set of ordered primitive tasks.Since the selection of mode of transportation is to be made upon evaluation of user based preferences, axiom of (:-Mode-Sel ?Mode) is used to reason/evaluate and choose the preferred method of reaching the destination work place (Listing 1).2) Planning problem: Planning problem description is the precise description of planning problem at hand i.e. the initial or current state and the goal state or the tasks to be realized.Problem description also includes the identification of various object types i.e. actors in the planning problem along with problem specific knowledge.
Transport module of the application has identified three different modes for reaching work place, each attributed with certain preference depending upon the user specification.The corresponding problem for above mentioned domain includes the declaration of Objects i.e.Transport (walk, car, and train), Locations (Home, Gas-Station, Bank, Work-Place, Subway-Station-A, Subway-Station-B) and their user defined metric preferences for each.The system ground state is defined by manipulating the predicate variables already defined in corresponding Domain Description.The problem satisfier Goal i.e.Reaching-Workplace is expressed containing evaluating variables (Listing 2).www.ijacsa.thesai.orgIn the Listing 3, implementation of transportation module of application is explained with the help of an algorithm.Application gets input from the user through UI and generates plans suggesting user the future course of action to be adopted based on his selected preferences.The screen shots presented in Fig. 3 & Fig. 4 show the implementation of application with respect to above goal models.

V. EVALUATION
The adopted technique incorporates Java front end UI integration of context sensors in order to impart ability to replan and adapt at runtime, seamless transition of domain and problem descriptions in PDDL to Java, and their parsing to Java based JSHOP2 for extraction of requisite plan.The complete cycle as depicted in Fig. 1 when traversed should take considerably more time than existing non-adapting frameworks, but keeping in mind the performance aspect of proposed approach, the goal model is dis-integrated into subgoal models; which are implemented with each having a considerably smaller domain, thus reducing the search space for each sub-problem and substantially enhancing its performance.Re-planning requires the multiple iterations of search space for reaching the most suitable plan.This is addressed by considering maximum possible scenarios (discussed below) that may pose user with unpredictable situations and incorporate them in goal model and generate search tree bifurcations.Fig. 5 depicts the time consumption for tasks to achieve the final goal state shown in the goal model (Fig. 2).www.ijacsa.thesai.org In this simple case, planner application just reminds user to carry different things (based on some initial conditions) before leaving for job and also suggests some tasks that he has to perform before leaving home.
 This scenario does not involve input from the user and CARE context sensing mechanism.
 The generated plan is only dependent on the location of different things that he has to pack before leaving home.
 Fig. 6 shows the plan suggested by daily planner of application as a reminder of packing different things before leaving based on initial conditions and final goal state (without using CARE technology).
Scenario 2: This scenario is also taken from working day module but it involves CARE technology.In this case transportation is suggested to the user and by using the CARE methodology, system itself analyzes the user preferences (based on some initial conditions, environmental conditions and user/system Case 1:  John asks for application suggestion for his suitable mode of transportation to reach job place.
 The context sensing mechanism of application starts checking the weather forecast in his town through web service agent.
 If the weather is sensed as pleasant and no forecast of rain is found then train is suggested as the suitable mode of transportation for John.
 After suggesting train, application checks if John has cash.If no cash is found, then planner is again invoked for some new sequence of tasks (re-planning).
 Planner suggests John to walk to bank and draw cash, meanwhile application also checks whether the nearby ATM is functional or faulty.
 Plan generated for John is shown in Fig. 7. Case 2:  Any changes in weather conditions again activate the context sensing mechanism of application and it starts checking the weather conditions.
 If weather is sensed cloudy and forecast of rain is found then planner is again invoked and car is suggested as the suitable mode of transport for John.
 After suggesting car, application automatically checks if John has gas/petrol in car by fuel sensor.If no/less fuel is found, planner is again invoked which starts replanning according to the changed situation.
 Finally, the plan shown in Fig. 8 is generated for John for his course of actions.www.ijacsa.thesai.orgScenario 3: This scenario is taken from holiday module of INSTA PLANNER application in which system not only plans and re-plans for user but also performs some actions to facilitate him in achieving his goals (as suggested by planner).

 John wakes up early morning and starts INSTA
PLANNER that plays the role of his smart secretary.
 INSTA PLANNER automatically checks the time of day.As it is early in the morning, it suggests different actions to John that he has to perform in morning like Prepare Breakfast, Clean snow, Clean house etc.
 In the afternoon, planner is invoked automatically and suggests to John that he has to perform some important tasks in afternoon like Do Laundry, Prepare Lunch etc.It also gives him some options for lunch, based on his preference that whether he wants some Healthy Food or Instant Food.Moreover, planner also suggests sequence of tasks to prepare selected lunch item.
 As soon as evening time is sensed INSTA PLANNER starts generating different excursion plans for John like Visit Relatives, Go for Movie or Go for Dinner.
 System also performs some actions to help John to achieve his final goal state, for example if he selects Go for Dinner, application starts searching for the nearby restaurants available in his city based on his preference of Chinese, Continental or Fast Food and also helps in reservation of table in his selected restaurant.
 If he selected Watch Movie as his goal then application gives him options of nearest cinema in his town and current movies in that cinema with their show timings.Application also gives him the option for online reservation of seats.Hundred percent goal state is achieved when application gives confirmation of seats reservation via email.
Table 1 presents a comparison of these three scenarios.

VI. CONCLUSION AND FUTURE WORK
This paper presents an adaptive reasoning mechanism for the run-time requirements in Self-Adaptive Systems (SAS).We have implemented a prototype application to validate our architecture by integrating AI planner with our application which addresses user preferences at runtime and generates plans according to these preferences.Moreover the said application also continuously senses changes in its operational environment and re-plans according to these changes.System also performs some actions to facilitate user to achieve his goals which is actually the execution of the selected plan.
Currently we are working on enabling the AI application to sense the changes in user intentions so that it can adapt and re-plan according to the changed mood and intentions of the user.

Listing 2 :
Planning Problem Initial State: {Is-Urgent(Car), Is-Enjoyable(Train), Is-Costeff(walk), Need-Gas (Car), Have-Cash (Cash),….}Goals: {Reach-Work-Place(Pref-U, Pref-E,Pref-C)} C. Development of CARE Reasoning Framework Prototype application named INSTA PLANNER is developed to validate the proposed architecture of CARE reasoning framework.Application has been developed using Java Net Beans IDE, MySql and JSHOP2 AI-Planner which is Java version of SHOP2.INSTA PLANNER is AI-Planner based self-adaptive application that incorporates online Web Services and Virtual Sensors and generates plans to achieve daily goals of user based on data coming from virtual context sensors, web Services and user preferences.

Fig. 6 .
Fig. 6.Plan 1 generated by INSTA PLANNER without using CARE.INSTA PLANNER is divided into two main modules.The first module covers the working day tasks of any professional.Second module is concerned with the weekend/holiday activities of individual.Following scenarios are developed to verify the proposed architecture.Scenario 1: This scenario is taken from the working day module of application which does not involve CARE technology.

TABLE I .
COMPARISON OF SCENARIOS