EBM and ABM The SLIE approach Carles Sierra

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

ABM vs EBM Behaviours Equations Individuals Observables

Proposal for Design Rules EBM Analysis Design Rules

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

Methodology

What is an Electronic Institution l l l 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.

Scenes l Scene is a pattern of multi-agent conversation. l 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. l An scene can be multiple-instantiated and played by different groups of agents.

Scenes(II) l l 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. l Minimum and maximum number of agents per role.

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

EIM: Supply chain

EIM: ISLANDER Language (define-scene-type negotiationt. NOU as roles = (supplier customer) dialogical_framework = Negotiation states = (w 1 w 2 w 3 w 4 w 5 w 6) initial_state = w 1 final_states = (w 5 w 6) acces_states = ((supplier (w 1)) (customer (w 1))) exit_states = ((supplier (w 5 w 6)) (customer (w 5 w 6))) agents_per_role = ((1 leq supplier leq 1) (1 leq customer leq 1)) connections = ((w 1 w 2 (offer ? s: supplier ? c: customer (Sign ? d: deal ? date)) (w 1 w 3 (offer ? c: customer ? s: supplier (Sign ? d: deal ? date)) ((w 2 w 3 w 4) w 2 (offer !s: supplier !c: customer (Sign ? d: deal ? date)) ((w 2 w 3 w 4) w 3 (offer !c: customer !s: supplier (Sign ? d: deal ? date)) (w 2 w 4 (reject !c: customer !s: supplier (Sign !d !date))) (w 3 w 4 (reject !s: supplier !c: customer (Sign !d !date))) (w 2 w 5 (accept !c: customer !s: supplier (Sign !d !date))) (w 3 w 5 (accept !s: supplier !c: customer (Sign !d !date))) ((w 2 w 4 w 3) w 6 (withdraw !c: customer !s: supplier)) ((w 2 w 4 w 6) w 6 (withdraw !s: supplier !c: customer))) constraints =())

Software components

Model Checking Multi-Agent Systems with MABLE

Model Checking z. Technique for verifying finite state systems z. To verify that S satisfies property P: ygenerate system state space -- a model which encodes all computations of system yexpress P as formula of temporal logic ydetermine whether formula is valid in this model yif “yes”, then system satisfies specification

State Space Explosion z. Systems containing interacting components generate astronomically large state space z. Main problem in model checking: ymanaging this state space explosion

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

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

SPIN Operation

MABLE z. Language & tool for automatic formal verification of multi-agent systems z. MABLE system contains agents & claims z. Makes use of SPIN model checker for ysimulation yautomatic verification

Agents in MABLE z. Programmed using imperative language yiteration, sequence, selection a la C ydata types: int, bool + enums, records ysynchronisation via locks z. Agents have beliefs, desires, intentions ymay be nested z. Communication via “inform”, “request” ywith FIPA-like semantics

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

The MABLE Compiler z. Translates MABLE agents into PROMELA z. Three components to translation: yimperative constructs to PROMELA (easy) y. BDI components to PROMELA data structures yclaims to SPIN-format LTL formulae

Translating Claims z. Works by: yexpanding out quantification (finite domains) ytranslating modalities to statements about data structures yrenaming predicates with propositions yannotating PROMELA model with new propositions for (does I stmt) construct

MABLE Operation

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