A source node with the standard semantics is active if condition (S2) is satisfied, while a sink node with the standard semantics is active if condition (S1) is satisfied. For source and sink nodes with routing semantics, the same applies in regard to conditions (R2) and (R1) respectively.
The behavior of each node can likewise be described by a constraint automaton. The be- havior of the Reo network then arises by the composition of the constraint automata that represent the behavior of the channels and constraint automata that represent the behavior of the Reo nodes. For example, the Reo network depicted in Figure 8.3b) exhibits the fol- lowing behavior. Data may enter the network at either nodeA or node B. The route node C ensures that only one of these ports is simultaneously active, as it chooses one of the channel endsC1andC2. The data is routed to one of the channel endsC3andC4 and thus to either
nodeD or E, i.e., one of the two FIFO1 channels if it is able to accept a new data item. NodeF can only be active if the upper FIFO1 channel is full, i.e., a data item may be read via channel endF1, and if the data item can be copied to both theF2 andF3 channel ends,
i.e., the source end of the synchronous channel to nodeH and the upper source end of the synchronous drain channel. As a consequence, the (data-aware) synchronous drain channel between nodes F and G ensures that data may only be read from both FIFOs simultane- ously and the data has to agree. The data-agnostic synchronous drain variant can be used instead, enforcing only the synchronization but not data equality between nodesF and G. When connected to some components via the open nodesA, B, H, I, the Reo network then coordinates the communication between the attached components in the described manner.
8.3
The modeling languages CARML and RSL
The purpose of the input languages CARML and RSL of Vereofy is then to provide a con- venient manner to model constraint automata and Reo networks. We provide here a brief overview of the main concepts, for a more detailed description we refer to [BBKK09, BKK]. A CARML module defines a component or channel by specifying an interface, i.e., a set of input and output data-flow locations, a set of local variables for the module with finite domains and a description of the transitions. It induces a constraint automaton with the data- flow locations in the interface. Each state of the constraint automaton then corresponds to a valuation of the local variables. Consider the module definition in Figure 8.4 of a customer from our initial example (cf. Figure 2.1).
First, a custom data type action_tis defined (line 1) to the singleton data domain {0},
representing an arbitrary signifying that the corresponding action is performed. Then, the interface in the form of data-flow locations which can pass data items fromaction_trepre-
senting the different actions that the customer can take is defined (lines 4–11). Lines 13–20 then define a local variablestatethat can take values from the specified, enumerated set
and is initially set to the valueWORKING. Lines 22–31 then describe the transitions in the
form of transition definitions. Each transition definition begins with a state guard, a propo- sitional formula over constraints on the current values of the local variables. The second part consists of an I/O-constraint, a concise description of the allowed activity at the data- flow locations and which will be formally introduced below. The third part of a transition
Chapter 8. Synthesis in the Reo and constraint automata framework 8.3. The modeling languages CARML and RSL
definition then consists of a list of assignments to the local variables. Variables that are not explicitly assigned a new value remain unchanged. Each transition definition in a CARML module then induces transitions in the constraint automaton from the states matching the state guard with a concurrent I/O-operation matching the I/O-constraint and with a target state that arises from the originating state by applying the corresponding state assignments. TheCustomerCARML module thus induces a constraint automaton matching the transition
system for the customer in Figure 2.1. Lines 34–52 in Figure 8.4 then provide analogously a CARML definition of the beverage machine, inducing a constraint automaton matching the transition system for the customer in Figure 2.1.
As noted above, we use I/O-constraints, propositional formulas over the activity of data- flow locations and the data items at the active locations to formalize sets of I/O-activity: Definition 8.5 (I/O-constraints). The abstract syntax of I/O-constraints over the setN of data-flow locations is given by the grammar
ioc ::= true A d(A) = x d(A) = d(B) ¬ioc ioc1∨ ioc2
whereA, B ∈ N and x ∈ Data. Each I/O-constraint ioc stands for a set of concurrent I/O-operationskiock ⊆ CION, defined as follows:
ktruek def = CION kAk def = c∈ CION : A∈ active(c) kd(A) = xk def
= c∈ CION : A∈ active(c) ∧ c(A) = x
kd(A) = d(B)k =def c∈ CION : A, B∈ active(c) ∧ c(A) = c(B)
k¬iock =def CION \ kiock
kioc1∨ ioc2k def
= kioc1k ∪ kioc2k
As for the data constraints, we derive the standard propositional operators and syntactic shorthand notations for data constraints. The notation{A1, . . . , An} with A1, . . . , An∈ N ,
is used as a shorthand that specified that exactly the listed data-flow locations are active, i.e., forVA∈NA∧VB∈N \N¬B with N = {A1, . . . , An}.
Atomic propositions and transition labels. State guards can be seen as atomic proposi- tions on the states of the induced constraint automaton. A CARML module can explicitly specify a list of atomic propositions by providing a corresponding state guard, allowing their use in formulas and objectives to concisely refer to these states. Likewise, a user of Vereofy can directly use state guards in formulas or objectives, as Vereofy generates the appropriate atomic propositions on-the-fly.
For transitions, CARML and Vereofy supports a similar concept of transition labels. After defining a list of transition labelsL = l1, . . . , lnin the interface part of a CARML mod-
ule, transition definitions can be marked with one or more of the transition labels using the label(li)keyword. All transitions in the constraint automaton induced by this transition
definition are then marked with exactly the specified transition labels.
At the constraint automaton level this can be encoded by introducing a fresh data-flow locationNli per transition label li. If there is a label(li)keyword in a transition defi-
8.3. The modeling languages CARML and RSL Chapter 8. Synthesis in the Reo and constraint automata framework
1 TYPE action_t = int(0,0); 2
3 MODULE Customer { 4 out: action_t work; 5 out: action_t wantCoffee; 6 out: action_t wantTea; 7 out: action_t requestCoffee; 8 out: action_t requestTea; 9 out: action_t takeCoffee; 10 out: action_t takeTea; 11 out: action_t complain; 12 13 var: enum { 14 WORKING, 15 WANT_COFFEE, 16 WANT_TEA, 17 REQUESTED_COFFEE, 18 REQUESTED_TEA, 19 WRONG_BEVERAGE 20 } state := WORKING; 21
22 state==WORKING -[ {work} ]-> state := WORKING;
23 state==WORKING -[ {wantCoffee} ]-> state := WANT_COFFEE; 24 state==WORKING -[ {wantTea} ]-> state := WANT_TEA;
25 state==WANT_COFFEE -[ {requestCoffee} ]-> state := REQUESTED_COFFEE; 26 state==WANT_TEA -[ {requestTea} ]-> state := REQUESTED_TEA;
27 state==REQUESTED_COFFEE -[ {takeCoffee} ]-> state := WORKING; 28 state==REQUESTED_COFFEE -[ {takeTea} ]-> state := WRONG_BEVERAGE; 29 state==REQUESTED_TEA -[ {takeTea} ]-> state := WORKING;
30 state==REQUESTED_TEA -[ {takeCoffee} ]-> state := WRONG_BEVERAGE; 31 state==WRONG_BEVERAGE -[ {complain} ]-> state := WORKING;
32 } 33
34 MODULE BeverageMachine { 35 in: action_t makeCoffee; 36 in: action_t makeTea; 37 in: action_t takeCoffee; 38 in: action_t takeTea; 39 in: action_t clean; 40 in: action_t suspend; 41
42 var: int(0,1) coffee := 0; 43 var: int(0,1) tea := 0; 44
45 // suspend action is always enabled (state guard is true) 46 -[ {suspend} ]->;
47
48 // clean machine if there are no beverages 49 coffee==0 & tea==0 -[ {clean} ]->;
50 coffee==0 -[ {makeCoffee} ]-> coffee:=1; 51 tea==0 -[ {makeTea} ]-> tea:=1; 52 coffee==1 -[ {takeCoffee} ]-> coffee:=0; 53 tea==1 -[ {takeTea} ]-> tea:=0; 54 }
Figure 8.4: CARML modules for the customer and beverage machine, corresponding to the transition systems in Figure 2.1.
Chapter 8. Synthesis in the Reo and constraint automata framework 8.3. The modeling languages CARML and RSL
for li, the data-flow location Nli is not active in the induced transition. For the compo-
sition of constraint automata these special data-flow locations are assumed to be unique to each constraint automaton and thus can not serve for synchronization in the product. Transition labels can then be used in I/O-constraints in formulas or objectives via the atom has label(li) to select all concurrent I/O-operations that are marked with the corre- sponding transition label.
Fairness conditions. To support the specification of fairness conditions for CARML mod- ules, we have extended CARML and Vereofy to specify fairness conditions on sets of con- current I/O-operations of a module. Vereofy supports the three usual fairness condition types, strong fairness (♦R −→ ♦G), weak fairness (♦R −→ ♦G) and uncondi- tional fairness (♦G), where R and G are sets of concurrent I/O-operations specified by I/O-constraints. An infinite sequence of concurrent I/O-operations is then said to be fair if it satisfies the conjunction of the fairness conditions of the CARML module.
In the CARML syntax, fairness conditions are specified using the fairness keyword, fairness(strong): R =⇒ G;
fairness(weak): R =⇒ G; fairness(unconditional): G;
whereR and G are I/O-constraints. Vereofy takes these fairness conditions into account dur- ing the verification and considers only the set of fair paths in the constraint automaton, i.e., those where the sequence of concurrent I/O-operations along the path satisfies the fairness conditions2.
RSL. A circuit definition in the Reo Scripting Language (RSL) is a recipe for the construc- tion of a Reo network from components, channels and Reo nodes. It provides the following basic Reo operations:
1. Instantiation of components, channels and Reo nodes. 2. Joining of channel ends, component ports and Reo nodes.
3. Splitting Reo nodes into two nodes, one source node where all the sink channel ends of the original node are joined and a sink node where all the source channel ends of the original node are joined.
To allow the parametrized construction of channels, i.e., building a FIFO buffer of sizek by connectingk FIFO1 channels, RSL supports control flow features such as script variables, loops and conditionals. When an RSL circuit is instantiated, the corresponding script is executed, finally resulting in a Reo network that can then be used as the basis for subsequent operations such as verification or controller synthesis.
Figure 8.5 lists an RSL script that provides the scenario for the beverage machine exam- ple and the resulting Reo network. The script consists simply of the instantiation of the two components for the beverage machine and for the customer. They are assigned names that allow references to their atomic propositions and local variables from formulas and
8.4. Synthesis of most general controllers in Vereofy Chapter 8. Synthesis in the Reo and constraint automata framework