CTL cc,α action postulates

Like Singh [81], we augment the proposed semantics by additional rules under the form of postulates. The purpose is to force the satisfaction of business rules, which are intuitive, sound, and reasonable in commitments, commitment actions, and business protocols under the following constraints: 1) for every conditional commitment, when a software agent per- formed a commitment action, other commitment actions cannot be applied in all states for every paths starting from a state satisfying the corresponding commitment action formula (Cond₁); and 2) for every conditional commitment, only a software agent can perform a commitment action on a given commitment state (Cond₂).

To guarantee the satisfaction of our postulates, Cond₁and Cond₂should be considered in the models of MASs. Let ξ ∈ {W, S} along with Cond1 and Cond2 be true, then our

postulates have the following three patterns:

Future computation patterns

1. F uξ(i, ξCC(i, j, ψ, ϕ))→ AXAG¬Caξ(i, ξCC(i, j, ψ, ϕ)) 2. F uξ(i, ξCC(i, j, ψ, ϕ))→ AXAG¬Reξ(j, ξCC(i, j, ψ, ϕ)) 3. F uξ(i, (ξCC(i, j, ψ, ϕ))→ AXAG¬Deξ(i, k, ξCC(i, j, ψ, ϕ)) 4. F uξ(i, (ξCC(i, j, ψ, ϕ))→ AXAG¬Asξ(j, k, ξCC(i, j, ψ, ϕ)) 5. Caξ(i, (ξCC(i, j, ψ, ϕ))→ AXAG¬F uξ(i, ξCC(i, j, ψ, ϕ)) 6. Reξ(i, (ξCC(i, j, ψ, ϕ))→ AXAG¬F uξ(i, ξCC(i, j, ψ, ϕ)) 7. Deξ(i, k, (ξCC(i, j, ψ, ϕ))→ AXAG¬F uξ(i, ξCC(i, j, ψ, ϕ)) 8. Asξ(j, k, (ξCC(i, j, ψ, ϕ))→ AXAG¬F uξ(i, ξCC(i, j, ψ, ϕ))

The first four patterns state that once fulfilled, strong and weak conditional commitments cannot be canceled, released, delegated or assigned again in the future computations. Other patterns can be read in a similar way.

Immediate state patterns

1. F uξ(i, ξCC(i, j, ψ, ϕ))→ ¬Caξ(i, ξCC(i, j, ψ, ϕ)) 2. F uξ(i, ξCC(i, j, ψ, ϕ))→ ¬Reξ(j, ξCC(i, j, ψ, ϕ)) 3. F uξ(i, ξCC(i, j, ψ, ϕ))→ ¬Deξ(i, k, ξCC(i, j, ψ, ϕ)) 4. F uξ(i, ξCC(i, j, ψ, ϕ))→ ¬Asξ(j, k, ξCC(i, j, ψ, ϕ))

While the previous patterns emphasize the consequence of the fulfillment action from the next state, the present patterns focus on the impact of actions on the current state. For example, when the strong and weak conditional commitment are fulfilled, then there is no possibility to apply cancel, release, delegate or assign action on the same commitment in the same state, which is reasonable, and intuitive. Other patterns can be read in a similar way.

Undesirable pattern

The undesirable pattern comes out when there is no possibility to fulfill, cancel, release, delegate and assign the activated conditional commitment in all states of every possible path. Formally, this pattern is specified as follows:

¬EF ξCC(i, j, ψ, ϕ)∧ AG 

(¬F uξ(i, ξCC(i, j, ψ, ϕ))

∧ ¬Caξ(i, ξCC(i, j, ψ, ϕ)) ∧ ¬Reξ(j, ξCC(i, j, ψ, ϕ)) ∧¬Deξ(i, k, ξCC(i, j, ψ, ϕ))∧¬Asξ(j, k, ξCC(i, j, ψ, ϕ))) We do not claim that the set of our postulates is complete, but we can investigate the com- pleteness6 _{of any subset of our logic that supports the postulates using the corresponding}

theory following the methodology introduced by Singh [81]. This means other patterns can be added (e.g., if a commitment is canceled, it cannot be delegated in the future).

Chapter 4

Symbolic Model Checking for CTL

cc,α

and Implementation

This chapter1_covers:

− An overview about the model checking technique and our symbolic verification tech- nique.

− The development of new symbolic model checking algorithm dedicated to CTLcc,α_,

which addresses the first part of Question 1.3.6 mentioned in Chapter 1. − Theoretical results about our algorithm.

− The implementation of our symbolic model checking algorithm and tool, which ad- dresses the second part of Question 1.3.6 mentioned in Chapter 1.

4.1 Overview

Since it is not known in advance whether a party will satisfy its commitment, then verifying whether or not the commitment is resolved is of a significant importance, especially agents are autonomous and heterogeneous. The term ‘resolved’ refers to either fulfill, cancel, re- lease, delegate, or assign action. Testing and simulation are the most widely employed verification techniques [32]. They are carried out at run time to enable designers to test design models or certain conditions, which are difficult or expensive to reproduce in the real world. When the systems (e.g., MASs) under the consideration of verification pro- cess have a complex and large state-space and their components need to synchronously or

asynchronously communicate with each other, these techniques cannot guarantee the full coverage of all possible behaviors [32]. Model checking, performed at design time, is an- other verification technique that can complement testing and simulation [32, 33, 72]. In the model checking technique, there are two main steps. In the first step, a real-world system is encoded as a logical model M to represent key aspects of the system, including the fun- damental requirements, components, and how those components communicate with each other. In the second step, a set of requirements (or specifications) are expressed in a tem- poral logic as logical formulae, named ϕ₁, ϕ₂, etc. By thoroughly exploring the run-time states (also called state-space) of the system model without running the system, it is then possible to automate the verification of whether M |= ϕ1 (or M  ϕ1), i.e., whether the

system model M satisfies (or doesn’t satisfy) the formula ϕ₁. The model checking termi- nation is assured by the finiteness of the system model [32, 33] and this is why the model checking technique can perform “exhaustive analysis”.

In this chapter, we investigate the problem of model checking CTLcc,α _{in a practical}

way. Given a model M representing a MAS and a CTLcc,α_{formula ϕ expressing a property,}

the decision problem of model checking CTLcc,α _{is determining whether or not M is a}

model for ϕ. It would be formalized as: (M, I) |= ϕ iff (M, s) |= ϕ ∀s ∈ I where I is the set of initial states. We adopt symbolic model checking techniques to tackle this problem for several technical reasons mentioned in Chapter 1. In principle, a symbolic model checker differs from a symbolic model checking algorithm, although they have the same inputs: Encoded model and set of formulae. Specifically, a symbolic model checking algorithm computes the set of states ϕ in the model M satisfying the given formula ϕ. The set ϕ would be formalized as ϕ = {s ∈ S | (M, s) |= ϕ}. On the other hand, a symbolic model checker is a tool that is built on top of a symbolic model checking algorithm. One of the most powerful features of this tool is the production of counter- examples (i.e., witnesses of the offending system behaviors) when the specifications are violated [32].

Figure 11 shows our symbolic verification technique. Algorithm 1 reports the general structure and function of our symbolic model checker for automatically checking the sat- isfaction of CTLcc,α _{formulae. Since our symbolic model checker is the extension of the}

symbolic model checker MCMAS [64] with our symbolic model checking algorithm, we call it MCMAS+. It starts with comparing the set of initial states I against the setϕ of states that satisfy CTLcc,α_{formula ϕ. This set is computed by our symbolic model checking}



Figure 11: Our symbolic verification technique

it returns false and counter-example. Notably, producing counter-examples (respectively,

Algorithm 1 MCMAS+(M, ϕ): Boolean

1: if I ⊆ ϕ then

2: return TRUE and witness-example 3: else

4: return FALSE and counter-example

5: end if

witness-examples) for some kind of formulae such as EF p (respectively, AG¬p) needs to generate the whole model. Other model checkers such as CWB-NC2 _{do not produce}

counter-examples.