00 positive Bewertungen00 negative Bewertungen

70 Ansichten67 SeitenState Chart Modelling in AMESIM

Sep 27, 2019

© © All Rights Reserved

PDF, TXT oder online auf Scribd lesen

State Chart Modelling in AMESIM

© All Rights Reserved

Als PDF, TXT **herunterladen** oder online auf Scribd lesen

70 Ansichten

00 positive Bewertungen00 negative Bewertungen

State Chart Modelling in AMESIM

© All Rights Reserved

Als PDF, TXT **herunterladen** oder online auf Scribd lesen

Sie sind auf Seite 1von 67

Lab AMESim

Statechart Rev 13

User’s guide

How to contact LMS Imagine.Lab

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

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.1. Introduction ............................................................................................................... 4

1.2. Create a simple StateChart ....................................................................................... 4

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

1. Getting started

1.1. Introduction

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.

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).

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 .

(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).

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

1.2.1. Build a simple Statechart

1. Create a new AMESim model, and then insert a new Statechart from the Modeling

menu:

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

sketch.

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.

Figure 2: Adding an input variable

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

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:

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:

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.

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:

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:

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:

Now we can plot the output from the component:

2. The Statechart in detail

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

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.

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

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.

• 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.

• 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:

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:

Figure 10: Reordering transitions through a drag and drop

The Error List is used to show errors resulting from the Statechart validation process. Note that

this tab is not state selection-dependent.

The initial state does not have a Transition priority tab given that exactly 1

outgoing transition is to be defined.

2.1.5. Transitions

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

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.

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.).

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:

Figure 14: Transition Error highlighted

Figure 16: Event Error highlighted

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

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.

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:

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:

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…).

2.1.10. Current Limitations

• 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

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).

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.

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.

3.3. Statechart graphical elements

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

state at any given moment.

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.

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

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.

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:

• 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.

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:

• 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.

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.

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.

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.

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.

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.

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:

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.

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:

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.

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

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:

• cont_out1 : real

• out_2 : real

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.

The following statechart has some redundant equations:

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:

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.

4. Appendix

Here is the list of available variables for the expressions:

time : real

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

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

trigger ::= e | ε

guard ::= [ e ] | ε

actions ::= / e { ; e } | ε

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

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

4.4.4. Global Arithmetic rules

4.4.6. Global rule

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"

~

4.5.3. E02001

"[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.

4.5.4. E02002

"[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:

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

4.5.5. E02004

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

(X) E02005 Can't read output variable out

"/ x := out"

~~~

4.5.7. E02006

"unknown_event"

~~~~~~~~~~~~~

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:

4.5.10. E02009

change '=' to ':=' or move the expression to a state.

"/ cont = 0.0"

~~~~~~~~~~

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

'=' or move the expression to a transition.

"x := 15.0"

~~~~~~~~~

• 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"

~~~~~~~~~~~~

• param : real

4.5.13. E02012

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

4.5.14. E02013

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

4.5.16. E03004

trigger or guard

4.5.16.1. Fix

4.5.17. E03006

empty transition are not allowed

4.5.17.1. Fix

4.5.18. E03008

transition

4.5.18.1. Fix

4.5.19. E03009

4.5.19.1. Fix

4.5.20. E03010

4.5.20.1. Fix

4.5.21. E03011

all have a priority

4.5.21.1. Fix

4.5.22. E03012

have different priorities. Here for the event 'clock' the

priority 1 is used multiple times

4.5.22.1. Fix

4.5.23. E03013

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.

4.5.24. E03014

or delete a transition to break the cycle.

4.5.24.1. Fix

• 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

4.5.25. E03017

4.5.25.1. Inputs

• y

• x

• z

• x=y

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.

4.5.26. E03018

4.5.26.1. Inputs

• Y

• X

• x = y; x = 2 *y

describing it : x

4.5.26.4. Fix

4.5.27. E03019

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

• 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.

4.5.29. W03002

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):

4.5.30. W03019

• X

• x=3*y

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.

Glossary

A

• 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.

• 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.

Bibliography

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

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

## Viel mehr als nur Dokumente.

Entdecken, was Scribd alles zu bieten hat, inklusive Bücher und Hörbücher von großen Verlagen.

Jederzeit kündbar.