EBM and ABM (The SLIE approach)

1. EBM and ABM(The SLIE approach) Carles Sierra Mike Wooldridge

2. ABM vs EBM Behaviours Equations Individuals Observables

3. Proposal for Design Rules EBM Analysis ABM Analysis Design Rules

4. Desired results If EBM:Price stable and ABM:Price increases then Increase average beta for customers

5. Methodology

6. What is an Electronic Institution • Role. Standardised patterns of behaviour required of all agents playing part in a given functional relationship. • Dialogic Framework. Ontological elements and communication language (ACL) employed during an agent interaction. • Scene. Agents meetings whose interaction is shaped by a well-defined protocol. • Performative Structure. Complex activities specified as connections among scenes. • Normative rules. Defines the consequences of the agent actions within scenes.

7. Scenes • Scene is a pattern of multi-agent conversation. • During the execution new agents can join the scene or some of the participants can leave the scene at definite states depending on their role. • An scene can be multiple-instantiated and played by different groups of agents.

8. Scenes(II) • Scene is specified by a finite state oriented graph where the nodes represent the different states and oriented arcs are labelled with the events that will make the conversation state evolve. • For each role is defined a set of access and exit states. • Minimum and maximum number of agents per role.

9. Performative Structure Complex activities can be specified by establishing relationships among scenes that: • capture causal dependency. • define synchronisation mechanisms. • establish parallelism mechanisms. • define choice points that allow roles leaving a scene to choose which activity to engage in next. • establish the role flow policy.

10. EIM: Supply chain

11. EIM: ISLANDER Language (define-scene-type negotiationtNOU as roles = (supplier customer) dialogical_framework = Negotiation states = (w1 w2 w3 w4 w5 w6) initial_state = w1 final_states = (w5 w6) acces_states = ((supplier (w1)) (customer (w1))) exit_states = ((supplier (w5 w6)) (customer (w5 w6))) agents_per_role = ((1 leq supplier leq 1) (1 leq customer leq 1)) connections = ((w1 w2 (offer ?s:supplier ?c:customer (Sign ?d:deal ?date) ?date)) (w1 w3 (offer ?c:customer ?s:supplier (Sign ?d:deal ?date) ?date)) ((w2 w3 w4) w2 (offer !s:supplier !c:customer (Sign ?d:deal ?date) ?date)) ((w2 w3 w4) w3 (offer !c:customer !s:supplier (Sign ?d:deal ?date) ?date)) (w2 w4 (reject !c:customer !s:supplier (Sign !d !date))) (w3 w4 (reject !s:supplier !c:customer (Sign !d !date))) (w2 w5 (accept !c:customer !s:supplier (Sign !d !date))) (w3 w5 (accept !s:supplier !c:customer (Sign !d !date))) ((w2 w4 w3) w6 (withdraw !c:customer !s:supplier)) ((w2 w4 w6) w6 (withdraw !s:supplier !c:customer))) constraints =())

12. Software components

13. Model Checking Multi-Agent Systems with MABLE

14. Model Checking • Technique for verifying finite state systems • To verify that S satisfies property P: • generate system state space -- a model which encodes all computations of system • express P as formula of temporal logic • determine whether formula is valid in this model • if “yes”, then system satisfies specification

15. StateSpace Explosion • Systems containing interacting components generate astronomically large state space • Main problem in model checking: • managing this state space explosion

16. CTL Model Checking • Uses CTL branching temporal logic • Low complexity (polynomial time) in size of model & specification • Symbolic CTL model checking with OBDDs main technique for handling state space explosion • Implemented in e.g., SMV, nuSMV

17. LTL Model Checking • LTL model checking more expensive (PSPACE complete) • But techniques to manage complexity: • partial order reduction • “on the fly” verification • Implemented in SPIN (AT&T Bell Labs) • Used for verification of software/protocols

18. SPIN Operation

19. MABLE • Language & tool for automatic formal verification of multi-agent systems • MABLE system contains agents & claims • Makes use of SPIN model checker for • simulation • automatic verification

20. Agents in MABLE • Programmed using imperative language • iteration, sequence, selection a la C • data types: int, bool + enums, records • synchronisation via locks • Agents have beliefs, desires, intentions • may be nested • Communication via “inform”, “request” • with FIPA-like semantics

21. Claims in MABLE • MABLE systems are augmented by claims • Claims expressed using MORA: • BDI modalities (believe i p)... • LTL modalities <>p, []p, p U q • limited quantification forall a : agent ... • pseudo dynamic logic (does I stmt) • macro definitions #define MBEL(i,j,p)...

22. The MABLE Compiler • Translates MABLE agents into PROMELA • Three components to translation: • imperative constructs to PROMELA (easy) • BDI components to PROMELA data structures • claims to SPIN-format LTL formulae

23. Translating Claims • Works by: • expanding out quantification (finite domains) • translating modalities to statements about data structures • renaming predicates with propositions • annotating PROMELA model with new propositions for (does I stmt) construct

24. MABLE Operation

25. Example MABLE Code // this is a claim claim <>(believe agent1 (intend agent2 (believe agent2 a==10))) // this is an agent agent agent2 { await (intend agent1 (believe agent2 a == 10)); if (intend agent1 (believe agent2 a==10)) && (a != 10)) print(“Agent 1 is a LIAR!”); else print(“Agent 1 tells the TRUTH!”); }