In this paper, we propose an approach to build a specification of a multi-agent system and then to prove the coordinated consensus of agents in the specification using Event-B.. The contex
Trang 1Coordinated Consensus Analysis of Multi-agent Systems
Using Event-B
Ninh-Thuan Truong, Thanh-Binh Trinh, and Viet-Ha Nguyen
College of Technology, Vietnam National University, Hanoi
144 Xuan Thuy, Cau Giay, Hanoi
{thuantn,binhtt.di07,hanv}@vnu.edu.vn
Abstract—Formal specifications and reasoning techniques in
software modelling are needed to ensure the correctness of
the system at the design phase Event-B is a formal method
with support tools that allows the stepwise development of
reactive systems Such systems include multi-agent systems
as a subclass In this paper, we propose an approach to
specify capabilities of a number of software agents We then
verify whether these capabilities help the agents to accomplish
a certain task using a supported tool for Event-B We use
the binary numeral system as a case study to illustrate our
approach
Coordinated consensus problems [5] have a long history of
study in computer science and their solutions have become
an important foundation of reactive systems such as
multi-agent systems These problems can now be formally and
efficiently analyzed thank to the development of formal
methods in software specification and verification
A multi-agent system [17], [19] is a collection of subsystems
in which each subsystem, called an agent, updates itself
in accordance with the information it gathers from some
of the other agents, i.e from its neighbors In general, the
neighbors of an agent are subject to change in time which
introduces a switching behavior to the dynamics of the
system through communication links It has been proved that
it is very important to study and understand the effect of this
varying communication topology on some common task to
be accomplished (i.e reaching a consensus) by the agents
composing the system
The B method [2] is a formal software development method,
originally created by J.-R Abrial The B notations are
based on the set theory, generalized substitutions and the
first order logic Event-B [1] is an evolution of the B
method that is more suitable for developing large reactive
and distributed systems Software development in
Event-B begins by abstractly specifying the requirements of the
whole system and then refining them through several steps to
reach a description of the system in such a detail that can be
translated into code The consistency of each model and the
relationship between an abstract model and its refinements
are obtained by formal proofs Tool supports have been
provided for Event-B specification and proof in the Rodin platform [1]
In this paper, we propose an approach to build a specification
of a multi-agent system and then to prove the coordinated consensus of agents in the specification using Event-B In our approach, each agent is specified by an abstract machine which sees its context machine The context and abstract machines of agents are later composed to form general ones
as the whole systems according to the rules of the protocol consensus algorithms The support tools provided by
Event-B enable to formally analyze the coordinated consensus of agent specifications through the composed machines The rest of this paper is organized as follows Section 2 presents an overview about multi-agent systems and
Event-B Section 3 presents our main contribution of using Event-B
to specify multi-agent systems and to prove the consensus
of the coordination of some agents We also illustrate in this section the proposed approach by a case study, the multi-agent system for calculations of binary numbers Section 4 discusses related works We conclude the paper and give some perspectives in Section 5
II PRELIMINARIES
A Multi-agent systems
Agents are independent entities with their own goals, ac-tions, and knowledge An agent can be a part of the envi-ronment Agents are explicitly modeled and interacting with one another and with the environment A multi-agent system (MAS) [14] is a system composed of multiple interacting agents A multi-agent system can be developed to solve a problem which is impossible or otherwise difficult for an individual agent or monolithic system to solve
On-line trading [12], disaster response [13], and social structures modeling [15] are examples that have been suc-cessfully implemented as multi-agent systems
Agents in multi-agent systems are normally reactive agents Reactive agents receive stimuli from the environment then react to these stimuli by modifying their behaviors and possibly, the environment Reactive agents do not necessarily have knowledge and representation of other agents in the system
2009 Seventh IEEE International Conference on Software Engineering and Formal Methods
2009 Seventh IEEE International Conference on Software Engineering and Formal Methods
Trang 2Though different agents may have their different purpose,
they share some characteristics in common: identifier, role
and organization These three characteristics are described
as:
• identifier: each agent in the system is uniquely
identi-fied by its identifier in the multi-agent system
• role: a role defines the behavior of an agent among
other agents in the society For instance, in the auction
multi-agent system, Seller or Buyer are possible roles
for agents An agent can have multiple roles in the
multi-agent system, or role of an agent can change
during the execution of the system
• organization: agents are evolving in multi-agent
sys-tems, and belong to one or several organizations
These organizations define the agents’ roles and the
relationships between the roles Organizations adhere
generally to human organizations, or animal ones such
as hierarchies, markets, groups of common interest, or
herds
A capability in a multi-agent system describes what an agent
in the system is able to do and under what circumstances
The capabilities of agents can be specified in a language
called Capability Description Language (CDL) [18] We can
specify the capabilities of the agents by inputs, outputs, input
constraints, output constraints and input-output constraints
B Event-B
Event-B is a kind of formal method which combines
math-ematical techniques from the set theory and the first order
logic It is used as a notation and method for the formal
development of discrete systems Event-B is an evolution of
others formal method notations like B-Method (also know
as classical B), Z and Action Systems It is considered as an
evolution because it simplifies the B machine notations, is
easy to learn and more suitable for parallel and distributed
reactive system development Another advantage that
Event-B offers is support tools for system modeling [1]
Event-B models are described in terms of two basic
con-structs: contexts and machines Contexts form the static
part of the model while machines form the dynamic part
Contexts can extend (or be extended by) other context and
are referred (seen) by machines
Being considered as the static part of the model, the context
is used to store, for instance, the types and constants used
during the development of the system
The machine contains the dynamic part of the model It
describes the system state, the operations to interact with
the environment together with the properties, conditions and
constraints on the model
The properties of a model are defined by the machine
invariant, which must be satisfied by every state in the
system To be consistent, we have to prove that every
event in the system preserves this invariant; this verification
requirement is expressed in a number of proof obligations
(POs) In practice this verification is performed either by model checking or theorem proving
The unit of the machine behavior is event An event e acting on (a list of) state variables v, subject to enabling condition, or guard G (v) with an action, or assignment A(v),
has syntax:
e = when G(v) then A(v) end That is, when the state is such that the guard is true, this
enables the action, or state transition defined by A(v) A(v) does not contain if statement, but we can specify an event
containing a conditional statement by two different events with two guards corresponding two branches
Refinement A machine can be refined by another machine Once an abstract model is built, a refinement process is applied to progress towards implementation An abstract model is transformed into a more concrete and elaborate model by refinement A refined model specifies the abstract model it refines in the REFINES clause New variables can
be introduced and the old variables can be refined into more concrete ones This is reflected in the substitutions of the events as well
One of the difference from the classical B is that new events may also be introduced These new events should not prevent forever the events already present from being triggered A VARIANT, which is a natural number expression that the new events must decrease, is introduced for ensuring it Furthermore, we can also merge several abstract events into one single event, as well as refine one abstract event by several events, as permitted by the event-level REFINES clause
Composition and Decomposition On one hand, compo-sition is a technique used to aggregate sub-systems and generate larger systems The motivation for the use of such techniques is the reusability of sub-components and the possibility of interaction between systems In a distributed application, this insight is even more important since the intention is to have independent systems interacting with one another, and at same time keeping all the individual properties
On the other hand, decomposition is the process on which
a system split into two or more parts This process is used when a system becomes too complex to be managed Divid-ing it into sub-systems keeps the manageability/tractability
An interesting property to be explored is the independent refinement of each sub-system This process must satisfy the constraint that the re-composition of (refined) components should be easy In other words, the result of re-composition can be obtained directly from the decomposition This property is known as compositionality The usability of this technique grows when applied to distributed systems: handling a large system can become unpractical, hence dividing it in separated sub-systems can benefit each of the sub-systems while at the same time, it will benefit the system
Trang 3has a whole.
III COORDINATED CONSENSUS ANALYSIS OF
In this section we propose an approach which allows the
composition of machines in Event-B in order to analyze
the coordinated consensus of the agents specification We
illustrate the proposed approach via a case study of binary
number calculation
A Coordinated consensus analysis using Event-B
composi-tion
In multi-agent systems, each agent and their capabilities
is provided to perfom particularly tasks These agents can
be coordinated to solve a problem which is impossible or
otherwise difficult for an individual agent or monolithic
system to solve However, the cooperation of agents has been
lacked the consensus analysis in specification and design
tools As a result, we propose an approach to analyse the
cooperation of agents to accomplish a task using Event-B
notation and tools
Note that, ”consensus” means to reach an agreement
be-tween agents regarding a certain quantity of interest that
depends on the state of all agents A ”consensus algorithm”
(or protocol) is an interaction rule that specifies the way
of information exchange between an agent and all of its
neighbors [7]
Before introducing the approach of coordinated consensus
analysis using Event-B, we give some definitions and their
corollary related to Event-B specification, they are useful in
the analysis process
Definition 1 An iterative event e = g, a is convergent
when the guard g is hold and then their list of actions a
executed until g is not hold in the future.
However, when the guard g is unsatisfied, proof obligations
of deadlock freeness defined in a model machine will be
unproved Thus, we have to add a new event e = g , a
to the model such that g ∨ g is always hold under the
execution of a or a
Corollary 3.1: The value of a convergent iterative event can
be obtained by a new added event
Proof Suppose that e = g, a is a convergent event.
According to the Definition 1, the guard g will be unsatisfied
at a moment in the future Then we can define additionally a
new event e = g , a to the machine in order to get results
of variables in event e where g =¬ g, in a simple case 2
Definition 2 The interaction of events which conforms to a
protocol execution is convergent when:
i The order of events is conformed to the protocol
execution,
ii The disjunction of all guards of related events will not
be hold at a moment in the future
The disjunction of all guards of related events will not be hold, then deadlock freeness of the model is violated We
have to add a new event e = g , a such that g1 ∨ g2 ∨ g n ∨ g hold
Corollary 3.2: When the interaction of events is convergent,
we can obtain the convergent value by a new added event The proof of the Corollary 3.2 is similarly as the one of the Corollary 3.1
In order to analyze the coordinated consensus of the compo-sition of the agents in a multi-agent system, we first compose the Event-B specification of the system The architecture of the specification is depicted in Figure 1
sees
sees
sees
composition composition
sees
In this specification, the context machines of different agents will be combined into a context machine of the system called MAS.ctx, while the abstract machines of different agents will be combined into a general abstract machine called MAS.mch
Note that composition in Event-B has been proposed ear-lier by Poppleton in [10] His approach of composition is
roughly described as follows Let M 1 and M2 be two models
which are proposed to be fused The variables and events from each model will be combined with the ones from the other model That is, they concatenate the variable lists and events, conjoin those events with common names (in a
manner to be defined) in a new model M The variable list v
in M1 comprises the list x of actioned variables and the list
y of skipping variables for each event Similarly variables
list w in M 2 comprise the list z of actioned variables and the list a of skipping variables for each event They define
xz = x∩z, the common actioned variables, and ya = y∩a, the
common skipping variables Note that the other intersecting
variable lists yz and xa are both empty, to enable meaningful
composition definitions [10]
This approach focuses on the composition of independent events and variables of machines and on assuring the cor-rectness of proof in the composition machine It means that, the events in systems do not affect results of the execution after the composition
In addition to the above, the composition mechanism in Event-B has to ensure that the overall behavior of the
Trang 4abstract model is kept and that the concrete model does not
get into two states:
• Divergence: this situation occurs when the system
be-haves chaotically, it happens whenever some events are
aborted
• Deadlock: this situation occurs when no event is
en-abled and as a consequence, the system’s state never
change since it happens
The first constraint (non-divergence), imposes to exhibit a
variant V, which is a well-founded structure (e.g N, ≤), is
proved to be decreased by a well-founded relation
The second constraint (deadlock freeness) is proved by proof
obligations which state that the disjunction of the event
guards always hold under the properties of the constant and
the invariant
The absence of the divergence and the deadlock can be
proved by the support tool of Event-B This leads us to
the thought of applying the idea of machine composition to
compose machines of agents and to analyze the coordinated
consensus between agents In this composition, the
interac-tion between events plays an important role in accomplishing
a task
Note that, in order to avoid the ambiguity in the case that
an agent may have many capabilities, we decompose it
to several model machines, each of them corresponds to
one capability The decomposition process is applied to a
model machine which specifies an agent with more than
one capabilities [4] Alternatively, we can also specify each
capability of the agent by a model machine at the beginning
Suppose that, in our model, an abstract machine specifies
an agent’s capability, which is expressed by a quatro-tuple
M i = v i , Init i , ec i , ee i where v i is the list of variables, Init i
is the initial event of the agent’s machine i, ec i is the list of
events which completely specify the agent capability, and ee i
is the event used to obtain the result (see the Corollary 3.1)
Definition 3 A multi-agent system Mult is a quatro-tuple
Mult = Ag, Mact, α, Γ where:
• Ag is a finite set of agents (in a MAS),
• Mact is the set of capabilities possible in Mult,
• α : Mact → Ag assigns to each capability of Mact the
agent that performs it,
• Γ is the execution protocol between capabilities to
accomplish a task
Then, let M = V, Init, ec, ee, ee M be the composed
ma-chine for the agent capabilities M i , i = 1, , n
With-out the loss of generality, we suppose that the execution
protocol between events of agents is the ordering Γ =
[ec1, ec2, ec3, ec n ] The construction of M must be
con-formed to the following principle:
1) V = ∪v i, the list of variables of the composition
machine contains variables of agent machines
2) ec = ∪ec i, the composition machine contains all
events of the agent machines
3) Init = Init1, the Init event of the composition is defined as the Init event of the first capability machine
in protocol execution
4) ee = ∪ee i where ee i = Init i+1∪ ee i, to activate the
events of the next capability, a part of its event Init
is combined to the get result event of the previous capability
5) ee M is the new event added to the model to get final result of computation process
After executing the composition, we have to optimize the MAS model machine and its context by eliminating some constants and variables which are redundant or unnecessary The principle proposed above is reasonable because it can make the events executed in the order of the protocol
consensus The event ec1 is executed first via the definition
Init of the machine, then the next event will be executed
via a part of the definition of the get result event of the previous event The convergence of each event and of the interaction between events will be automatically proved by the tool support of Event-B [1]
B Description of a case study
Supposing that in a multi-agent system, an organisation con-tains agents used to calculate the results of some operations for binary numbers: BitShift, Sum and MultiDigit agents Multiplication for binary numbers works in the same way
as for the decimal numbers In our multi-agent system,
we have three capabilities: multiplyWithOneDigit, shiftLeft, and addition These capabilities respectively belong to the
MultiDigit agent, the BitShift agent, and the Sum agent
In the BitShift operation, the digits are shifted left or right The shiftLeft capability of the BitShift agent enables digits
in a binary number move a number of bits left by the operation with the same number of right bits being filled
up by zero For instance, if we apply the shift left operator
by one position to the binary number00011011, we obtain the number 00110110 The BitShift agent can be specified
by AUML as depicted in Figure 2
Input
Organisation
<<agent>> BitShift
Calculator Protocol enter−society, exit−society, compute
shiftLeft, shiftRight
Role
<<capability>> shiftLeft
Output
Description
binaryNumber, numShift
binaryNumber
This capability makes the shift left a binary number with numShift bits
Input
Output binaryNumber, numShift
binaryNumber Description
<<capability>> shiftRight
binary number with numShift bits This capability makes the shift right a
The Sum agent is used to add or subtract two binary numbers The input of the Sum agent are two binary numbers and the output is a binary number as the result of the operation For example:
Trang 500110110 The capabilility of the MultiDigit agent is to multiply a
binary number by one digit number (0 or 1) The input is
a binary number and a binary digit, the output is a binary
number as the result
C Specifying the case study in Event-B notation
Let us consider the specification of these capabilities for
agents using Event-B notations We will use sets to represent
binary numbers The set representation for a binary number
is a set of pairs, each pair maps a position of the number
from the right to the binary digit of the number at that
position For example, binary number 00011011 can be
specified via set as follows:
{8 → 0, 7 → 0, 6 → 0, 5 → 1, 4 → 1,
3 → 0, 2 → 1, 1 → 1}
With this representation and ease of understanding the
algorithm, we use the conditional statement (if then) in the
part of actions of events We specify the MultiDigit agent as
presented in Figure 5 The abstract machine MultiDigit.mch
in Figure 5(a) specifies the dynamic part of the system
This machine sees the context MultiDigit.ctx depicted in
Figure 5(b)
The shiftLeft capability of the BitShift agent is specified
in Figure 6, the addition capability of the Sum agent is
specified in Figure 7 Note that, with each event
corre-sponds to a capability, we define a new event namely
[event name] result to get the convergent value (see
Corol-lary 3.1)
Using the three capabilities multiplyWithOneDigit, shiftLeft,
and addition in the agent organisation, we describe the
consensus algorithm of the multiplication of two binary
numbers as Algorithm 1
Algorithm 1 Consensus algorithm of agents in the
multipli-cation system
ar ← Multiplication2BinaryNumber(aa,bb)
1: for each ii ≤ size bb do
2: modr ← multiplyWithOneDigit(bb[ii], aa)
3: slr ← shiftLeft(modr, ii)
4: cc ← addition(slr, cc)
5: end for
Based on the consensus algorithm above and the principle
proposed in Subsection III-A, the composition of the agent
machines in the system called MAS.mch and MAS.ctx, these
are illustrated in Figure 3 and in Figure 4, respectively We
add an event called multiply2BinaryNumbers to get the final
result of the interaction between events (see Corollary 3.2)
The support tools of the Event-B will prove the consensus of
the coordination between agents capabilities The execution
of events in the composition machine MAS is as follows
First, the Init event is executed In Init event, we start the variable value jj := 1 It enables to activate the
ex-ecution of the event multiplyWithOneDigit As this event
is proved to be a convergent event in the machine
Mul-tiDigit then it run until the guard jj ≤ size aa is not
hold This implies the guard jj = size aa+1 hold and thus the event multiplyWithOneDigit result is activated.
This one, as defined in the machine MultiDigit, does not change the guard of any event However, the event
multiplyWithOneDigit result in the machine MAS.mch
con-tains a part of the Init event of the machine BitShift, as
defined in the principle composition above This definition
allows to activate the event shiftLeft, etc.
The mechanism is continued until all events in the protocol algorithm activated If these events are not convergent, they will run forever and proof obligations of non-divergence will
be violated If they are convergent, the conjunction of all related events will not be hold in the future, then the guard of
the event multiply 2BinaryNumbers will be satisfied, actions
in this event are executed As these actions do not contain
any variant, the guard of the event multiply2BinaryNumbers
thus always hold As a result, if proof obligations of the composition machine are preserved, the execution of the events will be convergent
IV RELATED WORK
In the literatures, there are many papers proposed to for-malize multi-agent systems using different formal methods
in order to support the formal verification of the system
Hilaire et al [7] proposed a general framework for modelling
multi-agent systems based on Object-Z and statecharts This framework focused on organisational aspects in order to
represent agents and their roles Similarly, Regayeg et al
[11] combined Z notations and linear temporal logic to specify the internal part of agents and the specification of the communication protocols between agents They proposed general patterns and the use of Z support tools to model-check their specifications
H Fadil and J Koning presented a work [6] involving the use of classical B to model agents roles and interactions The goal of the paper is to model the interaction between agents with a formal method that is able to check and then prove their initial UML specification
The paper [3] also focused on the interaction protocol between agents using Event-B Some patterns for the B specification of fault tolerance protocols are proposed in the case of agent communication
A Lanoix [8] proposed an approach to report their expe-rience with the Even-B stepwise development of a situated MAS which study the displacement of vehicles in a convoy
In the case study, they suppose that all the vehicles move in
a simultaneous movement using Event-B to ensure a safety
Trang 6machine MAS.mch
sees MAS.ctx
variables
ii
jj
.
invariant
ii ∈ NAT
jj ∈ NAT
.
events
INIT
ii:= 1
jj:= 1
.
end
multiply2BinaryNumbers
end
multiplyWithOneDigit
end
multiplyWithOneDigit result
end
shiftLeft
end
end
shiftLeft result
end
addition
else
carry := (cc(hh)+slr(hh)+carry) div 2
end
end
addition result
jj:= 1
end
end
context MAS.ctx context Sum.ctx constants
aa bb size aa size bb size res
axioms
aa ∈ NAT1 → 0 1
bb ∈ NAT1→ 0 1
0 < size aa
0 < size bb
size aa < size res size bb < size res
theorems ran(aa) = ∅ ran(bb) = ∅ end
property of the system: no collision must occur between a vehicle and its predecessor
The papers above try to specify protocol execution between tasks of agents using Z, classical B, Event-B, etc but it did not provide an approach to check if tasks are coordinated consensus, that our paper proposes
The coordinated consensus problems in multi-agent systems have been also considered in [5], [16], [9]
R Carli et al [5] discussed a work concerned a group
of autonomous mobile agents in order to analyse a com-mon task, communications constraints impose limits on the achievable control performance Analysing the consensus
or state agreement problem, the authors characterize the relationship between the amount of information exchanged
by the agents and the rate of convergence to the agreement Another approach to the coordinated consensus problem of multi-agent systems is presented in [16] In this approach, the authors introduce a characterization of contraction for bounded convex set For discrete-time multi-agent systems, the authors provide an upperbound on the rate of conver-gence to a consensus under some assumptions
However, these papers focused on analysing coordinated consensus problems using mathematical models, this is still impossible to use support tools to prove the convergence of tasks
Multi-agent systems play an important role in developing complex or distributed information systems As each agent
of the system usually be designed to be autonomous and does not aware of other agent existences, it is difficult for developers to ensure the coordinated task of these agents will be accomplished
In this paper, we proposed an approach to specify multi-agent systems and then verify the consensus property of
Trang 7agents using Event-B In our approach, each agent is
speci-fied by an abstract machine which sees its context machine
A context machine here refers to the environment of the
agents The interactions between agents are specified as
protocols or algorithms that modify machine states The
context and machines of agents are then composed to general
ones as the whole systems according to the rules of the
protocol consensus algorithms Then, we can use Event-B
tools to formally analyze the coordinated consensus of agent
specifications through the composed machines
We illustrated our approach by an example of a binary
multiplication system In this system, the result of a multiple
operation is accomplished by the collaboration of different
agents Using Rodin platform, we proved that the system
will reach the state that provide the result
Our approach is based on the proving ability of Event-B
tools so it cannot cope with large multi-agent systems which
have a large number of agents and complex interactions
An-other limitation is that it only works with simple consensus
problems that can be specified by Event-B
We are working to extend our approach to check the plan
of agents and to solve above limitations
This work is partly supported by the research grant of
College of Technology and by the research project No
QGTD 09.02 granted by Vietnam National University, Ha
Noi The authors would like to thank Dr Van-Hung Dang
for his useful comments
[1] http://event-b.org
[2] J.-R Abrial The B-Book, Assigning Programs to Meanings.
Cambridge University Press, 1996
[3] E Ball and M Butler Event-B patterns for specifying
fault-tolerance in multi-agent interaction In Proceedings of
Methods, Models and Tools for Fault Tolerance, volume 5454
of LNCS Springer, 2009.
[4] Michael Butler Decomposition structures for Event-B In
IFM’09: Proceedings of the 7th International Conference on
Integrated Formal Methods, pages 20–38, Berlin, Heidelberg,
2009 Springer-Verlag
[5] R Carli, F Fagnani, Speranzon, and A.Zampieri
Commu-nication constraints in coordinated consensus problems In
American Control Conference IEEE, 2006.
[6] H Fadil and J Koning A formal approach to model
multia-gent interactions using the B formal method In International
Symposium on Advanced Distributed Systems, volume 3563
of LNCS, pages 516–528 Springer Verlag, 2005.
[7] V Hilaire, P Gruer, A Koukam, and O Simonin Formal
specification approach of role dynamics in agent
organisa-tions: Application to the satisfaction-altruism model Int.
Jour of Software Engineering and Knowledge Engineering,
17(5):615–641, 2007
[8] Arnaud Lanoix Event-B specification of a situated multi-agent system: Study of a platoon of vehicles In TASE
’08: Proceedings of the 2008 2nd IFIP/IEEE International Symposium on Theoretical Aspects of Software Engineering,
pages 297–304 IEEE Computer Society, 2008
[9] R Olfati-Saber, J A Fax, and R M Murray Consensus and
cooperation in networked multi-agent systems Proceedings
of the IEEE, 95(1):215–233, 2007.
[10] Michael Poppleton The composition of Event-B models In
ABZ ’08: Proceedings of the 1st international conference on Abstract State Machines, B and Z, pages 209–222
Springer-Verlag, 2008
[11] A Regayeg, A.H Kacem, and M Jmaiel Specification and verification of multi-agent applications using temporal Z
In Intelligent Agent Technology Conference, pages 260–266.
IEEE Computer Society, 2004
[12] Alex Rogers, Esther David, Nicholas R Jennings, and Jeremy Schiff The effects of proxy bidding and minimum bid
increments within ebay auctions ACM Trans Web, 1(2):9,
2007
[13] Nathan Schurr, Janusz Marecki, Milind Tambe, and Paul Scerri The future of disaster response: Humans working with multiagent teams using defacto In In AAAI Spring Symposium on AI Technologies for Homeland Security, 2005 [14] Yoav Shoham and Kevin Leyton-Brown Multi-agent Sys-tems: Algorithmic, Game-Theoretic, and Logical Foundations.
Cambridge University Press, New York, 2009
[15] Ron Sun and Isaac Naveh Simulating organizational
decision-making using a cognitively realistic agent model J Artificial Societies and Social Simulation, 7(3), 2004.
[16] Sezai Emre Tuna and Rodolphe Sepulchre Quantitative
convergence analysis of multi-agent systems In 7th IFAC Symposium on Nonlinear Control Systems, pages 236–241,
August 2007
[17] Gerhard Weiss Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence The MIT Press, 2000 [18] G.J Wickler Using Expressive and Flexible Action Repre-sentations to Reason about Capabilties for Intelligent Agent Cooperation PhD thesis, The University of Edinburgh, 1999 [19] Michael Wooldridge An Introduction to MultiAgent Systems.
John Wiley & Sons, 2002
ANNEX Below we use Event-B to describe the specifications of multiplyWithOneDigit, leftShift and addition capabilities of the MultiDigit, BitShift and Sum agents, respectively
Trang 8machine MultiDigit.mch
sees MultiDigit.ctx
variables
pp
modr // Final result
jj
invariant
modr ∈ NAT1 → 0 1
pp ∈ NAT1 → 0 1
jj ∈ NAT
events
INIT
modr:= ∅
pp:= ∅
jj:= 1
end
multiplyWithOneDigit
end
multiplyWithOneDigit result
end
end
(a) MultiDigit machine
context
MultiDigit.ctx
constants
aa
digit
size aa
size modr
axioms
aa ∈ NAT1 → 0 1
digit ∈ NAT
0 < size aa
0 < size modr
size modr ≥ size aa
theorems
ran(aa) = ∅
end
(b) MultiDigit context
machine BitShift.mch sees BitShift.ctx variables
pp //Get temporary results slr //Result of the shift left kk
invariant
pp ∈ NAT1 → 0 1 slr ∈ NAT1 → 0 1
kk ∈ NAT
events INIT
pp:= ∅
slr:= ∅
end shiftLeft
end
end shiftLeft result
end end
(a) BitShift machine context
BitShift.ctx constants
pp size pp numShift
axioms
pp ∈ NAT1→ 0 1
0 < size pp
0 < numShift
numShift < size pp
theorems
end
(b) BitShift context
Trang 9machine Sum.mch
sees Sum.ctx
variables
cc //Get temporary results
ar // Result of the addition operation
carry
hh
invariant
cc ∈ NAT1 → 0 1
ar ∈ NAT1→ 0 1
hh ∈ NAT
carry ∈ NAT
events
INIT
cc:= ∅
ar:= ∅
hh:= 1
carry:= 0
end
addition
else
carry := (aa(hh)+bb(hh)+carry)
end
end
addition result
end
end
(a) Sum machine
context MAS.ctx
constants
aa
bb
size aa
size bb
size ar
axioms
aa ∈ NAT1 → 0 1
bb ∈ NAT1→ 0 1
0 < size aa
0 < size bb
size aa < size ar
size bb < size ar
size ar < size aa+size bb
theorems
ran(aa) = ∅
end
(b) Sum context