2.3.2 (Message) Sequence Charts
2.4 Communicating finite state machines (CFSMs)
2.4.2 StateCharts: implicit shared memory communicationcommunication
2.4.2.3 Edge labels and StateMate semantics
Until now, we have not considered outputs generated by our extended FSMs.
Generated outputs can be specified using edge labels. The general form of an edge label is “event[condition]/reaction”. All three label parts are optional.
The reaction-part describes the reaction of the FSM to a state transition. Pos- sible reactions include the generation of events and assignments to variables.
The condition-part implies a test of the values of variables or a test of the cur- rent state of the system. The event-part refers to a test of current events. Events can be generated either internally or externally. Internal events are generated as a result of some transition and are described in reaction-parts. External events are usually described in the model environment.
Examples:
on-key / on:=1 (Event-test and variable assignment), [on=1] (Condition test for a variable value),
off-key [not in Lproc] / on:=0 (Event-test, condition test for a state, variable assignment. The assignment is performed if the event has occurred and the condition is true).
The semantics of edge labels can only be explained in the context of the se- mantics of StateMate [Drusinsky and Harel, 1989], a commercial implementa- tion of StateCharts. StateMate assumes a step-based execution of StateMate- descriptions. Each step consists of three phases:
1 In the first phase, the impact of external changes on conditions and events is evaluated. This includes the evaluation of functions which depend on external events. This phase does not include any state changes. In our simple examples, this phase is not actually needed.
2 The next phase is to calculate the set of transitions that should be made in the current step. Variable assignments are evaluated, but the new values are only assigned to temporary variables.
3 In the third phase, state transitions become effective and variables obtain their new values.
The separation into phases 2 and 3 is especially important in order to guarantee a reproducible behavior of StateMate models. Consider the StateMate model of fig.2.22.
In the second phase, new values for a and b are stored in temporary variables, say a’ and b’. In the final phase, temporary variables are copied into the user- defined variables:
phase 2:a’:=b;b’:=a; phase 3:a:=a’;b:=b’
Figure 2.22. Mutually dependent assignments
As a result, the values of the two variables will be swapped each time an event e happens. This behavior corresponds to that of two cross-coupled registers (one for each variable) connected to the same clock (see fig.2.23) and reflects the operation of a synchronous (clocked) finite state machine including those two registers8.
Figure 2.23. Cross-coupled D-type registers
Without the separation into phases, the same value would be assigned to both variables. The result would depend on the sequence in which the assignments were performed. The separation into (at least) two phases is quite typical for languages that try to reflect the operation of synchronous hardware. We will find the same separation in VHDL (see page89). Due to the separation, the results do not depend on the order in which parts of the model are executed by the simulation. This property is extremely important. Otherwise, there could be simulation runs generating different results, all of which would be considered correct. This could be very confusing in all design procedures.
This is not what we expect from the simulation of a real circuit with a fixed behavior.
There are different names for this property:
Kahn [Kahn, 1974] calls this property determinate.
8We adopt IEEE standard schematic symbols [IEEE, 1991] for gates and registers for all the schematics in this book. The symbols in fig.2.23denote clocked D-type registers.
In other papers, this property is called deterministic. However, this term is employed with different meanings:
– This term is used to denote non-deterministic finite state machines, FSMs which can be in several states at the same time [Hopcroft et al., 2006].
– Languages may have non-deterministic operators. For these operators, different behaviors are legal implementations.
– Many authors consider systems to be non-deterministic if their behav- ior depends on some input not known before run-time.
– In the sense Kahn uses the term “determinate”.
In this book, we prefer to reduce possible confusion by following Kahn9. Note that StateMate models can be determinate only if there are no other reasons for an undefined behavior. For example, conflicts between transitions may be allowed (see fig.2.24).
Figure 2.24. Conflicting StateCharts transitions
Consider fig. 2.24(a). If event A takes place while the system is in the left state, we must figure out, which transition will take place. If these conflicts would be resolved arbitrarily, then we would have a non-determinate behavior.
Typically, priorities are defined such that this type of a conflict is eliminated.
Now, consider fig.2.24(b). There will be a conflict for x=15. Such conflicts are difficult to detect. Achieving a determinate behavior requires the absence of conflicts that are resolved in an arbitrary manner.
Note that there may be cases in which we would like to describe non-determi- nate behavior (e.g. if we have a choice to read from two inputs). In such a case, we would typically like to explicitly indicate that this choice can be taken at run-time (see theselectstatement of ADA on page104).
Implementations of hierarchical state charts other than StateMate typically do not exhibit determinate behavior. These implementations correspond to a
9In earlier versions of the book, we used the term “deterministic” together with an additional explanation.
software-oriented view onto hierarchical state charts. In such implementations, choices are usually not explicitly described.
The three phases described on page48 have to be repeatedly executed. Each execution is called a step (see fig.2.25).
Figure 2.25. Steps during the execution of a StateMate model
Steps are assumed to be executed each time events or variables have changed.
The set of all values of variables, together with the set of events generated (and the current time) is defined as the status10of a StateMate model. After executing the third phase, a new status is obtained. The notion of steps allows us to define the semantics of events more precisely. Events are generated, as mentioned, either internally or externally. The visibility of events is limited to the step following the one in which they are generated. Thus, events behave like single bit values which are stored in permanently enabled registers at one clock transition and have an effect on the values stored at the next clock transition. They do not live forever.
Variables, in contrast, retain their values, until they are reassigned. According to StateMate semantics, new values of variables are visible to all parts of the model from the step following the step in which the assignment was made on- wards. That means, StateMate semantics implies that new values of variables are propagated to all parts of a model between two steps. StateMate implic- itly assumes a broadcast mechanism for updates on variables. This means that StateCharts or StateMate can be implemented easily for shared memory- based platforms but are less appropriate for message passing and distributed systems. These languages essentially assume shared memory-based commu- nication, even though this is not explicitly stated. For distributed systems, it will be very difficult to update all variables between two steps. Due to this broadcast mechanism, StateMate is not an appropriate language for modeling distributed systems.
10We would normally use the term “state” instead of “status”. However, the term “state” has a different meaning in StateMate.