Journal of Logical and Algebraic Methods in Programming

In this paper, we study a subclass of constraint automata with local variables. The fragment denotes an executable subset of constraint automata for which synchronization and data constraints are expressed in an imperative guarded command style, instead of a denotational style as in the coordination language Reo. To demonstrate the executability property, we provide a translation scheme from symbolic constraint automata to Promela, the language of the model checker Spin. As a proof of concept, we model in Reo a software deﬁned network circuit, and use the Spin model checker to verify that our model satisﬁes some temporal properties. © 2022 The Author(s). Published by Elsevier Inc. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).


Introduction
Over the past decades, the increasing complexity of software required massive investments from both academia and industry to improve the quality.Although capable of solving complex problems, current systems are a source of difficulties for developers and designers, as they both need a formal ground for specifying such systems and verifying the intricate structures ruling the interaction among inner components.The formal description of component-based systems has been one of the major interests of Luis Barbosa, who first realized how to combine parametric behavior into a calculus of statebased software components using monads, just like in functional programming languages [1].
In this paper, we continue Luis Barbosa work on component based systems using Reo as a language to specify interaction among components explicitly [2].In Reo, a bit of interaction among components is modeled as a connector that constrains the data flowing at their ports.Formally, a connector is a relation over the set of ports in its interface that specifies which stream of data is allowed.Generally, connectors are built compositionally, using few synchronous and asynchronous primitive connectors that compose into more complex ones [3].A state-based specification of a connector as an automaton with constrains enables reasoning, verifying, and eventually simulating the behavior of a coordinated system.An instance of such state-based specification first appeared in [4] using constraint automata.An extension of constraint automata, adding memories [5], simplifies the specification of stateful connectors in the presence of data.However, the declarative nature of the constraints labeling transitions of constraint automata renders its translation to an imperative language (e.g., for simulation) difficult.
In our work, we consider an imperative subset of constraint automata with memory, that we call symbolic constraint automata.Intuitively, transitions in symbolic constraint automata are structured as guarded commands, where the command (i.e., an update of local memories and output port values) is executed only if the guard (i.e., a predicate on local memory values and input port values) is true.Contrary to declarative model of [5], we do not allow guards to act on output values or modify input values, reflecting the imperative nature of our work.The model is tailored towards an automatic translation to Promela, our main result of this paper.Our starting point is the work [6], where the authors define a Promela encoding of Reo ports, and give few examples of translations of simple Reo connectors, but leave open a systematic translation from Reo to Promela.In fact, our translation in itself is non-trivial as it requires the identification of a subset of constraint automata with memories, and the use of some control variables to circumvent syntactic restrictions in Promela.It is outside the scope of this paper to define a composition operator at Promela level compositionally reflecting Reo synchronization operator.We only show an example of composition of two connectors in Promela pointing in that direction.
Our translation of connector specifications to Promela enables the use of the Spin [7] model checker to verify temporal properties of components.Spin is a powerful model checker that can simulate and verify complex concurrent systems.For instance, it has been used for verifying spacecraft control systems [8] and avionics systems [9] and also Internet communication protocols.In fact, as a proof of concept, we apply our framework on a Reo model of software defined networks.In particular, we consider a network with a switch, programmed by a controller, that acts as a firewall by forwarding only permitted messages to one or more hosts.The switch is modeled by a symbolic constraint automaton, while the host and the controllers are modeled directly as Promela processes.We use our translation to obtain a specification of our system in Promela, that we verify against some liveness properties.
We proceed as follows.In Section 2 we introduce symbolic constraint automata, their semantics, and their composition.We give few examples of standard Reo connectors and of their composition.Section 3 describes the translation from symbolic constraint automata to Promela.In Section 4 we present our case study based on a software defined network architecture.We conclude the paper with few related works and a summary.

Symbolic constraint automata
In this section, we give a brief overview of some Reo connectors before presenting their encoding as a symbolic constraint automata.Also, we show how the composition method of Reo applies to symbolic constraint automata.
Reo is a coordination language used in component-based systems where components communicate through (stateful) connectors.A connector imposes data and synchronization constraints on the data flowing at its ports by allowing data to move from input ports to output ports only when all constrains are satisfied.Two connectors may share the same port name, but with different input/output polarity, in which case the data flowing at that port must be equal in both connectors.By sharing ports, connectors compose to form more complex circuits.
Reo also comes with a graphical syntax, that depicts connectors as graphs and compose connectors by merging nodes.For instance, Fig. 1 denotes a simple Reo connector modeling synchronous data flow.It connects a single input port A to a single output port B. The data received at port A is sent synchronously and without any modification to port B, thus blocking both components connected to A and B until the data flow takes place.More generally, a Reo connector can have more input ports, and output ports, and the constraints may be rather complex and conditional on the data received at (some of the) input ports.Connectors can be stateful, which means that a datum can be stored in an internal state hidden from other components.
The specification of a Reo circuit is compositional, and given by forming the product of each connector's specification.A primitive connector, e.g., a Reo channel, is usually specified using constraint automata [4].In that case, each transition is labeled by a synchronization and relational data constraints.Note that arbitrary primitive can be defined in Reo, which may involve arbitrary data constraints.Extensions of constraint automata with memories have been considered in [5].Still, data constraints remain declarative, as the expressiveness of the constraint language allows for arbitrarily complex label on transitions.In order to define an executable class of Reo circuits, we consider a subset of constraint automata with transitions labeled by symbolic guarded actions.We show that, under some simple consistency conditions, symbolic constraint automata can be implemented and systematically translated into the Promela language.In fact, most of original Reo basic connectors can be implemented, with as only exception filter channels with predicates that constraint output ports or transformer channels that update input ports.
The basic building blocks of a symbolic constraint automata include a finite set D of data ranged over by d, and a set V of variables, ranged over by x, y and z.We use variables to denote Reo ports shared between a connector and its environment, with different read and write permissions.An input port is a variable that the environment writes to (i.e., put a value into it), and from which a Reo connector destructively reads (i.e., take a value from it).Symmetrically, an output port is a variable that a connector writes to (i.e., put) and from which the environment destructively reads (i.e., take).Local variables are internal to a channel and can be used to store data.An assignment of variables to values is a function σ :V → D. We range over input, output, and local variables by i, o, and v, respectively.
To abstract from concrete actions, we use function symbols (ranged over by f ) and predicate symbols (ranged over by P ).As usual, each function symbol f comes equipped with an arity and coarity, i.e. the number of arguments it expects and it returns, respectively.Similarly, predicate symbols come with an arity.We assume the natural interpretation of such function and predicate symbols, as executable function on D n → D m and as decidable subset of D n , respectively.To simplify the notation, we use the same symbol to denote both the predicate and function symbols and their interpretations.Here, n is the arity and m the coarity.Syntactic substitution in a term t of every occurrence of variable x for a term t x is denoted as usual by t[t x /x].
Terms of symbolic constraint automata are defined by the grammar: Terms denote tuples of data values.Here the (local or port) variable x denotes the data value it stores, while t is a shorthand notation for a finite sequence of terms t 1 , . . ., t n , and f ( t) represents a tuple of values resulting from the computation f when executed with input values t.The size of these tuples depends on the arity and coarity of f .A guarded action α consists of a predicate and an assignment, P (x) → ȳ := t .
We call P (x) the guard of the guarded action α, and ȳ := t the action that is executed when the guard is true.In general, we refer to the guard of a guarded action α by g(α), and the assignment at the right-hand side of α by a(α).We implicitly assume that the size of ȳ corresponds to the coarity of t.To avoid problems with simultaneous assignments, and without loss of generality, different variables may occur only on the left-hand side of the assignment in an action.This way, for z ∈ ȳ, we can denote by a(α) z the z-projection of the tuple of values resulting from evaluating the term a(α).
Given finite subsets I, O , and V of V denoting some input, output, and local variables, respectively, let Act(I, O , V ) be the set of actions α such that all variables occurring in g(α) are in I ∪ V , all variables on the left-hand side of the assignment in a(α) are in O ∪ V , and all variables on the right-hand side of the assignment in a(α) are either in V or occurring in g(α).The idea is that a guard g(α) constrains what value input may take, based on the current value of its local variables and pending values supplied by the environment.If the guard holds then the right-hand side of a(α) can be satisfied using values from the local variables and values given by the environment on its inputs.The result is assigned to the variables on the left-hand side of a(α) changing the local store and communicating the result of the computation to the environment via the output variables.Since output ports are only used to communicate a value to the environment, we assume no occurrence of them on the guard g(α) and in the term on the right-hand side of the assignment a(α).Dually, since input ports receive values only from the environment, we assume no occurrence of them on the left-hand side of the assignment a(α).We denote by I(α) the set of all input ports occurring in α.Similarly, we denote by O (α) and V (α) the sets of output ports and local variables, respectively occurring on the left-hand side of the assignment in α.All input ports occurring in a(α) must appear in the input of the guard g(α).The text x = x denotes a guard that is true, and an assignment x := x denotes the skip action.We often do not write them in a transition unless the context requires it.
For example, the guarded action (i ) is an action in Act(I, O , V ), with I = {i}, O = {o} and V = {v}.But the guarded action (i ≤ v → (o, i) := [i, o]) is not because i and o appear both on the left-hand side and on the righthand side of the action, respectively.Here [−, −] is the pairing function, with arity 2 and coarity 2, mapping two inputs into their corresponding pair of values.Definition 1.A symbolic constraint automaton is a tuple (Q , q 0 , I, O , V , −→), where • Q is a finite set of states including the initial state q 0 , • I ⊆ V is a finite set of input ports, O ⊆ V is a finite set of output ports, V ⊆ V is a finite set of local variables such that they are mutually disjoint, i.e.,

transition relation between states and labeled by actions in Act(I, O , V ).
A transition q α −→ q denotes the possibility of executing the action α from the state q and moving to the state q .In order for the actual execution of α to take place, the guard of the action α must hold upon evaluation in the current state.
To simplify the notation, we will not write guards of actions that are always true.Note that, differently from [5], we do not need to specify pre-and post-values of a local variable, as our actions are imperative and thus the order is implicitly given by the assignment operator.
In Fig. 2, we show three symbolic constraint automata.The one on the left has no internal state, and the data received at the input port i is synchronously passed to the output o.This connector is called in Reo a synchronous channel and is depicted as in Fig. 1.The one in the middle has three variables: one input variable i, one output variable o, and an internal variable v.The automaton has two states: state 0 to indicate that the internal variable can be rewritten (i.e., the buffer is empty), and state 1 to indicate that it cannot (i.e., the buffer is full).The connector assigns to v the value taken from i if it is in the empty state 0, and puts to the port o the value from v if it is in the full state 1.The two states symbolic constraint automaton is simpler than the equivalent single state automaton (see Fig. 3), as it avoids guards on the internal variable and the use of an extra special value ⊥ to indicate that a variable is 'empty'.This connector is called a Fifo1 channel in Reo.Finally, the rightmost automaton has a non-trivial guard labeling each of its two transitions.If the predicate P holds when a value is available at an input port i, then the connector behaves like a synchronous connector and passes the input value to the output port o.Otherwise, ¬P holds on the value of i and the value is taken from i and lost, meaning that the component waiting for a synchronization on port i is released.An execution of a symbolic constraint automaton (Q , q 0 , I, O , V , −→) is given in terms of an infinite sequence (σ i ) i∈N of assignments of values to variables for which we can find an infinite sequence of states (q i ) i∈N starting from the initial state q 0 and such that for all n ≥ 0 there is a transition q n α −→ q n+1 satisfying the following three conditions: 1. the interpretation of the guard g(α) holds in the assignment σ n , 2. for all x ∈ O (α) ∪ V (α) the value σ n+1 (x) is the x-projection of the evaluation of the variables on the left-hand side of the assignment in a(α) in the state σ n , that is σ n+1 (x) = σ n (a(α) x ); 3. for all variables not involved in the guarded action α, the value does not change, that is, σ n+1 (y) = σ n (y) for all Consecutive assignments σ n and σ n+1 in a sequence represent the change of the internal and observable state of the system.
The above conditions guarantee that the guard must hold on the values assigned to input variables in the current state before an action is taken, and that, after execution of an action, the output variables and the local variables involved in the action change according to the action taken.The last condition guarantees that only variables that occur free in an action get modified (for example by the environment) when executing that action.Note that after the execution of an action, input variables in I(α) change to a new value assigned by the environment.Dually, the value assigned to an output variable before the execution of an action is presumably taken by the environment before the new output value, assigned by the action, overwrites it.In other words, a transition in symbolic constraint automata, likewise constraint automata, assigns values to its output and local variables while is constrained on input and local variables.Also, the environment is allowed to change the values assigned to other variables not declared in the automaton, i.e., any variable in V \ (I ∪ O ∪ V ).This represents the effect of an independent action executed by the environment in parallel with the automaton.
Local variables are used to store externally unobservable information.Only communication via input and output ports should be observable.Therefore, we define the semantics of a symbolic constraint automaton as the set of all possible executions (σ i ) i∈N defined as above, but projected only on their input and output variables.As usual, two automata are then equivalent if they have the same semantics, i.e. they generate the same set of finite traces of assignments of input and output variables.
Consider the symbolic constraint automaton in Fig. 2.(b).The following is an example of a sequence of assignments recognized by that automaton: Initially, the automaton is in state 0, for example, with value 1 on the input port i.The values of the two other variables do not matter at this point, and can be seen as previous values that remained stored but not accessible.By taking the transition to the state 1, the connector assigns the value of i to the internal variable v.The output port o is blocked and cannot be changed while executing this transition, while the input port is free and here is assumed to get the value 2 from the environment.When taking the next transition the content of the variable v is put in the port o, the input is blocked and the cycle can start again.For each such a sequence we can find an equivalent sequence for the automaton in Fig. 3, by using the extra value ⊥ to check if the buffer is empty Conversely, for every sequence representing the behavior of the automaton in Fig. 3 we can find an equivalent sequence of assignments for the automaton in Fig. 2.(b) by copying the previous value of v instead of ⊥, and assigning an arbitrary initial value for v.In other words, the two automata are equivalent.Note that the initial state of the automaton in Fig. 3 forces the connector to start with an empty buffer.Without this initial transition, the two automata would not be equivalent as one could start to output on port o the value stored in v.
The central operation on symbolic constraint automata is synchronization via their shared ports that are input ports for one automaton and output ports for another.Shared ports become internal local variables in the automaton resulting from the composition.No other synchronization by shared variables is allowed, as local variables are only visible within the scope of a connector.Our definition is similar in spirit to that of [5], but, in addition to that work, our symbolic constraint automata could be automatically translated to Promela.The explicit input and output variables, and the guarded command structure on the label impose some prerequisites on the product to avoid inconsistencies.In fact, we define composition only for pairs of symbolic constraint automata A 1 and A 2 such that (1) no local variables are in common, and (2) for every pair of actions α 1 and α 2 of the two automata, they synchronize only on some input ports used by one action and some output ports used by the other, but not on both input and output ports at the same time.More formally, we assume that, for all actions α 1 labeling a transition in A 1 and α 2 labeling a transition in A 2 , the following holds We call two automata with these two properties consistent.The intuition behind synchronizing two guarded actions α 1 and α 2 is that their data value should agree on their shared ports so that it can flow from the output of one to the input of the other actions.The above condition together with the fact that the two automata do not share local variables -and thus fact impose a causality in the execution of their actions as input is needed to update the internal state and to be passed to output ports.Next we define formally the synchronization of two guarded actions α 1 and α 2 .
Assume I(α 1 ) ∩ O (α 2 ) = ū = ∅, and let where x1 ∪ ū is the sequence of input and local variables occurring in P 1 , z1 ∪ ū the sequence of input and local variables occurring in t 1 , and ȳ2 ∪ ū the sequence of output and local variables occurring at the left-hand side of the assignment a(α 2 ).Note that variables in ū cannot occur in P 2 nor in t 2 as they are output variables for α 2 .Similarly, they cannot occur in ȳ1 , as they are input variables for α 1 .By definition of guarded action, they can occur in P 1 .Under these circumstances, we can define the synchronization α 1 ⊗ α 2 as the following guarded action Since the guard P 2 does not depend on output variables, we can evaluate it.If it holds we can then assign the values returned by t 2 to the output and local variables at the left-hand side of a(α 2 ).The values assigned to the shared output values ū are then used in P 1 as constant replacing the input variables ū.If this predicate holds, then the same substitution is applied to t 1 so that we can compute the assignment.Note that ).The definition of α 1 ⊗ α 2 for the symmetric case when O (α 1 ) ∩ I(α 2 ) = ∅ is similar.
Definition 2. Without loss of generality, let Q 1 and Q 2 be two disjoint sets of states, and V 1 and V 2 be two disjoint sets of local variables.The composition of two consistent symbolic constraint automata where: , and • −→ is defined by the following rules: Similar to the join operation on constraint automata the above synchronization operation on symbolic constraint automata synchronizes actions on shared ports and allow independent parallel behavior for actions with no shared ports.The composition of consistent symbolic constraint automata is symmetric and, when defined, associative.More examples of symbolic constraint automata can be found in the Appendix.

From Reo to Promela
Promela is a formal language [10] widely used to specify concurrent systems and is supported by Spin, an LTL model checker.A Promela program is composed of a set of processes.Processes run concurrently and interact through shared channels.Both synchronous and asynchronous communication between processes are supported.For synchronous communication, a channel works in a rendezvous mode with no buffer (zero capacity).For asynchronous communication, channels work as a Fifo buffer with a non-zero user specified capacity.
Spin is a model checker with Promela as specification language.In a nutshell, each Promela process is transformed by Spin into a finite state automaton.Processes are then synchronized into a single system automaton.Similarly, linear temporal properties expressed in the usual LTL syntax, are transformed into finite state automata.The automata representing both the Promela program and the LTL properties are exploited by Spin to verify and assert satisfaction of the properties [10].
Building on the work presented in [6], we translate some Reo connectors into Promela programs.We use symbolic constraint automata as a specification of Reo connectors, and use the resulting Promela process as a protocol to coordinate messages exchanged through the ports of other processes.

Implementing Reo ports in Promela
In Promela, a Reo port is expressed as a structure, as shown in Listing 1.It contains two Promela channels of capacity one: a data and a trig channel.A port in Reo is directional.We call putter the component that puts an element on the port, and getter the component that gets an element from the port.Operations on a port are blocking unless both a put and a get are performed at the same time.In which case the port fires, and the data is forwarded from the putter to the getter.
The data channel in the Promela implementation of a Reo port is used to forward the data message from the putter to the getter, while the trig channel is used to synchronize the putter and the getter.The reason of using two channels of size one instead of a rendezvous channel of size zero is that it is impossible in Promela to query whether a process is currently waiting on a rendezvous channel.We will later see that querying the state of a port is necessary for the protocol to coordinate the boundary processes.As described in Listing 2, two actions can be performed on a port: put and take.The function call put(q, a) atomically fills the data channel of q with the datum a, and blocks on the trig channel, waiting to synchronize with the component on the output side of q.The integer variable x is used to get a value from the trig channel, and hence to synchronize to it; the actual value communicated does not matter.
The function call take(q, a) atomically notifies, by outputting on the trig channel, that there is a component willing to take data, and blocks on the data channel, until a datum can be read and stored into the variable a.The integer value of −1 written into the synchronization channel is arbitrary, as trig is used only for signaling.
We describe two temporal properties in Listing 3 that reflect the synchronous behavior of a port.We say that a port fires whenever a data is exchanged between the putter and the getter.If a port does not fire, it is silent.In the case of an implementation of a port with two buffers, the firing property occurs whenever a port has both an input and an output request, i.e. both channels are full.We then know, due to the definition of the put and take operations, that the putter and the getter will be released from blocking on the port, and the getter will get the value from the data channel.We define some macros in Listing 3 to encode firing and silent property of port p as an LTL property.
Ports are not typed as input or output, as that depend on the component/connector that use them.We have seen in the previous section that within a connector, a port used in a guard must be an input port, whereas a port used on the left-hand side of the assignment of an action is an output port.

Implementing Reo connectors in Promela
Next we describe how to implement Reo connectors expressed as symbolic constraint automata in Promela.Let A = (Q , q 0 , I, O , V , −→) be a symbolic constraint automaton.
A symbolic constraint automaton is encoded, in Promela, as a proctype.A Promela proctype has a name, a signature, and a body.The Spin model checker executes each proctype of its main concurrently, while taking into account blocking operations on channels.As we will see, input/output variables of a symbolic constraint automaton lead to shared port channels in Promela between the protocol and the boundary processes.
Input ports I and output ports O are passed as parameters to the Promela process resulting from the translation.As expected, local variables in V are declared locally to the Promela process, i.e., within the proctype body.For each port P ∈ I ∪ O , a new local variable _p is declared so to store the value taken, if P is an input, or passed, if P is an output.We use mytype as a generic type for input, output, and memory variables.
Each state in Q is encoded as a special value for the state variable.The state variable therefore models the control flow between the states of the automaton.For simplicity, and without loss of generality, here we assume that q 0 = 0 is the initial state and Q = {0, 1, . . ., n}.
We use the Promela non-deterministic do − od construct to model concurrent applications of transitions of a symbolic constraint automaton.The guard (respectively, the command) of the statements in the do − od results from the translation of the guard (respectively, the command) in the action labeling the corresponding transition.As a result, each guard in the do − od loop contains a clause that controls that variable state has the value corresponding to the pre-state, and updates the value to the post-state in the command.The Promela language allows for non-destructive reads of channel's value: the operation A.data? < _a> assigns to the variable _a the value stored in channel A.data without actually removing the values from that channel.However, in Promela, this operation cannot be executed in a guard within a do − od statement.We circumvent this problem by using a control variable f i for each transition t i ∈−→ of the automaton.The variable f i can take two values.By default, f i is 1.If the synchronization constraint of the guard of the i-th transition is satisfied but the data constraint is not, then the value of f i is set to 0. Every transition, if taken successfully, resets all the f i to 1.
More formally, for a symbolic constraint automaton (Q , q, I, O , V , −→) we show in Listing 4 its translation to Promela: Here Q = {0, . . ., n}, q = 0, P = I ∪ O , v = V , and the remaining overlined variables are just consecutive sequences of them.For every (input or output) port p ∈ P there is a variable _p associated with it on which we store the value communicated via the port.The control variable state is used to store the current state of the automaton (thus it ranges between 0 and n), and variables {f1, . . .fk} are used when evaluating predicates on values received at input ports.Here k is the number of transitions.Let q α − → q be the j-th transition of the symbolic constraint automaton, with 1 ≤ j ≤ k, and remember that the input ports in α are I(α) = {i1, . . ., im} the output ports are O (α) = {o1, . . ., ol}, and the local variables occurring in α are {v1, . . ., vh}.Then transition j in the listing above is given by state==q && fj==1 && where P is a function encoding the guard of α and A is a function encoding the assignment action of α.When the control variables are not used in a transition (for example because there is no predicate on input variables), then it is possible to simplify the generated Promela code by removing such control variables.Similarly, when there is only one state, the variable state can be removed as its value is constant.In the Appendix, we show more examples of standard Reo connectors encoded as symbolic constraint automata and translated to Promela.It is important to remark that the control variables f i do not introduce fairness or priority among the transitions, they only control the flow so that Promela will not choose the same transition again with a guard that has already been evaluated to false.
We list several examples of translation of symbolic constraint automata to Promela.Listing 5 gives the Promela code resulting from the translation of the symbolic constraint automaton in Fig. 2 Here the parameter port A is the input port of the Sync channel and port B is the output port.There are no local variables except those associated with the ports, and the control variable state that we will discuss later.The condition full(A.data)&&full(B.trig) is satisfied if and only if there is an ongoing put(A, a) operation on the input port A and an ongoing take(B, x) operation on the output port B. In this case, the Sync process atomically takes the data from port A, stores it in a local variable _a, executes the action of the associated transition of the symbolic constraint automata, i.e. _a = _b, and puts the value in port B. Of course, the single state automaton of the Sync connector could have been modeled by a much simpler Promela process without such an extra variable, but, as for the other connectors, we keep it for generality.
Listing 6 shows the Promela code for a two states symbolic constraint automaton of the Fifo1 Reo connector given in Besides an input and an output port, this time we also have a local variable v for the buffer of the Fifo1 connector.The control variable state is initially set to 0, corresponding to the initial state of the automaton.This time, the do − od loop contains two transitions, one for each transition of the symbolic constraint automaton.One statement corresponds to the transition that moves the control from state = 0 to state = 1 if there is a pending data on the input port A. The value is then taken and assigned to the local variable v.The other statement corresponds to the transition that moves the control from state = 1 to state = 0 when there is a pending request at the output port.In which case, the stored value is forwarded to the output port B.
Next, we show how to translate the Filter connector of Fig. 2.(c) that, unlike the other two examples, contains two transitions labeled with a non-trivial predicate on the input variable.The Promela code of the Filter connector is presented in Listing 7.
Initially the control variables f1 and f2 associated to the two transitions are set to true, meaning that any transition can be potentially selected.As before, the satisfiability of each guard depends on the presence of some data at the input port A and the presence of some signal at the output port B. The predicate P is evaluated only after one of the two statements of the do − od loop is chosen.If true, the action of the transition is taken and the two control variables f1 and f2 are reset to true.Otherwise the value of the associated control variable fi is set to false and the control goes back to the loop statement.In this way the i-th transition associated with fn will not be selected anymore, even if all other predicates in the guard of the statement are true (for i = 1, 2), which removes some undesirable livelocks.We leave for future work a detailed description of the encoding in Promela of a composition operator mimicking that of symbolic constraint automata.We just give an example below corresponding to the composition of the Promela code generated for the Fifo1 and the Filter connectors in Listings 6 and 7, respectively.

A case study: verifying a software defined network
In this section, we apply our translation of symbolic constraint automata to Promela on a software defined network model, and use the Spin model checker to verify several temporal properties.We use the model of software defined networks introduced in [11], where all components of an SDN are represented as Reo connectors, and thus as symbolic constraint automata.The model is stateful and reflects the SDN separation between switches, controllers, and network.For each part, we briefly describe the Promela code obtained from the Reo components, and how we model the basic data flow operations of an SDN: PktIn, PktOut, FlowMod.

Preliminaries
An SDN consists of three planes: the application plane, the data plane, and the control plane.The data plane contains switches and the network infrastructure for distributing and receiving packets.The control plane consists of a set of operations that can be used to program the network switches.In short, the control planes are formed by a set of reactive controllers that communicate with the switches to program the behavior of the network.Controllers receive packets from the switches via the PktIn command, and send messages to them via the PktOut and the FlowMod commands.The former consists of a packet together with the set of ports of each switch the packet needs to be sent, the latter is used to update the flow table of the switch.A flow table is a list of pairs matching-action, where matching is a predicate evaluated on the header of incoming packets, and action is a set of ports where the packets need to be forwarded to after the  matching.When the set of ports is empty, the packet is dropped.Unlike traditional switches, a flow tables in an SDN can be dynamically updated via FlowMod operations.
In [11] we presented a generic SDN model built with a set of stateful and typed Reo connectors.Here we briefly summarize the model of a switch and refer the reader for more technical details to the original work.The Reo circuit of a SDN switch given in Fig. 4 is parametric on the input ports P i , i ∈ {0, . . ., n} and output ports Q j , j ∈ {0, . . ., m}.It is composed out of several transformers and filter channels that add relevant information and route the packets received at input ports to the right output port.The core of the switch is the flow table, here represented by the τ in the variable channel.The table can be updated by FlowMod operations or simply consulted for routing packets.Switches are connected with SDN controllers via synchronous channel between P 0 and the output port of the controller, and a bounded queue channel between Q 0 and the input port of the controller.FlowMod and PktOut messages are received by the switch at port P 0 and normal packets are received from all other input ports.PktOut messages need not be evaluated by the flowtable and can immediately be redirected to the relevant output ports, whereas FlowMod messages follow another route and will update the flow table.Normal packets are evaluated according to the rules in the flow table τ , and accordingly they will be either deleted or sent to one or more output ports.PktIn messages are generated after the evaluation of packets at the flow table and redirected to the controller via the output port Q 0 , for example to request a table update.

A Promela SDN model via symbolic constraint automata
Next we briefly describe the generated Promela code for the Reo model of a switch Switch(P0, P1, P2, Q0, Q1, Q2) with two input ports P1 and P2, two output ports Q1 and Q2 as shown in Fig. 5.As explained above, those ports form the interface of the switch with the rest of the network.Additionally, the switch interface is extended with an input port P0 and an output port Q0 that serve to exchange flow messages with the SDN controller that we can model directly in Promela code.Flow messages from the controller Controller(P, Q) to the switch are exchanged synchronously, via the synchronous connector Sync(P, P0).On the other direction, flow messages are exchanged asynchronously via a queue connector Queue(Q0, Q) from the port Q0 of the switch to the port Q of the controller.
Informally, the symbolic constraint automaton of a switch consists of a single state and few transitions labeled by the following type of guarded actions: • α 0 is executed when a FlowMod message is received from the input port P0.The action here consists in updating the flow table according to the information sent by the controller.
• α 1 is enabled when a PktOut message is received by the switch from port P0.The resulting action forwards a packet to a subset (possibly empty) of output ports of the switch.This subset is contained in the PktOut message from the controller.
• α 2 is enabled when one of the input port P1 or P2 of the switch receives a normal packet that is then forwarded to a subset (possibly empty) of output ports according to the current information in the flow table of the switch.
The Promela code of the switch obtained via the translation from a symbolic constraint automaton is presented (in a simplified manner for reason of space) below.The full code and the results of its verification can be found in [12].

... od}
Each transition synchronizes some of the actors in a network (hosts, switches, controllers).Packet forwarding is done on the basis of the result of a function Match() of the Reo transformer channel between ports D and E in Fig. 4. Another non-trivial function used here is update(), belonging to the transformer between ports F and E in Fig. 4 and used to model a FlowMod operation.
In our case study as described in Fig. 5, the network consists of a switch programmed by a controller, where hosts A and B produce packets, and hosts C and D consume them.We abstract from the specific behavior of the hosts and model them simply as producers and consumers of messages, respectively.proctype HostA(port A){ packet p1; atomic{p1.header= 11; p1.ipt = P1; put(A,p1)} } Host A produces a single packet that is sent to port P 1.Here we assume a packet contains a header (with information such as the tcp/ip source or destination), and the port of the switch it is supposed to be received directly from the host.Finally we give the Promela code of the controller.The controller takes a packet from port Q if available.If the packet originally passed through port P 1 then the controller adds a rule in the flow table to forward similar messages (i.e., coming from the same address as in the header) to port Q 1. Packets with header 22 need to be forwarded to both ports Q 1 and Q 2 (thus to hosts C and D).Finally, the following firewall is installed: packets with header 11 that have passed through port P 2 must be dropped.Note that the controller will insert rules into the flow table of the switch to execute the above commands, and will apply the action itself only the first time a packet is not matching any rule in the flow Port Q of the controller is linked to the output port of the queue connector Queue(Q0, Q) which may store at most 10 packets.This number is reasonable as we do not expect many PktIn messages to be forwarded to the Controller.Intuitively they say: The message of host A will receive B (no loop holes) and always, if B sends a 22-message, then both eventually C receives a 22-message (but not necessarily the same one), and eventually the same for D. Assuming that only B sends 22-messages then this means that every message with header 22 received from hosts C or D is originated from host B. Fig. 7 describes the scenario when the packet from host A is received at the switch.As the flow table of the switch is empty, the switch forwards the packet to the controller.However, the packet with the same header arriving from B is dropped.Of course, if the packet B arrives at the switch after the updates of the flow table due to the first message from host A, then the packet of B will match the flow table and be redirected to host C , violating the firewall rule.We can verify this formally in Spin via the following LTL property:

Verification and simulation
prop3 {<>(msg1.header==11)&&(<>[](HostC_counter==1))}/* unsatisfied */   This property together with the code of the three hosts A, B and C , states that there is a state in the system where a packet with header 11 is received (either from host A or B) and eventually C receive a message with header 11 and no other such a message afterwards.
We use the Spin model checker to verify the three LTL properties, with the following parameters: Extra Compile-Time Directives is set to 20700; the number of hash-functions in Bitstate mode to 5, and the Physical Memory Available to 102400 Mbytes.We used depth-first search with partial order reduction and Bitstate/Supertrace in order to achieve better performance [7].The results of the verification are shown in Table 1.
We simulate the results of prop3 with the first founded error written in the ".trail" file, the result of this simulation is shown in Fig. 8, where we see the packet forwarded by host B (here internally called prod2) to the switch (here called Protocol1).The flow table in the switch is updated successfully (see in action 25!11, 2) but soon the packet is dropped (see in action 25?11, 2).Before C (cons1) receive any other packets, the one sent from host A matches the new flow table (header = 11) and thus will be dropped (in action 1?11, 0) instead of being forwarded to C .

Related work
The first automata based model for Reo connectors appeared in [4] where constraint automata have been introduced.The authors define a product on constraint automata that implements the Reo composition operator on timed-data streams semantics [3].Since then, several other operational models followed, such as Büchi automata of records [13], guarded automata [14], and Reo automata [15].Those models extend constraint automata by allowing some context-dependent reasonings.See [16] for an overview of the main operational and denotational models of Reo.Constraint automata with memory and their composition have been thoroughly studied in [5].Our work is based on a similar model and semantics, but while we aim for finding a subset of it that can be easily implemented, the work in [5] concentrates on the efficient computation of the main composition operator.
Also model checking of Reo connectors has been a very active area of research.Vereofy is a dedicated model checker developed explicitly to verify linear time and branching time temporal properties of Reo connectors expressed as constraint automata [17].Vereofy, however does not allow for explicit data to be handled in the automata and properties.For this reason, in [18] the authors encode Reo connectors as communicating processes, and use μCRL2 to check some behavioral properties.The model checker μCRL2 [19], is based on Algebra of communicating processes [20] with properties expressed as formulas in the modal μ-calculus with strong and branching bisimulation as equivalences as well as strong and weak trace equivalence.UPPAAL is a model checker [21], for linear time temporal property of networks of timed automata [22].UPPAAL can perform reachability analysis, as well as simulation and error reports.See [23] for a recent use of UPPAAL to verify behavioral properties of real time Reo connectors.Our work differs from previous works on model checking Reo Connector in the following points.First of all, Spin is a data sensitive model checker.Contrary to Vereofy, we can verify temporal properties on connectors that involve data values and local memory.Second, our use of the Spin model checker is designed specifically to verify LTL properties of Reo connectors, contrary to the strong bisimulation equivalence used in proving equalities in the mCRL2 encoding of Reo channels in [18].Thus is more in line with Vereofy and the semantic basis of Reo that is trace based, without branching properties.In addition, the encoding of Reo described in [18] does not encompass memory.Finally, our translation into Promela differs from the above works in the use of atomic statements in order to enforce synchrony.Of course extension of our work to real time systems and UPPAAL are imaginable, and can be pursuit in the near future.All in all our work extends the literature by providing another tool chain to compile connectors to Promela and use the Spin model checker.
In [24], Ali Hussein et al. check network consistency properties in the model of SDN topology by using UPPAAL, the approach of them can detect an inconsistency or verify a flow in real-time.Elvira Albert et al. build an SDN model with barriers (which is Queue in our approach) in [25] by encoding it to language ABS based on top of the SYCO tool, then verify properties about safety policies and network loops.[26] uses Flow-LTL to specify the data flow in the extension of Petri nets with transits to check Petri Nets with transits by a hardware model checker ABC, and verifies concurrent updates and packets coherence in the network.

Conclusion
In this paper, we presented a full automatic translation from symbolic constraint automata to Promela.Symbolic constraint automata are a characterization of constraint automata with memory that can be used to compactly model almost all connectors of the coordination language Reo.In particular we restrict ourselves to an executable subset of Reo, assuming predicate and actions to be decidable.On the one hand, symbolic constraint automata cannot characterize relational constraint involving, for example, output ports in predicates.On the other hand, our symbolic constraint automata and their Promela translation easily allow for a generalization to lossy connectors by testing the non-presence of a trigger in an output ports before executing a lossy transition, as shown, for example, in the following Promela code for a lossy synchronous

Fig. 5 .
Fig. 5.A simple example of an SDN architecture.
.header = 11; put(B,p2)}; :: atomic{p2.header= 22; put(B,p2)} od } The above Promela code for host B is similar to that of A, except that host B repeatedly sends packets with header 11 or 22 to port P 2. Hosts C and D are consumers that repeatedly execute the take action from their ports C and D respectively.Once a packet is received, they update their own local counter storing the number of packets with header 11 that they receive.Below we show the Promela pseudocode of host C , that of D is similar.(C,q1); if q1.header==11 -> counter++;} od }

Fig. 6 .
Fig. 6.Packets from A and B arriving both to C .

Table 1
Verification results.