Programming Group Computations - DAI-Labor

Programming Group Computations


Benjamin Hirsch

Michael Fisher

Chiara Ghidini





Department of Computer Science, University of Liverpool, UK B.Hirsch, M.Fisher @csc.liv.ac.uk Automated Reasoning Systems Division (SRA), ITC-IRST, Trento, Italy [email protected] 



Abstract. In this paper, we consider the problem of effectively programming groups of agents. These groups should capture structuring mechanisms common in multi-agent systems, such as teams, cooperative groups, and organisations. Not only should individual agents be dynamic and evolving, but the groups in which the agents occur must be open, flexible and capable of similar evolution and restructuring. We enable the description and implementation of such groups by providing an extension to our previous work on programming languages for agent-based systems based on executable temporal and modal logics. With such formalism as a basis, we consider the grouping aspects within multi-agent systems. In particular, we describe how the implementation of grouping primitives has been carried out and analyse a variety of simple mechanisms for organising agents within such groups. Finally, we consider how this work can provide a (formal) basis for a “pattern-based” approach to multi-agent systems.

1 Introduction Agent-based systems are clearly important within both Computer Science research and the software industry. They are used in many areas, including e-commerce [8], industrial process control [2], web services [10] and autonomous vehicles [12]. In spite of the growing number of deployed systems, there remains a significant gap between the theory and practice within agent-based systems [1]. This leads to two problems: the lack of a verifiable agent system; and the lack of a clear set of programming concepts for building agent-based systems. The former is a problem when agents are deployed in (safety or business) critical applications; the latter is a problem when programming complex applications. In our work, we are concerned with the development of a set of concepts, encapsulated within and agent-based programming language, whose semantics is formally defined. In particular, we have been investigating such concepts within the framework of executable temporal logic [3, 4]. This framework provides high-level descriptions of the concepts we are interested in, while having clearly defined semantics. Our recent work has tackled the problem of organising multi-agent systems, not just programming individual agents. To some extent, such organisational aspects are independent of the language used in each agent. However, we have shown how, by again using executable temporal and modal logics, a high-level language for developing multi-agent structures can be developed [9]. This is eased by the fact that we treat group structures within multi-agent systems in exactly the same way as individual agents [6]. 1

In this paper, we will not consider the logical basis for this agent programming language in any great detail. Instead we will concentrate on the mechanisms we use for programming group structures. In particular, we will 1. provide an outline of the implementation, in Java, of the framework for grouping originally proposed in [9]; 2. carry out out an analysis and comparison of grouping structures that can be utilized, extending the initial analysis in [9]; and 3. argue that this group computation approach is well-suited to organising multi-agent systems, forming the basis for a pattern-based approach [7, 11] to organisation within multi-agent systems.

2 Background While executable logic forms the basis for the work described in this paper, we do not intend to highlight these aspects in the description and examples later. However, as this aspect is central to the programme of work, we provide a brief overview of relevant background in this section. 2.1 Agents The language we are developing is based on an extension of M ETATE M [4] incorporating notions of ability, belief, and confidence (ABC) for individual agents [5]. In order to model varieties of rational agent, the M ETATE M basis of linear temporal logic has been extended in a number of ways. In our context, belief is modelled using a multicontext logic that can be seen as similar to the standard KD45 modal logic [4], while confidence is a derived notion capturing the idea of “believing that, eventually, a specific aspect will become true”. The concept of ability used is very simple, being little more than a modality used to prefix formulae and identify abilities. (Note that we will not provide details of the logical basis here, since these are available in [5].) The ABC framework allows the agent to reason, not only about its own activities, but also about the beliefs, goals and abilities of other agents. One of the fundamental formulae in this approach is1 
  



(1)

meaning that “if agent  is confident in eventually occur.”





and has the ability to bring about , then



will

Although (1) may be modified for more sophisticated applications, it gives a flavour of the interaction between the different modalities and the way agents can reason using ability, belief, and confidence. 1



“agent means “at some time in the future”, Here,  means  believes”,  ” means “agent    is able”, and  captures the notion that “agent  is confident in .

2

2.2 Groups The view of individual agents provided above is then combined with the work on structuring M ETATE M agents within groups [6]. Here, not only are groups containing multiple agents defined, but the notion that “Agent Group” is proposed. Using this simplification, groups (agents) can contain several agents, and agents (groups) can participate in several groups (agents). Group membership is dynamic, in that agents can join and leave groups during run-time. It is vital to understand that while we use the words ‘agent’ and ‘group’ to identify certain aspects of the agent, we always refer to the same entities, namely agents. Without going in to too much detail (see [6, 9] for further details), we can summarize some of the advantages of this approach as follows. – Communication (which, in our approach, is based on broadcast) can be limited to subsets of agents and so can be constrained to the groups that the agent participates in. However, the use of broadcast easily allows the notion of open and evolving groups. – Groups, rather than being mere containers, can also have behaviours, captured by their internal policies and rules. Thus, a ‘standard’ agent is essentially a group with no contents, while a group that is a mere container or agents can be seen as an agent with contents, but with little autonomous behaviour. – Agents are opaque, in that their internal structure is hidden from other agents — it is not obvious whether agents have certain abilities natively, or merely make use of other (internal) agents2 . – The inherent structure can be exploited by having group agents based on a variety of aspects such as problem structure, abilities, and even meta-information such as owner, physical location etc. 2.3 Group Communication and Evolution Including groups in our framework involves identifying rules (formulae) that can be used to describe not only the behaviour of a single agent (like formula (1)), but also the behaviours of groups and of group dynamics (for instance, the creation and/or modification of a group). In [9] we showed examples of simple rules that can be used to “extend” (1) in a scenario where groups of agents are present. To give an idea of how (1) can be  expanded, suppose that agent  is confident in but does not have the corresponding ability. We can add to the description of this agent a rule
 




 

   









which specifies that if the agent is confident in but does not have the ability to bring about, it will ask other agents for help. Assuming that some agent answered positively  to the message, saying that they are able to bring about , we can distinguish different behaviours of the agent  , ranging from a “trusting” agent that just assumes that the 2

We see agent-based systems as a natural extension to the object oriented paradigm and wish to at least preserve the aspects of encapsulation that an object oriented approach offers.

3



answering agent will at some point bring about , to the “cautious” agent that sends a  message asserting that it is confident that the answering agents actually bring about at some point in the future, and a “demanding” agent that requests that will be brought about. Depending on the different behaviours of agent  [9] illustrates the different types of group structures, ranging from loose groups, teams, and tight groups. Another important aspect that involves structuring agents into groups, is the capability of creating an hierarchy of agents. As most readers are familiar with concepts of object oriented approach, which is based on a (often fixed) hierarchical structure of classes, we will give some short examples to show how we can (re)create such an hierarchy of agents and even simulate typical properties of the object oriented approach, such as inheritance and abstract methods. Note that in our system, the structure is dynamic, and indeed does not even have to resemble a tree at all3 . Such an agent system provides a natural way to inherit abilities (methods). Each agent has its “super agent” (a.k.a. super class) within its Context, and the following rules in its rule base (for readability purposes we omit some details):




               














  

          !#"%$ '& (
 )+*
      !#"%$ '&  "!$,$.-,$

 




















Context Context









 

(2) (3) (4)



 

Context







(5)

Formula (2) tells the agent to ask it’s Context if it encounters an ability it does not have itself. Formulae (3) to (5) define the reaction of agents that might get a request for an  ability . If they are not able to do , they re-send the message “upwards”, following (3). In the case that they do have the requested ability, they execute it and send the result to the requesting agent (4). Finally, if there are no ancestors, the agent returns with an error message (5).  concerning its Content To simulate an abstract ability , the agent may have a policy  that only allows agents to join the Content that do have ability . In the case of abstract classes, this has to be extended to a set of methods.

1012,34 65657#-89-,;:E- :    2 1 2  G  1G  /   G      2 1 2  1G  G2  1G 2  2 






G   C-,


 
 where is a target set and  is the instance of being sent.    Targetsets can be specified using the set operations union ( ), intersec 

         ), and exclusion ( ), where and can tion ( themselves be single agents, sets of agents, or set expressions 6. Thus,      
 

2






sends  to all members of the agent’s Content set except agent . Additionally, messages
  can be nested. Thus, if an agent receives a send message, it will interpret the relative to its Content/Context/Known sets. For example, agent  can send the following message         
  (11)     
 Then, all agents in ,  
 ’s Context receive the message and re-send  to all their Content, except for agent (which originally sent the message). So, using (11), can send messages to agents that are “on the same level” as itself, that share (some of) the same Context agents. Since nesting of message sends is so common, we also have a special send command

 , which is interpreted by agents to recursively re-send the message to the same set (relative to the receiving agent). For example,



   

 







 2 1 2  1G 



will ensure that message  will be recursively sent to all members of Content sets ‘below’ the sending agent. Also,

     

 









 





will ensure that  is propagated to the whole agent space. The implementation of

 is based on the equivalence



6   G   6   G 2  2  G  G      GG        2  

! #" 



#

" 

– –







 









 



 

Thus, agent , upon receiving 







, and



#" 











$ " %

 

&







#

(12)

, will execute two sends:

  '%

#



.

By removing itself from the list of agents that are to receive the message, we avoid some messages being sent over and over through the agent space. 6

Note that we sometimes use the mathematical notations (*),+*) and - for the set operations ./021 / 0 /434576875:93:021/ , and ; 032