Embed Size (px)
Citation preview
An Event-Driven High Level Model for the Specification of Laws in Open Multi-Agent Systems
Rodrigo Paes
© 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
Middlewareenforcement
© 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
© LES/PUC-Rio
Architecture for Laws:: MLAW
© LES/PUC-Rio
Conceptual Model
Law
Action
Norm
Clock
nScene
n
n
n
n
n
n
Agent
Protocol
1
1
-creator
State
Transition
-currentStatesn
-from
-outgoingTransitions
n
-toState
-requires
n
Constraint
n
Role
-participant
Message
-sender
nn
-receiver
-initialState 1
© LES/PUC-Rio
Event Mechanism
idle active
event
event
… t1(s0,s1, message_arrival(m1) ) … norm1{ give obligation to buyer when listen(transition_activation(t1)) } …
… t1(s0,s1, message_arrival(m1) ) clock1{ start to count when listen(norm_activation(norm1)) count until 10 min and generate(clock_tick(clock1)) } … norm1{ give obligation to buyer when listen(transition_activation(t1)) } norm2{ prohibit all interactions from buyer when listen(clock_tick(clock1)) } …
Pseudo code for activating a norm due to the firing of a transition
Pseudo code for composing the norm with the clock
© 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!!!
© 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)).
© LES/PUC-Rio
Related Approach #02: Electronic Institutions
Electronic Institutions XMLaw
Illocutory formulas Message
EI vocabulary (ontology) It is defined in the messages themselves, instead of separately.
Internal roles Not considered
External roles Role
Relationships over roles Not considered
Control over role playing Control over role playing
Scene Scene
Performative Structure Not considered.
Protocol Protocol
State State
Directed edge Transition.
Constraint Constraint
Time-out Clock
Normative rules Norms
Not considered Actions
Not considered Law
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.
© LES/PUC-Rio
Pros and Cons of XMLaw when compared to LGI and EI
Item LGI Electronic Institutions XMLaw
Level of abstraction Low High High
Level of flexibility in the composition of the elements (event-based model)
High Low High
Scalability with decentralized laws High Low Low
Global centered view of the system No Yes Yes
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)
No Yes
Approach is subject to a central point of congestion
No Yes (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 issues Certification authorities No No
Allows agents to communicate in any different content languages
No Partial (only prolog and lisp) Yes
Time-sensitive norms No No Yes
© 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.
© LES/PUC-Rio
DepEX - Dependability Explicity Computing
© 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.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
Thank you for your time … contributions
and specially for the patience!
Rodrigo Paes
