The different versions of light switches which we discussed so far define a couple of states but are quite simple in that respect that at any time at most one single state is active. You may object that hierarchy made up of composite states features a set of active states. This is not really true. Composite states just group a set of states but are not independent of their sub states. Leaf states are the real active states and the activation of a leaf state implies that also all its parent states are active. The leaf states also inherit the parent states behavior. There are scenarios which require orthogonal states (sometimes also called parallel states or and states).

Additionally, there are also scenarios where calculation become so complex that you don’t want to maintain them within a statechart. In these cases operations can be applied.

To illustrate these concepts we define a variant of the light switch which includes a presence simulation. It behaves as if a person operated the light at sensible and irregular intervals although nobody is present. The presence simulation is active on certain hours of the day only, namely from 17:00 to midnight and from 07:00 to 10:00. Here the motion detection and the twilight detection are left out for clarity.

To define the presence simulation the orthogonal state Active is defined. It contains two sub regions which are independent of each other and are executed virtually in parallel (their order is relevant, though). Each region can contain one active state. Each region is caring about different aspects. The region schedule includes a single state which cares about scheduling the next changePresence event. This event in turn is consumed by the presence region which switches the light on and off.

The events changePresence, startSimulation, and stopSimulation are internal events (also called local events) which are raised by the statechart itself when a certain condition is fulfilled. They can’t be raised by the environment and are not visible externally. These internal events will be processed directly after the current event. So internal events can be used to chain multiple processing steps. The states Idle and Waiting raise these internal events.

The definition of Presence Simulation get quite complex. There are especially a couple of textual rules and expressions which include calculations. Additionally, a modeler may require functions which are not directly available within the statechart. However, itemis CREATE allows you to implement your own operations to overcome these limitations. An operation is called from the state machine itself, so you don’t have to care about when and how they will be called. Operations can receive arguments from the state machine and return a value, exactly like a normal function or method call. Operations are declared by the statechart but are not defined within the statechart and must be implemented externally. The presence simulation uses two operations:

1. get_hour to ask for the current time of day to decide if the presence simulation must be activated.
2. get_rand to ask for a random float to calculate a random waiting interval in minutes between WAIT_MIN and WAIT_MAX.

interface:
	var brightness: integer

interface hmi:
	in event switch
	in event toggleMode
	in event changeBrightness

interface simulation:
	var WAIT_MIN: integer = 5
	var WAIT_MAX: integer = 1200
	var UPDATE_PERIOD : integer = 2


internal:
	var wait_time: integer
	var hour: integer
	
	event changePresence
	event startSimulation
	event stopSimulation
	
	operation get_rand(): real
	operation get_hour(): integer