Compositional verification of priority systems using sharp bisimulation

Abstract

Sharp bisimulation is a refinement of branching bisimulation, parameterized by a subset of the system’s actions, called strong actions. This parameterization allows the sharp bisimulation to be tailored by the property under verification, whichever property of the modal $\mu$-calculus is considered, while potentially reducing more than strong bisimulation. Sharp bisimulation equivalence is a congruence for process algebraic operators such as parallel composition, hide, cut, and rename, and hence can be used in a compositional verification setting. In this paper, we prove that sharp bisimulation equivalence is also a congruence for action priority operators under some conditions on strong actions. We compare sharp bisimulation with orthogonal bisimulation, whose equivalence is also a congruence for action priority. We show that, if the internal action $\tau$ neither gives priority to nor takes priority over other actions, then the quotient of a system with respect to sharp bisimulation equivalence (called sharp minimization) cannot be larger than the quotient of the same system with respect to orthogonal bisimulation equivalence. We then describe a signature-based partition refinement algorithm for sharp minimization, implemented in the BCG_MIN and BCG_CMP tools of the CADP software toolbox. This algorithm can be adapted to implement orthogonal minimization. We show on a crafted example that using compositional sharp minimization may yield state space reductions that outperform compositional orthogonal minimization by several orders of magnitude. Finally, we illustrate the use of sharp minimization and priority to verify a bully leader election algorithm.

Appendices

Appendix A: Detailed results on RERS 2019

The following table gives, for each problem of the “parallel CTL” category of the RERS 2019 challenge, the size of the LTS obtained using the partial sharp reduction described in [32] and the size of the LTS obtained using sharp minimization. The last column indicates the reduction rate (in number of states) obtained using minimization with respect to partial reduction. Each problem consists of the number of a model (from 101 to 109) and the number of a property that depends on the model (from 01 to 20). In each case, the set of strong actions is determined by the property, so that its preservation by sharp bisimulation can be ensured.

Problem	Partial reduction		Minimization		Extra reduction
	#states	#trans	#states	#trans	(% states)
101#01	10	23	6	11	40 %
101#02	5	8	5	8	0 %
101#03	10	23	10	23	0 %
101#04	5	9	5	9	0 %
101#05	3	6	3	6	0 %
101#06	9	10	8	18	11 %
101#07	26	63	26	63	0 %
101#08	9	19	9	19	0 %
101#09	7	12	7	12	0 %
101#10	5	8	4	6	25 %
101#11	6	10	6	10	0 %
101#12	17	33	17	33	0 %
101#13	13	37	4	7	54 %
101#14	5	9	5	9	0 %
101#15	6	11	6	11	0 %
101#16	8	13	8	13	0 %
101#17	7	12	7	12	0 %
101#18	10	24	10	24	0 %
101#19	17	49	5	9	71 %
101#20	12	26	12	26	0 %
102#01	9	20	6	11	33 %
102#02	16	40	9	18	78 %
102#03	5	9	5	9	0 %
102#04	12	24	7	12	42 %
102#05	16	33	10	17	38 %
102#06	4	7	4	7	0 %
102#07	4	9	4	9	0 %
102#08	7	11	7	11	0 %
102#09	7	12	7	12	0 %
102#10	6	15	6	15	0 %
102#11	3	5	3	5	0 %
102#12	5	9	5	9	0 %
102#13	5	8	5	8	0 %
102#14	8	16	6	11	25 %
102#15	16	29	9	14	44 %
102#16	3	4	3	4	0 %
102#17	9	15	9	15	0 %
102#18	4	5	4	5	0 %
102#19	8	16	8	16	0 %
102#20	7	11	7	11	0 %
103#01	8	13	5	7	38 %
103#02	6	12	6	12	0 %
103#03	3	6	3	6	0 %
103#04	4	6	4	6	0 %
103#05	6	12	6	12	0 %
103#06	6	11	5	9	17 %
103#07	6	12	6	12	0 %
103#08	5	8	5	8	0 %
103#09	51	154	21	55	59 %
103#10	5	10	5	10	0 %
103#11	10	16	7	10	30 %
103#12	10	24	8	16	20 %
103#13	7	13	7	13	0 %
103#14	5	9	5	9	0 %
103#15	6	10	6	10	0 %
103#16	4	7	4	7	0 %
103#17	6	12	6	12	0 %
103#18	8	19	8	19	0 %
103#19	4	6	4	6	0 %
103#20	3	6	3	6	0 %
104#01	25	48	5	6	80 %
104#02	6	8	6	8	0 %
104#03	9	12	9	12	0 %
104#04	7	9	7	9	0 %
104#05	34	74	6	8	82 %
104#06	16	31	6	8	63 %
104#07	13	21	8	10	38 %
104#08	16	34	4	6	75 %
104#09	10	16	6	8	40 %
104#10	4	6	4	6	0 %
104#11	55	110	15	24	73 %
104#12	14	27	5	7	64 %
104#13	28	58	24	51	14 %
104#14	14	30	3	4	79 %
104#15	16	29	5	7	69 %
104#16	47	104	5	7	89 %
104#17	15	30	10	18	33 %
104#18	15	23	13	18	13 %
104#19	25	55	15	29	40 %
104#20	7	9	7	9	0 %
105#01	19	37	11	17	42 %
105#02	12	26	12	26	0 %
105#03	24	66	20	56	17 %
105#04	7	12	7	12	0 %
105#05	20	60	10	29	50 %
105#06	5	7	5	7	0 %
105#07	5	8	5	8	0 %
105#08	6	8	6	8	0 %
105#09	4	7	4	7	0 %
105#10	7	10	7	10	0 %
105#11	14	31	8	14	43 %
105#12	5	12	5	12	0 %
105#13	2	4	2	4	0 %
105#14	10	17	10	17	0 %
105#15	8	25	8	25	0 %
105#16	30	91	16	39	47 %
105#17	4	7	4	7	0 %
105#18	7	12	7	12	0 %
105#19	6	13	6	13	0 %
105#20	10	23	7	14	30 %
106#01	18	48	6	12	67 %
106#02	18	51	10	25	44 %
106#03	8	21	4	7	50 %
106#04	18	48	6	11	67 %
106#05	22	54	8	14	64 %
106#06	18	48	6	12	67 %
106#07	7	15	3	5	57 %
106#08	5	11	5	11	0 %
106#09	15	35	9	19	40 %
106#10	16	41	6	11	63 %
106#11	7	15	3	5	57 %
106#12	5	10	5	10	0 %
106#13	4	9	2	3	50 %
106#14	23	86	13	42	43 %
106#15	14	33	14	33	0 %
106#16	527	1314	3	4	99 %
106#17	11	30	5	10	55 %
106#18	8	18	4	6	50 %
106#19	338	1085	5	11	99 %
106#20	14	36	6	12	57 %
107#01	1	2	1	2	0 %
107#02	99	247	8	13	92 %
107#03	71	192	6	10	92 %
107#04	86	221	8	13	91 %
107#05	86	279	7	16	92 %
107#06	29	69	3	4	90 %
107#07	1	2	1	2	0 %
107#08	269	829	12	25	96 %
107#09	30	70	4	5	87 %
107#10	72	223	12	31	83 %
107#11	71	264	6	17	92 %
107#12	46	100	7	9	85 %
107#13	29	70	3	5	90 %
107#14	102	287	16	40	84 %
107#15	99	233	8	12	84 %
107#16	43	124	4	7	91 %
107#17	44	99	5	8	89 %
107#18	29	70	3	5	90 %
107#19	32	81	5	11	84 %
107#20	85	234	7	13	92 %
108#01	1	2	1	2	0 %
108#02	6	15	6	15	0 %
108#03	11	27	8	16	27 %
108#04	11	21	9	15	18 %
108#05	3	4	3	4	0 %
108#06	16	35	8	13	50 %
108#07	7	15	7	15	0 %
108#08	15	41	11	31	27 %
108#09	22	68	22	68	0 %
108#10	22	61	10	18	55 %
108#11	4	5	4	5	0 %
108#12	3	5	3	5	0 %
108#13	4	8	4	8	0 %
108#14	8	22	5	12	38 %
108#15	4	5	4	5	0 %
108#16	5	8	5	8	0 %
108#17	6	13	6	13	0 %
108#18	15	30	11	19	27 %
108#19	4	11	4	11	0 %
108#20	9	19	8	15	11 %
109#01	93	386	9	26	90 %
109#02	1	2	1	2	0 %
109#03	207	763	10	24	95 %
109#04	105	396	9	24	91 %
109#05	106	296	8	15	92 %
109#06	53	205	5	13	91 %
109#07	68	156	8	12	88 %
109#08	68	251	6	16	91 %
109#09	27	64	3	4	89 %
109#10	53	141	5	9	91 %
109#11	27	65	3	5	89 %
109#12	14	53	2	5	86 %
109#13	1	2	1	2	0 %
109#14	28	91	4	7	86 %
109#15	69	213	8	18	88 %
109#16	145	485	13	29	91 %
109#17	28	108	3	9	89 %
109#18	17	58	5	10	71 %
109#19	27	64	3	4	89 %
109#20	66	178	6	10	91 %

Appendix B: LNT encoding of timestamp server

In this section we give some details about the LNT process that stores information about the timestamps of stigmergy variables. Specifically, for every pair of agents i, j and every stigmergy variable x, the process records whether the timestamp that agent i binds to x is greater, equal, or smaller than the one bound by j to the same variable. Since the LAbS semantics only cares about these comparisons, there is no need to store actual timestamps. We encode these comparisons as an LNT enumeration $\texttt {Comparison}$ with three values GREATER, SAME, and LESS. So, the process essentially has to maintain an $n \times n$ matrix of comparisons $M^x$ for each stigmergy variable x, and provide responses when queried about its contents.

Listing 3 shows a sketch of our implementation of the timestamps server. Notice that MatrixVar is the type of a 2-dimensional matrix associated to a single variable, whereas Matrix is the type of a 3-dimensional matrix composed of one MatrixVar for each variable. We use NVARS to denote the number of variables.

At first, the server initializes every element of M to SAME (line 3). Then, it enters a loop where it repeatedly sends M over the debug gate and handles a message from the environment. The send action does not affect the server in any way, and is only there to provide a richer counterexample to the user when it tries to model-check a property that does not hold.

As outlined in Sect. 7, the server accepts messages over two gates refresh and request. Gate refresh allows an agent i to ask for one of its own timestamps to be updated (lines 7–8). The server handles this request by calling a helper function refreshVar(M, x, i): this, in turn, updates M so that $M_{\texttt {i},j}^{\texttt {x}} = \texttt {GREATER}$ for every $j \ne \texttt {i}$.

Gate request, instead, allows an agent to retrieve the value of $M_{i,j}^{\texttt {x}}$ (lines 10–17). What actually happens, here, is that the server simultaneously offers all the contents of M over this gate. Since we force synchronization over request, the server will just wait for an agent to synchronize on one of these offers. After this happens, if the element $M_{\texttt {i},\texttt {j}}^{\texttt {x}}$ that was offered was GREATER, we need to perform some bookkeeping on M. Namely, this means that the receiver j has gotten a stigmergy message from i with a newer value of x than its own local one. According to the semantics of LAbS, then, j will update its value and timestamp to the ones in the message.

While the value update is handled within the Agent process, the timestamp update must be implemented in the server. This essentially amounts to setting $M_{\texttt {i},\texttt {j}}^{x}$ to SAME and then copying the column $M_\texttt {i}^{x}$ onto $M_\texttt {j}^{x}$. These operations are implemented by a helper function sync, not shown here.

Appendix C: LNT encoding of agents

The behaviour of LAbS agents is encoded into a parameterized LNT process Agent(id), where the parameter id is a unique numeric identifier. The structure of this process is shown in Listing 4. Similarly to the timestamp server (Appendix 2), Agent is composed of an initialization step (lines 5–6) followed by an event loop (lines 8–15).

The initialization creates two empty sets Zput, Zqry that will track pending stigmergy messages, and sets the agent’s state to its (potentielly nondeterministic) initial as described in the input specifications, implemented by the helper process InitAgent. The agent’s state includes its local stigmergy variables L and a set of local variables I that are not subject to stigmergic interaction, but may influence the agents’ link predicates.

The event loop allows the agent to perform an individual action, wait for another agent to make its move, and to send or react to a stigmergy message. Notice that this scheme also features an additional gate dead, which we omitted from the main text for sake of brevity. It will be used by the agent to signal whether it is in a deadlocked state.

Individual actions. Listing 5 shows the behaviours related to individual actions in more detail. These behaviours are guarded by a multi-party rendezvous on the tick gate. Every agent can always do nothing and allow a different one to act (line 2), or try and perform an action (lines 5–17). When multiple agents are all willing to make a move, the rendezvous will force the system to choose one.

Furthermore, an agent may only try to make a move if it has no pending messages (this is specified in the semantics of LAbS): the only if block at line 5 implements this rule by making this branch of the select deadlocked until the condition is met. Every individual action in the original behaviour is encoded into its own process action_$<x>$ (lines 8–14). These processes are always guarded by a condition on the pc variable: this variable is the program counter of the agent and tracks its execution point. Since LAbS also has guarded processes (like the $\ell\ \texttt{> id}\ \rightarrow \ldots$ one in Listing 1, lines 12–14), some of these actions may be further guarded by additional conditions. Thus, before getting to choose the next action to perform, we evaluate a function canProceed that tells us whether at least one of these guards can be satisfied (line 7). If this is not the case, we send the agent to a sink state where it endlessly performs a dead action to signal it is deadlocked (line 15).

Exchange of stigmergy messages. An exchange of a message is triggered by a rendezvous on either the put or qry gate. This, combined with the fact that actions over tick also require a multi-party rendezvous, guarantees that message exchange never overlap with each other or with individual actions. We only report the details about put behaviour, as the one for qry is quite similar. To propagate a variable, an agent must have at least one variable in its set of pending messages Zput: if this is the case, the agent may nondeterministically select one of these variables, offer it over put along with additional information, and remove the variable from Zput (lines 2–2). Each receiver, on the other hand, waits until a rendezvous on put becomes available (that is, until another agent s is willing to propagate: line 13). Then, it gets the appropriate timestamp comparison from the timestamp server, by means of a request transition (line 14). Finally, if the link predicate holds and the comparison value is GREATER, it overwrites its value for variable x with the one coming from the sender (lines 15–19). It also adds x to the pending propagation messages and removes it from that of pending confirmation messages, since receiving a new value is enough to conclude that the previous one was not up-to-date (lines 20–21).