1. An Event-Driven High Level Model for the Specification of Laws in Open Multi-Agent Systems Rodrigo Paes rbp@les.inf.puc-rio.br

2. © LES/PUC-Rio Introduction Laws commonly are used to –Restrict the autonomy of multi-agent systems –Impose some form of control Norms, Laws, Institutions, etc. Conceptual Model Language Middleware enforcement

3. © LES/PUC-Rio Today’s focus Give an overview of the conceptual model –Main features: High level abstractions Event-based model Show a comparison with related work –LGI –Electronic Institutions At the end –Point out some ideas related to dependability

4. © LES/PUC-Rio Architecture for Laws:: MLAW

5. © LES/PUC-Rio Conceptual Model

6. © LES/PUC-Rio Event Mechanism Pseudo code for activating a norm due to the firing of a transition Pseudo code for composing the norm with the clock

7. © LES/PUC-Rio Related Approach #01: LGI Lack of explicit conceptual model –Of course there is one ! Main regulated events –adopted –arrived –disconnected –exception –obligationDue –reconnected –sent –stateChanged –Submitted Main regulated operations –Deliver –Forward –Add –Remove –Replace Mostly concerned with low level communication issues!!!

8. © LES/PUC-Rio Example Requirement #1 –Fire transition t2 when the clock generates a clock_tick event. The transition changes the protocol from state s1 to state s2. –XMLaw t2{s1->s2, myXMLawClock} –LGI obligationDue("myLGIclock ") :- currentState(s1)@CS, do(remove(currentState(s1))), do(add(currentState(s2))), do(add(event(t2,transition_activation))), do(forward). Requirement #2 –Message m1 activates transition t1. The transition t1 changes the protocol state from s1 to s2. The norm n1 must be activated when transition t1 is fired. The norm is given to the agent that received the message m1. –XMLaw t1{s1->s2, m1} n1{$addressee, (t1) } –LGI sent(A,m1,Addresee) -> currentState(s1)@CS, do(remove(currentState(s1))), do(add(currentState(s2))), do(add(event(t1,transition_activation))), do(forward). imposeStateObligation( event(t1,transition_activation) ). stateChanged(event (t1,transition_activation)) :- do( add( event(n1,norm_activation) ) ), do(add(norm(n1,active,valid)).

9. © LES/PUC-Rio Related Approach #02: Electronic Institutions Electronic InstitutionsXMLaw Illocutory formulasMessage EI vocabulary (ontology)It is defined in the messages themselves, instead of separately. Internal rolesNot considered External rolesRole Relationships over rolesNot considered Control over role playing Scene Performative StructureNot considered. Protocol State Directed edgeTransition. Constraint Time-outClock Normative rulesNorms Not consideredActions Not consideredLaw Both approaches have high level abstractions!!! … however EI is not event-based Less flexibility it is not possible to connect time-outs and directed edges, for example.

10. © LES/PUC-Rio Pros and Cons of XMLaw when compared to LGI and EI ItemLGIElectronic InstitutionsXMLaw Level of abstractionLowHigh Level of flexibility in the composition of the elements (event-based model) HighLowHigh Scalability with decentralized lawsHighLow Global centered view of the systemNoYes Use of Java to help the specification of the laws Partial (in LGI it is possible to specify the laws using a prolog-based language or pure Java, however it is not possible to combine the declarative with the imperative parts of the laws as is done with actions in XMLaw) NoYes Approach is subject to a central point of congestion NoYes (although the enforcement is done locally, mediators have to synchronize the states to build a global view, in this way, the synchronization becomes a bottleneck) Yes Approach address security issuesCertification authoritiesNo Allows agents to communicate in any different content languages NoPartial (only prolog and lisp)Yes Time-sensitive normsNo Yes

11. © LES/PUC-Rio Laws and Dependability General idea –Laws define explicitly how the system is expected to behave –… and what should happen in case of non-conformity! –… and they have a mediator infrastructure (in most of the cases) So... Why not use laws for … –(i) the explicit specification of the dependability concerns; –(ii) the automatic collection of the dependability metadata reusing the mediators’ infrastructure presenting in law- governed approaches; –and (iii) to specify reactions to undesirable situations, thus preventing service failures.

12. © LES/PUC-Rio DepEX - Dependability Explicity Computing

13. © LES/PUC-Rio Further Information Conceptual Model –Rodrigo Paes, Carlos Lucena, Gustavo Carvalho and Don Cowan. An Event-Driven High Level Model for the Specification of Laws in Open Multi-Agent Systems - Journal of Systems and Software, 2009 - http://dx.doi.org/10.1016/j.jss.2008.08.033http://dx.doi.org/10.1016/j.jss.2008.08.033 Dependability –Rodrigo Paes, Gustavo Carvalho, Carlos Lucena and Ricardo Choren. Interaction Laws for Dependability Explicit Computing in Open Multi-agent Systems – IET Software, 2009

14. Thank you for your time … contributions and specially for the patience! Rodrigo Paes