A high-level programming tool for complex systems

01 October 2007

Statecharts are commonly used to design state machines that model the behaviour of real-time and embedded systems. They depict event occurrences and responses and are used for designing digital
machine controllers and system-protection applications.

The statechart model of computation is arguably the most functionally descriptive model of system behaviour. 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.

History of statecharts
Statecharts, invented in the 1980s by David Harel of the Weizmann Institute of Science in Rehovot, Israel, derive their name from classic state diagrams. According to Dr. 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 behaviour diagram within the Unified Modelling Language (UML) specification, which is used widely for modelling embedded systems.

Statechart diagrams are very similar to sequential function charts (SFCs) in their approach to system behaviour. However statecharts 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 singleboard 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.

The classic state diagram
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 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 substatecharts.

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, similar to defining actions within SFCs.

Statechart users typically use 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 fieldprogrammable 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 system.

Event response. The statechart programming model is especially useful for ‘reactive’ systems, which are systems characterised 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 behaviour. This is not a true weakness, however, because state-charts are not the right model of programming for state behaviour.

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

The LabVIEW Statechart Module
The National Instruments LabVIEW Statechart Module offers a programming model for designing applications at a higher, more abstract level. Programmers can develop statechart diagrams; define behaviours with LabVIEW dataflow programming; and execute the statecharts on desktop PCs, embedded real-time controllers, and FPGAs.

Statecharts are especially ideal 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. Statechart diagrams also complement the existing LabVIEW models of computation, which include graphical data flow, interactive configuration, text-based math and dynamic system simulation diagrams.

—Gerardo Garcia, National Instruments.