In the first part of this series, we used YAKINDU Statechart Tools to model the behaviour of a blind control as a state machine, and we discovered basic elements of the modeling language, such as states, transitions, or events.
In this second part we will look at other concepts and issues:
- How can actions be initiated based on clock time?
- How can a state have internal states (composite state)?
- How can different state automatons work side by side (orthogonal regions)?
The processing of elapsed time and reaction to it are important concepts for automatic state machines. Some examples might be:
- A traffic light control system that controls the respective duration of the red, yellow and green phases, either periodically – i.e. time-controlled – or triggered by requests.
- In technical installations – from the simple coffee machine example through motor vehicles to a nuclear power plant – maintenance intervals must be observed to ensure the proper functioning of the system. Maintenance might be triggered by specific performance issues of the system, or by a time sequence, whichever occurs first.
- An administrative act might become legally effective after the expiry of a period for its opposition unless an objection is filed beforehand.
- In a data communication protocol with a positive acknowledgment method, a message may be deemed lost if the sender does not receive a reception acknowledgment from the recipient within a predetermined time (timeout).
All these scenarios can be modeled using state machines and either directly controlled by software (traffic light, data communication) or supported by it (maintenance, administrative act).
We will extend our blind control system with time-controlled events to show how to operate the blinds automatically depending on the ambient brightness. In bright sun the blind should darken the room: if the brightness decreases, the blind should go up. We have already implemented a similar requirement: raising the blind in a strong wind to avoid damage. Since the wind speed always has priority over user requests, the modelling was quite simple, limited to two state transitions that trigger in strong winds and an additional condition that prevents the user from moving the blind down.
Controlling the blind based on environmental brightness is more complex, because different influencing variables intermesh. On one hand the blind control should react to the ambient brightness as described and adjust the blind automatically. On the other hand, users’ wishes should be taken into account: if someone wants bright sunlight in the room and operates a blind that has been lowered automatically, the blind control system should respect this choice and not try to oppose the users’ actions. If the user does not operate the blind for an extended period of time – this is where the time aspect comes into play – or if they have left the room, automatic behaviour should be resumed.
The basic idea is simple and can be explained by the following state machine:
The statechart above is limited to measuring the ambient brightness and initiating a corresponding response. Initially the state machine is in the state Sensing, in which it continuously polls the ambient brightness. As soon as the brightness – contained in the variable Sun.brightness – reaches or exceeds the specified Sun.BRIGHT threshold value, the machine performs the transition Sensing → Waiting. This transition triggers the Sun.down event, which is intended to shut the blind.
In the Waiting state nothing happens. Users can adjust the blind as they like and the automatic operation will not intervene as long as the wait is active. However, this is not always the case: the transition Waiting → Sensing returns to the state in which the control system measures the sun’s brightness and responds accordingly. This transition is triggered "after 4 * 60 * 60 s", i.e. four hours after activation of the Waiting state.
Combining several state machines
It would be nice if we could combine this simple state machine with the one we have already developed, so that the generated event Sun.down is effective there. The result looks like this:
This figure shows two so-called orthogonal regions. Both contain their own state diagram. While the area main region is waiting for a user request or strong wind, the ambient light control area simultaneously checks the ambient brightness. The state of the overall system thus consists of the states of its orthogonal regions. However, orthogonal ranges are not completely independent: when ambient light control changes from Sensing to Waiting the operator raise generates a Sun.down event to which the main region area reacts, and the blind should close. For this to happen, the transition Idle → Moving down requires the Sun.down event as another triggering event.
The simulation mode of YAKINDU Statechart Tools allows us to enter the ambient brightness value. If the value of Sun.brightness is 80 or higher, the result looks like this:
The blinds should not only close depending on the ambient brightness, but also open. If we want to support independent wait times for both functions, we duplicate the ambient light control area, adjust it for a brightness value, and extend the main region with a reaction Sun.up in the same way as we did before:
Orthogonal areas execute YAKINDU Statechart Tools sequentially within repetitive processing cycles. This is relevant when the raise operator creates an event in area A that is to be processed in area B. However, each event only exists within the current processing cycle, so the execution of area A must occur before area B is reached. For more information on this, see "Raising and processing an event" in the YAKINDU Statechart Tools documentation.
Composite states
Now consider the following scenario: on a cloudy day the sun is continually breaking through, then disappearing behind dense clouds. In this case the blind should not be moved up and down continuously, nor should it close in response to the first bright but short interval and then remain down for hours. It should restrict the sunlight only when it remains permanently bright outside, i.e. if the environmental brightness has not merely exceeded the threshold for a short time.
This behaviour is modeled as shown in another figure. If the ambient brightness is below the threshold, the Not bright state is active. If it exceeds the threshold value, the state machine changes to the Almost bright state. Effectively this is saying “It is bright outside, but we are not sure if it will last long”. We should therefore wait a little longer before we close the blind. As long as we are in the Almost bright state and the ambient brightness falls below the threshold, maybe because a cloud blocks the sun, the state machine immediately goes back to Not bright, only to jump back to Almost bright shortly afterwards. The transition leading to Waiting is triggered and the blind is lowered only when Almost bright is active for 10 minutes without interruption. This works because the period specified as the operand after is restarted each time the source state of the transition becomes active.
The figure above also shows an extremely useful way to keep state diagrams manageable and structured: the composite state. The more states and transitions an state machine contains, the less clear the graphical representation becomes, when it should actually provide clarity. It becomes difficult to keep a view of the whole machine and to recognize structures and logical connections. In the extreme, in state diagrams with hundreds or thousands of states, this becomes completely impossible.
Composite states put structure and modularization into the diagram. A composite state contains inner states and state transitions and can thus encapsulate functionality. In the example of the blind control system the functionality of delayed darkening is in the combined state Sensing. A transition can lead to a compound state as such, but also directly to one of its inner states. The transition Waiting → Sensing shows an example of the former. Leaving a composite state can be done by transitioning from an internal state to a state outside the composite state, for example Almost bright → Waiting. But a composite state as such can serve as the starting point of a transition. Such a transition is then triggered when the execution of the composite state reaches a final state or an exit node.
The composite state Sensing has only a single range. However, composite states may well comprise several orthogonal regions, as we have already seen in the top level of the model.
YAKINDU Statechart Tools allow the user to simplify the presentation further by hiding the interiors of a composite state in a subdiagram, as shown in the figure below.
Sensing now looks almost like a "normal" state: only the small symbol at the bottom right of the state indicates that it is a composite state. This type of representation saves a lot of space. The chapter "Using subdiagrams" in the YAKINDU Statechart Tools documentation discusses this further.
The graphical modeling language of YAKINDU Statechart Tools allows you to enter composite states via any number of named entry points (entries) and exit via any number of named exit points (exits). For the sake of clarity and intelligibility the number of these entry and exit points, as well as the number of transitions in and out, should be kept as small as possible.
Further possibilities for improving the model
The response of the blind control system to changes in ambient brightness can be further improved. Instead of every automatic opening or closing waiting for an extended period regardless of whether someone wants to change the blind’s position, it would be more flexible and comfortable to only let the automatic operation wait for a specific time if the user actually presses the [↑ ] or [↓] button.
In this context we might also consider combining the two orthogonal areas ambient light control 1 and ambient light control 2 into a single area and simplifying the working of the machine. This is left to the reader as an exercise.
In the third part of this series, I will show how state machines can be translated into other representations, for example into source code of a programming language. We will – at least in principle – see how to integrate the source code generated by YAKINDU Statechart Tools into an environment to sample real light sensors and to drive real motors.
To read the whole “How to use state machines for your modeling” series, download our whitepaper for free.
Comments