Statecharts can help program powerful systems

The statechart model of computation is arguably the most functionally descriptive model of system behavior. State-charts give programmers a high-level design tool with powerful scalability through programming concepts such as hierarchy, concurrency, and events. The statechart programming model is especially useful for designing complex systems that must respond to a variety of events, such as e...


The statechart model of computation is arguably the most functionally descriptive model of system behavior. State-charts give programmers a high-level design tool with powerful scalability through programming concepts such as hierarchy, concurrency, and events. The statechart programming model is especially useful for designing complex systems that must respond to a variety of events, such as embedded control systems and communications systems. Statecharts are most often used with other models of computation to program powerful systems.


This state diagram (Fig. 1) shows five states and seven transitions that illustrate how a vending machine operates.

History of statecharts

Statecharts, invented by David Harel of the Weizmann Institute of Science in the 1980s, derive their name from classic state diagrams. According to Harel, the purpose of the statechart diagram was to “extend conventional state-transition diagrams with…the notions of hierarchy, concurrency, and communication.”

In the years following the statechart’s introduction, several software tools appeared on the market for designing these diagrams, including I-Logix Statemate, The MathWorks, Inc. Stateflow software, Esterel SCADE, and recently the National Instruments LabView Statechart Module. More importantly, statecharts were adopted as a behavior diagram within the Unified Modeling Language (UML) specification, which is used widely for modeling embedded systems.

Statechart diagrams are very similar to sequential function charts (SFCs) in their approach to system behavior. The SFC language is part of the IEC 1131-3 family of languages for programmable logic controllers (PLCs). State-charts, on the other hand, are not typically used for PLC programming; rather, they are used to model software that runs on embedded real-time operating systems on microprocessor-based systems and single-board computers.

Statecharts and SFCs have common notions of states, transitions, and parallel execution but slightly different nomenclatures. For example, transition conditions in SFCs are referred to as guards in statecharts. The semantics of statecharts and SFCs also differ considerably. The visual representation of statecharts is based on state diagrams, while SFCs have a top-down approach that is more similar to a flowchart.

To begin understanding statecharts, it is best to start with the classic state diagram and then add the notions of hierarchy, concurrency, and events. The classic state diagram consists of two main constructs: states and transitions. In Fig. 1, the state diagram describes a simple soda vending machine with five states and seven transitions to illustrate how the machine operates. Fig. 2 shows a statechart that describes the behavior of the same machine. The notion of hierarchy and events reduces the number of states and transitions.

In the statechart, you can nest the “count coins” and “dispense” states within a superstate. You have to define only one transition (T3) from either of these two states to the “returning change” state. You can configure the T3 transition to respond to three events: soda dispensed, change requested, or coins rejected. Additionally, you can eliminate the “waiting for selection” state by introducing a “guard” condition to transition T2. Guard conditions must evaluate to “true” in order for the transition to occur. If the result of the guard condition is “false,” the event will be ignored and the transition will not take place.

Now expand the statechart to demonstrate the notion of concurrency by adding a temperature control element to the software within the vending machine. Fig. 3 shows how you can encapsulate the dispensing logic and the temperature control into an and -state. And -states are similar to simultaneous sequences in SFCs– they describe a system that is simultaneously in two states that are independent of each other. The T7 transition shows how statecharts can define an exit that applies to both sub-statecharts.

In addition to hierarchy and concurrency, statecharts have other features that make them valuable for complex systems. They have a concept of history, allowing a superstate to “remember” what substate within it was previously active. For example, consider a superstate that describes a machine that pours a substance and then heats it. A halt event may pause the execution of the machine while it is pouring. When a resume event occurs, the machine remembers to resume pouring.

The obvious question that arises when using statecharts is how do you define the execution of the states? State-charts do not represent a complete programming solution as compared to C or a ladder, for example. While you can write a complete application in C, statecharts usually require the use of an additional language for defining the state execution. This is similar to defining actions within SFCs.

Statechart users typically go with C, or some other text-based language, to define the actions within the states. Some statechart tools such as I-Logix Statemate allow you to generate C code that you can deploy to an embedded target. You can deploy the NI LabVIEW Statechart Module, which uses graphical data flow to define the actions of a statechart, directly to desktop systems, human machine interfaces (HMIs), programmable automation controllers (PACs) such as NI CompactRIO and PXI, and field-programmable gate arrays (FPGAs) within PAC hardware.


Complete system representation. State-charts describe the complete function and each possible state of a system. Use of statecharts helps eliminate the possibility of software “hangs” because you are forced to consider alternatives to which the software needs to respond.

Self-documentation. Statecharts are similar to graphical data flow in that they are self-documenting. A new member of a design team can look at a statechart diagram and quickly grasp the elements of a system.

Event response. The statechart programming model is especially useful for “reactive” systems, which are systems characterized by how they respond to inputs. You can define state reactions and transitions based on any combination of events.


Incompleteness. Statecharts are not complete. You must pair them with a different model of computation for defining state behavior. This is not a true weakness, however, because state-charts are not the right model of programming for state behavior.

Data communication. Statecharts do not represent data flowing between states well. While transitions show execution flow, they do not represent data. For the most part, data is passed through global variables that are not visible within the diagram representation.

The statechart model of computation offers embedded designers a sophisticated way to tackle complex application development. Statecharts are especially useful for programming event-response applications such as intricate user interfaces and advanced state machines used to implement dynamic system controllers, machine control logic, and digital communication protocols. Statecharts are also commonly used with dynamic system simulation.

Author Information

Gerardo Garcia is the National Instruments industrial and embedded software manager.

Programming methods series

Statecharts comprise the third installment in this series exploring different software programming methods. The goal of the series is to help programmers choose the best method of computation based on system requirements and architecture. The series covered ladder logic in March, textual languages in May, and function blocks in July. The final installment in September will cover simulation/modeling methods.

No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
The System Integrator Giants program lists the top 100 system integrators among companies listed in CFE Media's Global System Integrator Database.
Each year, a panel of Control Engineering and Plant Engineering editors and industry expert judges select the System Integrator of the Year Award winners in three categories.
This eGuide illustrates solutions, applications and benefits of machine vision systems.
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Additive manufacturing benefits; HMI and sensor tips; System integrator advice; Innovations from the industry
Robotic safety, collaboration, standards; DCS migration tips; IT/OT convergence; 2017 Control Engineering Salary and Career Survey
Integrated mobility; Artificial intelligence; Predictive motion control; Sensors and control system inputs; Asset Management; Cybersecurity
Featured articles highlight technologies that enable the Industrial Internet of Things, IIoT-related products and strategies to get data more easily to the user.
This article collection contains several articles on how automation and controls are helping human-machine interface (HMI) hardware and software advance.
This digital report will explore several aspects of how IIoT will transform manufacturing in the coming years.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Infrastructure for natural gas expansion; Artificial lift methods; Disruptive technology and fugitive gas emissions
Mobility as the means to offshore innovation; Preventing another Deepwater Horizon; ROVs as subsea robots; SCADA and the radio spectrum
Future of oil and gas projects; Reservoir models; The importance of SCADA to oil and gas
Automation Engineer; Wood Group
System Integrator; Cross Integrated Systems Group
Jose S. Vasquez, Jr.
Fire & Life Safety Engineer; Technip USA Inc.
This course focuses on climate analysis, appropriateness of cooling system selection, and combining cooling systems.
This course will help identify and reveal electrical hazards and identify the solutions to implementing and maintaining a safe work environment.
This course explains how maintaining power and communication systems through emergency power-generation systems is critical.
click me