One important variation among concurrent state machine styles is whether a state or a transition can be hierarchically decomposed into a more detailed state machine.
A second important variation among concurrent state machine styles has to do with how an event causes a concurrent transition in two or more state machines. In one case, event labels on transition arcs are further distinguished as either output events (calling events) or input events (receiving events). The figure shows this style using a common notation in which an output event is followed by an exclamation point and an input event is followed by a question mark. Each concurrent transition by two state machines is associated with a single event in which both machines simultaneously participate. In another variant, each transition arc may be labeled with an input event and also with one or more output events. A transition may occur when the input event occurs, and when it does all the associated output events are generated by the machine. Each state machine in this style can be viewed as a transformer of event sequences, responding to a sequence of events by generating a sequence of events. In this latter variant, care must be taken in defining how a state machine responds to its own generated events with respect to how the other state machines respond and how and whether generated but not yet accepted events are queued or lost.
A third important variation is whether there are explicit connections between state machines that show how events "flow" between them. In such styles it is possible to draw a related process event flow diagram where each process bubble represents one state machine, and the arcs show how events flow from a generating to a consuming process. Such a diagram appears on the right side of the figure above. The alternative choice is that events are implicitly relayed nondeterministically to any other state machine currently in a state having a transition labeled as inputting that event. In this case the set of possible interactions between the state machines is implicitly determined by the entire collection.
A fourth important variation has to do with the notion of "fairness" in a collection of state machines. If multiple state machines in a collection could make a state transition, what rule is used to determine the transition that is made? This order can affect which of the other transitions might occur later, i.e. it is possible to find cases where choosing one machine's transition has the effect of changing the set of possible transitions in the other machines. Various notions of fairness have been developed whose intent is that no machine can be arbitrarily overlooked forever, i.e. a machine that can make a state transition will eventually do so.
There are concurrent state machine variants that have associated analysis methods for verifying liveness and safety properties. Liveness properties are conditions that one wants to show are eventually made true for any possible sequence of events associated with a system, while safety properties are conditions that one wants to show will never occur in any possible sequence of events associated with a system. There are also analysis techniques that allow one to demonstrate relationships such as equivalence or substitute-ability between two specifications.
As with the other styles, different variants of the state machine style may have different coding guidelines. One coding guideline is to implement each state machine as a source module with its own thread of control, i.e. very much like a traditional operating system process. The state of such a machine is determined by the program counter (e.g. the basic blocks of the source code form the states of the machine), and service calls are available to support event sends and receives between processes. Languages like Ada and Occam provide features to support implementation guidelines of this form.
Another coding guideline keeps the state of each machine in a collection of variables. There may be a particular variable for each machine whose values range over the states of that machine, or (more generally) each state is a predicate that is true or false over a collection of variables (a machine is in a given state if that state predicate is currently true). Each event triggers the execution of a subprogram that changes the values of the variables, thus transitioning one or more machines to a new state. In this guideline, particular source modules are more associated with particular transitions than with particular state machines. Some mechanism must be used to insure that multiple subprograms triggered by multiple events do not simultaneously access the same variables. That is, some mutual exclusion mechanism or convention is needed.
A concurrent state machine style was used to develop a reusable software architecture for real-time executives for the MetaH architecture specification language and toolset.