Variable Dependency Graph

In order to describe how a control value is created, a graph representation of the dependencies between variables is generated, where variables and ports are represented as vertices and edges represent dependencies. For each instruction in an actor, where a variable is assigned a value from another variable, an edge is added to the graph between the corresponding nodes (a more detailed description in Paper 4). The individual graphs of the actors can be composed by adding edges corresponding to the FIFO connections of the CAL program.

By choosing the set of variables directly accessed by a specific guard expression form the graph and extracting the part of the graph which is reachable from these variables, a graph describing the exact generation of the control token that ends up in that guard is created. This graph is, however, rather complicated, as it includes every instruction that is executed when the action computes the control token. The graph is, for this reason, simplified to describe the relations in such a simple manner that it is easy to draw some conclusions from it.

A new simplified graph is generated, where, for each actor, the ports sending control tokens and the guards, are nodes with an edge to each state variable and port which is reachable from it in the original graph. Other variables that are not reached from these and local variables are removed from the graph. For the reachable variables, the only edges that are added to these are those to input ports or self loops. This is illustrated in Figure 3.6. From the simplified graph the dependencies and the complexity of the control token is easily identifiable. The types of control token generation in an actor can informally be divided in to three groups with different levels of complexity:

Galvanic Isolation The simplest form of control token is called galvanic

sending the control token to any input port, instead the connection is im- plicit in the sense that the input may decide which action is fired, but the input values are not directly used to create the control token. For a specific state of an actor, this type of control token is deterministic from the actor itself and the guards are always sufficient to schedule the composition. This is true because the control token is only used to schedule that specific actor and the guards of the actor are obviously strong enough for this purpose. Any potential control token generated from this actor only depends on input or the guards in the sense that it is generated as a result of which actions are fired.

A composition of two actors with this kind of a control token connection may include removing guards which depend on state variables in either of the actors. The control token may thus depend on control variables but those control variables may not depend on inputs. The value of this variable must

actor example ( ) IN ==> OUT : v a r i n t c o u n t := 0 a : action ==> guard c o u n t <= 0 do c o u n t : = 1 0 0 ; end b : action IN : [ i ] ==> OUT : [ o ] guard c o u n t > 0 v a r i n t s t e p ; do s t e p := i ; c o u n t := count−s t e p ; o := c o u n t+s t e p ; end end

Figure 3.6: Dependency graph simplification. Temporary variables such as step, i, and o are removed, and the edges of the graph are simplified to highlight the dependencies of a control value.

then be used to describe the state of the partition when the scheduling is performed.

Actors with this kind of control token dependency, can from the point of view of control tokens, always be composed. The obvious reason for this is that the control tokens entering a partition are directly used in guard expressions after which they are never used for scheduling again. Any other guard is only indirectly depending on the control token and may become enable as a result of which action was fired. For scheduling, this is a good situation, as the dependencies inside a partition are between action firings and not input values.

Shared Property A slightly more complicated type of control token prop-

agation is when there is an actual connection between a control token enter- ing the actor and the control token leaving the actor, but the generation of the control token is instant and completely done within an action firing. The control token may depend on input ports, but not on variables depending on input ports. This restriction has two benefits, first, the relation between the input value, the guard, and the output value, is simple. Second, the output control token only depends on the inputs read in that firing but not on inputs from previous firings.

The implication of this type of control tokes is that the guards checking the inputs of a composition must be proved to cover all the properties that affect the actors of the composition. Fortunately, the restrictions regarding how the control tokens are generated makes the verification simple. As there is no history of control tokens used, there is no need to verify properties of input sequences but only on individual control tokens. This fits well with formula (3.1) which can be verified for every pair of possible input values; this will be more closely discussed in Chapter 5.

Shared Information Path The third type of control information path

does not have any of the restriction of the two previous types. In the general case, it is difficult to analyze this kind of control tokens, as the value of the token may be a result of the history of inputs. By allowing the control path to include state variables, the propagation of control tokens through an actor is not necessarily purely the firing on an action, but the value of an input may reside in the actor between actor firings and be used at a later point to produce the output control token.

The main problem with this, is, that it is not anymore enough to ana- lyze single input tokens, but instead, sequences of inputs may be required. Composition of actors with this type of control token propagation is not performed, in the general case, as the control is more close to being part of the computations than simply propagating information. In some cases,

however, it is possible to transform the actor to correspond to the previous type, e.g. by merging actions that always fire in sequence and replacing state variables by local variables. In other cases, when a state variable with an unpredictable behavior is used to produce a control value, the state variable itself could be viewed as an input port, which then would move the behavior of the variable outside the analysis.

While some automation of the verification of the guard strengths regard- ing control tokens and transformations of the actors to allow this verification should be possible, it is outside the scope of this thesis. Instead this thesis focuses on showing what is needed to obtain correct models, and how this can be used to allow efficient composition of actors.