Time Events in State Machines#

In almost every embedded application, time-controlled activities are required. Examples include activities that run on a fixed cycle, activities triggered on a timeout, or the generation of specific signal patterns.

In UML state machines, a time event specifies an instant in time that triggers a transition once the specified time has elapsed—for example, a transition from state S1 to state S2 after one second.

Relative time events are used together with a trigger; the starting point is the moment at which that trigger becomes active. A relative time trigger uses the keyword after followed by an expression that evaluates to a time value, such as “after (5 seconds).”

Alternatively, an absolute time trigger uses the keyword at followed by an expression that evaluates to a time value, such as “Oct. 1, 2023, 12:00:00.”

While this looks very clear at first sight, it is not sufficient for code generation.

The first major problem is that there is no standard way to specify a timer ID or timer name for the timeout event. However, this is required in practice to associate the timeout with an underlying timer service. In embedded systems, it is not practical to create a new timer from scratch every time an after or at trigger is encountered. Quite the opposite—you just want to create a timer and reuse it in multiple places in a diagram. Of course, you could specify a name or ID in a linked UML comment or similar, but that is not an ideal solution.

The other big problem is that not all UML tools allow the specification of time events.

Finally, the code generator should not introduce any restrictions or constraints on the system’s time services. Yet meaningful use of time events would require the code generator to specify how time services are to be implemented—which would not always match your needs and would only add unnecessary restrictions.

So what is the proposed solution for implementing time events with the SinelaboreRT code generator?#

Two aspects must be considered when using timed transitions.

• All common ways of implementing timers in embedded systems must remain possible, and the code generator must not introduce new restrictions.
• All relevant information should be contained in the state diagram itself.

The recommended way is not to use the time event specification of the UML tools, but to use regular signal events. Timers can be “manually” created, started, or stopped in any action code. If static system initialization is required, timers can also be created at system startup. The underlying timer service of your choice (see below) simply sends the provided timeout events to the state machine input queue.

To indicate in the diagram that an event is a timer, it is recommended to use a naming convention and start the name of the timeout event with, for example, evTout.

In the following figure, a state machine uses two independent timers. One is configured as a cyclic timer and loops between S11 and S12. A second, one-shot timeout ends that loop after some time and stops timer1 on the transition to S2.

RTOS-based designs#

Each RTOS offers the possibility to define software timers. If a timeout occurs, a user-defined timeout function is called. In this function, the timeout event is then placed in the state machine event queue. Worked examples are available for VxWorks, FreeRTOS, and embOS.

Mainloop Designs#

In mainloop and foreground–background designs, you need some form of timer service. Often a hardware timer supplies the system tick. On each tick, a software timer service can check whether a timeout has occurred and then enqueue the corresponding timeout event for the state machine. An example of such a system appears in the low-power design example with MSP or low-power design example with PIC.

Conclusions#

Timed transitions can be implemented with signal events in a flexible way across many system architectures. All relevant information stays in the state diagram, so 100% of the state machine code can be generated—without hidden specifications and without imposing extra constraints on your system design.