how to show periodic call of a state machine in UML state diagram?

user_10468650 0
Viewed 147

I work in the field of embedded software. In a project, we are using a time-trigged software architecture so that each component is called periodically (with component's tick accordingly) and the component has a predetermined time to do its task.

Now suppose that one of these components has a state machine which is active whenever the scheduler calls the component. As the architecture is a time-trigged architecture, some time-based transitions in the state machine shall be synchronized with the component's call tick (suppose that the component is call every 10ms via the scheduler and , say, there is a transition from state A to B in the component's state machine that is triggered after 50ms).

The question is that is it necessary to show (in a way) the call tick of the component in its state machine? If so, how to show?

periodic-task state-machine scheduler embedded uml
3 Answers

A UML statemachine describes the behaviour of the system, not its implementation. Your method of calling each component at some time interval in order to progress/update its statemachine is an implementation detail.

The question is that is it necessary to show (in a way) the call tick of the component in its state machine?

So, no it is not necessary it would be an implementation constraint, and those should generally be avoided. The same statemachine would work just the same (at least for time triggered events) if you called each component asynchronously as fast as possible.

Your example:

 _____
|  A  |
|_____|
   | after 50ms/
   |
 __V__
|  B  |
|_____|

would work just the same, (and be more responsive for non-time triggered events).

The point is the UML state machine diagram should describe the required behaviour (i.e. the design) not the code or implementation. That is what it must do not the how it does it. You are not describing how to implement a statemachine here.

user_1689860

UML is agnostic on the diagram purpose: you may model the requirements, the high-level design, or the actual implementation. Whatever the purpose here, the key is separation of concerns. Therefore, in general:

  • If you want to show the timing of component interactions -- including at state level for some components -- you'd better go for a timing diagram. It does not show the general state machine but perfectly documents synchronization in a given scenario.
  • If you need to show active / on-hold states, you could consider two orthogonal state machines (i.e. one with your state machine, one for the process states, if both are independent)
  • If you have an important timing constraint, note it as a constraint in the diagram (i.e. { duration < 50 ms } ), rather than artificially defining timing events that are in reality just means to the end.

But if you cannot separate state transition and timing and precise timing it's part of your design, you may use time events as any other transition events:

  • after t for a relative time expression, i.e. a duration after having entered a state.
  • at t for an absolute time expression, e.g. a fixed time (e.g. 20:45) or a point in time (at 50 ms), the time origin being probably the very start of the state machine.
user_37234230

It sounds like the code servicing the "tick" should be disconnected from the general state machine of the target. Or rather, the state machine operates on a higher abstraction layer. The logic for providing data to the "tick" would be buried in some lower layer state handling code.

Store away data necessary to service the "tick" somewhere. If there's a lot of work to do for the MCU in relation to the "tick" time, then let some ISR or DMA design grab the latest available data when it's time to act, independent of the state machine. Or alternatively, if the MCU isn't busy and can easily finish one lap in it's main loop/state machine between ticks, you could even use a polling design.

user_5845180
Related