Automated Verification of Resource Requirements in Multi-Agent Systems Using Abstraction.

Full text

Page 1

Automated verification of resource requirements in
multi-agent systems using abstraction?
Natasha Alechina, Brian Logan, Hoang Nga Nguyen, and Abdur Rakib
University of Nottingham, UK
nza,bsl,hnn,rza@cs.nott.ac.uk
Abstract. Wedescribeaframeworkfortheautomatedverificationofmulti-agent
systems which do distributed problem solving, e.g., query answering. Each rea-
soner uses facts, messages and Horn clause rules to derive new information. We
show how to verify correctness of distributed problem solving under resource
constraints, such as the time required to answer queries and the number of mes-
sages exchanged by the agents. The framework allows the use of abstract spec-
ifications consisting of Linear Time Temporal Logic (LTL) formulas to specify
some of the agents in the system. We illustrate the use of the framework on a
simple example.
1Introduction
Much current work in multi-agent systems (MAS) development relies on the devel-
oper specifying agent behaviour in terms of pre-defined plans [1]. While the use of
pre-defined plans makes it easier to guarantee the behaviour of the multi-agent system,
e.g., [2], it can make it harder for the system to solve novel problems not anticipated by
the system designers. As a result, there has recently been increasing interest in provid-
ing general reasoning capabilities to agents in multi-agent systems (see, for example,
[3,4]). However, while the incorporation of reasoning abilities into agents brings great
benefits in terms of flexibility and ease of development, these approaches also raise
new challenges for the agent developer, namely, how to ensure correctness (will an
agent produce the correct output for all legal inputs), termination (will an agent pro-
duce an output at all), and response time (how much computation will an agent have to
do before it generates an output). For example, when developing a distributed problem
solving system which provides subway routes to users of the London Underground, a
developer may wish to verify that the system does not provide invalid routes (e.g., that
it takes current service disruptions into account), and that it provides bounded response
times under expected system loads (e.g., asynchronous queries from multiple simulta-
neous users). However proving correctness or resource bounds for such large complex
reasoning systems is infeasible with current verification technologies.
In [5], an approach to verifying resource requirements in systems of communicating
rule-based reasoners was proposed. The main emphasis of that paper was on modelling
?This work was supported by the Engineering and Physical Sciences Research Council [grant
EP/E031226/1].

Page 2

systems of communicating reasoners as state transition systems, where states corre-
spond to beliefs of the agents and transitions correspond to the application of a rule of
inference or sending a message. Properties of the system, for example, that a system of
two agents will be able to produce an answer to a query after exchanging at most one
message and applying 4 rules, were specified in modal logic, and proof-of-concept ver-
ification experiments using Mocha model-checker [6] reported. However, the encoding
of the system in the Mocha specification language had to be handcrafted, rules had to
be propositionalised using all possible substitutions for variables, and scalability of the
verification approach was not explored.
Inthispaperwedescribeanautomatedverificationframeworkforresource-bounded
reasoners, which takes rules specified in Hornlog RuleML with negation as failure [7]
augmented with communication primitives, and automatically produces a Maude [8]
specification of the system which can be efficiently verified. The properties that we
wish to verify are response-time guarantees of the form: if the system receives a query,
then a response will be produced within n timesteps. To allow larger systems to be
verified, abstract specifications can be used to model some agents in the system. Ab-
stract specifications are given as LTL formulas which describe the external behaviour of
agents, and allow their temporal behaviour (the response time behaviour of the agent),
to be compactly modelled. We illustrate the scalability of our approach by comparing it
to results presented in [9] for a synthetic distributed reasoning problem, and presenting
results for a more complex multi-agent reasoning example.
The remainder of the paper is organised as follows. In section 2 we describe our
model of communicating rule-based reasoners. In section 3 we describe the basic com-
ponents and ideas behind the verification framework, including our approach to pro-
ducing abstractions of agents. In section 4 we briefly describe a tool for translating
rule-based specification of the agents into Maude, and in section 5 we evaluate its per-
formance. We discuss related work and open problems in section 6 and conclude in
section 7.
2Communicating Reasoners
We adopt a general model of distributed reasoners. A distributed reasoning system con-
sists of n(≥ 1) individual reasoners or agents. Each agent is identified by a value in
{1,2,...,n} and we use variables i and j over {1,2,...,n} to refer to agents. Each
agent i has a program, consisting of first-order Horn clause rules with negation-as-
failure allowed in the premises1, and a working memory, which contains facts (ground
atomic formulas) representing the initial state of the system. The agents execute syn-
chronously. At each cycle, each agent matches (unifies) the conditions of its rules
against the contents of its working memory. The conditions of a rule are evaluated using
the closed world assumption (i.e., not P evaluates to true if P is not in working mem-
ory). A match for every condition of a rule constitutes an instance of that rule (a rule
may have more than one instance). The set of all rule instances for an agent form the
agent’s conflict set. Each agent then chooses a subset of rule instances from the conflict
1Rules are of the form P1∧ ... ∧ Pn → P where P is an atomic formula and Pi are atomic
formulas or atomic formulas preceded by the negation as failure operator.

Page 3

set to be applied. Applying a rule adds the consequent of the rule as a new fact to the
agent’s working memory. The cycle begins again with the match phase and the process
continues until no more rules can be matched and all agents have an empty conflict set.2
We assume that each reasoner has a reasoning strategy (or conflict resolution strat-
egy) which determines the order in which rules are applied when more than one rule
matches the contents of the agent’s working memory. The choice of reasoning strategy
is important in determining the capabilities of the agent. For example, different rea-
soning strategies may determine how quickly/efficiently an answer to a query can be
derived, or even whether an answer can be produced at all. The reasoning strategy is
also important in determining trade-offs between the resources required to process a
query. For example, if multiple queries arrive at about the same time, processing them
sequentially may reduce the memory required at the cost of increasing the worst case
response time for queries. Conversely, processing the queries in parallel may reduce the
worst case response time at the cost of increasing the peak memory usage.
Weassumethateachreasonerexecutesinaseparateprocessandthatreasonerscom-
municate via message passing. For concreteness, we assume a simple query-response
scheme based on asynchronous message passing. Each agent’s rules may contain two
distinguished communication primitives: ASK(i,j,P), and TELL(i,j,P), where i
and j are agents and P is an atomic formula not containing an ASK or a TELL.
ASK(i,j,P) means ‘i asks j whether P is the case’ and TELL(i,j,P) means ‘i tells
j that P (i ?= j). The positions in which the ASK and TELL primitives may appear
in a rule depends on which agent’s program the rule belongs to. Agent i may have an
ASK or a TELL with arguments (i,j,P) in the consequent of a rule, e.g.,
P1∧ P2∧ ... ∧ Pn=⇒ ASK(i,j,P)
Agent j may have the same expressions in the antecedent of the rule, e.g.,
TELL(i,j,P) =⇒ P
is a well-formed rule for agent j, that causes it to believe i when i informs it that P
is the case. No other occurrences of ASK or TELL are allowed. For simplicity, we
assume that communication is error-free and takes one tick of time.
3Verification Framework
We would like to be able to verify properties of systems consisting of arbitrary numbers
of complex communicating reasoners. However verifying such large, complex reason-
ing systems is infeasible with current verification technologies.
The most straightforward approach to defining the global state of a multi-agent
system is as a (parallel) composition of the local states of the agents. At each step in the
evolution of the system, each agent chooses from a set of possible actions (we assume
that an agent can always perform an ‘idle’ action which does not change its state). The
2Note that, although execution is synchronous, agents can return a ‘null action’ at any given
cycle, allowing the modelling of multi-agent systems in which each agent deliberates at a rate
which is a multiple of the cycle time of the fastest agent.

Page 4

actions selected by the agents are then performed in parallel and the system advances to
the next state. In a multi-agent system composed of n (≥ 1) agents, if each agent i can
choose between performing at most m (≥ 1) actions, then the system as a whole can
move in mndifferent ways from a given state at a given point in time. Along with state
space size, model checking performance is heavily dependent on the branching factor
of states in the reachable state space and the solution depth of a given problem. In
general, the model checking algorithm for reachability analysis performs a breadth-first
exploration of the state transition graph. When checking invariant (safety) properties,
the model-checker will either determine that no states violate the invariant by exploring
the entire state space, or will find a state violating the invariant and produce a counter-
example.3However, even with state-of-the-art BDD-based model-checkers, memory
exhaustion can occur when computing the reachable state space due to the large size of
the intermediate BDDs (because of the high branching factor).
To overcome this problem, our modelling approach abstracts from some aspects
of system behaviour to obtain a system model that is tractable for a standard model-
checker. Our use of abstraction is however different from classic approaches in model-
checking, such as [11,12]. We assume that, at any given point in the design of the
overall system, the detailed behavior of only a small number of agents (perhaps only
a single agent) is of interest to the system designer, and the remaining agents in the
system can be considered at a high level of abstraction. Given that the properties we are
interested in are response time guarantees of agents, the concrete internal representation
of some agents can be replaced by an abstract specification of their behaviour, that
produces queries and responds to queries within specified bounds. Specifications of this
external (observable) behaviour of abstract agents may be derived from, e.g., assumed
characteristics of as-yet-unimplemented parts of the system, assumptions regarding the
behaviour of parts of the overall system the designer does not control (e.g., quality of
service guarantees offered by an existing web service) or from the prior verification of
the behaviour of other (concrete) agents in the system.
This behavior is specified using the language of the temporal logic LTL containing
epistemic operators. The general form of the formulas which can be used to represent
the external behavior of abstract agents is given below, where X is the next step tempo-
ral operator, Xnis a sequence of n X operators, G is the temporal ‘in all future states’
operator, and Bifor each agent i is a syntactic epistemic operator used to specify agent
i’s ‘beliefs’ or the contents of its working memory.
ρ :: Xnφ1| G(φ2→ φ3)
φ1:: BiASK(i,j,P)
|BiTELL(i,j,P)
|BiASK(j,i,P)
|BiTELL(j,i,P)
|BiP
3Even with on-the-fly model-checking [10], the model checker has to explore the state space at
least until the solution depth.

Page 5

φ2:: Bj ASK(i,j,P)
φ3:: XnBiTELL(j,i,P)
Formulas of the form Xnφ1describe agents which produce a certain message or
input to the system within n time steps. The G(φ2 → φ3) formulas describe agents
which are always guaranteed to reply to a request for information within n timesteps.
Note that we do not need the full language of LTL (for example, the Until operator) in
order to specify abstract agents. The verification language of Maude contains full LTL,
but abstract specifications and the response-time guarantee properties we wish to verify
can be expressed in the fragment above.
Formulas expressing abstract specifications are translated into the specification lan-
guage of the model checker. This is a kind of backward modeling, which basically im-
poses a restrictions on possible runs of a model. The multi-agent system is then simply
a parallel composition of both the concrete and abstract agents in the system.
4 Automated Verification Tool
In this section, we describe a tool based on the Maude [8] rewriting system which im-
plements the approach to verification described above. The tool generates an encoding
of a distributed system of reasoning agents for the Maude LTL model checker, which
is then used to verify the desired properties of the system. We chose the Maude LTL
model checker because it can model check systems whose states involve data types of
infinite cardinality; in fact, in any algebraic data types. The only assumption is that the
set of states reachable from a given initial state is finite. This simplifies modelling of
the agents’ (first-order) rules and reasoning strategies.
The tool consists of three main components: the user interface, the encoding gen-
erator and the system verifier. The tool takes as input: (a) a set of concrete agent de-
scriptions, each comprising a set of rules, a set of initial working memory facts, and a
control strategy, (b) a set of abstract agent descriptions specified by a set of temporal
epistemic logic formulas, and (c) the properties of the system to be verified specified in
temporal epistemic logic. Rules and facts can be expressed in RuleML or in a simplified
ASCII syntax e.g., < n : P1&...& Pn=> P >, Pk. The general XML syntax of rules
accepted by the framework corresponds to Hornlog RuleML with negation as failure,
and is shown below.
<!- -Representation of rules - ->
<Implies>
<head>
<Atom>
<Rel>Predicate< /Rel>
<Var>variable< /Var>
...
<Ind>constant< /Ind>
...