Archived: Introduction to UML Terminology in the LabVIEW Statechart Module

NI does not actively maintain this document.

This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.


This document examines the components and terminology associated with statecharts and the ways they are implemented within the NI LabVIEW Statechart Module.


Introduction to Statecharts

David Harel designed the statechart diagram to overcome the shortcomings of prior state machine representations by adding hierarchy, concurrency and communication. Statecharts were adopted as a behavioral diagram within the Unified Modeling Language (UML) specification. Using the NI LabVIEW Statechart Module, you can create applications using statecharts. By taking advantage of the abstraction that statecharts provide, you can efficiently develop complex applications while using LabVIEW to target desktop, real-time, field-programmable gate array (FPGA), and embedded targets.

A statechart comprises regions, states, pseudostates, transitions, and connectors. These tools are available in LabVIEW when you are developing a statechart diagram.

Statechart Regions

A region is an area that contains states. The top-level statechart diagram is a region within which states are placed. Additionally, you can create regions within states to take advantage of hierarchical designs by creating states within another state. This ability is illustrated in the image below where a substate has been created within a state using a region. Each region must contain an initial pseudostate. 

Statechart States

A state is a condition that a statechart can be in. States must be placed within regions and have at least one incoming transition. 

Entry and Exit Actions within States

Each state has an associated entry and exit action. An entry action is LabVIEW code that executes when entering a state. An exit action is code that is executed when leaving a state (just before transitioning to the next state). Each state has only one entry and exit action in which both are optional. The entry and/or exit executes the action every time the state is entered or exited when present.

You can access this code through the Configure State dialog box.



Static Reactions within States

You can further configure states to have static reactions. A static reaction is the action a state performs when it is not taking any incoming or outgoing transitions. An individual state can have multiple static reactions that can execute at each iteration of the statechart.    

Each static reaction comprises three components – trigger, guard, and action.

A trigger is an event or signal that causes a statechart to react. Asynchronous statecharts execute only after receiving a trigger – for example, a pushbutton or some user-interface interaction can produce a trigger. The trigger value is passed to the statechart that then acts based on the trigger. In synchronous statecharts, triggers are automatically passed to the statechart at periodic intervals. By default, the trigger value is set to NULL.

A guard is a piece of code that is evaluated before performing the action of the state. If the guard evaluates to true, the action code executes. If it evaluates to false, the action is not executed.

If the statechart receives a trigger that is to be handled by a particular static reaction, and the guard code evaluates to true, the reaction performs the action code. The action is LabVIEW code that performs the desired logic of the state. This can be reading inputs or internal state information and modifying outputs accordingly.

You can create static reactions through the Configure State dialog by creating a new reaction. Once you create a new reaction, you can associate it with a trigger and have guard and action code implemented. Only static reactions can be configured to have a trigger and guard.

Orthogonal Regions and Concurrency

When a state contains two or more regions, the regions are said to be orthogonal. Regions 1 and 2 in the diagram below are orthogonal.


Substates in orthogonal regions are concurrent, which means that while the superstate is active, the statechart can be in exactly one substate from each orthogonal region during each statechart iteration. Concurrency is different from parallelism. Concurrent substates take turns being active during each statechart iteration, whereas parallel substates are active simultaneously. The LabVIEW Statechart Module does not support parallel state activity.

Description of a Transition

Transitions define the conditions that statecharts move between states. 

Transitions consist of ports and transition nodes. Ports are the connections between states, and transition nodes define the behavior of the transition using triggers, guards, and actions. You configure transition nodes through the Configure Transition dialog.

Triggers, guards, and actions are identical in transitions as they are in states. A transition responds to a trigger, and if the guard code evaluates to true, the action is executed and the statechart moves to the next state. If the guard code does not evaluate to true, the action code is not executed and the statechart does not move to the state indicated by that transition.

Pseudostates and Connectors


A pseudostate is a statechart object that represents a state. The LabVIEW Statechart Module includes the following pseudostates:

Initial state – Represents the first state that occurs when entering a region. An initial state must be present in each region.

Terminal state – Represents the final state of a region and ends the execution of all states within that region.

Shallow history – Specifies that, when the statechart leaves and then returns to a region, the statechart enters the highest-level substates that were active when the statechart left the region.

Deep history - Specifies that, when the statechart leaves and then returns to a region, the statechart enters the lowest-level substates that were active when the statechart left the region. 


A connector is a statechart object that connects multiple transition segments. The LabVIEW Statechart Module includes the following connectors:

Fork – Splits one transition segment into multiple segments.

Join – Merges multiple transition segments into one segment.

Junction – Connects multiple transition segments.

Statechart Iteration Sequence

The first iteration of the statechart executes the following two steps:

  1. Takes the transition to the state that the top-level initial pseudostate specifies.
  2. Executes any entry action of this first state and any specified substates.

After which the statechart performs the following actions when it receives a trigger:

  1. Reacts to this trigger.
  2. Checks the internal trigger queue.
  3. Reacts to any triggers in this queue.
  4. Checks the internal trigger queue again.

The following diagrams show a full iteration of an asynchronous statechart. Synchronous statecharts behave the same, but they do not receive external triggers.

The following figures show detailed views of processes A, B, and C in the previous figure. Items 1, 2, and 3 are the results of these processes.

Related Links

To obtain more information on the LabVIEW Statechart Module, visit