visualstate Reference Guide

Transcription

1

2 COPYRIGHT NOTICE Copyright IAR Systems AB. No part of this document may be reproduced without the prior written consent of IAR Systems. The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such a license. DISCLAIMER The information in this document is subject to change without notice and does not represent a commitment on any part of IAR Systems. While the information contained herein is assumed to be accurate, IAR Systems assumes no responsibility for any errors or omissions. In no event shall IAR Systems, its employees, its contractors, or the authors of this document be liable for special, direct, indirect, or consequential damage, losses, costs, charges, claims, demands, claim for lost profits, fees, or expenses of any nature or kind. TRADEMARKS IAR Systems, IAR Embedded Workbench, C-SPY,, The Code to Success, IAR KickStart Kit, I-jet, I-scope, IAR, and the logotype of IAR Systems are trademarks or registered trademarks owned by IAR Systems AB. Microsoft and Windows are registered trademarks of Microsoft Corporation. Unified Modeling Language and UML are registered trademarks or trademarks of the Object Management Group, Inc. All other product names are trademarks or registered trademarks of their respective owners. EDITION NOTICE Fifth edition: June Part number: RGVS-5 This document applies to version 7.3 of the software. 2

3 Contents Figures... 7 Tables... 9 Preface About this guide About this edition Assumptions Introduction The tools State machines Statechart diagrams Projects, Systems and files File hierarchy Project System System types Instances Statechart file Global and local elements Element declarations and definitions files and name extensions State Definition of state Topstate Simple state Composite state Region Off page region Default state

4 Initial state Shallow history state Deep history state The join and fork pseudostates The junction and connector pseudostates Transition Definition of transition transition types Transition description Condition side of transition Action side of transition Trigger Explicit trigger Implicit trigger Guard expression Double buffering State condition Source state Positive state condition Negative state condition Action function Timer action function Assignment State action Force state action Destination state State reactions Definition of state reaction Internal reaction Entry reaction Exit reaction Do reaction Final state

5 Contents Completion transition Reserved keywords operators Precedence of operators Assignment operators Binary arithmetic operators Bit-manipulation operators Logical operators Relational operators Unary arithmetic operators Unary bitwise operators Unary logical operators operands variable types Internal variables External variables constants Syntax Supported syntax Index

6 6

7 Figures 1: Example of a state machine : Statechart diagram of an air conditioning unit : Project structure : Example of a Project : Event handling : Statechart files in the state hierarchy : Example of state compartments : The simple state symbol : Composite state composed of concurrent regions : Composite state composed of mutually exclusive states : State machine with an off page region in the state On : State machine contained in the off page region : Example of an initial state and a default state : Example of the use of shallow history state : Effect of using the shallow history state : Example of the use of a deep history state : Example of an ordinary transition : The condition side and action side of a transition : The condition side elements of a transition : Condition side modeled as a (simplified) class diagram : The action side elements of a transition : Action side modeled as a class diagram : Event processing in : Multiple events resulting in the same change in state : Example of the use of event group : Signal queue handling in : Example of a live lock : Example of a positive state condition : Example of a negative state condition : Example of the use of force state action : State reactions

8 32: Example of the use of internal reactions : Example of the use of entry and exit reactions : Entry and exit reactions moved to ordinary transitions : Example of the use of a do reaction : The contents of the do reaction DoPlayTrack

9 Tables 1: Terminology changes in this edition of : file name extensions : Reserved keywords : Assignment operators : Binary arithmetic operators : Bit-manipulation operators : Logical operators : Relational operators : Unary arithmetic operators : Unary bitwise operators : Unary logical operators : variable types : Allowed types of specific operands

10 10

11 Preface This guide is intended as a source of reference for users of. It describes the constructs, elements and principles of state machine modeling that are available in. For information on how to use the individual tools, refer to the user documentation. About this guide This guide consists of the following chapters: Introduction, page 13 gives an overall description of the software and its modules. It also describes statechart diagrams and state machines. The chapter Projects, Systems and files, page 17 describes the different types of files and how they are related to each other and includes a list of the name extensions of files. The chapter also deals with instances and elements. The chapters State, page 25, Transition, page 39, and State reactions, page 55 give a detailed description of the various modeling constructs available in. Reserved keywords, page 61 lists the reserved keywords in. operators, page 63 and operands, page 67 list the operators and operands available in. Syntax, page 71, describes the supported syntax for guard expressions and action expressions. ABOUT THIS EDITION Most figures are from version 4.3 and are therefore outdated. The differences are only cosmetic. This edition of comprises some major changes compared to the previous edition,, Version 4, Second Edition. The following features no longer exist: Boundary transitions and no-condition state transitions no longer exist. If an old project contains such transitions, they must be removed before the project can be used with version 5. The S/E notation for Systems does no longer exist. The Safe UML System notation are replaced by the Safe mode option in Designer. 11

12 Assumptions The Matrix editor is no longer part of. The following features have been changed or added: Unit states have been replaced by off page regions that work in a similar way. The signal queue error mode used for Systems is now an attribute of a project. In previous versions of, the signal queue error mode was a Coder option. Constants must have explicit types like external and internal variables. All kinds of elements are designated either as a declaration or a definition. The behavior of the pseudostates initial, shallow history, and deep history has been changed. The pseudostates join, fork, junction, and connector have been added. Terminology changes in this edition In this edition of the, the following terminological changes have been made, compared to, Version 4, Second Edition: Version 4, 2nd edition This edition history state shallow history state superstate composite state termination transition completion transition Table 1: Terminology changes in this edition of Assumptions It is assumed that readers of this guide are familiar with basic programming and state/event modeling principles. 12

13 Introduction is a suite of fully integrated tools for the entire embedded software development process. It includes a graphical design environment, advanced verification and validation tools, a very powerful code generator, and a documentation facility. has been developed in accordance with the Unified Modeling Language notation for state machines (UML), but can also be used for designing state/event systems compliant with the Mealy notation. This chapter gives an overall description of: The tools State machines Statechart diagrams. The tools The software comprises the following tools and standard APIs: Navigator: A browser-based shell facility for the overall handling of Projects and files. It is also used for launching the other modules of the software. Designer: A graphics-based application for designing statechart diagrams using the UML notation. Validator: A graphics-based application for simulation, analysis and debugging of Systems developed with Designer. Verificator: A powerful program for dynamic formal verification of models. Coder: Can automatically code generate models created with Designer. Documenter: Is used to create documentation reports on models. 13

14 State machines OSEK Kit: Provides a user-friendly interface to using the software in an OSEK environment. APIs: Basic API, Expert API. For detailed information on how to use the tools and APIs, refer to the relevant user documentation. State machines A state machine is a specification of the dynamic behavior of a model. A state machine consists of a finite set of states and a collection of transitions (see State and Transition). A state machine can be in one and only one state at a time. See Figure 1, page 14. StateMachine1 StateMachine2 StateB StateMachine3 StateA E1() / E2() / StateC StateE E3() / E4() / StateD StateF Figure 1: Example of a state machine is used to model hierarchical state machines as described in the UML. Thus a state machine may contain other state machines. This is the case if one of the states in the state machine is a superstate or if the state machine contains a do reaction. A superstate will map to one state machine if it is composed of mutually exclusive states. If the superstate is composed of concurrent regions, each region will map to a state machine. A do reaction maps to a single state machine. Each of these state machines may again contain other state machines (see Composite state, page 27, and Do reaction, page 59). 14

15 Introduction Statechart diagrams In, statechart diagrams are used to model state machines. Each statechart diagram models a hierarchy of state machines (see Figure 2, page 15). A state machine and hence a statechart diagram is composed of states and transitions (see State and Transition). The statechart diagram shown in Figure 2, page 15 models a (simple) air conditioning unit for a car. The model is composed of different state types. Figure 2: Statechart diagram of an air conditioning unit The logic of a statechart diagram is contained in a Statechart file (see Statechart file, page 20). If the Statechart file contains several concurrent regions, each concurrent region will be represented in its own independent statechart diagram (see Region, page 28). Do reactions and off page regions are also modeled in separate statechart diagrams (these constructs are described in Do reaction, page 59 and Off page region, page 29). 15

16 Statechart diagrams 16

17 Projects, Systems and files This chapter gives a description of the different types of files and how they are related to each other. It also describes instances, and global and local elements. File hierarchy The files are structured in a hierarchy so as to ensure the logical consistency of the final application. The file hierarchy comprises Projects and Systems (see Figure 3, page 17). The practical handling of Projects, Systems and files is by means of the tree browser of Navigator. For information about how to use the Navigator, refer to User Guide. Project A Project is a collection of Systems. The Systems group the individual Statechart files together. Thus each Project is capable of containing several statecharts, as shown in Figure 3, page 17. See System, page 18, and Statechart file, page 20. Project System System System Statechart Statechart Statechart Figure 3: Project structure 17

18 System In addition to binding Systems and statecharts together, a Project contains elements that are shared across Systems. These elements are termed global elements and are described in Global and local elements, page 22. The Project data is stored in a Project file which has the name extension vsp. Figure 4, page 18 shows the structure of a Project as it can be viewed with the tree browser of Navigator. Figure 4: Example of a Project The Project shown in Figure 4, page 18 is named 'Car'. The Project contains two Systems named 'AirCondition' and 'Viper' respectively. System A System is a collection of one or more Statechart files (name extension vsr), i.e. the logical representation of state/event models. If state/event models are grouped in the same System, they can be synchronized to each other via state conditions (see State condition, page 49). Thus their behavior can be affected by the behavior of the other state/event models within the same System. For example, if you want to create a state/event model for a car light that is to react to the behavior of the model for the car locking system, it is a good idea to include the two models in the same System. If two models within a Project are to operate independently of each other, a System for each model should be created (see Figure 3, page 17). 18

19 Projects, Systems and files In target, the logical unit of is the System. Thus when an event occurs, it is interpreted on a per System basis. So although a System may contain more than one hierarchical state machine (see Introduction and State), the event occurs for all state machines in this particular System. If the Project consists of more than one System, and the Systems share an event, or in other words, they must react to the same event, the event handling mechanism in target must ensure that the event occurs once for each System. This principle is shown in Figure 5, page 19. Event queue 1 System 1 Event API Event Event queue 2 System 2 Figure 5: Event handling Figure 5, page 19 shows the interaction between and the external environment. The event happens physically in the external environment, and is added to the event queue of the individual System. From there the event is sent into the API on a per System basis. This event queue must be created by the developer. SYSTEM TYPES In it is possible to design two types of System: UML System Safe Mode. 19

20 Instances UML System A UML System is a System that is designed in accordance with the Unified Modeling Language specification for statechart diagrams. UML System is the default System notation, and when it is used, it is possible to apply all the elements available in. Safe Mode Safe Mode should be used in cases when you want to be sure that the design is verifiable with Verificator. When you use Safe Mode, a warning will be given during the design process if a non-verifiable element is used. Otherwise there is no difference between UML System and Safe Mode. For a list of verifiable elements, refer to User Guide. Instances If you want to be able to control multiple identical units by means of the same state machine design, you can use instances. Instead of taking a copy of the code for each individual unit, you create instances which in principle are a copy of the data for the unit. It is only possible to change instance when a macrostep has been finished (for a description of macrosteps, see Signal, page 45). At runtime is capable of handling more than one instance of each System. Each instance has its own state configuration and its own copy of the internal variables so that the instances are completely independent of each other. Only one instance can be active at a time. The API is used to activate an instance. Statechart file A Statechart file (extension vsr) is a file that contains the logic information about the designed model, for example states and transitions. The Statechart file represents a way of modularizing a System. When a System is split into more than one Statechart file, it is possible to gain the benefits of team development on the same System. There are two different logical interpretations of a Statechart file: If a System only consists of one Statechart file, then the topstate of the Statechart file represents the topstate of the System (see Topstate, page 26). 20

21 Projects, Systems and files If the System consists of more than one Statechart file, then two more levels in the state hierarchy will automatically be introduced: A System topstate. A region for each Statechart file. The topstate of each Statechart file will then be inserted as a state in a region in the topstate of the System. This aspect is illustrated in Figure 6, page 21. Topstates of statechart files Figure 6: Statechart files in the state hierarchy Figure 6, page 21 shows the state tree structure of a loaded Project as it appears in the System window of Validator. The call-outs pinpoint the topstates of the Statechart files. The loaded Project contains two Systems, named AirCondition and Viper respectively (the names of the files in the Project are shown in Figure 4, page 18). The AirCondition System is made up of one Statechart file called AirCondition. The Viper System is made up of two Statechart files called FrontViper and RearViper, which are contained in the regions MergedTopRegion0 and MergedTopRegion1 respectively. The Statechart file again is divided into one or more regions or mutually exclusive states (see Region, page 28 and Composite state, page 27). 21

22 Global and local elements Global and local elements In the following elements are available: Events See Transition, page 39 Event groupssee Transition, page 39 Action functionssee Transition, page 39 Timer action functionssee Transition, page 39 SignalsSee Transition, page 39 Internal variablessee operands External variables See operands ConstantsSee operands. The elements can be either global or local. Global elements are defined at Project level, and have the scope of the Project, including all Systems contained in it. Local elements are defined at topstate level, and normally have the scope of the topstate itself (see Topstate, page 26). However, if two local elements are defined with the same name in multiple sibling topstates, they are interpreted as a single element definition having the scope of the parent System. In such cases, the element definitions must be retyped in exactly the same way in the sibling topstates. Note that although multiple definitions are made, they all define the same single element. Elements with overlapping scope cannot have identical names. In addition, names of elements of the types external variable and action function must have unique names throughout the entire Project (see Action function, page 51, and External variables, page 69). ELEMENT DECLARATIONS AND DEFINITIONS Every element must be designated as either a declaration or a definition. As in the C language, the general rule is that an element can be declared any number of times, but must be defined exactly one time. The only exception to this rule is that action functions and timer action functions can only be declared, but not defined (they are defined externally in user-written code). The scope of elements defined at the topstate level (local elements) is the System containing the topstate. The scope of elements defined at the Project level (global elements) is the entire Project. To refer an element defined at Project level or in another sibling topstate, a declaration of the element is required in the topstate that refers the element. External variables are special, because they always have scope of the entire Project, also when defined in a topstate. 22

23 Projects, Systems and files files and name extensions Table 2, page 23 lists the most commonly used files and their name extensions. File name extension File vsp Project files. Contain information on: the Systems that make up the Project the files that make up the Systems Coder options global element declarations state conditions between topstates. vsr Statechart files. Contain local element declarations and logic. bk<x> Designer backup files. vst Designer interval backup files. nws Navigator workspace files. vws Validator workspace files. vlg Validator log files and animation files. vsa Validator static analysis files. vda Validator dynamic analysis files. Validator workspace backup files. Table 2: file name extensions 23

24 files and name extensions 24

25 State This chapter describes the state construct and related constructs, such as Topstate Simple state Composite state Region Off page region Default state Initial state Shallow history state Deep history state The join and fork pseudostates The junction and connector pseudostates. Final states are described in Final state, page 59. Definition of state A state is a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event. In, a state machine moves from one state to another state if a specific event occurs. Depending on 25

26 Topstate the transition defined, specific conditions must also be satisfied for the state machine to move to another state (see Transition). There are different types of states having their own graphical representation and logical meaning, as described in this chapter. In general a state is diagrammed as a rectangle with rounded corners. It may consist of up to three different compartments (see Figure 7, page 26): The name compartment. In this compartment the name of the state is written. The state reactions compartment. This compartment holds a list of the state reactions of the state (see State reactions). The substate compartment. The two latter compartments are optional. Whether they are present or not depends on how the state is composed. Name compartment State reactions compartment Substate compartment Figure 7: Example of state compartments Topstate A topstate is the topmost state in a state hierarchy. A topstate is typically a composite state with a number of concurrent regions (see Composite state, page 27). In a state is referred to as a topstate in two situations: The topmost level of the state hierarchy in a Statechart file is referred to as a topstate. The topmost level of the state hierarchy in a System is a topstate. A topstate will always be active. Consequently, the only allowed state reactions in a topstate are entry reactions, which will be fired upon reset, and internal reactions. Exit reactions are not allowed state reactions in a topstate because they will never be 26

27 State executed. For a description of internal reactions, entry reactions and exit reactions, see State reactions. Note: If a System only comprises a single Statechart file, then the topstate in the Statechart file is also the System topstate. Simple state A simple state is a state at the lowest level in the state hierarchy, and it does not contain any other states or regions. Graphically a simple state is represented as shown in Figure 8, page 27. Figure 8: The simple state symbol A simple state may have state reactions (see State reactions). Composite state A composite state is a state composed of other states. A composite state is either composed of Two or more concurrent regions (see Figure 9, page 27), or Mutually exclusive states (see Figure 10, page 28). Figure 9: Composite state composed of concurrent regions A composite state composed of concurrent regions is sometimes referred to as a concurrent state. Each of the concurrent regions represents a state machine, and the 27

28 Region individual concurrent region is active as long as the containing composite state is active. The concurrent regions are separated by dashed lines. A composite state composed of mutually exclusive states is shown in Figure 10, page 28. Figure 10: Composite state composed of mutually exclusive states If a composite state is composed of mutually exclusive states, the composite state itself represents the state machine composed of the mutually exclusive states. If a composite state is active, one, and only one of the states in the state machine represented by the composite state will be active. Region Regions are used to represent state machines. They appear in the following different ways: As concurrent regions in the topstate, i.e. the top-level state machines in a Statechart file. Example: In Figure 6, page 21, AirCondition is an example of this. As concurrent regions in composite states. Example: See Figure 9, page 27. As automatically inserted concurrent regions if the System is composed of more than one Statechart file. Example: In Figure 6, page 21, MergedTopRegion0 and MergedTopRegion1 under the topstate MergedTopState (Viper) are examples of this. 28

29 State In the UML specification, concurrent regions are sometimes referred to as concurrent substates. Off page region Off page regions are used for modularizing complex models in statechart diagrams. They make it possible to move advanced control logic of a composite state to another statechart diagram instead of representing it directly in a composite state. The graphical representation of an off page region in the parent state is a small state chart symbol that indicates that the contained state machine is represented in its own diagram. An example of the use of an off page region is illustrated in Figure 11, page 29 and Figure 12, page 30. The runtime behavior of a composite state with an off page region is the same as the runtime behavior of a composite state containing a state machine directly. The difference between the two constructs is only their graphical representation in a statechart diagram. Figure 11: State machine with an off page region in the state On Figure 11, page 29 shows a device that can be in two different states: Off and On. State On in its turn contains other states, which are drawn as an off page region (see Figure 29

30 Default state 12, page 30). Figure 12: State machine contained in the off page region Figure 12, page 30, shows the state machine that is contained in the off page region in Figure 11, page 29. The two figures also illustrate that it is possible to compose a transition that crosses the parent/child boundary (and vice versa) from the containing state to the states in the off page region. This is accomplished by using connector states. The transition triggered by the event E_SETUP is an example of this. Default state An initial state represents a default state that is the source for a single transition to the default state of a composite state. There must be exactly one such initial state in every non-concurrent composite state. A shallow history state is a shorthand notation that represents the most recent active substate of its containing state (but not the substates of that substate). A composite state can have any number of shallow history states. A transition coming into one of the shallow history states is equivalent to a transition coming into the most recent active substate of a state. By having more transitions going into different shallow history states, you can let different conditions decide which default state you enter for each shallow history state. Exactly one transition must originate from each shallow history state to the default shallow history state. This 30

31 State transition is taken in case the composite state had never been active before or the history has been cleared when this shallow history state is entered. A deep history state is used as a shorthand notation that represents the most recent active configuration of the composite state that directly contains this pseudostate; that is, the state configuration that was active when the composite state was last exited. A composite state can have any number of deep history states. Exactly one transition must originate from the deep history state to the default deep history state. This transition is taken in case the composite state had never been active before or the history has been cleared when this deep history state is entered. Upon entering a non-concurrent composite state, the following cases are differentiated: Default entry: Graphically, this is indicated by an incoming transition that terminates on the outside edge of the composite state. In this case, the default transition is taken. Explicit entry: If the transition goes to a substate of the composite state, then that substate becomes active and its entry reaction is executed after the execution of the entry reaction of the composite state. This rule applies recursively if the transition terminates on a transitively nested substate. Shallow history entry: If the transition terminates on a shallow history state, the active substate becomes the most recently active substate prior to this entry, unless the most recently active substate is the final state or if this is the first entry into this state. In the latter two cases, the default history state is entered. This is the substate that is destination of the transition originating from the history pseudostate. Deep history entry: The rule here is the same as for shallow history except that the rule is applied recursively to all levels in the active state configuration below this one. Initial state When the source of the initial transition is an initial state, the initial transition is fired and the default state is entered when: 1 The owning state machine becomes active and, 2 The destination state of the transition causing the state machine to become active is not contained in the state machine or one of its descendants. 31

32 Initial state For example, if the owning state machine is a composite state, and the transition causing the machine to become active has this composite state as its destination state, the default state becomes active. Figure 13, page 32 shows an example of an initial state and a default state. Default state Initial state Figure 13: Example of an initial state and a default state In Figure 13, page 32, state A is the default state, which is indicated by the transition from the initial state into state A. This means that upon reset, state A is entered. When event E1 occurs, the state machine will go from state A to composite state B. Because the state machine contained in composite state B is being activated, it will first enter its initial state and from there immediately enter its default state C. State C represents a state machine which will enter state E. 32

33 State Shallow history state Shallow history states behave as described in the UML specification. If a shallow history state is to have any effect, the transition must go to the history state (and not to its parent, as in version 4.x and earlier of ). To use a shallow history state, place one at the level where you want it and make a transition point to it. There should be exactly one outgoing transition from the shallow history state to another state. The first time the transition to the shallow history state is taken, the state pointed to by the outgoing transition from the shallow history state will be entered. The next and every following time the transition is taken the state machine will remember its previous state, until a final state inside the state machine is entered and the history is cleared. Figure 14: Example of the use of shallow history state Figure 14, page 33 shows the same example as the one shown in Figure 13, page 32. The difference between the two figures is that in Figure 14, page 33, state B contains a 33

34 Shallow history state shallow history state and not an initial state. The first time state B is entered, the result is the same as in Figure 13, page 32. The series of screen captures below shows the results of sending the following sequence of events upon reset: E1(), E2(), E3(), E1(), E1(). 1. Reset of state machine => The state machine will be in the default state A. 2. Event E1 is sent => The state machine enters state B and its default state C. State C represents a state machine which will enter state E. 34

35 State 3. Event E2 is sent => The state machine enters state G which is the default state of the state machine that is represented by state machine D. 4. Event E3 is sent => The state machine enters state H. 5. Event E1 is sent => The state machine enters state A. 35

36 Deep history state 6. Event E1 is sent => The state machine enters state B. Because state B contains a shallow history state, it will enter state D. Figure 15: Effect of using the shallow history state The difference between using an initial state and a shallow history state can be seen from the fact that when the state machine reenters state B, state D is entered and not state C. Thus state B has a history of the state it was in when it was left. You can have both a shallow history state and an initial state in a state. All transitions that go to the border of the state enter the initial state, and all transitions that go to the shallow history state will go to the history state. Deep history state Deep history states behave as described in the UML specification. If a deep history state is to have any effect, the transition must go to the history state (and not to its parent, as in version 4.x and earlier of ). To use a deep history state, place one at the level where you want it and make a transition point to it. There should be exactly one outgoing transition from the deep history state to another state. The first time the transition to the deep history state is taken, the state pointed to by the outgoing transition from the deep history state will be entered. The next and every following time the transition is taken the state machine will remember its 36

37 State previous state, until a final state inside the state machine is entered and the history is cleared. The behavior obtained by using the deep history state with a state machine is the same as the behavior obtained by using the shallow history state with the same state machine and all state machines below in the hierarchy. An example of using the deep history state is shown in Figure 16, page 37. The example is the same as the one in Shallow history state, page 33. However, in Figure 16, page 37, state B has been changed to contain a deep history state. Assume that the following sequence of events is sent: E1(), E2(), E3(), E1(), E1(). The effect will be that upon re-entering state B, the state machine remembers the last state it was in at all lower levels in the hierarchy before it was left. In contrast to the shallow history example it is now remembered that the state machine represented by state D was in state H. Note: If a deep history state is used, an initial state must still be applied to each state machine in the hierarchy below the deep history state. Note: If the design contains a deep hierarchy, for example in the case of a off page region, the use of the deep history state will create a very complex model. It may be quite difficult to foresee the consequences of the deep history state at the lower levels of the hierarchy. Figure 16: Example of the use of a deep history state 37

38 The join and fork pseudostates The join and fork pseudostates Join and fork states have the same behavior as described in the UML specification. Join states serve to merge several transitions emanating from source states in different concurrent regions. The transitions entering a join state cannot have transition descriptions. Fork states serve to split an incoming transition into two or more transitions terminating on destination states in different concurrent regions. The transitions outgoing from a fork state cannot have transition descriptions. The junction and connector pseudostates Junction states have the same behavior as described in the UML specification. Junction states are semantic-free states that are used to chain together multiple transitions. They are used to construct compound transition paths between states. For example, a junction can be used to converge multiple incoming transitions into a single outgoing transition representing a shared transition path (this is known as a merge). Conversely, they can be used to split an incoming transition into multiple outgoing transition segments with different guard conditions. This realizes a static conditional branch, meaning that the evaluation of the guard conditions do not depend on any action expressions located on transition segments before the junction. Connector states are similar to junction states. Connector states exist in (connected) pairs with identical names. Connector states are used to construct compound transitions that cross an off-page boundary. 38

39 Transition This chapter describes the transition constructs and the elements of transitions, including Trigger Guard expression State condition Action function Assignment State action. Definition of transition The concept of transition is similar to that of the UML. Thus, a transition is defined as a relationship between two states indicating that a state machine in the source state will perform certain actions and enter the destination state when a specified event occurs, and provided specified conditions are satisfied (see Figure 17, page 39). In, a transition must always have a trigger, either an implicit or an explicit trigger (see Trigger, page 43). Graphically, an ordinary transition is rendered as a solid line with an arrowhead at the end pointing at the destination state. Beside the line, the description of the transition is placed. Figure 17, page 39 shows an ordinary transition between the source state State_1 and the destination state State_2. Transition description Source state Destination state Figure 17: Example of an ordinary transition 39

40 transition types Note: In the UML specification, destination state is referred to as target state. transition types The following types of transitions are available in : Ordinary transitions (see Figure 17, page 39). Completion transitions (see Completion transition, page 60). Transition description The description of a transition is divided into a condition side and an action side. The condition and action sides are separated by a slash (/). See Figure 18, page 40. Condition side Action side E1 () [(x == 0)] A!B / [x = A1()] A2() D ^S1 Figure 18: The condition side and action side of a transition Figure 18, page 40 shows an example of a transition description with its condition side and action side. Before the action side can be executed, all conditions on the condition side must be satisfied. Thus the transition in Figure 17, page 39 covers the following: If then the System is in state State_1 the event E1() occurs the variable x equals 0 the System is in state A the System is NOT in state B assign the return value from the action function A1() to the variable x execute the action function A2() force the System into state D add the signal S1 to the signal queue enter state State2 AND AND AND AND AND AND AND AND 40

41 Transition CONDITION SIDE OF TRANSITION The condition side of a transition describes which conditions must be satisfied for the action side to be executed. The condition side is composed of a number of elements, as shown in Figure 19, page 41. Guard condition Trigger E1 () [(x == 0)] A!B Guard expression Negative state condition Positive state condition Figure 19: The condition side elements of a transition The relationship between the individual elements is shown in Figure 20, page 41. Condition side 1 Trigger 1 Guard condition 0...* Implicit trigger Explicit trigger Guard expression State condition 0...* 0...* Termination Do Entry Exit Event 0...* 1 Event group Signal Positive Negative Source state Figure 20: Condition side modeled as a (simplified) class diagram First a trigger must occur (see Trigger, page 43). In Figure 19, page 41, this is the expression E1(). A trigger can be an event, or an event group (which is a collection of events), or a signal. These types of trigger are termed explicit triggers. Note that only one trigger per transition is allowed. For example a trigger can be the entering of a state; this type of trigger is termed implicit trigger. When the trigger has occurred, the guard condition must be satisfied for the transition to fire. The guard condition includes guard expressions and state conditions. Guard expressions are expressions that can be evaluated to true or false. In Figure 19, page 41, 41

42 Transition description the guard conditions are contained in the expression [(x==0)] A!B Note: Guard conditions are not allowed for entry and exit reactions. State conditions can be either positive state conditions, negative state conditions, or source states (see State condition, page 49). ACTION SIDE OF TRANSITION The action side of a transition describes all the actions that will be executed if the conditions on the condition side are satisfied. Like the condition side, the action side contains a number of elements, as illustrated in Figure 21, page 42. Action expressions [(x = A1()] A2() D ^S1 Assignment Action function Signal State action Figure 21: The action side elements of a transition The relationship between the individual elements is shown in Figure 22, page 42. Action side 1 Action expression 0...* 0...* State action Signal Assignment Action function 0...* Force state action Destination state Figure 22: Action side modeled as a class diagram The action side consists of action expressions, state actions, and signals. In Figure 21, page 42, the action expressions are covered by the expression [(x=a1()] A2() 42

43 Transition Trigger In a trigger is what causes the condition side of a transition to be evaluated. Thus, when a trigger occurs, and the condition side is evaluated to be true, the transition will fire. There is always one and only one trigger per transition. In there are two types of triggers: explicit and implicit triggers (see Explicit trigger, page 43 and Implicit trigger, page 48). EXPLICIT TRIGGER As illustrated in Figure 20, page 41, an explicit trigger can be one of the following: An event, including event parameters. See Event, page 43. An event group, which is a collection of events. See Event group, page 44. A signal. See Signal, page 45. Event An event is something that happens in the external environment of a System (see Figure 23, page 43). In events are always processed sequentially. The event may cause the transition that it triggers to fire, provided the conditions on the condition side are satisfied. The transitions that fire will result in one or several actions. Event from external environment API Action(s) System Figure 23: Event processing in Because an event is considered a momentary input (such as a button that is activated), it must be captured and stored before it can be interpreted by. Note: The software developer must ensure that the software in the target application is capable of capturing the events required for the System. Furthermore the developer must specify a queue structure if such one is required for the target application. 43

44 Trigger Event parameter In an event can have parameters. An example of a parameter is the activation of a key on a numeric keyboard where the event describes that a key is being activated, and the event parameters describe which key is being activated. An event parameter can be declared as any of the allowed variable types (see variable types, page 67), and there is no limitation to the number of parameters with which an event can be declared. Event group An event group is a collection of disjunct events, and is used as an explicit trigger for a transition. When an event belonging to the event group occurs, it will trigger a specific transition, provided the transition conditions are satisfied. An event group in itself never occurs; only one of its events can occur. An event can be a member of more than one event group. Example: If several events can cause a state machine to go from one specific state to another specific state, this could be modeled as multiple parallel transitions, as shown in Figure 24, page 44. Figure 24: Multiple events resulting in the same change in state However, if the events triggering the transitions are included in an event group, it is only necessary to draw one transition, as shown in Figure 25, page 44. Figure 25: Example of the use of event group In Figure 25, page 44, the event group EG1 includes the events Event1 and Event2 shown in Figure 24, page

45 Transition Event groups can be used when several transitions have the same elements but different events. The use of the event group construct offers the following advantages: The design model is easier to grasp. Code size is reduced. Signal A signal is used for triggering transitions, like an event. In contrast to an event, which occurs in the external environment, a signal is sent internally in. Thus it functions as an internal trigger for. That is why signals are found on both the condition side and the action side of transitions. A transition can send any number of signals, and because an event can trigger more than one transition, there must be a mechanism for queuing up the signals that have been sent. This queuing up of signals is handled entirely by. In addition to explicit triggers, a special property trigger-less can be applied to the transition to indicate it has no explicit trigger. The resulting trigger-less transitions are especially useful in combination with choice vertexes, but they can be used on any transition. The trigger-less transitions are considered as part of macrosteps. 45

46 Trigger Macrosteps and microsteps At runtime, can deal with one event at a time, and the handling of an event is called a macrostep. Figure 26: Signal queue handling in Figure 26, page 46, shows how the macrostep includes the entire handling of the event. Each macrostep can be considered a number of microsteps. In each microstep you can have breakpoints that are evaluated in C-SPYLink and in the Validator. The handling of a macrostep starts with receiving the event to handle (A in the figure). The runtime code first takes a microstep (B), where it checks to see if there are any trigger-less transitions that are active. As long as at least one transition is active and causes any side effect (if any action functions are called, any assignments are performed, or any signals are added to the queue), a new microstep is taken looking at trigger-less transitions that are now active (similar to B). When there are no side effects from taking trigger-less transitions, the event that was sent to is then itself handled (C). After the event has been handled, the runtime code again loops around checking for active trigger-less transitions as described above (D). If any signals were added to the queue in the preceding part, the first signal is taken out from the signal queue and handled (E). 46

47 Transition As before, the trigger-less transitions that are now active and has side effects are then treated (F). The runtime code loops around in an iterative fashion at points E and F as long as there are any signals in the queue. When there are no more signals in the queue, and there are no side effects from looking at trigger-less transitions, the macrostep is completed and the runtime code is ready to handle the next event. Signal queue Each System has a signal queue whose size must be determined by the software developer. Thus the following issues should be considered carefully when designing a System that includes signals: Signal queue size Signal queue type is drop-if-full FIFO, which means that the queue size is static. The developer must pre-calculate the required size of the queue and set it so that no overflow will occur. If the System reaches the end of the queue, additional signals will not be added to the queue. However, the developer can specify that an error code is returned during runtime if the signal queue runs full. Note: The selected signal queue size is checked by the Verificator. Priority Signals have priority over events and can only be sent internally. Thus it is not possible to send signals from the external environment into the System. Live lock Because signals can trigger transitions, which again will send signals, the system can be brought into a live lock (see Figure 27, page 47). No mechanism is built in to handle this during runtime so the design should be examined carefully in order to avoid this situation. S1 / State1 Entry / ^S1 Self-transition Figure 27: Example of a live lock In Figure 27, page 47 an example of a live lock is shown. The entry reaction of State1 sends the signal S1. This triggers the self-transition, which upon re-entry into State1 will send signal S1, which again will trigger the self-transition etc. Thus a live lock has been constructed. 47

48 Guard expression IMPLICIT TRIGGER As illustrated in Figure 20, page 41, any of the following reserved keywords constitutes an implicit trigger: Entry (can only be used in state reactions. See State reactions) Exit (can only be used in state reactions. See State reactions) Do (can only be used in state reactions. See State reactions) Termination (can be used in completion transitions. See Completion transition, page 60). See Reserved keywords. Guard expression Guard expression is found on the condition side of a transition (see Figure 19, page 41). For a transition to fire, all guard expressions must evaluate to true. A guard expression is either a logical expression or a relational expression. A logical expression is one or more relational expressions separated by logical operators. A relational expression is composed of a left side, a relational operator, and a right side. The left side is either an external variable, an internal variable, an event parameter or a constant. The right side is a complex expression, involving operators and operands of different types. Example of a guard expression: (x >= 0) && (x < 10 + Action(7, 3)) The guard expression in this example is a logical expression that consists of two relational expressions with the variable x as the left side in both relational expressions. For detailed information about the guard expression syntax, see Syntax. DOUBLE BUFFERING Double buffering is a facility that automatically detects and optimizes variables used in guard expressions. Double buffering ensures that during the evaluation of guard expressions, the operands used in the evaluation have the same value as they had before the microstep started (see Figure 26, page 46). The principle of double buffering is that when a variable might be changed during a microstep, and the value of the variable might affect the logic of the system, then a copy of the variable is made. 48

49 Transition The reason for double buffering is that the occurrence of an event may result in more than one transition being triggered. This again may result in a variable value being changed by one transition and then used in a guard expression by another transition, in another region. Thus double buffering ensures that the evaluation of guard expressions is deterministic. State condition State conditions ensure that another state machine within the same System satisfies specific conditions before a transition fires. State conditions are found on the condition side of a transition, as shown in Figure 19, page 41. For a transition to fire, all conditions, including state conditions, must be satisfied. There are three types of state conditions: Source states Positive state conditions Negative state conditions SOURCE STATE The source state of a transition is the state from which a transition originates. The source state is a special case of state conditions which are found on the condition side of transitions. Source state applies to: Ordinary transitions (see Definition of transition, page 39 Completion transitions (see Completion transition, page 60) State reactions (see State reactions, page 55). 49

50 State condition POSITIVE STATE CONDITION A positive state condition is when another state machine must be in a specific state for the state condition to be satisfied. Only if the state condition is satisfied, will the transition fire. This principle is illustrated in Figure 28, page 50. Postive state condition Figure 28: Example of a positive state condition Figure 28, page 50 shows an example of a positive state condition in a security system. Here the purpose of the state condition is to ensure that the security system will only be armed if all doors are closed. This is achieved by the positive state condition in the state machine Alarm. The state condition is specified by the expression Closed on the transition from the state Idle to the state Armed. This transition will only go to the state Armed if the state machine Door is in the state Closed. 50

51 Transition NEGATIVE STATE CONDITION A negative state condition is the opposite of a positive state condition. Here the state condition is satisfied only if the state machine is NOT in a specific state. This principle is illustrated in Figure 29, page 51. Negative state condition Figure 29: Example of a negative state condition Figure 29, page 51 shows the same security system as the one shown in Figure 28, page 50. However, in Figure 29, page 51 the state condition is negative in that the door must NOT be in the state Open. This is specified by the expression!open on the transition from the state Idle to the state Armed. This transition will only go to the state Armed if the state machine Door is not in the state Open. Action function An action function is an action that is executed when a transition fires. An action function can be used on a transition in the following ways: As a function that has to be executed when a transition fires. A typical example of this use is the calling of a device driver. As an operand in guard expressions and assignments. In this case the action function has to return a value. In the target application, the action functions are user-written C functions. The activation of action functions is completely handled by which ensures fully deterministic action function sequencing of the system. As with ordinary C-functions an action function used in can have parameters and it may return a value. For the allowed types of action parameters and action function return values, see operands. 51

52 Assignment TIMER ACTION FUNCTION Timer action functions are a special case of action functions. They are reserved for starting a timer that is to cause an event to occur upon timeout. Return type of timer action functions is VS_VOID. Timer action functions accept two parameters: 1 The first parameter is the event. 2 The second parameter is the number of ticks before a timeout occurs. It is recommended to incorporate the following in the target application with regard to timer action functions: A timer action function for starting a timer, for example from a timer pool, with the specified number of ticks before a timeout. The event to be sent must be saved. Upon timeout, the timer response routine should send the event into the API to have it processed. Assignment Assignments are found on the action side of a transition, as illustrated in Figure 21, page 42. An assignment is the assigning of a new value to a variable. An assignment contains an assignment operator, in the form of =. On the left side of the assignment operator is the variable that is to be assigned a new value. On the right side of the assignment operator an entire expression can be written, using all allowed unary and binary arithmetic operators, logical operators or bit-manipulation operators, and all allowed operands or values (see operators and operands). Example of an assignment: x = A1() + 10 For detailed information about the assignment syntax, see Syntax. State action State action comprises force state action and destination state. See Figure 21, page

53 Transition FORCE STATE ACTION Force state action is a method by which another state machine can be forced into a specific state, regardless of its currently active state, and regardless of the transitions in this state machine (see Figure 30, page 53). Force state actions are found on the action side of a transition. Thus it will be executed when the transition fires. Door WashingMachine Motor Open Stop Force state action E_CLOSE() / E_OPEN() / Stop Interval Closed Running Figure 30: Example of the use of force state action Figure 30, page 53 illustrates the state machine WashingMachine. The state machine Motor will go to Stop each time the door is opened, regardless of the active state in the region Motor. This applies even if there are no transitions between the states in the region Motor. The reason is that in the state machine Door, there is a force state action named Stop on the transition from Closed to Open. Note: A force state action can be considered a transition from all other states in the state machine to the state being forced to. Thus it may seem a convenient and easy way to model potentially many transitions. However, force state actions could be compared to a goto statement in C which often results in a design that is more difficult to grasp. DESTINATION STATE The destination state of a transition is the state that a transition enters. Destination state is a special case of state action which is found on the action side of transitions. When a transition has been fired, the destination state will become the active state of the state machine. Destination state applies to the following types of transitions: Ordinary transitions (see Definition of transition, page 39) Completion transitions (see Completion transition, page 60) 53

54 State action 54

55 State reactions This chapter explains the state reaction constructs, including Internal reaction Entry reaction Exit reaction Do reaction Final state Completion transition. Definition of state reaction State reactions behave like transitions, but in contrast to transitions they do not change state. Whereas an ordinary transition has a source state and a destination state, a state reaction has no destination state and it is only associated with a single state. State reactions are fired or can be fired in the following cases: When the state machine is entered. While the state machine is in a state. When the state machine is exited. supports four types of state reactions, as illustrated in Figure 31, page 55. State reaction Entry reaction Exit reaction Do reaction Internal reaction Figure 31: State reactions Graphically, the state reactions are listed in the state reactions compartment of the state (see State). 55

56 Internal reaction Like a transition, a state reaction consists of a condition side and an action side, but in contrast to transitions, there are certain elements that are not allowed in state reactions. The individual state reaction types are described in Internal reaction, page 56, Entry reaction, page 56, Exit reaction, page 58, and Do reaction, page 59. Internal reaction An internal reaction is a transition that fires without leaving the state. Thus it has no destination state. Internal reactions are composed in the same way as ordinary transitions (see Transition). Figure 32, page 56 shows the use of internal reactions. Internal reactions Figure 32: Example of the use of internal reactions In Figure 32, page 56 two internal reactions are used to adjust the value of a variable. Note: Drawing a transition from a state and back to the same state (a self-transition) does not have the same logical implication as an internal reaction. An internal reaction never leaves the state and will thus not cause any exit and entry reactions to be executed (see Entry reaction, page 56 and Exit reaction, page 58). In contrast, a self-transition will actually leave and re-enter the state (see Figure 27, page 47). Entry reaction An entry reaction is an action that will be executed each time a state is entered. An entry reaction is triggered by an implicit trigger with the reserved name Entry each time a state is entered (see Figure 20, page 41). 56

57 State reactions Graphically an entry reaction is marked with the keyword Entry. No other conditions than the implicit trigger are allowed on entry reactions. Entry reactions are used instead of placing the actions on each of the transitions that enters the state. Thus initialization should be designed as entry reactions. The use of entry reactions offers the following advantages: It is easier to place the actions in the state instead of having to place them on each individual transition that enters the state. This also eliminates the risk of errors. It gives a much simpler graphical model because the actions are represented only once. When a model is modified, the action is automatically associated with a new entering transition. Example: See Figure 33, page 57 and Figure 34, page 58. The two statechart diagrams model exactly the same behavior. However, in Figure 33, page 57 the entry and exit reactions are placed in the state Auto. In Figure 34, page 58, the entry and exit reactions are placed on the individual transitions, giving a more complex graphical model. Figure 33: Example of the use of entry and exit reactions 57

58 Exit reaction Figure 34: Entry and exit reactions moved to ordinary transitions Exit reaction An exit reaction is an action that will be executed each time a state is exited. An exit reaction is triggered by an implicit trigger with the reserved name Exit each time a state is exited (see Figure 20, page 41). Graphically an exit reaction is marked with the keyword Exit. No other conditions than the implicit trigger are allowed on exit reactions. Exit reactions are used instead of placing the actions on each of the transitions that exits the state. The use of exit reactions offers the following advantages: It is easier to place the actions in the state instead of having to place them on each single transition that exits the state. This also eliminates the risk of errors. It gives a much simpler graphical model because the actions are represented only once. When a model is modified, the action is automatically associated with a new exiting transition. The example shown in Figure 33, page 57 and Figure 34, page 58 illustrates how the use of exit reactions gives a less complex graphical model. 58

59 State reactions Do reaction A do reaction (or do invocation), which is called a do activity in the UML specification (version 1.1), is an ongoing activity that is invoked when its parent state is entered. It is active until it enters its final state or leaves its parent state. No other conditions than entering the state are allowed when a do reaction is invoked. In a do reaction is logically interpreted as a separate state machine that is concurrent to whatever state machines may be contained in its parent state. The actual content of the do reaction is modeled in a separate statechart diagram. In the example shown in Figure 35, page 59, the do reaction is activated in the parent state Playing. Do reaction Termination transition Figure 35: Example of the use of a do reaction The do reaction contains a simple state named PlayTrack and a final state named PlayTrackfinal (see Figure 36, page 59). Final state Figure 36: The contents of the do reaction DoPlayTrack FINAL STATE In the UML, a final state is used to visualize that an object or a state machine has completed its operation. 59