Language support for verifying reconfigurable interacting systems

Reconfigurable interacting systems consist of a set of autonomous agents, with integrated interaction capabilities that feature opportunistic interaction. Agents seemingly reconfigure their interaction interfaces by forming collectives and interact based on mutual interests. Finding ways to design and analyse the behaviour of these systems is a vigorously pursued research goal. In this article, we provide a modelling and analysis environment for the design of such system. Our tool offers simulation and verification to facilitate native reasoning about the domain concepts of such systems. We present our tool named R-CHECK (please find the associated toolkit repository here: https://github.com/dsynma/recipe). R-CHECK supports a high-level input language with matching enumerative and symbolic semantics and provides modelling convenience for features such as reconfiguration, coalition formation, and self-organisation. For analysis, users can simulate the designed system and explore arising traces. Our included model checker permits reasoning about interaction protocols and joint missions.


Introduction
Reconfigurable interacting systems [28,26], or Reconfigurable MAS for short, have emerged as new computa-tional systems, consisting of a set of autonomous agents that interact based on mutual interest, and thus creating a sort of opportunistic interaction.That is, agents seemingly reconfigure their interaction interfaces and dynamically form groups/collectives based on run-time changes in their execution context.Designing these systems and reasoning about their behaviour is very challenging, due to the high-level of dynamism that Reconfigurable MAS exhibit.Reconfigurable MAS can be viewed as a special case of Collective-Adaptive Systems (CAS) [38].Indeed, the only major difference is that the latter focus more on scalable systems with large number of components.Reconfigurable MAS, instead, focus on small scale systems with collective behaviour.Reconfigurable MAS are useful for applications in control systems, smart factories, autonomous vehicles, etc., while CAS can be used to explain systems with a very large number of (relatively small) agents.For instance, theories about CAS can be used to reason about the spread of disease infection [34], utilisation of bike-sharing systems [32], etc.That being said, theories on Reconfigurable MAS focus more on qualitative measures while CAS theories are quantitative.In this article, we focus on qualitative analysis (through, e.g., model checking) of reconfigurable systems.
Traditionally, model checking [16,31] is considered as a mainstream verification tool for reactive systems [7] in the community.A system is usually represented by a low-level language such as NuSMV [14], reactive modules [9,25], concurrent game structures [10], or interpreted systems [22].The modelling primitives of these languages are very close to their underlying semantics, e.g., predicate representation, transition systems, etc.Thus, it makes it hard to model and reason about highlevel features of Reconfigurable MAS such as reconfiguration, group formation, self-organisation, and similar.Indeed, encoding these features in existing formalisms would not only make it hard to reason about them, but will also create exponentially large and detailed models that are not amenable to verification.The latter is a classical challenge for model checking and is often termed as state-space explosion.
Existing techniques that attempt to tame the statespace explosion problem (such as BDDs, abstraction, bounded model checking, and so on) can only act as a mitigation strategy, but cannot provide the right-level of abstraction to compactly model and reason about high-level features of Reconfigurable MAS.
MAS are often programmed using high-level languages that support domain-specific features of MAS like emergent behaviour [3,37,8], interactions [5], intentions [17], knowledge [22], and so forth.These descriptions are very involved to be directly encoded in plain transition systems.Thus, we often want programming abstractions that focus on the domain concepts, abstract away from low-level details, and consequently reduce the size of the model under consideration.The rationale is that reasoning about a system requires having the right level of abstraction to represent its behaviour.Thus, there is a pressing demand to extend traditional model checking tools with support for reasoning about high-level features of Reconfigurable MAS.This suggests supporting an intuitive description of programs, actions, protocols, reconfiguration, self-organisation, etc.
ReCiPe [6,5] is a promising framework to support modelling and verification of reconfigurable multi-agent system.It is supported with both an enumerative semantics and a symbolic semantics and model representation that permits the use of symbolic representation to enable efficient analysis.However, writing programs in ReCiPe is very hard and error prone.This is because ReCiPe models are encoded in a predicate based representation that is far from how people usually write programs.In fact, the predicate representation of ReCiPe supports no programming primitives to control the structure of programs, and thus everything is encoded using state variables.
In this article, we present R-CHECK, a toolkit for designing, simulating, and verifying reconfigurable multiagent systems.R-CHECK supports a minimalistic highlevel programming language with symbolic semantics based on the ReCiPe framework.The syntax of the language was first presented briefly, along with a short case study, in [2].
Here we formally present the syntax and semantics of R-CHECK language and use it to model and reason about a nontrivial case study from the realm of reconfigurable and self-organising MAS.We integrate ltol [5,6] -a logic specialised for interaction -into R-CHECK, and thus allowing a native reasoning about selective interaction strategies.This article is an extended and an enhanced version of the paper in [1].There are two major new contributions with respect to [1]: (i) we have integrated native reasoning about message exchange by supporting ltol [6] specifications, an extension to ltl with native support for message exchange.We devise a new algorithm for ltol model checking that is different from the one presented in [6] to allow integration with nuXmv.Indeed, rather than a bespoke automata construction in [6], we extend the underlying system with additional information and model check an extended ltl formula over it.This alternative algorithm is integrated into R-CHECK; and (ii) we also now support a native interpreter for the semantics of R-CHECK models, and thus we can now simulate and visualise the counter examples from the model checking algorithm directly on the generated symbolic automata.In [1], we could only enable simulation by completely relying on nuXmv, and had no way to replay model checking counter examples.Note that the counter examples that nuXmv supports are state-based and due to possible nondeterminism it was hard to link them to message exchange.Our interpreter instead focuses on message exchange.
This specialised integration provides a powerful and native tool that permits verifying high-level features of Reconfigurable MAS.Indeed, we can reason about systems both from an individual and a system level.We show how to reason about synchronisations, interaction protocols, joint missions, and how to express high-level features such as channel mobility, reconfiguration, coalition formation, self-organisation, etc.
The structure of this article: In Sect.2, give a background on ReCiPe [6,5], the underlying theory of R-CHECK.In Sect.3, we present the language of R-CHECK and its symbolic semantics.In Sect.4, we provide a nontrivial case study to model autonomous resource allocation.In Sect. 5 we present the ltol logic and motivate it through the case study.In Sect.6 we present our new algorithm of ltol embedding in nuXmv.We also discuss the integration of R-CHECK on a nuXmv.Finally, we report concluding remarks in Sect.7.

ReCiPe: a model of computation
We present the underlying theory of R-CHECK and explain its semantics.R-CHECK accepts a high-level language that is based on the symbolic ReCiPe formalism [6,5].We briefly present ReCiPe agents and their composition to generate a system-level behaviour.All these definitions are based on discrete systems [36].
ReCiPe relies on (attributed-) channel communication, where agents agree on channel names to exchange messages.These messages carry data (in variables d) specified by senders.Agents can also specify the target of communication by attributing the channels through predicates, similar to [3,8].As opposed to the latter, ReCiPe supports a dynamic reconfiguration of channel utilisation.Moreover, ReCiPe supports two kinds of communication, channelled-broadcast and channelledmulticast.In channelled-broadcast, the communication is non-blocking, that is the communication can still go through if a targeted receiver is not ready to engage.Contrarily, in multicast, the communication is blocking until all targeted receivers are willing to accept the message and engage in the communication.Agents agree on a set of channels ch, which includes the one used exclusively for broadcast, ⋆.
Usually, broadcast is used for service-discovery.For instance, when agents are unaware of the existence of each other, and want to be discovered or to establish links for further interaction.On the other hand, multicast can capture a more structured interaction where agents have dedicated links to interact on.The reconfiguration of interaction interfaces in ReCiPe makes it possible to integrate the two ways of communication in a meaningful way.That is, agents may start with a flat communication structure and use broadcast to discover others.Thanks to ReCiPe's channel passing feature, agents can dynamically build dedicated communication structures based on channel references they exchange during execution.
In order to target a subset of agents, in an interaction, sending agents rely on property identifiers.That is, identifiers that senders use to specify properties required of targeted receivers.The set of property identifiers is pv.For instance, agent k may specify that it wants to communicate on channel "a" with all agents that listen to "a" and satisfy the property "BatteryLevel ≥ 30%".In other words, property identifiers pv are used by agents to indirectly specify constraints on the targeted receivers.
Each agent has a way to relate property identifiers to its local state through a re-labelling function.As we will see later, we have generalised this function in R-CHECK to deal with more sophisticated expressions.Thus, agents specify properties anonymously using these identifiers, which are later translated to the corresponding receiver's local state.Messages are then only delivered to receivers that satisfy the property after re-labelling.
Formally, an agent is defined as a Discrete System (DS) [36]: • V is a finite set of typed local variables.
• f : pv → V is a function, associating propriety identifiers to local variables.• g s (V, ch, d, pv) is a send guard specifying the property of the targeted receivers, based on the current evaluation of V, ch, and d , which is checked against every receiver j after applying f j .• g r (V, ch) is a receive guard describing the connectedness of an agent to a channel ch.We let g r (V, ⋆) = true, i.e., every agent is always connected to the broadcast channel.• T s (V, V ′ , d, ch) and T r (V, V ′ , d, ch) are assertions describing, respectively, the send and receive transition relations.We assume that an agent is broadcast input-enabled, i.e., ∀v, • θ is an assertion on V describing the initialization of the agent.
In this definition, a state of an agent s is an assignment to the agent's local variables V, i.e., for v ∈ V if Dom(v) is the domain of v, then s is an element in v∈V Dom(v).In case that all variables range over a finite domain then the number of states is finite.A state is initial if its assignment to V satisfies θ.Note that A is a discrete system, and thus we use the set V ′ to denote the primed copy of V .That is, V ′ stores the next assignment to V .Moreover, we use Id to denote the assertion v∈V v = v ′ .That is, V is kept unchanged.We use d to denote an assignment to the data variables d.We also abuse the notation and use f for the assertion Agents exchange messages of the form m = (ch, d, i, π): a message is defined by the channel it is sent on ch, the data it carries d , the sender identity i (we assume a unique identifier for each agent), and the assertion specifying the property of targeted receivers π.The predicate π is obtained by grounding the sender's send guard on the sender's current state, used channel ch, and exchanged data d.
Send transition relations T s characterise what messages may be sent, with one message sent at each point in time.While receive transition relations T r characterise the reaction of a receiving agent to a message.
We use keep(X) to denote that a set of variables X is not changed by a transition (either send or receive).That is, keep(X) is equivalent to the assertion A set of agents agreeing on property identifiers pv, data variables d, and channels ch define a system.We give the semantics of systems in terms of predicates to facilitate efficient symbolic analysis (through BDD or SMT).We use for disjoint union.
Formally, a ReCiPe systems is a Discrete System (DS), and is defined as follows: Definition 2 (System) Given a set {A i } i of agents, a system is S = ⟨V , ρ, θ⟩, where V = i V i , a state of the system s is in i v∈Vi Dom(v) and the initial assertion θ = i θ i .The transition relation ρ of S is as follows: The transition relation ρ describes two modes of interactions: blocking multicast and non-blocking broadcast.Formally, ρ relates a system state s to its successors s ′ given a message m = (ch, d, k, π).Namely, there exists an agent k that sends a message with data d (an assignment to d) with assertion π (an assignment to g s k ) on channel ch and all other agents are either (a) connected to channel ch, satisfy the send predicate π, and participate in the interaction (i.e., have a corresponding receive transition for the message), (b) not connected and idle, or (c) do not satisfy the send predicate of a broadcast and idle.That is, the agents satisfying π (translated to their local state by the conjunct ∃pv.f j ) and connected to channel ch (i.e., g r j (s j , ch)) get the message and perform a receive transition.As a result of interaction, the state variables of the sender and these receivers might be updated.The agents that are not connected to the channel (i.e., ¬g r j (s j , ch)) do not participate in the interaction and stay still.In case of broadcast, namely when sending on ⋆, agents are always connected and the set of receivers not satisfying π (translated again as above) stay still.Thus, a blocking multicast arises when a sender is blocked until all connected agents satisfy ∃pv.f j ∧ π.The relation ensures that, when sending on a channel different from ⋆, the set of receivers is the full set of connected agents.On the broadcast channel agents not satisfying the send predicate do not block the sender.
Example: Consider a ReCiPe system that is composed of two agents A 1 and A 2 , agreeing on the set of channels ch = {⋆}, the data variables d = {msg, lnk}, and the property variables pv = {pv}.Here, we use non-boolean variables to simplify the presentation.
A 1 is defined as follows: That is, A 1 has two local variables cLink of channel type and role of enumerate type.Moreover, A 1 relabels the property identifier pv locally as the value of its local variable role.The send predicate g s 1 indicates that A 1 intends to interact on the broadcast channel ⋆ with agents that satisfy the property pv = client according to their local relabelling.The receive predicate g r 1 indicates that A 1 is always enabled to receive.
Behaviour-wise, A 1 can send a message join with a link c on the broadcast channel ⋆.Moreover, A 1 is not willing to receive any messages.
Initially, the local variables of A 1 are set such that cLink is assigned link c and role is a client.
A 2 is defined as follows: - Clearly, A 2 only differs from A 1 with respect to the send guard, the send transition relation (which are set to false), the receive transition relation (which indicates that A 2 is willing to receive a message named reserve and stores the value of lnk of the message in cLink) and the initial condition where cLink is set to ⊥.
By applying Def. 2, we have that the composition of A 1 and A 2 indeed forms a ReCiPe system (where local variables of A 1 and A 2 are joined with disjoint union to account for similar local naming).Now starting from the initial conditions of both agents, we apply the system transition relation ρ.Clearly, there exist only one message that satisfies ρ, namely the message on channel ⋆ and data variables assigned as follows {msg → join, lnk → c}, where A 1 is the sender (i.e., its send transition relation T s 1 is satisfied).Moreover, there is only one receiver A 2 which is connected to ⋆ (i.e., g r 2 is satisfied), its receive transition relation T r 2 is satisfied with respect to the same message, and the send guard g s 1 is (ch = ⋆ ∧ pv = client) in conjunction to local relabelling of A 2 (i.e., pv = role) is satisfiable.Thus, ρ holds and as a result A 2 sets its local cLink variable to c that is communicated in the message.In the next cycle, ρ is checked again based on the new updated states.
Clearly, ReCiPe is a low-level formalism that is geared towards efficient BDD-representation and model-checking; and thus is not meant to be used as a modelling language.R-CHECK, on the other hand, builds on the efficient representation of ReCiPe and provides a set of high-level primitives that can be used for modelling purposes.
R-CHECK adopts a symbolic model checking approach that directly works on the predicate representation of ReCiPe systems.Technically speaking, the behaviour of each ReCiPe agent is represented by a firstorder predicate that is defined as a disjunction over the send and the receive transition relations of that agent.Moreover, both send and receive transition relations can be represented by a disjunctive normal form predicate of the form ( j assertion j ).That is, a disjunct of all possible send/receive transitions enabled in each step of a computation.In the following, we will define a highlevel language that can be used to write user-friendly programs with symbolic computation steps.We will also show how to translate these programs to ReCiPe predicate representation.

The R-CHECK Language
We formally present the syntax of R-CHECK language and show how to translate it to the ReCiPe predicate representation.
An R-CHECK program starts with a prelude, reported in Fig. 1, explicitly defining the communication context: by defining the channel names (line 1); the data variables a message carries (line 2), and defining the property variables (line 3).Moreover the user is allowed to define custom enum types (lines 4-6).After the communication context is defined, the user can define the set of agents that compose the systems.We define agents behaviour as data types.
We now introduce the agent type, its structure, and how to instantiate it; we also introduce the syntax of the agent behaviour and how to create a system of agents.The type agent is reported in Fig. 2. Intuitively, each agent type has a name that identifies a specific type of behaviour.As we will see later, we permit creating multiple instances/copies with the same type of behaviour.Each agent has a local state local represented by a set of local variables V T , each of which can be of a type boolean, integer or enum.The initialisation of an agent init: θ T is a predicate characterising the initial assignments to the agent local variables.The section relabel is used to implement the relabelling function of predicate variables in a ReCiPe agent.Here, we allow the relabelling to include a boolean expression Exp over local variables V T to accommodate a more expressive relabelling mechanism, e.g., pv ← (length ≥ 20).The section receive-guard specifies the connectedness of the agent to channels given a current assignment to its local variables.Syntax-wise, to specify receive guards we use a special variable ch to denote the channel a message was sent on at the current time step, thus we can write ch = a to denote that an agent is always receptive to messages sent on channel a.Moreover, an agent is always receptive to messages on broadcast, i.e. ch = * is implicitly added as a disjunct to whatever receive guard the user writes.The latter permits input-enabled broadcast as explained in Def. 1 The non-terminating behaviour of an agent is represented by repeat: P, which executes the process P indefinitely.
Before we introduce the syntax of agent behaviour, we show how to instantiate an agent and how to compose the different agents to create a system.
An agent type of name A can be instantiated as follows A(id, θ).That is, we create an instance of A with identity id and an additional initial restriction θ.Here, we take the conjunction of θ with the predicate θ T in the init section of the type A as the initial condition of this instance.
We use the parallel composition operator ∥ to inductively define a system as shown in the following production rule.
(System) S :: That is, a system is either an instance of agent type or a parallel composition of set of instances of (possibly) different types.The semantics of ∥ is fully captured by ρ in Def. 2. 2The syntax of an R-CHECK process is inductively defined as follows. (Process) An agent behaviour corresponds to an infinite repetition of a process.A process P is either a command prefix process C; P , a non-deterministic choice between two processes P + P , a loop rep P , or a command C.There are three types of commands corresponding to either a labelled command, a message-send or a messagereceive.A command of the form l : C is a syntactic labelling and is used to allow the model checker to reason about syntactic elements as we will see later. 3A command of the form ⟨Φ⟩x! π d U corresponds to a message-send.Intuitively, the predicate Φ is an assertion over the current assignments to local variables, i.e., is a pre-condition that must hold before the transition can be taken; x is a place holder (or a bound name) for a channel name.Note that x may refer to the value of a local variable, since we allow local variables to have the type channels.As the names suggest π and (respectively) d are the sender predicate, and the assignment to data variables (i.e., the actual content of the message).Lastly, U is the next assignment to local variables after taking the transition.We use ! to distinguish send transitions.A command of the form ⟨Φ⟩x? U corresponds to a message-receive.Differently from messagesend, Φ can also predicate on the incoming message, i.e., the assignment d.We use ? to distinguish receive transitions.
Despite the minimalistic syntax of R-CHECK, we can express every control flow structure in a high-level programming language.For instance, by combining nondeterminism and pre-conditions of commands, we can encode every structure of IF-statement.Similarly, we can encode finite loops by combining rep P and commands C, e.g., (rep C1 + C 2 ) means: repeat C 1 or block until C 2 happens.We define a system by instantiating agent types and put them in parallel, as shown bellow.
Finally, the user can supply logical specifications/properties on the behaviour of the system as a set of ltl and ltol formulas as shown below: We initially give a structural semantics4 to R-CHECK process using a finite automaton such that each transition in the automaton corresponds to a symbolic transition.Intuitively, the automaton represents the control structure of an R-CHECK process.We will further use this automaton alongside the agent definition to give an R-CHECK agent an execution semantics based on the symbolic ReCiPe framework.This two-step semantics will help us in verifying structural properties about R-CHECK agents.
Definition 3 (Structure automaton) A structure automaton is of the form G = ⟨S, Σ, s i , E⟩, where We use (s 1 , σ, s 2 ) to denote an edge e ∈ E such that s 1 is the source state of e, s 2 is the target state of e and the letter σ is the label of e. Now, everything is in place to define the structure semantics of R-CHECK processes.We define a function [si,s f ] : P → 2 E which takes an R-CHECK process P as input and produces the set of edges of the corresponding structure automaton.The function returns a set of transitions corresponding to the input process, starting from state s i and (possibly) finishing at state s f .The definition is reported below.
for a fresh s 1 Given a process P appearing in the body of agent type under repeat, we construct its corresponding structure automaton by constructing the set of edges E = P [si,si] , given some state s i .Let S and Σ respectively be the set of states and commands used in E. Then the corresponding structure automaton is: ⟨S, Σ, s i , E⟩.
Note that the states of the structure automaton only represent the control structure of the process, and an agent can have multiple initial states depending on θ T while starting from s i .
We explain informally the semantics.
is the union of the transitions created by P 1 and P 2 while creating a fresh state in the graph s 1 to allow sequentiality, where P 1 starts in s i and ends in s 1 and later P 2 continues from s 1 and ends in s f .That is, the structure of the process is encoded using an extra memory.Differently, the non-deterministic choice does not require extra memory because the execution of P 1 and P 2 is independent.The semantics of rep P [si,s f ] is similar to repeat : P [si,s f ] and is introduced to allow finite looping inside a nonterminating process.Finally, the semantics of a command in C corresponds to an edge {(s i , C, s f )} in the structure automaton.This means that the alphabet Σ of the automaton ranges over R-CHECK commands.Note that the translation is completely syntactic and does not enumerate variable values, resulting in a symbolic automaton.
To translate an R-CHECK agent into a ReCiPe agent, we first introduce the following functions: typeOf, varsOf, predOf and guardOf on a command C. That is, typeOf(C) returns the type of a command C as either ! or ?.For example, typeOf(⟨Φ⟩ ch !π d U) = !.Moreover, varsOf(C) returns the set of local variables that are updated in C, while the predOf(C) returns the predicate characterising C in terms of local variables V T , the primed copy V ′ T , the channel ch and the data variables d (excluding π).For instance, That is, we provide a predicate that uniquely characterises the information in the command.
Finally guardOf(C) returns the send predicate π in a send command and false otherwise.
Next we define how to construct a ReCiPe agent from an R-CHECK agent with structure semantics interpreted as a structure automaton.
Definition 4 (from R-CHECK to ReCiPe) Given an instance of agent type T as defined in Fig. 2 with a structure semantics interpreted as a structure automaton G = ⟨S, Σ, s i , E⟩, we can construct a ReCiPe agent A = ⟨V, f, g s , g r , T s , T r , θ⟩ that implements its behaviour.
We construct A as follows: -V = V T ∪ {st}: the union of the set of declared variables V T in the local section of T in Fig. 2 and a new state variable st ranging over the states S in G of the structure automaton, representing the control structure of the process of T .Namely, the control structure of the behaviour of T is now encoded as an additional variable in A; -The initial condition θ = θ T ∧ (st = s i ): that is the conjunction of the initial condition θ T in the init section of T in Fig. 2 and the predicate st = s i , specifying the initial state of G; f and g r have one-to-one correspondence in section relabel and section receive-guard, respectively, of T in Fig. 2; Namely, the structure of the R-CHECK process is encoded as a state variable st in ReCiPe.The send transition relation is encoded as the disjunction of all edges labeled with send commands, and similarly the receive transition relation.The send guard is a disjunction of all guards in send commands.Lastly, the initial condition of the ReCiPe model is initialised to the initial state of the state variable.

Case Study: Autonomous resource allocation
We model a scenario where a group of clients are requested to jointly solve a problem.Each client will buy a computing virtual machine (VM) from a resource manager and use it to solve their task.Initially, clients know the communication link of the manager, but they need to self-organise and coordinate the use of the link anonymously.The manager will help establishing connections between clients and available machines, and later clients proceed interacting independently with machines on private links learnt when the connection is established.
There are two types of machines: high performance machines and standard ones.The resource manager commits to provide high performance VMs to clients, but when all of these machines are reserved, the clients are assigned to standard ones.The protocol proceeds until each client buys a machine, and then all clients have to collaborate to solve the problem and complete the task.
To model this scenario in R-CHECK we need three agent types: client, manager, and machine.Each type can be instantiated multiple times, to model scenarios of different size.We continue by defining each agent type.We assume an enum type that identifies the role of each agent: rolevals = {client, manager, machine}.
A client uses the local variables cLink, mLink, and tLink of type channels, and role : rolevals to control its behaviour, where cLink is a link to interact with the manager, mLink is a placeholder for a mobile link that can be learnt at run-time, tLink is a link to synchronise with other clients to complete the task, and role is the role of the client.A client's initial condition θ c is: specifying that the resource manager is reachable on c, the mobile link is empty, the task link is t and the role is client.
Note that the interfaces of agents are parameterised to their local states and state changes may create dynamic and opportunistic interactions.For instance, when cLink is set to empty, the client does not connect to channel c; also when a channel is assigned to mLink, the client starts receiving messages on that channel.
In our example, clients are not aware of the existence of each other while they share the resource manager channel c.Thus they may coordinate to use the channel anonymously by means of broadcast.A client reserves the channel c by means of a broadcast message with a predicate targeting other clients.All other clients selforganise and disconnect from c and wait for a release message.
A message in R-CHECK carries an assignment to a set of data variables d.In our scenario, d = {lnk, msg} where lnk is used to exchange a link with other agents, and msg denotes the label of the message and takes values from {reserve, request, release, buy, connect, full, complete} Agents in this scenario use one predicate variable pv ranging over roles to specify potential receivers.Remember that every agent i has a relabelling function f i : pv → V i that is applied to the send guard once a message is delivered to check whether it is eligible to receive.For a client, f c (pv) = role.The send guard of a client appears in the messages that the client sends, as we will explain later.In general, broadcasts are destined to agents assigning to the predicate variable pv a value matching the role of the sender, i.e, client; messages on cLink are destined to agents assigning mgr to pv; and other messages are destined to everyone listening on the right channel.
The receive guard g r c is That is, reception is always enabled on broadcast and on a channel that matches the value of cLink or tLink.
Note that these guards are parameterised to local variables and thus may change at run-time, creating a dynamic communication structure.

Fig. 3: Client Behaviour
The behaviour of the client is reported in Fig. 3.In this example, we label each command with a name identifying the message and its type (i.e., s for send and r for receive).For instance, the send transition at Line 2 is labelled with sReserve while the receive transition at Line 4 is labelled with rReserve.We use these later to reason about agent interactions syntactically.
Initially in Lines 2−6, every client may either broadcast a reserve message to all other clients (i.e., (pv = role)) or receive a reserve message from one of them.This is to allow clients to self-organise and coordinate to use the common link.That is, a client may initially reserve an interaction session with the resource manager by broadcasting a reserve message to all other clients, asking them to disconnect the common link c (stored in their local variable cLink); or receive a reserve message, i.e., gets asked by another client to disconnect from channel c.In either case, the client progress to Line 8. Depending on what happened in the previous step, the client may proceed to establish a session with the resource manager (i.e., (pv = mgr)) and a machine (Lines 9 − 25) or gets stuck waiting for a release message from the client, currently holding the session (Lines 26 − 27).In the latter case, the client gets back in the loop to (Line 1) after receiving a release message and attempts again to establish the session.
In the former case, the client uses the blocking multicast channel c to send a request to the resource manager (Line 9) and waits to receive a private connection link with a virtual machine agent on cLink (Line 12).When the client receives the connect message on cLink, the client assigns its mLink variable the value of lnk in the message.That is, the client is now ready to communicate on mLink.On Line 14, the agent releases the common link c by broadcasting a release message to all other clients (with (pv = role)) and proceeds to Line 17 and starts communicating privately with the assigned VM agent.The client buys a service from the VM agent on a dedicated link stored in mLink by sending a buy to the VM agent to complete the transaction.The client proceeds to line 20 and wait for other clients to collaborate and finish the task.Thus, the client either initiates the last step and sends a complete message when the rest of clients are ready (Line 21) or receives a complete message from another client that is ready (Line 23).
We now specify the manager and the virtual machine, and show how reconfigurable multicast can be used to cleanly model a point-to-point interaction.
The resource manager's local variables are hLink, sLink, cLink, role where hLink and sLink store channel names to communicate with high-and standard-performance VMs respectively and the rest are as defined before.
The initial condition θ m is: Note that the link g 1 is used to communicate with the group of high performance machines while g 2 is used for standard ones.
The send guard for a manager is always satisfied, (i.e., g s m is true) while the receive guard specifies that a manager only receives on broadcast or on channels that match with cLink or hLink, i.e., g r m is

Fig. 4: Manager Behaviour
The behaviour of the agent manager is reported in Fig. 4. In summary, the manager initially forwards requests received on channel c (Line 2) to the high performance VMs first as in (Line 3).The negotiation protocol with machines is reported in Lines 5 − 13.The manager can receive a connect message and directly enable the client to connect with the virtual machine as in (Line 6) or receive a full message, informing that all high performance machines are fully occupied (Line 9).In the latter case, the requests are forwarded to the standard performance machines on sLink as in (Lines 10 − 11).The process repeats until a connect message is received (Line 6) and the manager gets back to (Line 1) to handle other requests.Clearly, the specifications of the manager assumes that there are plenty of standard VMs but not a lot of high performance ones.Thus it only expects a full message to be received on channel hLink.Note also that the manager gets ready to handle the next request once a connect message is received on channel c and leaves the client and the selected VM to interact independently.
The virtual machine's local variables are: gLink, pLink, cLink, asgn where asgn indicates if the VM is assigned, gLink is a group link, pLink is a private link and gLink is as before; the initial condition θ vm is ¬asgn ∧ cLink = empty (note gLink and pLink will be machine specific), where initially virtual machines are not listening on the common link cLink.Depending on the group that the machine belong to, the gLink will either be assigned to high performance machine group g 1 or the standard one g 2 .Moreover, each machine has a unique private link pLink.A VM's send guard is always satisfied, (i.e., g s mv is true) while its receive guard (g r vm ) specifies that it always receives on the broadcast channel, and also any channel held in the variables pLink, gLink and cLink i.e., g r vm is

Fig. 5: Machine Behaviour
The behaviour of the virtual machine agent is reported in Fig. 5. Intuitively, a VM either receives the forwarded request on the group channel gLink (Line 2) and thus activating the common link and also a nondeterministic choice between connect and full messages (Lines 4 − 11) or receives a buy message from a client on the private link pLink (Line 13).In the latter case, the VM agent agrees to sell the service and stays idle.In the former case, a VM sends connect, with its private link pLink carried on the data variable lnk, on on cLink if it is not assigned (Line 4), or sends full on gLink otherwise (Line 6).Note that a full message can only go through if all VMs in group gLink are assigned.Note that reception on gLink is always enabled by the receive guard g r vm .Moreover, the receive transition at Line 6 specifies that a machine enables a send on a full message only when it is assigned.For example, if gLink = g 1 then only when all machines in group g 1 are assigned, a full message can be enabled.
Furthermore, a connect message will also be received by other VMs in the group cLink (Line 8).As a re-sult, all other available VMs (i.e., ¬asgn) in the same group do not reply to the request.Thus, one VM is non-deterministically selected to provide a service and a point-to-point like interaction is achieved.Note that this easy encoding is possible because agents change communication interfaces dynamically by enabling and disabling channels.Now, we can easily create an R-CHECK system as follows.
This system is the parallel composition (according to Def. 2) of three copies of a client {client 1 , . . ., client 3 }; a copy of a manager {manager}; and finally three copies of a machine {machine 1 , . . ., machine 3 }, each belongs to a specific group and a private link.For instance, machine 1 belongs to group g 1 (the high performance machines) and has a private link named vmm1.The symbolic automata corresponding to the different agents are reported in Fig. 6.There, the interaction structure and the control flow of the different agents are exposed to facilitate a fine-grained reasoning about interactions.

Model Checking of R-CHECK Systems
We present the required background on ltol, an extension of ltl with the ability to refer and therefore reason about agents interactions.We also show how to use ltol to reason about R-CHECK models.In the following sections, we show how to efficiently integrate ltol model-checking into R-CHECK toolkit.

The ltol Specification Logic
ltol is an extension of the Linear Time Temporal logic (ltl) with the ability to refer and therefore reason about agents interactions.ltol majorly differs from ltl with respect to the next operator (i.e., X).Indeed, ltol replaces the next operator of ltl with observation descriptors that characterise the contents of the message and the sender predicate.Namely, we distinguish two descriptors: possible ⟨O⟩ and necessary [O], to refer to messages and the intended set of receivers.The syntax of formulas φ and observation descriptors O is as follows: where pv is a property identifier, ch is a channel name (identifying the channel the current message is sent on), k is an agent identifier (indicating the sending agent at the current time step), and d is a data variable (whose value is determined by the payload of the current message).
We use the classic abbreviations →, ↔ and the usual definitions for true and false.We also introduce the temporal abbreviations Fφ ≡ true U φ (eventually), Gφ ≡ ¬F¬φ (globally) and φ W ψ ≡ ψ R(ψ ∨ φ) (weak until ).Furthermore the semantics assumes that all variables mentioned in the specification are Boolean.Note that every finite domain can be encoded by multiple Boolean variables.R-CHECK, however, supports constraints over non-Boolean variables, including variables with infinite domain (e.g., integers) as part of the LTOL syntax.
The syntax of ltol is presented in positive normal form to avoid unnecessary blowup during model checking.That is, we push the negation down to atomic propositions.
Observation descriptors are built from referring to the different parts of the message and their Boolean combinations.Thus, they refer to the channel in ch, the data variables in d, the sender k, and the sender predicate over predicate variables in pv.These predicates are interpreted as sets of possible assignments to property identifiers, and therefore we include existential • ∃ O and universal • ∀ O quantifiers over these assignments.
The semantics of a descriptor O is defined for a ReCiPe message m = (ch, d, k, π).Recall π identifies the set of receivers the sender wishes the message to reach, by identifying the assignments to property identifiers pv that a receiver is allowed to have.Given an assignment c and a variable pv ∈ pv we write c ⊨ pv if c assigns pv to true and c ̸ ⊨ pv otherwise.The semantics is defined as follows: We only comment on the semantics of the descriptors • ∃ O and • ∀ O as the rest are standard propositional formulas.The descriptor • ∃ O requires that at least one assignment c to the property identifiers in the sender predicate π satisfies O. Dually • ∀ O requires that all assignments in π satisfy O. Using the former, we express properties where we require that the sender predicate has a possibility to satisfy O while using the latter we express properties where the sender predicate can only satisfy O.For instance, both observations (ch, d, k, pv 1 ∨ ¬pv 2 ) and (ch, d, k, pv 1 ) satisfy • ∃ pv 1 while only the latter satisfies • ∀ pv 1 .Furthermore, the observation descriptor • ∀ false ∧ ch = ⋆ says that a message is sent on the broadcast channel with a false predicate.That is, the message cannot be received by other agents.In our example in Sect.4, the descriptor • ∃ (pv = client)∧ • ∀ (pv = client) says that the message is intended exactly for agents of client role.
We interpret ltol formulas over system computations: Definition 5 (System computation) A system computation ρ is a function from natural numbers N to 2 V × M where V is the set of state variable propositions and M = ch×2 d ×K ×2 2 pv is the set of possible observations.That is, ρ includes values for the variables in 2 V and a message in M at each time instant.We denote by s i the system state (i.e., an assignment to system variables) at the i-th time point of the system computation.Moreover, we denote the suffix of ρ starting with the i-th state by ρ ≥i and we use m i to denote the message (ch, d, k, π) in ρ at time point i.
The semantics of an ltol formula φ is defined for a computation ρ at a time point i as follows: Intuitively, the temporal formula ⟨O⟩φ is satisfied on the computation ρ at point i if the message m i satisfies O and φ is satisfied on the suffix computation ρ ≥i+1 .On the other hand, the formula [O]φ is satisfied on the computation ρ at point i if m i satisfying O implies that φ is satisfied on the suffix computation ρ ≥i+1 .Other formulas are interpreted exactly as in ltl.
With observation descriptors we can refer to the intention of agents in the interaction.Consider the following formula: The formula states that eventually a client k will communicate with the resource manager mgr using a request message.Note that we not only specify the message contents in ltol, but also we can predicate on the targeted receivers.Expressing this formula in ltl, which was the only specification language supported in the conference version [1] of this article, is only possible by including (manually) additional instrumentation in the system.Thus, we integrate ltol model checking into R-CHECK.Here, we would like to use existing implementations of ltl model checking rather than the bespoke ltol model checking algorithm in [6].The algorithm here, replaces the large alphabet required in [6] by extending the model with observation variables (to be explained below) and creating a modified ltl formula relating to them.Thus, we reduce ltol model checking to ltl model checking over a model that is extended with additional variables.The details are given in Section 6.2.
Practically, the implementation of the latter algorithm is done through an encoding into the nuXmv model checker [15].First, we transform an R-CHECK model into a symbolic ReCiPe model, encode it as an nuXmv module, and later we rely on the symbolic model checking algorithms of nuXmv to reason about R-CHECK.

ltol Showcasing
We will use Eq. 1, Sect. 4 and the corresponding structure automata in Fig. 6 as the system under consideration.
We show how to verify ltol properties about agents both from individual and interaction protocols level by predicating on message exchange rather than on atomic propositions.Unlike the conference version, we will use formulas that natively characterise interactions and the different coordination mechanisms.For instance, we can reason about a client and its connection to the system as follows.

G([sender
The liveness condition (1) specifies that after a client reserves the common link they send a request to the manager c; the liveness condition (2) specifies that the client does not hold a live lock on the common link c.Namely, the client releases the common link eventually.The liveness condition (3) specifies that the system is responsive, i.e., after the client's request, other agents collaborate to eventually supply a connection.
We can also reason about synchronisation and reconfiguration in relation to local state as follows.
In ( 4), the manager has to forward the request before a machine can get connected to the common link.That is, a machine reconfigures its interaction interface and starts listening to link c.Moreover, in (5) every machine that is not assigned must eventually supply a connection.
We can also specify channel mobility and joint missions from a declarative and centralised point of view, as follows. k∈Client That is, eventually one client will initiate the mission's termination by synchronising with the others to solve the joint problem.Notice that the quantified sub formula over clients (in the second line) that are not senders ensures that they must participate and supply a receive transition (i.e., j−rSolve, see Fig. 3, Line 23).Moreover, each client eventually receives a mobile link (i.e., k-mLink ̸ = empty).
This is interesting because we can zoom in and specify senders and receivers natively.Indeed, this level of reasoning is impossible to achieve while considering only the states of the system.We must be able to refer to contents of messages as allowed by ltol.The full tool support and all examples in this paper are available on the git repository.
In the following, we show how to integrate ltol into R-CHECK.

LTL & LTOL Model-Checking and Simulation
We show how to model check both ltl and ltol [5,6] through nuXmv.With nuXmv, we can support BDDbased symbolic model checking (with finite-state-space) or IC3 and bounded model checking BMC (with infinitestate-space).Moreover, we present a new native frontend and interpreter for R-CHECK and showcase it.

Integrating ltl Model Checking into R-CHECK
We give individual R-CHECK agents a symbolic semantics based on the ReCiPe framework as shown in Sect.3.1 and Def. 4. Notably, we preserve the labels of commands (i.e., l : σ) and use them as subpredicate definitions.For instance, given a labeled edge (s 1 , l : σ, s 2 ) in the structure automaton G in Def. 3, we translate it into the following predicate in ReCiPe as explained in Def.4: The only difference here is that the label l is now a predicate definition and its truth value defines if the transition (s 1 , l : σ, s 2 ) is feasible.Since every command is translated to either message-send or message-receive, we can use these labels now to syntactically refer to code reachability.That is, we can directly specify if a line of code is reachable.
Moreover, we rename all local variables of agents to consider the identity of the agent as follows: for example, given the cLink variable of a client, we generate the variable client−cLink.This is important when different agents use the same identifier for local variables.We also treat all data variables d and channel names ch as constants and we construct a ReCiPe system S = ⟨V , ρ, θ⟩ as defined in Def. 2 while considering subpredicate definitions and agent variables after renaming.Technically, a ReCiPe system S has a one-toone correspondence to a nuXmv module M .That is, both S and M agrees on local variables V and the initial condition θ, but are slightly different with respect to transition relations.For efficiency, the composition of agents to a system, discards the information about messages.Thus, we do not add variables that capture these details and rely on correct conjunction of transition disjuncts to capture the existence of an appropriate message.Finally, the transition relation ρ of S as defined in Def. 2 is translated to an equivalent transition relation ρ of M as follows: That is, nuXmv translates deadlock states in S into stuttering (sink) states in M where system variables do not change.
Note that the above mentioned translation to nuXmv unlocks the native model simulator and ltl model checker of nuXmv.As messages are not encoded directly in the model, only basic reasoning about message exchange using labelled commands is possible.As shown in the early version [1] of this article, one can use such labels to reason about interactions as follows: This formula can be used in our example to specify that after the client's request eventually a machine supplies a connection.Although this formula is correct in our example, it is not strong enough to indicate that a request message is actually happening.It can only indicate that a request message is enabled.This is because the label sRequest only indicates if a line of code is reachable and feasible, but does not tell if it is executed.One needs a more expressive language to express the actual exchange of messages.For instance, this is straightforward in the following ltol formula: Clearly, formula (1) natively expresses that it is always the case that if a client sends a request message, it will eventually receive a connection where its mobile link mLink is assigned.However, to allow such high-level verification of message exchange, we need to integrate ltol model checking into R-CHECK.

Integrating ltol Model Checking into R-CHECK
We provide a new algorithm for model checking ltol.The original algorithm [6] constructed directly a corresponding automaton from an ltol specification.Furthermore, during model checking additional satisfiability checks of individual steps were required.Here, to reuse existing state-of-the-art tools, we instead augment our system model to be able to project ltol model checking onto ltl model checking.Note that this is not equivalent to an encoding of ltol into ltl.Such encoding does not actually exist, and this is why our algorithm requires augmenting the model with new variables.
Our algorithm exploits the original insights of the algorithm for ltol model checking [6].Namely, to concentrate on checking messages against top-level observations, appearing in the ltol formula.
A core difficulty in the present algorithm is that the observation descriptors O that appear in ltol formulas are not (completely) part of R-CHECK models.Therefore, we need a way to embed them efficiently in R-CHECK models and use this embedding to reason about interactions through nuXmv.To do so, we introduce a variable obs i for each descriptor that appears in the ltol formula, embed obs i into the nuXmv encoding of R-CHECK model, and later use an extended ltl formula to reason about it.We stress that the embedding of obs i into the nuXmv encoding ensures that the value of obs i reflects the truth value of the observation after each transition.
Formally, let obs(φ) be the set of observations appearing "top-level" in the operators ⟨•⟩ and [•] in φ.More precisely, obs(φ) is closed under the subformula relation of φ, but is not closed under the subformula relation of O. Consider φ in Formula 1: We denote by |obs(φ)| the size of the set obs(φ).Thus, for a formula φ over an R-CHECK system Sys, we create a modified system Sys ′ by introducing |obs(φ)|-new variables (one for each descriptor) to the system.These variables can be used to record the changes of truth values to the different observation descriptors.We set the initial condition θ ′ of the modified system Sys ′ to the conjunction of the initial condition θ of the original system Sys and a false assignment to all these new descriptor variables, to mean that no messages have been exchanged initially.
Recall that the predicate semantics of an R-CHECK system is of the form i ( j cmd j ), where each conjunct in the disjunction represent a message send command in T s i conjuncted with reactions of receivers in T r j with respect to g r j , while evaluating the send predicate g s i on each receiver state.This means that it is sufficient to set the new descriptor variables after the execution of each conjunct to specify which message is executed.In what follows, we abuse the notations and use T s i to denote the set of send transitions of agent i and τ s i to denote a single send transition of agent i.In other words, for each conjunct ( j cmd k ) in the system semantics, we conjunct it with the truth value of each descriptor in the next state.Namely, the latter conjunct is transformed into: That is, every time a message is emitted, we assign each obs k with its truth value in the next state (hence we use the prime copy obs ′ k ) through an embedding function.The latter takes the descriptor O k for sender k and the send transition τ s j as parameters.The definition of the embed function is shown below.
The rationale is that each transition at system level is a send transition, which is originated by a single sender.Thus, every time is a message is emitted, we set the truth values of all observation descriptors.We embed the observations for each send transition τ s k ∈ T s k of agent k.The embedding function is defined as follows: Definition 6 (Observation embedding) We define an embedding function embed(O k , τ s j ) that takes an observation O k and a send transition τ s j of agent j, rewrites the observation to a formula with respect to τ s j and the send predicate g s j of agent j.We use c to denote an assignment to property identifiers in pv and f [c] to denote a grounding of formula f on c: Namely, we rewrite the observation in relation to the current executed send command and the sender predicate.We require that ltol formulas are written in a normal form where pvs do not appear outside quantifiers, and there is no nesting of quantifiers.This is important to handle quantified formulas correctly.Now, everything is in place to translate ltol descriptor formulas into ltl as follows: Intuitively, the translation faithfully follows the trace semantics of descriptor formulas as explained in Sect.5.1.Note that the resulting ltl formula is linear in size with respect to the ltol one.Here, we consider the size of an ltol formula with respect to top-level observations as in [6], and thus we consider an observation alphabet in 2 |obs(φ)| .Since we eventually employ ltl model checking on the modified model and formula, it is clear that the model checking problem is still in pspace.However, the size of the model is dependent on the extra variables added to account for top-level observations |obs(φ)|.More precisely we have the following: Theorem 1 (Model-Checking) The Model-Checking problem of an ltl formula φ ′ translated from an ltol formula φ is pspace-complete with respect to the size of the original ltol formula |φ| and the size of the modified system |Sys| × |obs(φ)|, where |Sys| is the (symbolic) size of the original system.
Note that the stated bound in terms of |Sys| × |obs(φ)| instead of logspace is because R-CHECK systems are symbolic.Indeed, logspace complexity is achieved for enumerative representation, which is anyway exponentially larger.
Clearly, the size of the resulting ltl formula (which is linear compared to ltol) does not play a role in the asymptotic complexity.The only major difference is due to the enriched system model.Since the number of toplevel observations in the formula |obs(φ)| impacts on the size of the model, one could mitigate the blowup by model-checking individual formulas, and thus building smaller enriched system models for each LTOL formula.
Theorem 2 (Correctness) Given a ReCiPe system Sys and an ltol formula φ, we have that: where Sys ′ is an enriched system model according to Eq. 2 and Def.6 and φ ′ is an ltl formula translated from φ according to Eq. 3.

Proof
We have two directions.We prove the Only if direction (⇐) and the if (⇒) direction follows in a similar way.Moreover, we restrict our attention to base and descriptor formulas.Note that the translation of other formulas is the identity function.
(⇐) Assume Sys ⊨ φ and prove Sys ′ ⊨ φ ′ : For a ReCiPe system Sys, a computation is of the form σ : (s 0 , m 0 )(s 1 , m 1 ) . . ., where s 0 is an initial state, s i ∈ 2 V and m i ∈ M (see Def. 5).An R-CHECK system computation, on the other hand, is of the form σ ′ : s 0 , s 1 , . . .where information about messages (m i ) is dropped after composition to produce a nuXmv module.Our algorithm aims at enriching the states of a computation when needed to allow reasoning about message exchange.We know that Sys ⊨ φ iff for every computation σ in Sys, we have that σ ⊨ φ.Now consider an arbitrary ReCiPe computation σ : (s 0 , m 0 )(s 1 , m 1 ) . . . of Sys, and consider the following cases for φ: -Consider a state formula (v): a state formula does not contain observation descriptors, and thus |obs(v)| = 0.In other words, both the system Sys and the formula φ are not changed by our algorithm, and thus this case holds easily (state information are sufficient to prove φ).
-Consider a descriptor formula (⟨O⟩φ): By semantics of ltol, we have that Unlike the nuXmv simulator used in the conference version [1] of this article, the current interpreter is developed based on the interaction semantics of ReCiPe, and thus allows to simulate the interactions and provides better understanding of the scenario under consideration.
Note that in R-CHECK, we limit ltol specifications to only refer to property identifiers of finite-domains (e.g., boolean variables, channels, enums, and bounded integers).This important because the definition of embed requires, for certain cases, existential (e.g. for • ∃ ) or universal (for • ∀ ) quantification over the possible assignments to pv; and thus we may need to enumerate all such assignments.

The R-CHECK Frontend and Interpreter
R-CHECK is implemented in a prototype tool, which can either be invoked from a command line or a userfriendly web interface (with graphical illustrations).
The web interface (e.g., Fig. 7 below) provides a rich text area and support for model-checking or simulation.
The text area permits writing high-level syntax corresponding to the language of R-CHECK, providing syntax colouring and highlighting to improve readability.The user can build the model by either compiling to an SMT model (with infinite-state space) or to a plain BDD (with finite-state space) by hitting the Build model button.When the model is ready, the user will also be presented with a representation of the agents in the system as symbolic automata, shown in the lower part of the interface (See Fig. 7).
For model checking purposes, the user can use different options, depending on the model type.Currently, we support BDD-based symbolic model checking (which is Model-Checking (MC) that requires a BDD model), IC3 and Bounded Model Checking (BMC) (which require an SMT model).When either IC3 or BMC is selected, a text field appears where a verification bound can be specified; this is optional for IC3 and mandatory for BMC.
The user writes all specifications at the bottom of the text area, and each specification should be prefixed by the keyword SPEC.Once the model checking procedure is over, the user gets a report with the verification outcome for each specification.
The interpreter tab allows the user to interactively explore the system's executions.We set up the interpreter by hitting the Start button.When this happens, the initial state is computed,5 a dropdown gets populated with all available transitions, and the Start button itself is replaced by a Next button.Then, the user makes the system evolve by choosing a transition from the dropdown and hitting Next.The Back button allows instead to undo the latest transition and go back to the previous step.The interpreter can be restarted completely by hitting Reset.Additionally, whenever a verification task (in the Model Checking tab) finds a counter example, the user will be given the option to load it into the interpreter.
Let us now consider the R-CHECK example of Section 4, and show how to use the Web frontend to modelcheck the following specifications against it: We expect property (1) to hold, and (2) to be violated.Informally, (1) states that eventually one client will initiate the mission's termination.Moreover, each client eventually receives a mobile link; (2), on the other hand, states that once the manager forwarded the request, all machines will get connected to the common link.
Fig. 8a below depicts the outcome of the IC3 model checker.As we can see, the tool allows us to load the counter example for the second property into the interpreter.When we do that (see Fig. 8b) below, we Fig. 7: The R-CHECK Web-based interface, after building a model.can easily see that after the manager sends a request message from state 2, only machine1 and machine2 get connected to link c.This is not the case for machine3, and thus violating property 2.

Concluding Remarks
We introduced the R-CHECK model checking toolkit for verifying and simulating reconfigurable multi-agent system.We formally presented the syntax and semantics of R-CHECK language in relation to the ReCiPe framework [6,5], and we used it to model and reason about a nontrivial case study from the realm of reconfigurable and self-organising MAS.Our semantics approach consisted of two types of semantics: structural semantics in terms of automata to recover information about interaction features, and execution semantics based on ReCiPe.The interaction information recovered in the structural semantics is recorded succinctly in the execution one, and thus permits reasoning about interaction protocols and message exchange.R-CHECK is supported with a command line tool, a web editor with syntax highlighting and visualisation.We integrated ltol [5,6] model checking into R-CHECK, and thus allowing a native reasoning about selective interaction strategies.The integration consisted of providing a dynamic embedding of ltol descriptor formulas into the model under consideration.We built R-CHECK based on a compilation to nuXmv to enable both ltol and ltl verification through symbolic, bounded, and IC3 model checking.We showed that this specialised integration provides a powerful tool that permits verifying high-level features such as synchronisations, interaction protocols, joint missions, channel mobility, reconfiguration, self-organisation, etc.
As mentioned, our work is focused on multi-agent systems, which is a special case of collective adaptive systems.The difference here is that the number of agents is usually small, and thus the issue of scalability is not our main concern.Indeed, if we consider a large number of agents then qualitative reasoning with ltol would not be sufficient and probabilistic techniques, like statistical model checking [30], would be more appropriate.
Related works.We report on closely related modelchecking toolkits.MTSA toolkit [21] is used to reason about labelled transition systems (LTS) and their composition as in the simple multiway synchronisation of Hoare's CSP calculus [27].MTSA uses Fluent Linear Temporal logic (fltl) [24] to reason about actions, where a fluent is a predicate indicating the beginning and the end of an action.As the case of MCMAS, the communication structure is fixed and there is no way to reason about reconfiguration or even message exchange.
A few other languages have been proposed that entirely drop channel-based interaction, letting agents select their interaction partners through attribute-based predicates.Here we only report on those languages with an associated verification platform.In SCEL [19], each agent (or process) has an associated tuple space and interaction happens by attribute-based insertion, lookup, or deletion of tuples.This makes the interaction mechanism somehow asynchronous, in the sense that (i) the insertion of a tuple cannot be blocked, and (ii) there is no guarantee that a tuple insertion modelling a service request will elicit a response within any time bound.While SCEL is arguably a more dynamic language than R-CHECK, featuring dynamic instantiation of names and processes as well as higher-order communication (i.e., exchanging processes by storing them in tuples), its verification capabilities are based on the statistical model checking [35].This is due to the fact that SCEL's models have typically infinite-state-space both behaviourally (dynamic creation of processes) and domain wise (use infinite-domain state variables).Thus, statistical reasoning fits more with SCEL.
AbC [3,8] instead provides attribute-based multiway synchronisation as the core interaction primitive.AbC specifications may be verified through symbolic bounded model checking (BMC) [18].This approach seems limited to verification of safety property and appears to be better suited for bug-finding than for liveness and fairness properties, since completeness of BMC depends on choosing an appropriate verification bound.Compared to SCEL and AbC , R-CHECK offers channelbased communication that may be further specialised through predicates over properties.These, in turn, bear a loose resemblance to attributes.Properties appear to be more flexible and to better support encapsulation: the value of a property is the result of an arbitrary expression over the state of agents, whereas attributes either coincide (AbC ) or directly map to internal variables (SCEL).At the same time, properties are not essential to the Reconfigurable MAS aspects of R-CHECK.For instance, agents may still block each other over multicast channels even without send guards.
Other frameworks that deal with dynamic reconfiguration include DREAM [20] and BIP [11].In the former, components (agents) live within motifs that also dictate rules for components to interact with each other or migrate towards another motif.In the latter, behaviour and interactions are logically distinct layers.The behavioural layer only specifies how a component communicates over a set of ports; the interaction layer, in turn, specifies connectors that model links and modes of synchronisation between ports.This modelling style is known as exogenous, as opposed to the endogenous style where coordination primitives are part of the components' behaviour.Proponents of exogenous modelling argue that it enables to abstract formal analysis of the coordination model away from the behavioural layer.ReCiPe applies instead an endogenous approach: our rationale is that not having to specify global coordination rules simplifies modelling, and that the lack of a clear separation of layers is effectively mitigated by appropriate logical formalisms (LTOL) and state-of-the-art verification techniques (IC3).
Moreover, R-CHECK is uniquely distinguished from existing formalisms whether they are attribute-based such AbC or connector-based such as static BIP [12] due to run-time reconfiguration of interaction interfaces.In attribute-based communication, the interaction is based on value-passing broadcast, and thus there is no way to create dedicated communication structure at run-time.For connector-based communication, the communication structure is static and cannot be changed.R-CHECK could be viewed as a generalisation of π-calculus [33] like reconfiguration in a multi-party settings.Moreover, R-CHECK is uniquely distinguished from existing formalisms whether they are attributebased such AbC or connector-based such as static BIP [12] due to run-time reconfiguration of interaction interfaces.In attribute-based communication, the interaction is based on value-passing broadcast, and thus there is no way to create dedicated communication structure at run-time.For connector-based communication, the communication structure is static and cannot be changed.R-CHECK could be viewed as a generalisation of π-calculus [33] with reconfiguration in a multi-party settings.
Several model-checking toolkits support specification languages that are designed to reason about concurrent systems and protocol design, and thus allow to model processes that may interact with each other, usually via channel synchronisation.Examples include SPIN, mCRL [13], and CADP [23].These toolkits are successful in reasoning about static coordination protocols, mainly related to fixed-structure systems like hardware and low-level communication protocols, but do not expand their coverage to multi-agent system features.They also cannot handle infinite-state systems, are usually tied to a limited choice of verification algorithms, and have limited support for interoperability: this last concern is partially mitigated by third-party projects such as LTSmin [29].By contrast, the input language used by nuXmv [15] is designed at the semantic level of transition systems, making it an excellent candidate to serve as a backbone for special-purpose model-checking tools.Furthermore, this toolkit implements a large number of efficient algorithms for verification.These considerations led us to integrate R-CHECK with nuXmv.
Future works.We plan to equip R-CHECK with a richer specification language that allows reasoning about the knowledge of agents and the dissemination of knowledge in distributed settings.For this purpose, we will investigate the possible integration of R-CHECK with MCMAS [31] to make use of the specialised symbolic algorithms that are introduced for knowledge reasoning.We also plan to integrate the partial order semantics of ReCiPe models that were introduced in [4].

Fig. 6 :
Fig. 6: Symbolic structure automata (a) Model checker tab with verification outcome.(b) Interpreter with a counter example to a violated specification.
and σ ≥i+1 ⊨ φThe modified R-CHECK system Sys ′ has computations of the form σ ′ : (s 0 , o 0 )(s 1 , o 1 ) ..., where o i ∈ 2 obs O for i ≥ 0 and o 0 = ∅ (no messages have been exchanged earlier).Note that o i in a computation (except for o 0 ) evaluates to true iff the predicate embed(O, τ s k ) is satisfiable for the previously executed send command τ s k of some sender k (recall that the embed is assigned as the next assignment to obs O (i.e., obs ′ O ) ).By easy inspection, it is not hard to see that the semantics of m i ⊨ O is actually equivalent to the satisfiability of the predicate returned by embed(O, τ s k ) (or the value of obs ′ O ).In other words,m i ⊨ O implies o i+1 is true.Now, φ ′ ≜ X(obs O ∧ φ ).Thus, for a modified R-CHECK computation σ ′ : (s 0 , o 0 )(s 1 , o 1 ) ..., we have that σ ′ ≥i ⊨ X(obs O ∧ φ) iff σ ′ ≥i+1 ⊨ obs O and σ ′ ≥i+1 ⊨ φ .Simulation.R-CHECK provides an interactive interpreter (or simulator) that allows the user to simulate the system either randomly or based on the user choice.The simulator can also backtrack from a specific state of the system.The latter feature is used to simulate the counter examples from the model checking algorithm.