LMS Imagine.

Lab AMESim
Statechart Rev 13
User’s guide
How to contact LMS Imagine.Lab

www.lmsintl.com Web site

www.lmsintl.com/support Technical support

See here for e-mail addresses for

your local office: Sales, pricing and general information
www.lmsintl.com/lmsworldwide

+33 4 77 23 60 30 Phone

+33 4 77 23 60 31 Fax

LMS Imagine
7 place des Minimes Postal address
42300 Roanne - France

AMESim® User’s Guides

© Copyright LMS Imagine 1995-2013

The software described in this documentation is furnished under a license agreement. The software may be used
or copied only under the terms of the license agreement. No part of this manual may be photocopied or repro-
duced in any form without prior written consent from LMS Imagine.

Trademarks
AMESim® is a registered trademark of LMS Imagine
AMESet® is a registered trademark of LMS Imagine
AMERun® is a registered trademark of LMS Imagine
AMECustom® is a registered trademark of LMS Imagine
LMS Imagine.Lab® is a registered trademark of LMS International N.V.
LMS Virtual.Lab Motion® is a registered trademark of LMS International N.V.
SysDM® is a registered trademark of LMS International N.V.
System Synthesis® is a registered trademark of LMS International N.V.

Other product or brand names are trademarks or registered trademarks of their respective holders.
 ®
TABLE OF CONTENTS

1. Getting started ................................................................................................................. 4

1.1. Introduction ............................................................................................................... 4
1.2. Create a simple StateChart ....................................................................................... 4

2. The Statechart in detail ................................................................................................. 13

2.1. Statechart Graphical Environment .......................................................................... 13

3. Statechart language....................................................................................................... 25
3.1. Introduction ............................................................................................................. 25
3.2. Global overview ....................................................................................................... 25
3.3. Statechart graphical elements ................................................................................. 27
3.4. Events ..................................................................................................................... 28
3.5. Transitition Expressions .......................................................................................... 29
3.6. Variable declaration................................................................................................. 29
3.7. Transition priorities .................................................................................................. 30
3.8. Activation chains ..................................................................................................... 30
3.9. Variable assignment ................................................................................................ 32
3.10. Continuous selector............................................................................................... 35
3.11. Default continuous equations ................................................................................ 36

4. Appendix ........................................................................................................................ 38
4.1. Built in variables ...................................................................................................... 38
4.2. Built in functions ...................................................................................................... 38
4.3. Expression syntax and grammar ............................................................................. 39
4.4. Expression type system .......................................................................................... 39
4.5. Error Message reference......................................................................................... 43

Glossary ............................................................................................................................. 65

Bibliography ....................................................................................................................... 66

November 2013 Statechart 3/67

1. Getting started

1.1. Introduction

The Statechart Environment is an AMESim integrated graphical Definition, Simulation and

Analysis environment for control and operating logic based on the Harel Finite State Machine
theory and using clear and robust language semantics based on Modelica.

1.1.1. The aim of the Statechart Environment

The Statechart Environment is designed to provide an easy to use graphical environment to

define Statecharts, simulate them, and analyze results in a way that is very similar to the
methods used in other AMESim analysis tools (such as Plots or Dashboards).

1.1.2. How does Statechart work?

In contrast to most other AMESim components that typically have to be selected from a Library,
the Statechart component is fully defined by the end-user in AMESim by inserting it from the
Modeling menu and using the Statechart Environment graphical environment .

This Statechart Environment is accessible in each mode

(Sketch/Submodel/Parameter/Simulation) through a right-click, and adapts it behavior to the
available functions.

A user first defines inputs, outputs, parameters and events for his or her Statechart, and then
adds some states and transitions, and defines how outputs will vary according to inputs. Both
continuous and discrete outputs are supported.

After a validation check the Statechart is compiled into a Modelica file which is itself compiled
into a standard AMESim component. This whole process is transparent to the user.

If the validation process detects an error, clear messages are displayed together with a highlight
of states/transitions/expressions involved in order to pinpoint the error so that it can be
corrected.

Validated Statechart components will behave as regular sketch components; they are compiled
into the global system, can be parameterized, and can be simulated and analyzed.

Last but not least, the Statechart environment behaves as an Analysis Tool supporting
Monitoring (to update results during simulation) and Replay (to view results after simulation).

1.2. Create a simple StateChart

In this section we will illustrate a very simple Statechart example.

November 2013 Statechart 4/67

1.2.1. Build a simple Statechart
1. Create a new AMESim model, and then insert a new Statechart from the Modeling
menu:

Figure 1: Creating a State Chart

You will have to save your model before placing the Statechart icon on the
sketch.

2. Right-click on the icon and select Launch Statechart environment

The Statechart environment opens.
3. In the Data interface pane on the right-hand side, right-click on Input variables and
select Add new input variable.

November 2013 Statechart 5/67

 Figure 2: Adding an input variable

4. Double-click to name the variable input:

5. Add a Continuous output variable named output:

The icon on the sketch is updated with 2 ports:

November 2013 Statechart 6/67

 6. Add a ramp component to the left-hand side and a signalsink to the right-hand side:

Figure 3: Add a ramp and signal sink

Next, we will start defining the states by inserting an initial state (the black dot) and 2 atomic
states named First State and Second State. To insert a state, click on it in the Toolbox to select
it (the cursor takes on the form of that object), and then click in the graphical editor to place it:

November 2013 Statechart 7/67

 Figure 4: Placing an object in the graphical editor

7. Add one initial state, and two atomic states to the graphical editor.
8. Click on each of the atomic states and enter their names in the Assignments tab as
follows:

November 2013 Statechart 8/67

 9. Draw transitions by clicking the transition icon . Click on the first state
and keeping the mouse button pressed, drag the cursor onto the target state.

10. Select the First State and in the Assignments tab enter output=0.
11. Select the Second State and in the Assignments tab enter output=time.

November 2013 Statechart 9/67

Now we only have to define when the transition will be taken. To do this, in the Data interface,
we will define an event “e” as input>5:

Figure 5: Defining an event

12. Select the transition between First and Second state and in the Trigger tab put e:

13. Click the Validation button . This should produce the message The statechart is
valid:

November 2013 Statechart 10/67

Now we can switch to the main AMESim interface and run a simulation. You are advised to
activate Discontinuities printout in the Standard options tab of the Run Parameters dialog box.
You can leave the Statechart dialog open.
After the simulation you will notice the First State is colored blue as the environment is now
ready to analyze the result (showing the active state at time=0):

By pushing the Next State Change button we observe that the change to Second State
occurs at 5s which is exactly what was expected:

November 2013 Statechart 11/67

Now we can plot the output from the component:

November 2013 Statechart 12/67

2. The Statechart in detail

2.1. Statechart Graphical Environment

2.1.1. Creating a new Statechart

You create a new Statechart in Sketch mode through the Modeling menu :

Figure 6: Creating a Statechart

When you click this menu item, you are prompted to save the system. Once this is done, the
cursor takes the appearance of the Statechart icon and the component can be placed on the
sketch.

2.1.2. The graphical editor

You launch the Statechart’s graphical editor through a right-click on the Statechart icon :

November 2013 Statechart 13/67

 Figure 7: Launching the graphical interface

The central pane of this environment is the graphcial scene, in which you can draw states and
transitions. As with the Dashboard, you can click on a primitive and place it on the scene. To
create a transition, you select the transition icon, click on the first state, and drag the cursor to
the second (target) state to connect the two.
• On the left-hand side, the Basic primitives toolbox contains basic primitives that you can
place on the graphical scene.
• On the right-hand side is the Data interface in which you define inputs, outputs, parameters
and events.

November 2013 Statechart 14/67

• At the bottom, a contextual view (based on the state or transition selected in the scene) also
hosts the error tab which displays messages and erorrs and warnings.

2.1.3. The data interface

Figure 8: The Data interface

The data interface consists of:

• Input variables: variables coming from the rest of the AMESim sketch that are fed into the
Statechart. Users can define an input variable’s name (only in Sketch mode).
• Continuous output variables: continuous output variables that the Statechart will influence
during the simulation based on the inputs and parameters using continuous affectation.
Users can define a continuous output variable’s name (only in Sketch mode).
• Discrete output variables: discrete output variables that the Statechart will influence during
the simulation based on the inputs and parameters using discrete affectation. Users can
define a discrete output variable’s name.
• Parameters: to define parameters that are used within the Statechart and that users can
assign values to in Parameter mode (without changing the definition of the Statechart) –
including the possibility of Batches. Users can define a parameter’s name, type (real or int)
and default value (only in Sketch mode).
• Events: to define events that are used in triggers (see the Appendix for more details). Users
can define a trigger’s name and value (only in Sketch mode).
See the Statechart language for more information on Statechart semantics.

2.1.4. States
For an AMESim Statechart to be valid, it needs to have exactly 1 initial state (the black dot).
This initial state also needs to have exactly 1 transition towards another state; this transition is
also called the initial transition. There cannot, of course, be a transition towards the initial state.
As it is not permitted for the Statechart to be finished before a simulation has ended, no final
state exists.
When you select a state on the scene (other than the initial state) you will see the following
contextual view at the bottom of the Statechart environment:

November 2013 Statechart 15/67

 Figure 9: The Statechart scene

In the Assignments tab we can assign Continuous output variables to an algebraic equation
using inputs, parameters and ‘time’ such as
my_output=sin(my_input)* time+my_parameter.
See the Statechart language for more information on Statechart semantics.
These Continuous output variables will retain the formula affectation as long as we are in this
state.

For every state, every continuous output variable needs to be defined. To avoid
having to redefine the default values on all states, it is possible to define the
default value on the initial state.

It is not permitted to assign values to Discrete output variables on States; this is done in
Transitions as will be seen later.
All outgoing transitions from the selected state are listed In the Transition priority tab. In order to
reach a deterministic behavior on simultaneous triggers an order is imposed and indicated using
the #n information – which can also be seen on the transitions on the graphical scene (with #0
being the transition having the highest priority).
If you want to change this order you can simply drag and drop a transition in this tab to a
different location in the list, and then press the Apply button:

November 2013 Statechart 16/67

 Figure 10: Reordering transitions through a drag and drop

The Comment tab can be used to store comments.

Figure 11: Comment tab

The Error List is used to show errors resulting from the Statechart validation process. Note that
this tab is not state selection-dependent.

Figure 12: Error tab

The initial state does not have a Transition priority tab given that exactly 1
outgoing transition is to be defined.

November 2013 Statechart 17/67

2.1.5. Transitions
On selection of a transition (other than the initial transition), the following tabs will appear:

Figure 13: Statechart tabs

You may also note that the transition label on the graphical scene is linked to the selection and
shows the trigger with priority information (this label is generated and cannot be changed).
• On the Trigger tab you can enter an expression using events that define when transitions
can be made.
• On the Guard tab you can enter conditions that will be checked once a trigger has been
encountered. If the condition is true, the transition is made; otherwise it is not.
• The Actions tab is the counterpart of the Assignments tab but this time for Discrete Output
variables. The format is also different: my_discrete_output:=my_discrete_output+1.
• The initial transition is different in the sense that is has neither trigger nor guard tab (as it is
made right at the start of the simulation).
• See the Statechart language for more information on Statechart semantics.

November 2013 Statechart 18/67

2.1.6. Statechart Environment restrictions according to the current
AMESim mode
Since the Statechart environment has a specific function in each of the different AMESim
modes, there are also some important restrictions that you should be aware of when you want to
edit your Statechart.
Since the addition or removal of inputs and outputs in Statechart changes the port on the
sketch component, this can only be done when AMESim is in Sketch mode.
Here is an overview of the most important actions that are enabled or disabled according to the
current AMESim mode:

Mode Function
In this mode you may:
• Change the input/output variables, change parameters and
their default values, change events.
• Add/remove states and transitions.
Sketch mode
• Change properties of states and transitions including the
layout of the Statechart (for example, moving states to other
locations).
In this mode, there is no replay capability.
In this mode, you may perform the same operations as in Sketch
mode, except for those that change the icon ports:
Submodel • Changes to the input/output variables are not allowed
mode (add/delete/rename).
• Changes to parameters, events, states and transitions are
allowed.
In order to enter Parameter or Simulation mode, the model must be
compiled. This means that anything related to the icon and submodel
cannot be changed:
• You cannot make changes to inputs/outputs.
Parameter • You cannot add, remove or rename parameters, nor change
and their default values. You can, however, change a
Simulation parameter’s actual value through the Parameters view in the
mode same way as for standard AMESim components on the
sketch.
• You cannot modify Events in any way.
• You can perform graphical operations and modify comments
(moving states/labels/transitions etc.).

2.1.7. Validating the Statechart

Before proceeding to compilation and simulation you must Validate the Statechart using the
Validate Statechart button:
.
Any errors will be listed in the Error tab. When you double-click on an error, the corresponding
state/transition or expression will be highlighted in red to assist you in understanding and
correcting this error:

November 2013 Statechart 19/67

 Figure 14: Transition Error highlighted

Figure 15: Expression Error highlighted

November 2013 Statechart 20/67

 Figure 16: Event Error highlighted

The Validation process is also triggered when you switch to parameter mode.

2.1.8. Simulating the Statechart

Once the Statechart is validated we can simulate it.

Before doing so we can observe that by selecting the Statechart component on the sketch we
can see the defined parameters in the AMESim Contextual parameters view window and we
can change them as for a standard AMESim library component.

November 2013 Statechart 21/67

That also means exposed parameters can be used in batch simulations.
It is also possible to observe the state changes and values of inputs and outputs during the
simulation using the Automatic update function, in the same way as for the Plot/Dashboard/3D:

Figure 17: Selecting a batch

2.1.9. Analyzing a Statechart simulation

After simulation it is possible to replay the simulation using the play button in the toolbar.

In particular, note the Previous and Next State Change buttons which help you finding the
timestep situation when a next/previous state change took place:

November 2013 Statechart 22/67

 Figure 18: Previous and Next State Change buttons

Finally you can either export the graphical scene to a file (File  Export to File…) or video
(Tools  AVI export…).

November 2013 Statechart 23/67

2.1.10. Current Limitations

Currently not supported in this version are:

• Composite states
• Parallel states
• Storing a Statechart in a Supercomponent
• Storing a Statechart in a Library
• Synchronization of current timestep with other analysis tools
• Pack and Unpack facility

November 2013 Statechart 24/67

3. Statechart language

3.1. Introduction
In this document, we describe the subset of the statechart formalism, or statecharts, as
implemented in AMESim. Statecharts is a visual formalism that can be used to describe reactive
subsystems such as discrete controllers, schedulers, etc., in a more convenient way than
offered by classical AMESim submodel assemblies. Indeed, essential information such as
transitions between states is directly expressed in a graphical manner, which greatly eases
understanding of subsystem logic. As stated above, only a subset of statecharts is implemented
in AMESim; this subset has been defined with simplicity and soundness in mind. As a
consequence, the use of statecharts in AMESim provides a high level of safety and robustness
in comparison with what could be achieved by means of classical signal submodel assemblies.
This manual introduces AMESim’s statechart subset; for more general information about
statecharts, see for instance (Harel, 1987).

3.2. Global overview

Submodels automatically derived from statechart specifications offer a flexible and convenient
mean to control continuous AMESim models. When models are composed of a plant part and of
a control part, the whole control part as well as the interface between continuous and discrete
behavior can be specified by means of the statechart utility. Starting from a statechart
specification, AMESim is able to automatically derive the corresponding discrete state machine,
which, coupled with its continuous selector, can be connected to the plant part of the model to
control it.

November 2013 Statechart 25/67

This manual introduces the important concepts of AMESim’s statechart utility:
- Basics of subset of the statechart graphical language implemented in the utility
- The continuous selector and its role in information exchange between plant models and
controllers.

November 2013 Statechart 26/67

3.3. Statechart graphical elements

3.3.1. Basic state

Basic element of the statechart, a state can be active or inactive. There can be only one active
state at any given moment.

3.3.2. Pseudo initial state

The pseudo initial state is used to indicate which basic state will be active when the statechart
start. The initial transition, which is the transition from the pseudo initial state to the first active
state, must be unique. There can be only one pseudo initial state per statechart.

3.3.3. Transition

A transition is defined between two states, with a transition expression (explained later) and a
possible priority. The basic state activation is transferred from basic state to basic state following
the transitions.

November 2013 Statechart 27/67

3.4. Events
The statechart reacts to events yield by event generators declared at statechart creation time.
An event generator is defined by an expression depending on inputs and parameters. Events
are raised each time the expression becomes true. For example, for the expression:

input1 >= x

declares an event generator reacting to changes of input1 (x is supposed here to be a

parameter). When input1 follows the blue curve pictured below, the expression becomes true at
the blue points whose abscissa corresponds to points in time called events.

November 2013 Statechart 28/67

3.5. Transitition Expressions
A transition links a source state with a destination state. In order to take the transition, the
source state must be currently active, and an event must trigger the transition. For example,
given the following transition expression:

• Trigger: The events which the transition reacts to.

• Guard: If the event is raised, to take the transition, the guard must also be true.
• Actions: a set of assignments updating some discrete variables (internal or output),
when the transition is taken.

3.6. Variable declaration

The variables internal to the statechart are declared on the initial transition of the statechart.
As an example, two internal variables x and y are declared in the following statechart:

This yields the following complete declarations:

• x with type int.
• y with type real.

The type of the variable depends of the value used to initialize it. Here for instance the use of
the literal integer 0 and of the float literal 0.0 lead to actual types int and real respectively: type
determination is automatically performed and eventually propagated in the whole statechart (any
subsequent use of x and y propagate the int and real type constraints in involved expressions).

You cannot mix and match int variables with real variables, you must convert
them with the function to_real and to_int. Int constants can be used as a real
constant everywhere but in transition from initial state.

November 2013 Statechart 29/67

3.7. Transition priorities
Without transition priorities, the following statechart is ambiguous. Indeed, the state following
State 1 is not unique because the two guards x>= 2 and x > 0 are true since x is given the value
5 during the initial transition.

This ambiguity can be resolved by adding priority numbers to the transitions:

Priority numbers are unique numbers attached to transitions exiting a given state. Among
several candidate transitions, the one having the lowest priority number is taken. Here for
instance transition to State 2 is taken.

3.8. Activation chains

Transitions triggered by an event generator must wait for an event to happen to be taken: they
remain blocked by the trigger until an event eventually happens. On the other hand, transitions
with just a guard can be taken without waiting for an event provided the guard is true.
An activation chain is a path of transitions having no triggers.

November 2013 Statechart 30/67

For instance in this statechart initially in State 1, when e fires then State 2 is reached via the
previously blocking transition. Once in State 2, outgoing transitions without trigger (i.e. the non-
blocking ones) are examined according to priority number order to see if one of them can be
taken.

The first transition has guard [x >= 0], which is true, so the transition is taken to the State 3.
The outgoing transition from State 3 being triggered by e, it’s blocking. What is observable is
that when e is fired, there is a ‘jump’ from State 1 to State 3

The execution of an activation chain occur within the event instant, the time
doesn’t advance while taking the transitions.

November 2013 Statechart 31/67

3.8.1. Activation chain cycle
In order to ensure that a statechart execution halts, cycle in activation chains is forbidden. In the
following, slightly modified, statechart, the outgoing transition from the state 3 is not triggered.

This implies that the execution could loop from state 2 to state 3 and back to state 2.

Even if the condition inside the guard cannot be taken, we don’t allow an
activation chain loop.

3.9. Variable assignment

When performing an affectation in a transition, there is a clear distinction for the values used. In
the expression below

The blue part represents the value at the moment when the event was raised, and the green
part represents the value that will be updated after the execution of all the activation chains.
For the following statechart:

November 2013 Statechart 32/67

The execution will happen as following when in state 1 and the event e is raised:
- Go to State 2, update the future value of x
- Check transition with priority 1, x is still equal to 0; the transition cannot be taken.
- Check transition with priority 2, x is still equal to 0; the transition can be taken, go to
State 4.
- End of activation chain, the future value of x become its actual value, so the value of x
become 1, and we stay in State 4.
Another possibility can be shown using this modified version, the guard for the transition of
priority 2 having been updated:

Here the execution will go as follow when in state 1 and the event e is raised:
- Go to State 2, update the future value of x
- Check transition with priority 1, x is still equal to 0, so discard
- Check transition with priority 2, x is still equal to 0, so discard
- End of activation chain, the future value of x become its actual value, so x get the value
1, and we stay in State 2.
During the next raise of the event e the execution will continue:
- Check transition with priority 1, x being equal to 1, the guard is true and go to state 3.
November 2013 Statechart 33/67
 - End of activation chain, we stay in state 3.

3.9.1. Variable double affectation

The affectation updates the value of the variable or discrete output at the end of an activation
chain. Thus a problem arises when the same value is assigned twice, which one should we
use?

Does x should have the value 1 or the value 18? To avoid ambiguity of the statechart execution,
multiple update of a variable in an activation chain is forbidden. In order to break the chain, you
must add a trigger to one of the transition:

November 2013 Statechart 34/67

This way, the transition between the state 2 and the state 3 is not taken directly; the event e
must be raised in state 2 before re-updating the variable x.

3.10. Continuous selector

The selector controlled by the state activation is used to control the continuous outputs. Each
continuous output should be described by an equation depending only on:
• The inputs
• The parameters
• Some constants.
• The discrete variables and outputs defined in the statechart

No other information is available in the continuous equations. As AMESim require continuous

variable to be always present, a unique equation must be present for every continuous output at
every state. This force a continuous output must be fully covered by the states.
As an example:

With the following continuous outputs:

• cont_out1 : real
• out_2 : real

Adding the equation to the states gives:

November 2013 Statechart 35/67

By writing the continuous equations in a table we can check that the continuous outputs are
covered for every state:
Output State 1 active State 2 active State 3 active
cont_out1 0.0 2 * input1 + 3.0 0.0
out_2 3.14 sin(input1 + 3) sin(input1 + 3)

The continuous part of the statechart is considered as valid. If a cell in the previous table was
empty, it would be an error and the statechart would be rejected by the compiler.

3.11. Default continuous equations

The following statechart has some redundant equations:

Output State 1 active State 2 active State 3 active

cont_out1 0.0 2 * input1 + 3.0 0.0
out_2 3.14 sin(input1 + 3) sin(input1 + 3)

The equation cont_out1 = 0.0 and out_2 = sin(input1 + 3) could be factored out. In
order to avoid copying the same equation over and over, there is a mechanism of equation
defaulting. If an equation is not defined for the state and a default equation exists for the
continuous output, then the default one is used.

To define default continuous equations, they have to be declared on the pseudo–initial state.
Rewriting our previous statechart leads to:

November 2013 Statechart 36/67

The state 3, which was using all the default equations don’t even need to get specific equations.
The two left equations are just the specific cases.

November 2013 Statechart 37/67

4. Appendix

4.1. Built in variables

Here is the list of available variables for the expressions:
time : real

4.2. Built in functions

Here is the list of available functions for the expressions:
mod : ( int, int ) -> int
sqrt : ( real ) -> real
sin : ( real ) -> real
cos : ( real ) -> real
tan : ( real ) -> real
asin : ( real ) -> real
acos : ( real ) -> real
atan : ( real ) -> real
atan2 : ( real, real ) -> real
sinh : ( real ) -> real
cosh : ( real ) -> real
tanh : ( real ) -> real
exp : ( real ) -> real
log : ( real ) -> real
log10 : ( real ) -> real
to_real : ( int ) -> real
to_int : ( real ) -> int
abs : num in {real, int} . ( num ) -> num
max : num in {real, int} . ( num, num ) -> num
min : num in {real, int} . ( num, num ) -> num

November 2013 Statechart 38/67

4.3. Expression syntax and grammar
The operators in the expressions have the following priorities and associativity:

:= = Right associative
or Left associative
and Left associative
not Prefix
< <= > >= == <> Left associative
+- Left associative
/* Left associative
(unary)- , (unary) + Prefix
^ Right associative

Here is the grammar in EBNF form describing the grammar of the action element to be
implemented by the compiler.
e ::= if e then e else e
| ID := e | ID = e
| or_e or e
| e and e
| not e
| e < e | e <= e | e > e | e >= e | e == e | e <> e
| e + e | e - e
| e * e | e / e
| - e | + e
| e ^ e
| ID
| false | true
| INT_LIT | FLOAT_LIT | STRING_LIT
| ( e )
| ID ( e { , e } )

ID ::= [a-zA-Z][_a-zA-Z0-9]*
INT_LIT ::= [0-9]+
FLOAT_LIT ::= INT_LIT . [0-9]* exp_mark?
| . INT_LIT exp_mark?
| INT_LIT exp_mark

exp_mark ::= [Ee] [+-]? INT_LIT

The global transition specification is as follow:

trigger ::= e | ε
guard ::= [ e ] | ε
actions ::= / e { ; e } | ε

transition ::= trigger guard actions

Note: The ε stand for an empty grammar rule, it means « nothing ».

4.4. Expression type system

Here is the succinct inference rules describing the type system implemented in the type checker
for the expressions in the transitions, states and events. The notation used in this page is the
standard type rule or type judgment used in the literature, an introduction can be found on
Wikipedia.
November 2013 Statechart 39/67
4.4.1. External element rules

When v has a simple type (int, string, real).

4.4.2. Constants rules

4.4.3. Boolean operations rules

November 2013 Statechart 40/67

4.4.4. Global Arithmetic rules

4.4.5. Control rules

November 2013 Statechart 41/67

4.4.6. Global rule

November 2013 Statechart 42/67

4.5. Error Message reference

4.5.1. E01001

(X) E01001 Syntax error in an expression, Expression expected in expr "[time >
]"
"[time > ]"
~

4.5.2. E01002

(X) E01002 Event conjunction ('and') is not allowed, only disjunction allowed
('or') in expr "e and e2"
"e and e2"
~

November 2013 Statechart 43/67

4.5.3. E02001

(X) E02001 Undefined variable x in node

"[x]"
~

4.5.3.1. Fix

You can add an Boolean inner variable, by setting it on the initial transition, or declare a
parameter, discrete output or input with a matching type.

November 2013 Statechart 44/67

4.5.4. E02002

(X) E02002 Incompatible types type int against string

"[x == y]"
~

4.5.4.1. Fix

The problem is that equivalent types are expected, when they are different. The first possibility is
to change the type of y to match the one of x, transform everything into integers:

Another possibility is to declare y with a real type and cast it for the comparison:

November 2013 Statechart 45/67

The last possibility is to declare y as float and cast x for the comparison:

4.5.5. E02004

November 2013 Statechart 46/67

4.5.5.1. Inputs

• in : Real

(X) E02004 Input can be only read, so impossible to assign a value to the input
'in'
"/ in := x"
~~~~~~~

4.5.6. E02005

4.5.6.1. Outputs

• out : continuous real

(X) E02005 Can't read output variable out
"/ x := out"
~~~

4.5.7. E02006

(X) E02006 Undefined event unknown_event

"unknown_event"
~~~~~~~~~~~~~

November 2013 Statechart 47/67

4.5.8. E02007

4.5.8.1. Inputs

y : real
(X) E02007 The trigger is not an event y
"y"
~

4.5.9. E02008

4.5.9.1. Inputs

y :real
x :real
(X) E02008 Continuous binding ('=') can be only used on continuous outputs, not
on 'y'
"y = x"
~~~~~

4.5.9.2. Fix

Either transform the y input to a continuous output, or simply remove the continuous binding:

November 2013 Statechart 48/67

4.5.10. E02009

(X) E02009 There is a continuous binding on a discrete transition, either

change '=' to ':=' or move the expression to a state.
"/ cont = 0.0"
~~~~~~~~~~

4.5.10.1. Continuous output

• cont : real continuous output

4.5.10.2. Fix

If the intent is to update a continuous variable, then move the binding to a state:

If the intent is to update a discrete variable, change the kind of cont to a discrete output or inner
variable and change the operator to ‘:=’

4.5.11. E02010

(X) E02010 There is a discrete assignation on a state, either change ':=' to

'=' or move the expression to a transition.

November 2013 Statechart 49/67

 "x := 15.0"
~~~~~~~~~

4.5.11.1. Continuous expressions

• On state n0 : “x := 15.0”

4.5.11.2. Fix

You can remove the continuous binding, making x just an inner variable:

Or you can declare x as a continuous output and let the continuous binding on the state:

4.5.12. E02011

(X) E02011 Parameters are constants, so it's impossible to modify the value of
the parameter 'param'
"/ param := 2.0"
~~~~~~~~~~~~

4.5.12.1. Statechart parameters

• param : real

November 2013 Statechart 50/67

4.5.13. E02012

(X) E02012 Continuous outputs must be bound (using '=') in states, so

impossible to assign (using ':=') a value to 'co'
"/ co := 2.0"
~~~~~~~~~

4.5.13.1. Fix

If the intention was to change the binding to the continuous output, then the binding should be
moved to a state:

If the intention was to change a discrete variable, then the co variable must change from a
continuous output variable to a discrete output variable or an inner variable.

4.5.13.2. Variables

• co : continuous output

November 2013 Statechart 51/67

4.5.14. E02013

(X) E02013 An integer constant is too big to be represented at

runtime.
"/ i := 2147483648"
~~~~~~~~~~

4.5.14.1. Fix

The accepted range for integer constants is , change the constant to fit in this
range.

4.5.15. E03003

(X) E03003 A composite state must have only one initial state

4.5.15.1. Fix

Remove one of the initial state.

November 2013 Statechart 52/67

4.5.16. E03004

(X) E03004 A transition from an initial node must be free of

trigger or guard

4.5.16.1. Fix

Remove the guard

4.5.17. E03006

(X) E03006 A transition require a trigger or a guard (or both),

empty transition are not allowed

4.5.17.1. Fix

Add a trigger or a guard on the transition from n0 to n1.

November 2013 Statechart 53/67

4.5.18. E03008

(X) E03008 An Initial node can't be the destination of a

transition

4.5.18.1. Fix

Remove the transition ending on the initial state

November 2013 Statechart 54/67

4.5.19. E03009

(X) E03009 An Initial node must have an unique output transition

4.5.19.1. Fix

Remove a transition from the initial state

4.5.20. E03010

(X) E03010 An Initial node must have an output transition

4.5.20.1. Fix

Add a transition from the initial state to another state.

November 2013 Statechart 55/67

4.5.21. E03011

(X) E03011 Multiple transitions reacting to the same event must

all have a priority

4.5.21.1. Fix

Add a priority to the other transition

November 2013 Statechart 56/67

4.5.22. E03012

(X) E03012 Multiple transitions reacting to the same event must

have different priorities. Here for the event 'clock' the
priority 1 is used multiple times

4.5.22.1. Fix

Change one of the two priority.

November 2013 Statechart 57/67

4.5.23. E03013

(X) E03013 The variable "x" is assigned twice in an activation

chain

4.5.23.1. Fix

A variable can only be assigned once in an activation chain, the solution is to add a trigger on
the transition from n1 to n2 or remove the assignation of x.

November 2013 Statechart 58/67

4.5.24. E03014

(X) E03014 An activation chain must be cycle free, use a trigger

or delete a transition to break the cycle.

4.5.24.1. Fix

To break the activation cycle you can :

• Add a trigger on a transition, for example if you add a trigger on the transition from n0
to n1 or on the transition from n1 to n0, you will block waiting for the event.
• Remove some transitions, either the transition from n1 or n0

November 2013 Statechart 59/67

4.5.25. E03017

4.5.25.1. Inputs

• y

4.5.25.2. Continuous outputs

• x
• z

4.5.25.3. Continuous equation defined in state i0

• x=y

(X) E03017 These continuous output must have an equation

describing them on every state : z

4.5.25.4. Fix

Adding an equation for the continuous output z on the state n1 or on the pseudo initial state
(using the defaulting mechanism).
For instance, add an equation “x = time” on the n1 state.

November 2013 Statechart 60/67

4.5.26. E03018

4.5.26.1. Inputs

• Y

4.5.26.2. Continuous outputs

• X

4.5.26.3. Continuous equation defined in state i0

• x = y; x = 2 *y

(X) E03018 A continuous output must have an unique equation

describing it : x

4.5.26.4. Fix

Removing one of the two equations: “x = y” or “x = 2 *y”

4.5.27. E03019

(X) E03019 This potentially transitive state possess specific continuous

bindings

4.5.27.1. Variables

• x : continuous output
• y : real input
November 2013 Statechart 61/67
4.5.27.2. Continuous equations

• i0: x = y
• n1: x = 3 * y

4.5.27.3. Fix

Fixing the error imply adding a trigger to all outgoing transitions or move the continuous
equation on the n1 state to the initial state and rely on the defaulting mechanism.

4.5.28. E03023

(X) E03023 An event is declared but not used, you may have unexpected
transition change : e2

4.5.28.1. Declared events

• e
• e2

4.5.28.2. Fix

Getting rid of this warning imply to either removing the e2 event or using it in any transition of
the statechart.

November 2013 Statechart 62/67

4.5.29. W03002

/!\ W03002 A continuous output is used as a discrete output and

should be transformed into one: out

4.5.29.1. Fix

The continuous output in this current state could be transformed to a discrete one by moving the
equations to affectations in transitions, and declaring it as discrete output:

Or the continuous output should have an equation containing at least one continuous variable
(input or time):

November 2013 Statechart 63/67

4.5.30. W03019

4.5.30.1. Continuous output

• X

4.5.30.2. Continuous equation on n1

• x=3*y

/!\ E03019 This potentially transitive state possess specific

continuous bindings

4.5.30.3. Fix

Fixing the error imply adding a trigger to all outgoing transitions or move the continuous
equation on the n1 state to the initial state and rely on the defaulting mechanism.

November 2013 Statechart 64/67

Glossary
A

• Activation chain – a path of un-triggered transitions.

• Action – The act of changing the value of a discrete output or an internal variable.

• Continuous output – An output of continuous value, not stemming from the statechart. A
continuous output must be the combined values of continuous inputs.
• Continuous input – Any input of the statechart.

• Discrete output – A statechart output which reflects the value of a discrete variable.

• Event – A Boolean expression used to start the execution of the statechart once it become
true (raising front).

• Guard - a boolean expression which must be true in order to be able to take a transition.

• Initial transition – The transition from the initial pseudo state to the first active state.

• Output – An output with discreetly assigned value.

• State – Basic element of the statechart, a state can be active or inactive.

• Trigger – A collection of events used to describe the events to which a transition reacts to.
• Transition – What link two states and react to events with potentially a guard and actions.

November 2013 Statechart 65/67

Bibliography
Harel, D. (1987). Statecharts: A Visual Formalism For Complex Systems.

November 2013 Statechart 66/67

Index

Global rule...................................................... 42
Guard ............................................................. 18
A
Actions ........................................................... 18
Activation chain cycle..................................... 32
I
Activation chains ............................................ 30 Initial transition .............................................. 15
Appendix ........................................................ 38 Input variables ............................................... 15
Assignments ................................................... 16
L
B Limitations ..................................................... 24
Basic state ...................................................... 27
Boolean operations rules ............................... 40
Built in functions ............................................ 38
P
Built in variables ............................................. 38 Parameters..................................................... 15
Pseudo initial state......................................... 27
C
Constants rules .............................................. 40
S
Continuous output variables .......................... 15 Statechart graphical elements ....................... 27
Continuous selector ....................................... 35 Statechart language ....................................... 25
Control rules .................................................. 41

T
D
Transition ....................................................... 15
Default continuous equations ........................ 36 Transition priorities ........................................ 30
Discrete output variables ............................... 15 Transitition Expressions ................................. 29
Trigger ............................................................ 18
E
Error List ......................................................... 17
V
Error Message reference................................ 43 Validating ....................................................... 19
Events ............................................................. 15 Variable assignment....................................... 32
Expression syntax and grammar .................... 39 Variable declaration ....................................... 29
Expression type system .................................. 39 Variable double affectation ........................... 34
External element rules ................................... 40

G
Global Arithmetic rules .................................. 41

November 2013 Statechart 67/67