A multi-agent based transport system is modeled by timed automata model extended with clock variables. The correctness properties of safety and liveness of this model are verified by timed automata based UPPAAL. Agents have a degree of control on their own actions, have their own threads of control, and under some circumstances they are also able to take decisions. Therefore they are autonomous. The multi-agent system is modeled as a network of timed automata based agents supported by clock variables. The representation of agent requirements based on mathematics is helpful in precise and unambiguous specifications, thereby ensuring correctness. This formal representation of requirements provides a way for logical reasoning about the artifacts produced. We can be systematic and precise in assessing correctness by rigorously specifying the functional requirements.
The use of formal methods to define the requirements, design and architecture of a multi-agent system results in precise and unambiguous specifications. These formal specifications provide the basis for systematic, mathematically-proven, well-defined, and unambiguous software development phases of analysis, design, and implementation. Multi-agent systems are distributed, decentralized, consisting of autonomous computing entities known as agents. Correctness is a mathematical property that establishes the equivalence between software and its specifications. Software systems analyzed, designed, and implemented by using agents to offer significant challenges in ensuring their correctness. One of the methods of ensuring the correctness of safety and liveness properties of these agent-based systems is to use formal model checking methods based on timed automata.
The primary objective of a formal approach is precise and unambiguous specification. A representation of the requirements based on mathematics aids in precise specification of the software, thereby ensuring that the correctness, completeness, and unambiguous properties of the system are preserved [
The most important reasons to use formal methods in software engineering are: rigorous analysis of system properties; property-preserving transformations; error-free implementation; high quality of each phase of the development process; firm foundation for the adaptation and evolution process; continuous correctness as multi-agent systems are concurrent and often have dynamic environments; formal specification and modeling of a multi-agent system architecture which can change at run-time (i.e. dynamic architecture); specification according to the functional and non-functional properties; property-preserving step-by-step transformations from abstract to concrete concepts and then stepwise refinement to implementation code; improved documentation and understanding of specifications.
An agent is a computer system that is capable of autonomous actions on behalf of its user or owner [
・ Autonomous: agents have a degree of control on their own actions, they own their thread of control and under some circumstances, they are also able to take decisions;
・ Proactive: agents do not only react in response to external events (i.e. a remote method call), but they also exhibit a goal-directed behavior and where appropriate are able to take initiative;
・ Social: agents are able to and need to interact with other agents in order to accomplish their task and achieve the complete goal of the system [
The environment is a first-class abstraction that provides the surrounding conditions for agents to exist and that mediates both the interaction among agents and the access to resources [
A multi-agent system is composed with autonomous entities (i.e. agents) that interact with one another. Multiple agents are necessary to solve a problem, especially when the problem involves distributed data, knowledge, or control [
A program is functionally correct if it behaves according to its stated functional requirements. Correctness is a mathematical property that establishes the equivalence between software and its specifications [
Safety and liveness properties are correctness properties. The safety property is an invariant which asserts that something bad never happens, that an acceptable state of affairs is maintained. Magee and Kramer [
Formal verification is the mathematical demonstration of the correctness of a system. The basic idea is to construct a mathematical model of the system under investigation, a model which represents the possible behavior of the system. The correctness requirements are specified along with the other functional requirements that represent the desirable behavior of the system. Based on these specifications, we check formal proof whether the possible behavior agrees with the desired behavior. Verification process can be made precise by using formal methods. Formal verification leads to proving or disproving the correctness with respect to this formal correctness notion. Formal verification can achieve complete exhaustive coverage of the system thus ensuring that undetected failures in the behavior are excluded.
In summary, formal verification requires a model of the system consisting of:
1) A set of states incorporating information about values of variables program counters;
2) A transition relation that describes how the system can change from one state to another;
3) A specification method for expressing requirements in a formal way;
4) A set of proof rules to determine whether the model satisfies the stated requirements.
To obtain a more concrete feeling of what is meant, we consider the way in which sequential programs can be formally verified.
Model checking [
Model checking addresses finite systems but can be scaled up to a more complex system as a multi-agent system. Here, by complex we mean a system with a large number of independent interacting components, with non-linear aggregate activity, with concurrency between components and constant evolution. Model checking basic idea is to use algorithms executed by software tools to verify the correctness of the system. The user inputs a description of a model of the system, the possible behavior, and a description of the requirements specification, i.e. the desirable behavior, and leaves the verification up to the machine. If an error is recognized, the tool provides a counter-example showing under which circumstances the error can be generated. The counter-example consists of a scenario in which the model behaves in an undesired way. Thus the counter-example provides evidence that the model is faulty and needs to be revised. This allows the user to locate the error and to repair the model specification before continuing. If no errors are found, the user can refine its model description e.g. by taking more design decisions into account so that the model becomes more concrete and can restart the verification process.
A timed automaton is a finite state automaton equipped with a finite set of real value clock variables called clocks, which are used to measure the elapse of time. Timed automata are used to model finite state real-time systems. A state of a timed automaton consists of the current location of the automaton plus the current values of all clock variables. Clocks can be initialized when the system makes a transition. Once initialized, they start incrementing their value implicitly. All clocks proceed at the same rate. The value of a clock thus denotes the amount of time that has been elapsed since it has been initialized. Conditions on the values of clocks are used as enabling conditions of transitions: only if the clock constraint is fulfilled, the transition is enabled, and can be taken; otherwise, the transition is blocked. Invariants on clocks are used to limit the amount of time that maybe spent in a location. Enabling conditions and invariants are constraints over clocks.
UPPAAL [
UPPAAL uses a query language (i.e. subset of TCTL) for defining requirements. The query language consists of state formulae and path formulae. State formulae describe individual states with regular expressions such as x ≥ 0. State formulae can also be used to test whether a process is in a given location. Path formulae quantify over paths of the model and can be classified into reachability, safety, and liveness properties:
・ Reachability properties are used to check whether a given state formula f can be satisfied by some reachable state. The syntax for writing this property is E <> f.
・ Safety properties are used to verify that something bad will never happen. There are two path formulae for checking safety properties. A[
・ Liveness properties are used to verify that something eventually will hold, which is expressed as A <> f.
Processes communicate with each other through channels. Binary channels are declared as chan x. The sender x! can synchronize with the receiver x? through an edge. If there are multiple receivers x?, then a single receiver will be chosen non-deterministically. The sender x! will be blocked if there is no receiver. Broadcast channels are declared as broadcast chan x. The syntax for sender x! and receiver x? are the same as for binary channels. However, a broadcast channel sends a signal to all the receivers, and if there is no receiver, the sender will not be blocked. UPPAAL also supports arrays of channels. The syntax to declare them is chan x [N] or broadcast chan x [N], and sending and receiving signals are specified as x[id]! and x[id]?. Processes cannot pass data through signals. If a process wants to send data to another process then the sender has to put the data in a shared variable before sending a signal and the receiver will get the data from shared variable after receiving the signal.
In this section we present a case study of multi-agent system. It is a system composed of transporting agents. The objective is to specify our system using timed automata and then verify the correctness properties of safety and liveness. The mission is to transport stock from one storehouse to another. They move in their environment which in this case is static, i.e. topology of the system does not evolve at run time. We have specified each and every part of the system, i.e. agents along with the environment in the form of LTS.
There are three types of agents:
1) Carrier agent: It transports stock from one storehouse to another, it can be loaded or unloaded and can move both forward and backward direction. Each road section is marked by a sign number and the carrier agent can read this number.
2) Loader/Un-loader agent: It receives/delivers stock from the storehouse, it can detect if a carrier is waiting (for loading or unloading) by reading the presence sensor, it ensures that the carrier waiting to be loaded is loaded and the carrier waiting to be unloaded is unloaded.
3) Store-manager agent: It manages the stock count in the storehouse and it also transports the stock between storehouse and loader/un-loader.
The template of the Carrier agent has eight locations: Safe, Appr Loaded Carrier, Parking Store House A, Start Loaded Carrier, Crossing, unload Carrier, Parking Store House B and Start Empty Carrier. The templates for Carrier agent and path have been modeled as shown in figure 1.
The Carrier Agent Template: The initial location is Safe, which corresponds to a carrier agent has not appeared on crossing loaded yet. The location has no invariant, which means that a carrier agent may stay in this location for an unlimited amount of time. When a carrier agent is approaching, it synchronizes with the controller. This is done by the channel synchronization appr! on the transition to Appr Loaded Carrier. The controller has a corresponding appr?. The clock x is reset and the parameterized variable e is set to the identity of this carrier agent. This variable is used by the queue and the controller to know which carrier agent is allowed to continue or which carrier agent must be stopped and later restarted.
The location Appr Loaded Carrier has the invariant x ≤ 20, which means that the carrier agent must leave the location within 20 time units. The two outgoing transitions are guarded by the constraints x ≤ 10 and x ≥ 10, which corresponds to the two sections before the crossing: can be stopped and cannot be stopped. At exactly 10, both transitions are enabled, which allows us to take into account any race conditions if there is one. If the carrier agent can be stopped (x ≤ 10) then the transition to the location Parking Store House A is taken, otherwise the carrier agent goes to location Crossing. The transition to Parking Store House A is also guarded by the condition e == id and is synchronized with stop?
When the controller decides to stop a carrier agent, it decides which one (sets e) and synchronizes with stop!
The location Parking Store House A has no invariant: a carrier agent may be stopped for an unlimited amount of time. It waits for the synchronization go?. The guard e == id ensures that the right carrier agent is restarted.
We can assume that a carrier agent may receive a go? synchronization even when it is not stopped completely, which will give a non-deterministic restarting time. The location Start Loaded Carrier has the invariant x ≤ 15 and its outgoing transition has the constraint x ≥ 7.
This means that a carrier agent is restarted and reaches the crossing section between 7 and 15 time units non-deterministically. The location Crossing is similar to Start Loaded Carrier in the sense that it is left between 3 and 5 time units after entering it.
The Template of the Path: The path controller synchronizes with the Carrier agent. Some of its locations do not have names. Typically, they are committed locations (marked with a c). The controller starts in the Free location (i.e., the path is free), where it tests the queue to see if it is empty or not. If the queue is empty then the controller waits for approaching carrier agent with the appr? synchronization. When a carrier agent is approaching, it is added to the queue with the add! synchronization. If the queue is not empty, then the first carrier agent on the queue is restarted with the go! synchronization.
In the Occ location, the controller essentially waits for the running carrier agent to leave the path (leave?). If other carrier agent is approaching (appr?), they are stopped (stop!) and added to the queue (add!). When a carrier agent leaves the path, the controller removes it from the queue.
A well-defined, precise, timed automaton based model of a multi-agent transport system is proposed. The correctness properties of safety and liveness of this proposed model are verified. The multi-agent system is modeled as a network of timed automata. A clock variable evaluates to a real number and clocks progress synchronously.
Our future work is the proposition, design and implementation of transformation rules for the translation of the current timed automata based formal model into a working system. This working system would have a formal foundation as it would be based on timed automata model.
We are grateful to The Worthy Vice Chancellor, The Islamia University of Bahawalpur for motivation and en-
Declarations | UPPAAL Specifications | |
---|---|---|
System declarations | 1 2 | //Template instantiations system Carrier_Agent,Path; |
Global declarations | 1 2 3 4 5 | //Global declarations const int N = 2; //number of carrier agents typedef int [0,N-1] id_carrier; chanappr[N], stop[N], leave[N]; urgent chan go[N]; |
Carrier agent declarations | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | id_carrier list[N+1]; int[0,N] len; // Postcondition: Put an element at the end of the queue void enqueue(id_carrier element) {list[len++] = element;} // Postcondition: Removes the front element of the queue void dequeue() { int i = 0; len -= 1; while (i < len) {list[i] = list[i + 1]; i++;} list[i] = 0; } // Postcondition: Returns the front element of the queue id_carrier front() {return list[ |
Formal verification using UPPAAL verifier | 1 2 3 4 5 6 7 | //Collion Detection on Crossing Area E<> Carrier_Agent(1).Crossing imply not Carrier_Agent(0).Crossing //Reachability E<> Carrier_Agent(1).Crossing //Check Deadlock For System A[ |
couragement. This work has been possible due to the support of The Department of Computer Science & IT, The Islamia University of Bahawalpur, Pakistan.