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

Strengths

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.

Weaknesses

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.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.