Extension of Modelica to improve State Machine Libraries
1
Extension of Modelica to improve State Machine
Libraries
May 22, 2009, 12:20
This document proposes extensions to the Modelica language for improved handling of state machines and shall
be included in to the Modelica Language Specification 3.1.
Revisions
May 22, 2009
May 17, 2009
April 18, 2009
Draft 3 by M. Otter: Revised based on feedback from Sven Eriks prototype
implementation of the Connections.XXX functions.
Draft 2 by M. Otter: Revised specification based on the experience with the prototype
implementation Modelica_StateMachines from M. Otter and M. Malmheden.
Draft 1 by M. Otter, based on discussion between H. Elmqvist and M. Otter on April 1 in
Berlin.
Background
The goal is to support safe hierarchical state machines in Modelica. Practically all state machine formalisms (e.g.
Statechart) work in such a way that (1) there is a hierarchy in the state machine graph, and on all hierarchical
levels the variables of the state machine can be accessed. Furthermore, there are restrictions, so that (2) state
machine connections between branches of a Parallel graph are not allowed, although connections of other blocks
are allowed also between branches of a Parallel graph. Finally, (3) connections in state machines are performed
between nodes and actions are associated with the connection (e.g., when a transition takes place and optionally
that a variable is set when the transition fires).
If a similar view shall be provided in Modelica, drastic changes to the core of Modelica would be needed, since
none of the requirements above are available in Modelica. It seems not justified to change Modelica in this
respect, just for one new library. The only practical way to implement hierarchical state machines in Modelica is
therefore that the connection structure is building up the state machine hierarchy, in a similar way as controllers
with the Modelica_EmbeddedSystems library are identified by the connection structure and not by a Modelica
hierarchy. Example from the prototype implementation of library Modelica_StateMachines:
2
ModeGraph and StateGraph Issues
This state machine consists of the first state machine hierarchy (s1,t1,P,t3) of steps/states and transitions. The
second hierarchy is the parallel step/state P. This is a “standard” Modelica component where the “green” border is
just the icon of “P” and the drawing is made directly in the icon (all “green” components are currently “active”).
This is unusual, but correct Modelica. The connections within “P” describe two branches that are executed in
Parallel. From a Modelica point of view, all components are on the same level and can therefore also access all
variables declared on this level.
A parallel graph can be suspended. In this case, all steps/states in it must be deactivated. Since a parallel graph
may contain other parallel graphs, this may result in a large “state-machine-hierarchy” of steps/states that must be
disabled via one flag. It is planned to use the Modelica_EmbeddedSystems techniques for this part. The tricky part
is to enable the parallel graph again, since it must either be re-initialized or must start at the “previous” state,
depending on an activation flag. The only practical way to communicate this flag is via connectors and
connections. Since a state machine graph may have loops, overdetermined systems of equations occur for the
activation flag. The only way to handle this in current Modelica are virtual connection graphs defined by
Connections.branch(..) statements. Therefore, the proposal below is an extension to virtual connection graphs. The
extensions are made in such a way, that the correct connection structure of a state machine can be guaranteed with
respect to (a) initial step/state and (b) synchronization of parallel branches via entry/exit connectors (see figure
above).
Extension of Modelica to improve State Machine Libraries
1.1.1
3
Connection Graphs for State Machines (new section 9.4.2)
In order that a Modelica translator can guarantee the connection structure of hierarchical state machines, some
additional operators are needed for the virtual connection graph. This special virtual connection graph is called
“virtual state machine graph” in the sequel. Virtual state machine graphs are undirected graphs having
overdetermined type or record instances as nodes. The branches are defined by connect(..) and by
Connections.branch(..) statements. With the new operators “Connections.uniqueRoot(..) and
Connections.uniqueRootIndices(..) restrictions to the graph are introduced, as defined in the following table. If
one node of a virtual connection graph is marked with uniqueRoot(..), then a virtual state machine graph is present
and it is not allowed to apply the operators Connections.root(..), Connections.potentialRoot, or
Connections.isRoot(..) on a node of this graph.
Operator Connections.
uniqueRoot(root, message="")
rootIndices = uniqueRootIndices
(roots, nodes, message="")
Description
The overdetermined type or record instance “root” is a unique
root node in a virtual state machine graph. Every virtual state
machine graph must have exactly one uniqueRoot(..) definition,
before breakable branches are removed. Argument “root” may
be a vector. Then, the operator is applied on every element of
this vector.
The second argument is a message that shall be reported if
the root is not unique. From all uniqueRoot(..) definitions of the
same graph, only one of the message arguments shall
(arbitrarily) be selected and used in the error message. [The
error message should additionally include the path (= instance
names) between the unique root definitions. A typical value for
message is: “Two or more state machine graphs are connected
that should not be connected”]
The two first input arguments are vectors of overdetermined
types or record instances with the restriction that
size(nodes,1) <= size(roots,1)
Vector “roots” must contain unique roots in the virtual state
machine graphs. The function returns an Integer vector which is
a permuted version of vector “1:size(roots,1)”:

rootIndices[i], i = 1,.., size(nodes,1):
There is a path from roots[rootIndices[i]] to nodes[i]. It is an
error, if such a path does not exist. In such a case, the error
message should include the third argument “message”.

rootIndices[j], j = size(nodes,1) + 1, ..., size(roots,1):
There is no path from roots[rootIndices[j]] to an element of
nodes[:].