Remediating critical cause-effect situations with an extended BDI architecture

Expert Systems With Applications 95 (2018) 190–200

Contents lists available at ScienceDirect

Expert Systems With Applications journal homepage: www.elsevier.com/locate/eswa

Remediating critical cause-effect situations with an extended BDI architecture J. Faccin a,∗, I. Nunes a,b a b

Universidade Federal do Rio Grande do Sul, Instituto de Informática, Av. Bento Gonçalves, 9500, Porto Alegre, RS 91501–970, Brazil TU Dortmund, Fakultät für Informatik, Otto-Hahn-Straße 12, Dortmund 44227, Germany

a r t i c l e

i n f o

Article history: Received 7 June 2017 Revised 14 November 2017 Accepted 15 November 2017 Available online 15 November 2017 Keywords: Software agents BDI Architecture Remediation action Cause-effect Goal generation Plan selection

a b s t r a c t Remediation actions are performed in scenarios in which consequences of a problem should be promptly mitigated when its cause takes too long to be addressed or is unknown. Such scenarios are recurrent in the real world, including in the context of computer science. Existing approaches that address these scenarios are application-specific. Nevertheless, the reasoning about remediation actions as well as cause identification and resolution, in order to address problems permanently, can be abstracted in such a way that they can be incorporated to autonomous software components, often referred to as agents. They can thus autonomously deal with these scenarios, which we refer to as critical cause-effect situations. In this paper, we propose a domain-independent extension to the belief-desire-intention (BDI) architecture that provides such agents with this automated reasoning. Our work provides an extensible solution to this recurrent problem-solving strategy and allows agents to flexibly deal with resource-constrained scenarios. This solution removes the need for manually implementing the coordination of actions performed by agents, using causal models to capture the knowledge required to carry out this task. Therefore, it not only allows the development of systems with remediative behaviour, but also enables the reduction of development effort by means of a reusable infrastructure that can be used in several different domains. Our approach was evaluated based on an existing solution in the network resilience domain, which showed that our extended agent can autonomously address a network challenge, with a reduction in the development effort and no impact in agent performance. © 2017 Elsevier Ltd. All rights reserved.

1. Introduction Human problem-solving is complex and involves the adoption of different strategies when facing problems. A not unusual scenario involves the realisation that what is being addressed is actually a consequence, or effect, that has a cause. In order to permanently solve the problem, both cause and effect must be dealt with. In such scenarios, there are issues to be taken into account in the practical reasoning (Bratman, 1987), i.e. the process of deciding how to act. First, remediation actions may be performed in order to mitigate effects, before addressing the cause, which must also be dealt with; otherwise, effects will likely reappear. Second, the cause may be unknown and, in this case, this should be investigated so that the real problem can be identified and resolved. If causes remain unaddressed, effects may return even with greater impact.

∗

Corresponding author. E-mail addresses: [email protected] (J. Faccin), [email protected] (I. Nunes). https://doi.org/10.1016/j.eswa.2017.11.036 0957-4174/© 2017 Elsevier Ltd. All rights reserved.

There are many real-world situations that match the scenario described above. In computer science, different examples can be observed. An example is in the context of network resilience (Sterbenz et al., 2010), which is the ability to provide and maintain an acceptable level of service in the face of faults and challenges to normal operation (e.g. a malicious attack). When dealing with a distributed denial-of-service (DDoS) attack, network operators must minimise the number of users affected by the unavailability of the service provided by the infrastructure being attacked. At the same time, they must act towards the identification and isolation of the attack origin to have it permanently blocked (Schaeffer-Filho et al., 2012). Another example can be seen in selfhealing systems (Breitgand, Goldstein, Henis, Shehory, & Weinsberg, 2007), which are software systems able to monitor, diagnose, analyse and heal their problems, and prevent them from reappearing. To automate software memory management, objects that are no longer used, but still referred to, in Java programs (loitering objects, a form of memory leak in Java) may be “paged”, in order to keep the system operational while the software is debugged to identify such objects (Goldstein, Shehory, & Weinsberg, 2007).

J. Faccin, I. Nunes / Expert Systems With Applications 95 (2018) 190–200

Although promising, all these approaches were individually analysed and implemented, thus being application-specific solutions. Furthermore, the actions of mitigating effects and searching for causes are all explicitly modelled and hard coded. Existing solutions can potentially support a more flexible implementation of these approaches by exploiting the use of autonomous software components, called agents. However, the reasoning towards the selection of remediation actions, and cause identification and resolution is still manual. The belief-desire-intention (BDI) architecture (Rao & Georgeff, 1995) is such a solution. This architecture provides such agents with a reasoning cycle that includes an option generation function, in which goals to identify and resolve causes can be generated, and a plan selection function, in which remediation plans (sequences of actions) can be selected because other plans may not prioritise the mitigation of effects. However, such functions are abstract in the BDI architecture, and must be customised in specific applications to provide the desired behaviour. In fact, there are many existing approaches that extend, adapt and customise the gaps of the BDI architecture (Faccin & Nunes, 2015; Nunes & Schaeffer-Filho, 2014; Singh, Sardina, Padgham, & Airiau, 2010), but none are able to cope with the aforementioned scenario. In this paper, we abstract from this described target scenario and propose a domain-independent extension of the BDI architecture that allows agents to autonomously select appropriate, possibly remediation, plans to solve a problem (i.e. achieve a goal) and deal with possible problem causes. The goal of our extension is not to serve as replacement of the traditional BDI architecture in agent development, but to automate the coordination of an agent’s actions in our target scenario. This approach thus promotes reuse across domain-dependent solutions, designed and implemented in an ad hoc way, and allows agents to flexibly decide the best action according to the current context, agent goals and preferences. Our BDI architecture extension includes a set of components to capture the required domain knowledge to allow agents to make such decisions. This knowledge is then used in a customised reasoning mechanism, which selects remediation plans, when needed, and generates goals to search and deal with problem causes. Our approach is evaluated by taking an existing network resilience scenario (Nunes & Schaeffer-Filho, 2014; Schaeffer-Filho et al., 2012), which is implemented in an application-specific way, and developing it with our approach. Results show that our approach is able to reproduce the behaviour in a domain-independent way. Moreover, an empirical evaluation shows that the performance is not compromised by postponing the practical reasoning process regarding remediation plans to runtime and the developers’ implementation effort is reduced. Our approach thus promotes software reuse in an important recurrent scenario, thus freeing developers from the complex reasoning to deal with critical cause-effect situations. Moreover, it is a flexible solution that chooses between remediation and definitive plans, depending on the current preferences and constraints. In Section 2, we describe our problem by presenting an illustrative scenario that is used as a running example. We detail the elements comprising the extended BDI architecture in Section 3 and describe our customised reasoning mechanism in Section 4. Our approach evaluation is presented in Section 5. Finally, related work is discussed in Section 6, and conclusions are presented in Section 7. 2. Problem and running example Before detailing the elements that comprise our meta-model, we introduce an illustrative example to provide a better understanding of the scenario addressed. It is used throughout this paper as a running example. Despite its simplicity and perhaps not adequacy of an agent-based solution to this problem, it allows us to

191

clearly illustrate the class of problems we are targeting and concepts of our approach without having to detail additional domain background. Consider the problem of dealing with a ceiling leak. Alice is a person who notices a ceiling leak in the room of her house. To deal with it, she has three options (or plans): (i) cover the leak with duct tape; (ii) use a towel to absorb the liquid coming from the ceiling; or (iii) put a bucket underneath the drip. The three available plans can achieve the goal of dealing with the ceiling leak. However, each of them has particular characteristics concerning how this goal is achieved. Each plan requires different amounts of time to be performed. Covering the leak with duct tape, for example, requires much more time than putting a towel under the drip. Plans are also related to different execution costs. If Alice chooses to use the towel to achieve the goal, she will have to afford the cost of such towel (assuming that it would be thrown away after being used). If she chooses to use the bucket instead, the cost she has to afford will be lower, given that a bucket can be reused. Therefore, plan executions are directly associated with the consumption of resources. Further, considering that the floor can become wet if the leak is not addressed as soon as possible, Alice has constraints over the execution time of her plans. In this context, using duct tape to cover the leak may not be a feasible solution. Moreover, every time Alice wants to deal with a ceiling leak, she may have different preferences on how to spend resources. For instance, if she wants to address it quickly, the plan execution time becomes more valuable than its cost. Although performing one of the available plans achieves the given goal, Alice’s problem is not completely solved. The leak is an effect of several possible causes, e.g. a broken pipe or a cracked roof tile, which must be addressed in order to stop the leak permanently. Moreover, there may be plans that deal with both cause and effect. However, they possibly cannot be executed in such a way that constraints are met. Therefore, assuming that an agent A is in charge of resolving this whole problem, two key issues must be addressed: (i) how can agent A select the most adequate plan, possibly a remediation one, to achieve its goal based on its constraints and current preferences?; and (ii) how can agent A identify and address the causes of the effect associated with this goal to permanently solve the problem? In the traditional BDI architecture, an agent is structured in terms of beliefs, desires and intentions, which are mental attitudes that represent the information the agent has about the world, the state of the world it wants to bring about (i.e. its goals), and its commitment to achieve its desires, respectively. Agents based on this architecture have their goals explicitly specified, and plans to reach these goals are provided at design time. However, there is no specified strategy to choose among available plans. Moreover, depending on how the problem is modelled, plans that deal with the effect of the problem may not achieve the causes of this problem. Therefore, once a plan achieves the goal associated with the effect, its causes may remain unaddressed. Finally, the BDI architecture does not include means of searching for causes of problems being tackled. 3. Software agent architecture The example presented above introduces many key concepts, such as resources and preferences. Some of these, e.g. goals and plans, can be associated with existing components of the BDI architecture. Others, however, are domain-independent concepts that can be incorporated to this architecture to provide agents with the ability of dealing with what we refer to as critical cause-effect situations. These situations are those in which goals must be achieved considering a set of constraints and correspond to effect mitigation before searching and dealing with its cause. Examples are the goals of dealing with a ceiling leak, potential network attack or problem

192

J. Faccin, I. Nunes / Expert Systems With Applications 95 (2018) 190–200

with memory management, as mentioned previously. In this section, we first formalise these concepts and then integrate them as an extension to the traditional BDI architecture. 3.1. Constrained goals Goals express a state of affairs that an agent wants to bring about. However, in order to achieve a goal, the execution of actions consumes resources, such as processing time and allocated memory. In some scenarios, achieving this state of affairs is useless for an agent if the amount of consumed resources is not limited to a specified amount. Moreover, in other scenarios, if there are different means of achieving a goal, there may be restrictions on how resources should be spent, for example, spend the least as possible of a particular resource. Therefore, we define a particular type of goal, namely constrained goal, that incorporates these two notions, which are operation constraints and objective functions, respectively. These concepts are formalised as follows. Definition 1 (Resource). A resource ri ∈ R is any consumable supply of asset, whose consumption can be measured by an agent. Each resource ri is associated with a value vc (ri ) ∈ R, which is a consumed amount of ri . Example 1. There are two resources in our running example: time taken to prevent liquids to accumulate in the floor (time) and the money spent to do so (cost). The resource vc (time) is the number of seconds passed since the goal of dealing with the ceiling leak was set as a goal, while vc (cost) is the amount of money spent while performing a set of actions to achieve this goal. Definition 2 (Operation Constraint). An operation constraint c is a constraint over the desired consumption of resources. It is expressed with the following grammar.

c ::= (c ∧ c )

| ( c ∨ c ) | ( ¬c ) | e

e ::= (r op v ) op ::= >

| ≥ | < | ≤ | = | =

where r is a resource and v is a value v ∈ R. Moreover, an operation constraint is over a single resource r. Example 2. Assuming that Alice does not want to spend more than $5 to solve her problem, an operation constraint is cost < $5. Definition 3 (Objective Function). O : R  {min, max} is a partial function that specifies whether the consumption of a resource r must be minimised or maximised. Example 3. Alice has no specific constraint regarding the amount of time taken to deal with the ceiling leak, but she wants to do so as soon as possible, in order to prevent permanent damage in her floor. Therefore, the resource time is associated with min to indicate that the minimum amount of time should be spent to accomplish this. The definitions presented above are then used to define a constrained goal, which is a goal complemented by constraints over resources and specifications regarding how they should be spent. We assume that a goal is specified as proposed in the AgentSpeak language (Rao, 1996), in which there are achievement (!g) and test (?g) goals. The former indicates that an agent wants g to be a true belief, while the latter to test whether the formula g is a true belief. Definition 4 (Constrained Goal). A constrained goal gc is a tuple g, C, O , where g is an achievement goal or a test goal, C is a conjunctive set of operation constraints that states restrictions over resources to be consumed to achieve g, and O is an objective func-

tion that states whether the consumption of resources should be minimised or maximised when achieving g. Example 4. Alice wants no ceiling drip in her roof, i.e. Alice wants to believe that ¬ceiling_drip is true. Therefore, in order to deal with the ceiling leak, and considering the operation constraints and objective function defined above, she has the following goal: ceil ing_l eak = !¬ceiling_drip, {cost < 5}, { time, min } . This means that this goal must be achieved spending less than $5, as soon as possible. In Example 4, C has a single operation constraint but, given that constrained goals have a conjunctive set of constraints, if there were other constraints, all of them must be satisfied to achieve this goal. 3.2. Plan required resources The introduced definitions allow the specification of how goals must be achieved. However, given that plans are those that consume resources while trying to achieve goals, there must be means of specifying how such resources are consumed. This is formalised next. Definition 5 (Plan Required Resource). A plan required resource Rreq p : R → R, which gives, for a resource r, the amount v ∈ R that a plan p spends while executing. Example 5. Consider the different alternatives, presented in Section 2, to achieve the goal ceil ing_l eak. Using a duct tape has a small cost, but takes 600s to be accomplished, thus RreqDT (cost ) = 0.5 and RreqDT (time ) = 600, while using a towel costs $6, but takes 120s to be accomplished, thus RreqT P (cost ) = 6.0 and RreqT P (time ) = 120. Definition 6 (Plan). A plan p is a tuple P re, G, Rreq p , Body where Pre is a set of context conditions in the form of logical predicates that specify the context in which p must be executed, i.e. they must hold true before the execution of p thus being its preconditions, G is a set of achievable goals by p, Rreq p is the plan required resources to execute p, and Body is a set of actions that comprise the plan body. Example 6. Using a towel is considered a way to deal with ceiling leak, and thus is a plan to achieve the goal ceil ing_l eak. Such plan is specified as detailed below, where a1 , . . . , an are actions to be executed.

towel _ plan =

{has_towel }, {!¬ceil ing_drip}, {cost → 6, time → 120}, {a1 , . . . , an }

3.3. Cause-effect modelling As previously stated, our approach deals with a scenario in which problems are resolved, and such problems involve an initial issue (effect) to be addressed, which has a cause—composed of a set of cause factors—which must also be tackled. Our goal is to address both effect and its cause but, to do so, domain knowledge regarding the cause-effect relationship must be provided. We thus in this section specify how such knowledge is modelled. We assume that it is given as part of an agent belief base. Definition 7 (Cause-effect Relationship). A cause-effect relationship ceR (e) of an effect e is a tuple M, O, Ac , where M is a set of mandatory cause factors, O is a set of optional cause factors, and Ac is a set of tuples A, min , max , in which A is a set of alternative cause factors, and min, max ∈ N, such that min ≤ |A| ≤ max , are the allowed cardinality of cause factors of A.

J. Faccin, I. Nunes / Expert Systems With Applications 95 (2018) 190–200

193

Fig. 1. Cause-effect knowledge model.

A cause-effect relationship thus associates the effect of a problem with possible factors that are its cause. There are cases where a factor is necessarily part of the cause, and in this case it is a mandatory cause factor. Moreover, there may be additional factors that depending on the situation they may be part of the cause (optional or alternative). Example 7. The ceiling_drip fact has a set of alternative causes, as possible cause factors: cracked_roof_tile or broken_pipe, with 1 and 2 as minimum and maximum values, respectively, because both cause factors may be part of the cause. The cause-effect relationship is as shown below.

ceR (ceiling_drip) = ∅, ∅, { {broken_ pipe, cracked_roo f _tile}, 1, 2 }

This cause-effect relationship can be graphically visualised in a directed graph, referred to as cause-effect knowledge model, in which nodes are logical predicates that can be an effect or a cause factor. Edges link an effect with a cause factor, and we use a particular notation to distinguish those mandatory, optional or alternative, detailed in Fig. 1. In this figure, an effect e has several cause factors, m, o, o , a, a . Mandatory and optional cause factors are represented by edges with filled and unfilled rounded line ends, respectively. Alternative cause factors, in turn, are represented by edges with open arrowheads near its targets, with a line connecting cause factors within the same set. This notation is inspired by feature models (Czarnecki & Eisenecker, 20 0 0; Kang, Cohen, Hess, Novak, & Peterson, 1990) that, although have a completely different purpose, also represent this notion of mandatory, optional and alternative concepts. Both cause factors and effects are logical predicates, therefore, an effect f may be associated with a cause factor f , which in turn may be associated with a cause factor f  . This can be seen in Fig. 1, where o is simultaneously a cause factor of e and an effect of m . Cause factors can also be associated with more than one effect. This situation is also depicted in Fig. 1, where a is both a cause factor of e and e . We assume there are no cycles. Cause-effect relationships (and the cause-effect knowledge model) only indicate possible factors that comprise the cause of an effect. How, based on this knowledge, the actual cause is identified at runtime and how this information is used are described when we detail our customised reasoning cycle. 3.4. EBDI Software agent and architecture Before introducing our reasoning cycle, we describe our extended BDI agent, EBDI agent, defined as follows. There is one single extension, which is a preference function that gives the importance of a resource for an agent.

Fig. 2. EBDI architecture.

Definition 8 (EBDI Agent). An EBDI agent is a tuple B, G, P, P , where B is a set of beliefs, G is a set of (possibly constrained) goals, P is a set of plans, and P is a preference function. Definition 9 (Preference Function). P : R  [0, 1] is a partial function that maps resources ri to a value indicating the agent preferences over resources. A preference is a value ri pre f ∈ [0, 1] that indicates the importance of a resource r, with 0 and 1 being the lowest  and highest preference, respectively. Moreover, r ∈domP P (ri ) = 1. i

Example 8. In our example, agent A has a belief corresponding to the cause-effect relationship, detailed in Example 7. It has three plans, namely duct_tape_plan, towel_plan, and bucket_plan, each of them being able to achieve the goal ceiling_leak. The preference function P gives A’s preferences over the use of resources cost and time, which are 0.3 and 0.7, respectively, thus {cost →0.3, time →0.7}. This description of EBDI agents allows us to derive the EBDI architecture, shown in Fig. 2. It details the different components that comprise an EBDI agent. Moreover, we highlight behavioural modules that are detailed in next section. 4. Customised reasoning cycle In the previous section, we focused on detailing the agent structure. We now focus on detailing its behaviour at runtime, by customising steps of the BDI reasoning cycle. This cycle can be generally described as an iterative sequence of steps performed by different functions, namely: 1. belief revision function, responsible for updating beliefs based on events (internal or external) perceived by the agent; 2. option generation function, which updates agent current goals, by generating or dropping goals; 3. filter function, which selects, from agent goals, those that the agent will commit to achieve, thus becoming intentions; and 4. plan selection function, responsible for selecting, from a set of predefined suitable plans, a plan to achieve goals that are intentions, according to a given criteria. In order for an agent to provide the required behaviour to deal with critical cause-effect situations, functions of this reasoning cycle must be customised. First, in order to choose among plans, including those with remediation actions, our plan selection function

194

J. Faccin, I. Nunes / Expert Systems With Applications 95 (2018) 190–200 Table 1 Required resource of agent A’s plans.

time cost

has the highest utility value, as follows.

duct _tape_ plan

towel _ plan

bucket _ plan

600 $0.5

120 $6.0

150 $0.0

P Sel (gc , P ) =

4.1. Plan selection With a set of intentions, which are goals to be achieved, an agent must choose suitable plans to be executed. A single plan is chosen for each intention in an iteration of the reasoning cycle. Our plan selector performs two key steps. The first selects a set of candidate plans and then, from these, the second step chooses the one that best satisfies preferences over resource consumption. Definition 10 (Candidate Plan). A plan p is candidate plan of a goal g, candidate(p, g), if it (i) has all its context conditions satisfied by the current context, i.e. for all pre ∈ Pre, pre must be an agent true belief; (ii) can achieve g, i.e. g ∈ G; and (iii) satisfies all its operation constraints C, i.e. for all c ∈ C, Rreq p satisfies c, if g is a constrained goal. Example 9. Table 1 details the plan required resources of the three plans of our running example, for each considered resource. No plan has context conditions, they all achieve the goal ceil ing_l eak, and Alice has an operation constraint cost < $5. Therefore, the set of candidate plans of this goal is {duct _tape_ plan, bucket _ plan}. Plan preconditions and operation constraints are both used to discard plans that are not candidates to achieve a given goal. However, it is important to highlight that they are semantically different. The former is used to indicate the requirements needed for a plan to be executed, while the latter specifies the conditions in which a goal must be achieved. After the selection of candidate plans, a utility value associated with resource consumption is assigned for the remaining plans. We assume that the amount of resource consumed by a plan has a linear relationship with the promoted utility value, which is in the range [0, 1]. Therefore, for each resource over which an agent has preferences, i.e. for each r ∈ domP, we normalise the range of plan required resources, considering plans that can achieve the given goal, to the range of utility values. This normalisation takes into account the goal objective function. If the resource is associated with min, the lowest and highest required resource are associated with 1 and 0 utility values, respectively and, the opposite, if it is associated with max. If the objective function is undefined for a given resource, the utility value of that resource is 0 for all plans. In order to obtain plan utility, a weighted sum is calculated considering the agent preference function as weights. This is shown in the following equation, which gives the utility values of a plan p.



P (r ) × T(Rreq p (r ))

U ( p)

(2)

where gc is a constrained goal, Candidates(P, gc ) gives the candidate plans of gc , i.e. p ∈ P, such that candidate(p, gc ).

chooses for execution the plan that satisfies goal constraints and, at the same time, contributes most for the satisfaction of agent preferences over resource consumption. Second, our option generation function is able to identify, evaluate and generate goals for a cause and its factors. Note that the first function is focused on constrained goals, while the second takes into account cause-effect relationships. In this way, we may have constrained goals with no associated cause-effect relationship, or a traditional goal with a cause-effect relationship. However, their combination is required for addressing our target situations.

U ( p) =

argmax

p∈Candidates(P,gc )

(1)

r∈domP

where T is the function that normalises the plan required resource. Finally, our plan selector PSel chooses for execution the plan that

Example 10. Considering the plans and their required resources to achieve ceil ing_l eak, described in Table 1, the range of possible values is [120, 600] for time. Therefore, after normalisation and considering the need for minimising time consumption, duct _tape_ plan has a required resource value equals to 0.0, i.e. the lowest desirable time possible, while bucket _ plan has a required resource value equals to 0.9. Remember that the time required by bucket _ plan is 150s, which is very close to the best time possible (120s from towel _ plan). Given that the objective function is undefined for the resource cost, it is not taken into account. Considering U, the two candidate plans have the following utilities, considering preferences over resources: U (duct _tape_ plan ) = 0.3 × 0.0 + 0.7 × 0.0 = 0.0, and U (bucket _ plan ) = 0.3 × 0.0 + 0.7 × 0.9 = 0.6. The selected plan is thus the bucket _ plan plan. Our plan selection function thus selects a plan that best satisfies a constrained goal. This selection process is similar to existing plan selection approaches satisfying other criteria (Faccin & Nunes, 2015). In our work, our plan selection function is used in combination with the goal generation function to address our target scenario. The selected plan may be a plan that can simply achieve the achievement or test goal associated with this goal, or may also address associated causes, if this goal is associated with a cause-effect relationship. The former would be a remediation plan, which can be selected considering preferences and required resources. However, if it is selected, the cause must still be addressed, and this is done with our goal generation function, as detailed next. 4.2. Goal generation As stated earlier, the option generation function is responsible for managing agent goals. In our work, this function plays a crucial role, because it manages the tracking of goals that are associated with effects that have a cause in order to generate goals associated with cause factors and conclude (based on them) whether a problem has been fully resolved. To keep track of the effect, cause and cause factors, we use an internal reasoning cycle structure defined as follows. For simplicity in the explanation, we assume that effect and cause factors are logical propositions (a fact) instead of logical predicates. However, the approach can be generalised for covering the latter. Definition 11 (Cause-effect Problem). A cause-effect problem ceP (e) of an effect e is a tuple ge , CFS , ceES , where ge is an achievement goal in the form !¬e; CFS is a set of cause-factor status fact, si , su , ?g, !¬g , where fact is a possible cause factor of e according to the cause-effect relationship ceR (e), si ∈ {true, false, nil} is the initial state, su ∈ {true, false} is an updated state, ?g is a generated test goal, and !¬g is a generated achievement goal; and ceES is the problem end state. The key idea is that, when an achievement goal that focuses on dealing with the effect of a problem is added, a cause-effect problem is created to keep track of it. Based on the cause-effect relationship, all possible cause factors have their status monitored. si stores whether a cause factor holds, at the first time that this information is known. For example, when adding the ceil ing_l eak goal, Alice may already know that there is a broken pipe. In this case, si becomes true, without searching whether broken_ pipe holds. su

J. Faccin, I. Nunes / Expert Systems With Applications 95 (2018) 190–200

195

stores whether the state of the cause factor changed since its initial state is known. This is important because, if a non-remediation plan was performed to achieve ge that also had as postcondition ¬fact, it is possible to infer that the cause factor fact was already dealt with. If this was not the case, goals to investigate (?fact) and address (!¬fact) the cause factor must be generated, and these are stored in ?g, !¬g, respectively. Whenever the state of fact changes, su is updated. Therefore, if other effects with a shared cause factor already addressed it, no goal is generated to do it again. The idea described above is shown in our option generation function presented in Algorithm 1. Before detailing our algorithm,

Algorithm 1: GenerateGoals(G, B). Input: G: set of agent goals, B: set of agent beliefs Output: G: updated set of agent goals 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

foreach !¬g ∈ G do if ∃ceR (g) ∧ ceP (g) then ceP (g) ← !¬g, ∅, nil ; foreach ci ∈ causeFactors (ceR (g)) do ceP (g)[CFS ] ← ceP (g)[CFS ] ∪ ci , nil, nil, nil, nil

if ∃ceP (g) then foreach c f ∈ ceP (g)[CFS ] do if c f [si ] = nil then if c f [ f act] ∈ B then c f [si ] = true; else if ¬c f [ f act] ∈ B then c f [si ] = f alse; c f [su ] = f alse; else if (c f [si ] = true ∧ ¬c f [ f act] ∈ B ) ∨ (c f [si ] = f alse ∧ c f [ f act] ∈ B ) then c f [su ] = true; if finished (goalStatus (!¬g)) then if knownCause (ceP (g), ceR (g)) then if causeFinished (ceP (g)) then ceP (g)[ceES ] ← endState(ceP (g)); ceP (g) ← nil; else foreach c f ∈ ceP (g)[CFS ] do if c f [su ] = f alse ∧ c f [!¬g] = nil then c f [!¬g] ←!¬c f [ f act]; G ← G ∪ {c f [!¬g]}; else if causeNotFound (ceP (g)) then ceP (g)[ceES ] ← endState (ceP (g)); ceP (g) ← nil; else foreach c f ∈ ceP (g)[CFS ] do if c f [si ] = nil ∧ c f [?g] = nil then c f [?g] ←?c f [ f act]; G ← G ∪ {c f [?g]}; return G;

we introduce the definition of sets of elements that are used throughout this section. They are defined in Table 2, which also specifies the possible states available for goals and cause-effect problems. Moreover, the algorithm uses a set of auxiliary functions that are described in Table 3. In order to facilitate its understanding, we present in Fig. 3 an overview of this algorithm in a UML activity diagram, focusing solely on what happens with achievement goals that focus on dealing with the effect of a problem. In each execution of the BDI reasoning cycle, this algorithm is executed. First, when a goal that is an effect according to a causeeffect relationship is added, a cause-effect problem is created asso-

Fig. 3. Option generation activity diagram.

ciated with it (Activity 1, lines 2–5 of Algorithm 1). Then, for this new added cause-effect problem and all existing others, the cause factor status are updated (Activity 2, lines 7–16 of Algorithm 1). Next, the status of the goal associated with the effect is evaluated (Activity 3, line 17 of Algorithm 1). If this goal did not reach a finished state—see the finished(gS ) function, in Table 3—no goals are generated. Otherwise, the cause is evaluated (Activity 4, lines 18 and 28 of Algorithm 1). If the cause is unknown, test goals associated with cause factors for those with an unknown initial state are generated, if needed (Activity 5, lines 32–34 of Algorithm 1). If the cause is known, there are two possibilities. The first is that achievement goals associated with cause factors have not been generated or have not finished yet and, in this case, they are created if needed (Activity 6, lines 23–26 of Algorithm 1). The second is that they all reached a finished state. In this case, the causeeffect problem reached an end state, and this state is updated according to the possibilities described in Table 4 (Activity 7, lines 19–21 of Algorithm 1). Finally, if after searching for the cause, it was not possible to identify it, the end state is updated accordingly (Activity 7, lines 28–29 of Algorithm 1). Example 11. We assume, in our running example, that the constrained goal ceil ing_l eak is achieved by the bucket _ plan plan, selected with our plan selection function. Such constrained goal has as goal !¬ceiling_drip, which has an associated cause-effect relationship ceR (ceiling_drip). Due to this, a cause-effect problem ceP (ceiling_drip) is created. After ceil ing_l eak is achieved, two test goals are generated: ?broken_ pipe and ?cracked_roo f _tile. Assuming that both goals were achieved, and only broken_ pipe is true, an achievement goal !¬broken_ pipe is generated. If this goal is achieved, the end state of our cause-effect problem is Fully Resolved.

5. Evaluation Given that we presented both our proposed architecture and customised reasoning cycle, we now focus on the evaluation of our approach. We first briefly describe how we implemented it as an extension of an existing BDI agent platform, namely BDI4JADE (Nunes, Lucena, & Luck, 2011). Then, we describe the procedure of our evaluation, followed by obtained results.

196

J. Faccin, I. Nunes / Expert Systems With Applications 95 (2018) 190–200 Table 2 Status Set Descriptions. Set

Set Description

Set Elements

Element Description

GS

The set of all possible status of a goal

CEES

The set of all possible end states of a cause-effect problem

achieved unachievable noLongerDesired nil unsuccessful causePartiallyResolved causeResolved mitigated partiallyResolved fullyResolved

The goal has been achieved The goal cannot be achieved The goal is no longer desired The agent is trying to achieve the goal Neither the effect or its cause are solved The effect is not solved and its cause is partially addressed The effect is not solved and its cause is completely addressed The effect is solved and its cause is not addressed The effect is solved and its cause is partially addressed The effect is solved and its cause is completely addressed

Table 3 Description of auxiliary functions. (a) Predicate

Logic Expression

finished(gS )

f inished (gS ) =

knownCause(ceP (g), ceR (g))

causeNotFound(ceP (g))

Description



true, if gS ∈ GS \ {nil } f alse, otherwise

It is true when a goal g has reached a finished status, that is, it is true, if gS = nil, or false, otherwise.

(∀c f ∈ ceP (g)[CFS ], c f [si ] = nil )∧ (∀ f ∈ ceR (g)[M]∃c f ∈ ceP (g)[CFS ]|c f [ f act] = f, c f [si ] = true )∧ (∀ac ∈ ceR (g)[Ac ], ac [min] ≤ |{c f : c f ∈ ceP (g)[CFS ]∧ c f [ f act] ∈ ac [A]∧ c f [si ] = true}| ≤ ac [max] )

∃c f ∈ ceP (g)[CFS ], c f [si ] = nil∧ f inished (goalStatus(c f [?g] )

causeFinished(ceP (g)) ∀c f ∈ ceP (g)[CFS ] : c f [su ] = true

It is true when the cause of an effect was identified. It means that the initial state of all cause factors are known, mandatory cause factors are true, and those alternative satisfy the cardinality of an alternative set. It is true when it was not possible to identify the cause of an effect. It means that there are cause factors with an unknown initial state, even after associated test goals reached a finished status. It is true when the update state of all cause factors that are actually part of the cause is true.

(b) Function

Mathematical Expression

causeFactors(ceR (g))

{ f : f ∈ ceR (g)[M]∨ f ∈ ceR (g)[O]∨

goalStatus(g) endState(ceP (g))

f ∈ ac [A], ac ∈ ceR (g)[Ac ]}

Description Gives the set of all possible cause factors, including those that are mandatory, optional and alternatives within the alternative sets.

goalStatus(g): G → GS

Gives the current status of a goal g.

endState(ceP (g)) = CEP → CEES

Gives the end state of a cause-effect problem. Possible states are detailed in Table 4.

5.1. BDI4JADE implementation To evaluate our approach, we implemented it using the BDI4JADE platform (Nunes et al., 2011). This platform was selected because it provides means of an easy extension of the steps of the reasoning cycle. With respect to constrained goals, we added a new type of goal to the platform, with the class ConstrainedGoal implementing the Goal interface of BDI4JADE. In addition, the classes ResourcePreferences and PlanRequiredResources were implemented to represent preferences over resources and required resources of plans, respectively. The former is added as an agent belief, while the latter as plan metadata (available in the platform). These and other associated classes are used in a customised plan selection strategy (an extension point of the platform). We also created the classes needed to model the cause-effect knowledge model, which is also added as an agent belief. Such classes are used in an implemented option generation function, another platform extension point. All these described components are added as part of a capability. BDI4JADE uses this concept to modularise agents. To imple-

ment a BDI agent using our approach, this capability must be instantiated and the knowledge regarding preferences over resources, plan required resources and cause-effect relationships must be provided. 5.2. Scenario and procedure Our approach has the goal of allowing agents themselves to choose appropriate actions to mitigate the effects of a problem and resolve its cause. In order to evaluate the approach, we thus selected an existing solution for combating distributed denial-ofservice (DDoS) attacks (Schaeffer-Filho et al., 2012), which manually implements this behaviour we aim to automate. This strategy begins by initially observing an abnormal network traffic in a network link by a link monitor. This is a problem that should be addressed, and the abnormal traffic is its effect. Before investigating the cause of this problem, it is essential to mitigate the effect, otherwise servers may become unavailable. Therefore, the link is limited to reduce the amount of traffic. The first step towards the cause identification is to identify the victim of the attack. For this, an anomaly detection component makes a statistical analysis of the traffic. Now, that part of the cause was identified,

J. Faccin, I. Nunes / Expert Systems With Applications 95 (2018) 190–200

197

Table 4 Cause-effect problem end states. End State

Logic Expression

Description Effect Goal

Unsuccessful

(goalStatus(g) ∈ GS \ {achieved, nil } )∧ ((causeNotF ound (ceP (g))∨ (∀c f ∈ ceP (g)[CFS ], c f [su ] = f alse ))

Cause Partially Resolved

(goalStatus(g) ∈ GS \ {achieved, nil } )∧ (¬causeNotF ound (ceP (g))∧ (∃c f ∈ ceP (g)[CFS ], c f [su ] = f alse )∧ (∃c f ∈ ceP (g)[CFS ], c f [su ] = true )

Cause Resolved

(goalStatus(g) ∈ GS \ {achieved, nil } )∧ (¬causeNotF ound (ceP (g))∧ (∀c f ∈ ceP (g)[CFS ], c f [su ] = true )

Mitigated

(goalStatus(g) = achieved )∧ ((causeNotF ound (ceP (g))∨ (∀c f ∈ ceP (g)[CFS ], c f [su ] = f alse ))

Partially Resolved

(goalStatus(g) = achieved )∧ (¬causeNotF ound (ceP (g))∧ (∃c f ∈ ceP (g)[CFS ], c f [su ] = f alse )∧ (∃c f ∈ ceP (g)[CFS ], c f [su ] = true )

Fully Resolved

(goalStatus(g) = achieved )∧ (¬causeNotF ound (ceP (g))∧ (∀c f ∈ ceP (g)[CFS ], c f [su ] = true )

the traffic destined to the attack victims is reduced. The second step towards the cause identification is to identify the malicious flows of the attack, i.e. not only the victim should be known, but also the source of the attack. When this is done, malicious flows can have their traffic limited, and this completes the resolution of the problem. The described strategy has a police-based (Schaeffer-Filho et al., 2012) and a multi-agent (Nunes & Schaeffer-Filho, 2014) implementation. To evaluate our approach, we implemented such strategy using our described BDI4JADE extension. This allows us to: (i) demonstrate that agents can autonomously and flexibly deal with a critical cause-effect scenario; (ii) assess the impact of the domainindependent problem-solving strategy in the performance; and (iii) measure the reduction of development effort. 5.3. Results and analysis Our implementation of the strategy to combat DDoS attacks used the previous multi-agent implementation as a baseline (Nunes & Schaeffer-Filho, 2014). This was performed in order to have similar plans, so that variance in our measurements would not be due to plan body implementations or other details not related to the problem-solving reasoning. We next describe how the strategy was implemented. Initially, the cause-effect relationships between elements of the scenario were identified and instantiated in a cause-effect knowledge model, which is represented in Fig. 4, together with plans to achieve test and achievement goals. The different stages of the strategy described above are modelled as two cause-effect relationships. A detected abnormal traffic in a link (overUsage(link)) can be due to an anomalous usage, meaning that exists at least one server receiving abnormal incoming traffic (anomalous(IP)). This in turn can be due to a malicious attack, which means that there exists at least one flow that is a threat (threat(flow)). This model together with the plans work in the following way. First, when the traffic in a link is above a threshold, a ¬overUsage(link) goal is added. Then, a cause-effect problem is created and the LimitLink plan is executed to achieve the goal. Next, because of the cause-effect problem, a test goal is generated to verify the cause, and the AnaliseLinkStatistics plan executes, resulting in a set of, if any, servers receiving anomalous traffic. This leads to the cre-

Cause / Cause Factors Cause not found or none of the cause factors were achieved.

Unachievable or No longer desired

Cause identified and some of the cause factors were achieved.

Cause identified and all of the cause factors were achieved.

Cause not found or none of the cause factors were achieved.

Resolved

Cause identified and some of the cause factors were achieved.

Cause identified and all of the cause factors were achieved.

Fig. 4. DDoS cause-effect model.

ation of achievement goals to limit the server traffic (LimitIP)— as stated before, here we made a simplification that causes are facts, but the approach can be generalised to many cause factor instances, as the approach is implemented. Finally, for each anomalous(ip), its cause is investigated by the ClassifyFlow plan, and flows that are threats are resolved by the LimitFlows plan. This implemented behaviour follows the strategy as proposed, in which a remediation plan is always performed. We now show a benefit of our approach that provides agents with flexible behaviour by simply informing preferences over resources. Assume that, in order to achieve the ¬overUsage(link) goal, there are two additional plans: (i) one that takes the time to analyse the traffic, find target servers, and only limits the traffic to these servers (FindLimitIP); and (ii) another to do nothing, assuming that the abnormal traffic was temporary (DoNothing). Then, we specify resources required by the plans. The first is time taken to execute (time), the second is associated with how much network bandwidth will become unavailable (Network Availability), and the last is associated with how much the network will become vulnerable (Vulnerability). Depending on preferences, and possibly constraints, specified for the ¬overUsage(link) goal, which is then a constrained goal, different remediation plans can be selected. Moreover, note that the approach is robust enough for not searching for known causes. If the FindLimitIP plan is selected and executed, as result of its execution, which includes the analysis of the link statistics, anomalous(IP) would already be known. Therefore, in this case,

198

J. Faccin, I. Nunes / Expert Systems With Applications 95 (2018) 190–200 Table 5 Evaluation results.

Baseline Our approach

Executing Time (s)

Development Effort (LOC)

82.086 82.105

733 553

the cause becomes known while mitigating the effect and, after that, the cause is immediately addressed. Finally, we compare our approach with our baseline from two perspectives: performance and development effort (estimated by lines of code). The baseline implementation is a project that has 3260 lines of code (LOC). We limited ourselves to reengineer only the behaviour associated with the reasoning automated by our approach. The portion of code that implemented this reasoning (with goal generation, plans, etc.) has 733 LOC. Our application implementation, using our BDI4JADE extension, consists of 553 LOC. Consequently, our approach was able to reduce 24.5% of the development effort in terms of LOC. Note that such behaviour that was automated is typically complex, thus hard to implement and maintain. We also assessed if, by providing a domain-independent solution, agent performance would decay. For this purpose, we used synthetic data to simulate a DDoS attack scenario to be dealt with and compared the executing time of both strategy implementations. As shown in Table 5, which summarises obtained results, the executing time of the simulation of both implementations is similar—our approach took only 19ms more to execute. It is important to highlight that the use of real data would not impact the outcome of this experiment, given that it is directly associated with the behaviour implemented within plan bodies, which is the same in both system versions. Moreover, because of the deterministic behaviour of both implementations—there is only one possible execution path—the presented results correspond to a single execution of each of them. We in fact run the simulation multiple times, always obtaining the same results. In summary, our approach is able to reduce the amount of code to be developed (in terms of LOC) by approximately 25%, by providing a reusable automated solution to our addressed problem. Moreover, this domain-independent solution does not reduce system performance, despite its generality. Although LOC is not a synonym of development effort, because code varies in complexity, we emphasise that the code that is now automated by our approach is not a trivial part of the implementation, due to the many conditions that should be considered in the design and implementation of remediation behaviour. Therefore, by automating the reasoning about remediation actions, we potentially reduce the development effort, thus reducing time-to-market and development costs. We do not expect a reduction of 25% of the effort in any software project, given that the proportion between the reasoning about remediation actions and other concerns to be implemented varies. However, some reduction in effort is always expected. By suppressing the need for this reasoning to be manually implemented in software systems, we also potentially improve maintainability because this concern is typically implemented interleaved with the code that implements the standard behaviour of plans. Therefore, our approach provides a better separation of concerns. Despite the automation provided by our approach, causal relationships must still be manually modelled. This task is not trivial and, therefore, would benefit from further automation, if it is possible to infer it by monitoring the system execution. Nevertheless, this is not addressed in our approach, leaving an open issue to be addressed in the future. 6. Related work There is much work suggesting different customisations to the functions that are part of the BDI reasoning cycle.

Plan selection function. Regarding the plan selection function, several approaches proposed the use of preferences. Padgham and Singh (2013), for instance, exploited the concept of preferences to address the problem of over-constrained plan preconditions. They argue that in typical BDI agent implementations, conditions that define the applicability of plans are over-constrained, making these plans unusable in situations in which they would be potentially useful. In this context, the use of preferences would not only soften these hard constraints, but also allows an agent to explain its decisions to end-users. In this approach, preferences are specified as numerical values over relational formulas comprising context attributes. These preferences are used to calculate plan values according to their attributes and the current context. Results from such calculation, which may vary according to the situation, are used to set the order in which plans are attempted. Although able to select plans that better satisfy agent preferences, this approach does not focus on dealing with scenarios such as those targeted in our work, in which resource consumption plays a key role. In our work, in contrast, we assume that constraints are used only to specify conditions in which a plan would be non-operational and preferences enable the choice of the most suitable plan according to the current context, leading to a better use of resources. Visser, Thangarajah, and Harland (2011) specified sets of preference formulas over goal attributes and values regarding plan’s resource usage, thus determining the preferable way in which goals must be achieved. In their work, the agent’s plan library is seen as a goal-plan tree (Airiau, Padgham, Sardina, & Sen, 2008) in which each node is annotated with information regarding goal properties and the use of resources. Similarly to the previous approach, this information is used to compute a score for each applicable plan, which is then used to determine the order in which plans will be attempted. An issue is that developers must guarantee that values assigned for preference formulas are consistent with the behaviour required from the agent. Nunes and Luck (2014), in turn, defined preferences regarding resources, which are represented as softgoals. These preferences are specified as numerical values, ranging from 0 to 1, in which higher values represent higher preferences, and optimisation functions, which determine how goals must be accomplished. This information is used in a utility function whose outcome specifies the degree of satisfaction provided by a given plan. More than just considering how plans would contribute to the satisfaction of agent preferences, this approach also takes into account the uncertainty inherent to plan executions, thus selecting not only the plan with the highest contribution, but that plan that will most likely succeed. Although similar to our proposal, the plan selection approaches proposed by Visser et al. (2011) and Nunes and Luck (2014) are limited to the use of preferences and do not deal with other elements that can impact plan selection, such as the use of constraints. Dasgupta and Ghose (2010) proposed an approach able to address this limitation. In their work, preferences are defined as optimisation functions specified over resources, which are represented by softgoals. Constraints are thus used to specify the context in which plans are considered applicable. The plan selected for execution is that with constrained preconditions that are satisfied in the current context, and that is able to better satisfy the specified optimisation functions. This use of constraints is, however, not valid in our scenario, because our goal operation constraints are goal-specific and not valid for a plan to achieve any goal. Our proposed constraints thus specify how a goal must be achieved rather than the requirements for the execution of a plan. In Table 6, we present a summary of how each of these related approaches deals with the main challenges faced when selecting plans in the scenario targeted in this work. As can be seen, approaches use constraints only to inform whether a plan can be executed to achieve a goal. Our approach also considers goal con-

J. Faccin, I. Nunes / Expert Systems With Applications 95 (2018) 190–200

199

Table 6 Comparison of characteristics of approaches that customise the BDI plan selection function.

Padgham and Singh (2013)

Visser et al. (2011)

Nunes and Luck (2014)

Dasgupta and Ghose (2010) Our solution

Preferences

Goal Constraints

Plan Constraints

Resource Consumption

Numerical values specified over relational formulas comprising context attributes. Numerical values specified over relational formulas comprising goal attributes and plan values. Numerical values and optimisation functions specified over softgoals. Optimisation functions specified over softgoals. Numerical values and optimisation functions specified over softgoals.

-

Relational formulas that specify when a plan is applicable.

-

-

Relational formulas that specify when a plan is applicable.

Estimated in terms of the expected plan outcomes.

-

Relational formulas that specify when a plan is applicable.

Measured in terms of the expected plan outcomes.

-

Relational formulas that specify when a plan is applicable. Relational formulas that specify when a plan is applicable.

Specified as plan attributes.

Relational formulas that specify how a goal must be achieved.

straints, which impose restrictions on how goals can be achieved, enabling the agent to choose remediation actions, when long-term solutions cannot be used considering context conditions. In particular, we focus on the representation of preferences, how each approach deals with constraints, and how resource consumption is represented. It is possible to notice that every approach is able to address some of these challenges in a certain degree. However, none of them is capable to deal with all of them at once. Our proposed plan selection process aims to aggregate the strengths of these approaches in a single place, thus practically selecting plans able to achieve constrained goals and to satisfy preferences accordingly. Moreover, as discussed, the plan selection function alone cannot address our critical cause-effect situations.

Option generation function. Regarding adaptations of the option generation function, we are not aware of other work considering goal relationships analogous to the cause-effect relationships we propose. However, there are several approaches specifically suggesting different general purpose models to specify causality. Pearl (1995) proposed the use of graphical models, which are based on the graph theory, to represent causal relationships. In these graphical models, similarly to our cause-effect knowledge model, nodes describe either causes and effects, and the relationships between them are depicted as directed edges. In some cases, these edges may contain values indicating the probability of a given factor to be the cause of another one. This graphical representation provides an easy and immediate identification of existing causal relationships as well as the inference of additional information such as the independence between factors, i.e. when a factor has no influence on others. A different approach, proposed by Pearl (2009) and revised by Halpern (2015), uses structural equations to model causal relationships. In their model, the world is described in terms of variables and its corresponding values, and the influence that variables have among them is described by the structural equations. This approach can deal with more complex scenarios in which the dependency between causes must be considered or when there is a need for identifying and “blaming” the cause of a problem, for example. These existing approaches have different characteristics, such as different degrees of complexity and informative power, which make them more or less suitable according to the given context. Such existing work on causal modelling could be used in our work; however, they would introduce an unnecessary complexity to our solution, which could compromise its practical adoption or would not provide the information we require. In fact, our causal model exploits the strengths of these modelling approaches, being able to represent what is needed for

Measured in terms of the expected plan outcomes.

providing our desired behaviour in a way that more complex models would not aggregate value to our proposed solution. Many other approaches are complementary to our proposal, specially regarding additional reasoning that agents can perform. In our approach, goals associated with a cause-effect problem are achieved in a stepwise way. Therefore, the conventional binary representation of goal states, i.e. fully achieved or unachieved, becomes insufficient. Aiming to address the need for a suitable representation, van Riemsdijk and Yorke-Smith (2012) presented an abstract framework that can be taken as a basis for representing partial goal satisfaction. This framework allows the representation of quantitative notions of partiality through the use of progress metrics, which can be domain-dependent or domain-independent (e.g. time or utility). An agent using this representation can assess how far it is in achieving a goal. Such information becomes valuable, for example, in a context in which goals must be prioritised based on its completeness degree. However, although describing how agents can reason based on such representation, the authors did not provide any detailed computational mechanisms. This issue is addressed by Thangarajah, Harland, Morley, and Yorke-Smith (2014), with the proposal of an approach that can be used computationally to quantify a measure of goal completeness. They propose the use of resource consumption and effects of achieving a goal as factors to determine a quantifiable measure of goal accomplishment. They used annotations in plans and goals to explicitly specify lower and upper bounds for each factor and, from these annotations, derive functions that specify the degree of accomplishment of a goal. Considering our context, the completeness of dealing with a causeeffect problem can be assessed basing on the completeness of its effect and cause factor goals, and such information can be used to select plans that achieve goals with more impact on other goals. Nevertheless, this would be an extension of our work and can be addressed in future work. 7. Conclusion The adoption of remediation actions in order to mitigate the effects of a problem being addressed is not an uncommon strategy to deal with situations in which the cause of the problem cannot be solved in a timely fashion or is unknown. This idea is implemented in application-specific, including agent-based, solutions. In this paper we looked at this scenario in an abstract way, and proposed a BDI-agent-based approach in which agents can autonomously choose and execute remediation plans to deal with a problem, and also search, identify, and resolve its causes. Our approach is composed of structural and behavioural parts. The former consists of an architecture, which extends the traditional BDI com-

200

J. Faccin, I. Nunes / Expert Systems With Applications 95 (2018) 190–200

ponents by adding mainly the notion of constrained goals, plan required resources and cause-effect relationships. The latter provides the specification of two abstract functions of the BDI reasoning cycle, which are the plan selection and goal generation functions. In order to evaluate our approach, we considered an existing strategy for combating distributed denial-of-services (DDoS) attacks, which uses remediation actions before addressing the cause of the attack. By using our approach, we demonstrated that our extended BDI agent can autonomously select appropriate plans to deal with the attack and generate goals to identify and resolve its cause. Moreover, we compared the performance of our approach with the existing implementation of this strategy, and results indicate that our approach reduces development effort and does not reduce performance due to the automated reasoning made at runtime. Our work thus provides a ready-to-use solution in which agents are provided with a sophisticated and flexible problem-solving strategy, promoting software reuse in software agents. This work leaves many open challenges that can be addressed to further improve our problem-solving strategy. For example, satisfying all goal constraints may be infeasible, but achieving the goal may be more important than satisfying all constraints. Therefore, dealing with over-constrained cases is relevant. Moreover, goals associated with cause factors may also be constrained goals, and there must be ways to specify constraints and optimisation function for them. In addition, one of the main weaknesses of our approach is the need for manually specifying domain-specific causal models at design time. Providing a solution able to automatically generate such models from information collected at runtime would reduce even more the effort of developing systems with remediative behaviour and increase the systems’ ability to dynamically cope with unpredictable scenarios. This can be achieved, e.g., by using learning approaches such as case-based reasoning. Another issue is that our work is unable to automatically manage remediative actions that must be reverted after their corresponding problems are completely solved. The development of a solution able to identify and revert these actions would benefit not only the kind of scenario addressed in this work, but any situation in which the effects of an action must be temporary. Finally, in order to demonstrate its feasibility and to promote the use of our solution in industry, the development of real world applications and testbeds is mandatory. These are extensions and development tasks that are ongoing work. Acknowledgments This work was supported by the National Council for Scientific and Technological Development (CNPq) (grant numbers 141840/2016-1, 303232/2015-3); the Coordination for the Improvement of Higher Education Personnel (CAPES) (grant number 761915-4); and Alexander von Humboldt (grant ref. BRA 1,184,533 HFSTCAPES-P). References Airiau, S., Padgham, L., Sardina, S., & Sen, S. (2008). Incorporating learning in BDI agents. Adaptive learning agents and multi-agent systems workshop (ALAMAS+ALAg-08), Estoril, Portugal. May.

Bratman, M. (1987). Intention, plans, and practical reason. Cambridge, MA: Harvard University Press. Breitgand, D., Goldstein, M., Henis, E., Shehory, O., & Weinsberg, Y. (2007). PANACEA towards a self-healing development framework. In Integrated network management, IM 2007. 10th IFIP/IEEE International Symposium on Integrated Network Management (pp. 169–178). IEEE. Czarnecki, K., & Eisenecker, U. (20 0 0). Generative programming: Methods, tools, and applications. Addison Wesley Longman. Dasgupta, A., & Ghose, A. K. (2010). Implementing reactive bdi agents with user– given constraints and objectives. International Journal of Agent-Oriented Software Engineering, 4(2), 141–154. Faccin, J., & Nunes, I. (2015). Bdi-agent plan selection based on prediction of plan outcomes. In 2015 IEEE/WIC/ACM international conference on web intelligence and intelligent agent technology (WI-IAT). vol. 2 (pp. 166–173). Dec. Goldstein, M., Shehory, O., & Weinsberg, Y. (2007). Can self-healing software cope with loitering? In Fourth international workshop on software quality assurance: In conjunction with the 6th ESEC/FSE joint meeting. SOQUA ’07 (pp. 1–8). New York, NY, USA: ACM. doi:10.1145/1295074.1295076. Halpern, J. (2015). A modification of the Halpern-Pearl definition of causality. In IJCAI 2015 (pp. 3022–3033). Kang, K., Cohen, S., Hess, J., Novak, W., & Peterson (1990). Feature-oriented domain analysis (foda) feasibility study. Tech. Rep. CMU/SEI-90-TR-021. Software Engineering Institute, Carnegie-Mellon University. November. Nunes, I., Lucena, C. J. P. D., & Luck, M. (2011). BDI4JADE: A BDI layer on top of JADE. In International workshop on programming multi-agent systems (pp. 88–103). Nunes, I., & Luck, M. (2014). Softgoal-based plan selection in model-driven bdi agents. In Proceedings of the 2014 international conference on autonomous agents and multi-agent systems. AAMAS ’14 (pp. 749–756). Richland, SC: International foundation for autonomous agents and multiagent systems. http://dl.acm.org/ citation.cfm?id=2615731.2615852. Nunes, I., & Schaeffer-Filho, A. E. (2014). Reengineering network resilience strategies using a BDI architecture. In Proceedings of the 5th workshop on autonomous software systems (autosoft 2014). maceió, Brazil (pp. 25–36). Padgham, L., & Singh, D. (2013). Situational preferences for bdi plans. In Proceedings of the 2013 international conference on autonomous agents and multi-agent systems. AAMAS ’13 (pp. 1013–1020). Richland, SC: International foundation for autonomous agents and multiagent systems. Pearl, J. (1995). Causal diagrams for empirical research. Biometrika, 82(4), 669–688. Pearl, J. (2009). Causality: Models, Reasoning and Inference (2nd ed.). New York, NY, USA: Cambridge University Press. Rao, A. S. (1996). Agentspeak(l): Bdi agents speak out in a logical computable language. In Proceedings of the 7th european workshop on modelling autonomous agents in a multi-agent world: Agents breaking away: Agents breaking away. MAAMAW ’96 (pp. 42–55). Secaucus, NJ, USA: Springer-Verlag New York, Inc. http: //dl.acm.org/citation.cfm?id=237945.237953. Rao, A. S., & Georgeff, M. P. (1995). BDI Agents: From theory to practice. In First international conference on multi-agent systems (ICMAS) (pp. 312–319). van Riemsdijk, M. B., & Yorke-Smith, N. (2012). Towards reasoning with partial goal satisfaction in intelligent agents. In Proceedings of the 8th international conference on programming multi-agent systems. proMAS’10 (pp. 41–59). Berlin, Heidelberg: Springer-Verlag. doi:10.1007/978- 3- 642- 28939- 2_3. Schaeffer-Filho, A. E., Smith, P., Mauthe, A., Hutchison, D., Yu, Y., & Fry, M. (2012). A framework for the design and evaluation of network resilience management. In NOMS. IEEE (pp. 401–408). Singh, D., Sardina, S., Padgham, L., & Airiau, S. (2010). Learning context conditions for bdi plan selection. In Proceedings of the 9th international conference on autonomous agents and multiagent systems. AAMAS ’10 (pp. 325–332). Richland, SC: International foundation for autonomous agents and multiagent systems. http://dl.acm.org/citation.cfm?id=1838206.1838252. Sterbenz, J. P. G., Hutchison, D., Çetinkaya, E. K., Jabbar, A., Rohrer, J. P., Schöller, M., & Smith, P. (2010). Resilience and survivability in communication networks: Strategies, principles, and survey of disciplines. Computer Networks, 54(8), 1245–1265. Thangarajah, J., Harland, J., Morley, D. N., & Yorke-Smith, N. (2014). Quantifying the completeness of goals in BDI agent systems. In ECAI - 21st european conference on artificial intelligence (pp. 879–884). doi:10.3233/978- 1- 61499- 419- 0- 879. Visser, S., Thangarajah, J., & Harland, J. (2011). Reasoning about preferences in intelligent agent systems. In Proceedings of the twenty-second international joint conference on artificial intelligence - volume volume one. IJCAI’11 (pp. 426–431). AAAI Press. doi:10.5591/978- 1- 57735- 516- 8/IJCAI11- 079.