AN: Capstone Dive Computer Example - Quantum Leaps

More documents

Recommendations

Info

Application Note: Capstone Dive Computer Example www.state-machine.com The state machine in Figure 5 reflects the structure of the requirements, which divide the behavior of the Dive Computer into “always”, “at the surface”, and “while diving” categories. The state “always” contains the actions of the Dive Computer in the “always” category. The substate “surfaced” performs all actions from the “at the surface” category. Finally, the substate “diving” performs all the actions in the “while diving” category. NOTE: This design makes use of the state nesting feature of the modern UML state machines. State nesting allows the “always” state to have nested substates “surfaced” and “diving”, which inherit the behavior of their superstate. (1) The state transition originating at the black ball is called the initial transition. Such transition designates the first active state after the state machine object is created. An initial transition can have associated actions, which in the UML notation are enlisted after the forward slash “/”. In this particular case, the Capstone state machine starts in the “surfaced” state and the actions executed upon the initialization consist of subscribing to button events. Subscribing to an event means that the QP framework will deliver the specified event to the Capstone active object every time the event is published to the framework. NOTE: The UML intentionally does not specify the notation for actions. In practice, the actions are often written in the programming language used for coding the particular state machine, which is C in this case. However, to avoid clutter in the diagram, the action code must necessarily be abbreviated, so it conveys the meaning of the action, but might not necessarily be directly executable. The convention used in the code presented in this Application Note is that the C expressions refer to the data members associated with the state machine object through the “me->” prefix and to the event parameters through the “e->” prefix. For example, the action “me->ascent_rate = e->raw;” means that the internal data member ascent_rate of the active object is assigned the value of the event parameter raw. (2) The label entry below the state name denotes entry actions executed unconditionally whenever this state is entered. These actions consist in this case of arming the time events (timers) to post themselves periodically to the Capstone active objects. The me->heartbeat timer posts itself every ½ seconds while the me->dt_tts timer posts itself every 2 seconds. (3) The event name HEARTBEAT enlisted in the compartment below the state name denotes an internal transition. Internal transitions are simple reactions to events performed without a change of state. The HEARTBEAT event is generated by the me->heartbeat timer every ½ seconds, as described at step (2). This event triggers ADC conversion and toggles the heartbeat LED. (4) An internal transition, as well as a regular transition, can have a guard condition, enclosed in square brackets. Guard condition is a Boolean expression evaluated at runtime. If the guard evaluates to TRUE, the transition is taken. Otherwise, the transition is not taken and no actions enlisted after the forward slash “/” are executed. In the particular case of the B2_DOWN event, the guard condition checks whether the depth is displayed in meters (‘m’). If so, units of depth are changed to feet ‘f’ and the depth display is updated. (5) The guard [else] denotes a complementary guard to the guard already present in the state for the same event. Here, the B2_DOWN event triggers change of units to meters ‘m’ and the depth display is updated. (6-7) The event DT_TTS is generated from the timer me->dt_tts every 2 seconds. This event toggles between Dive-Time and Time to Surface (TTS). Copyright © Quantum Leaps, LLC. All Rights Reserved. 14 of 29
Application Note: Capstone Dive Computer Example www.state-machine.com Per the semantics of state nesting, the substate “surfaced” inherits all the behavior from its superstate “always”. The substate can override the inherited behavior and it can also define new behavior. 2.4.2 AlarmMgr State Machine The main responsibility of the Alarm Manager (AlarmMgr) state machine is to handle all alarm conditions autonomously. As shown in the sequence diagram in Figure 4, the Capstone active object sends only alarm requests and silences alarms based on the diving conditions. However, Capstone might end up requesting several alarms simultaneously, and it is up to the AlarmMgr to always play the highest-priority alarm at any one time. This includes the situation when an alarm is silenced, but others still remain active, in which case the AlarmMgr must keep playing the highest-priority alarm at that time. The AlarmMgr is designed generally, to handle any number of alarms (it is not hard-coded to handle only three alarms specified in the requirements). The design of the AlarmMgr state machine hinges on the data representation for alarms. The central data structure is the priority-set, which is provided in the QP framework. The priority set allows inserting elements numbered 1..n and removing elements. The set also allows discovering the highest-number event currently present in the priority set quickly and very efficiently. Figure 6 shows the state machine associated with Alarm active object. Figure 6 Alarm state machine. Copyright © Quantum Leaps, LLC. All Rights Reserved. 15 of 29
Page 1 and 2: QP state machine framework example
Page 3 and 4: 1 Introduction This Application Not
Page 5 and 6: Application Note: Capstone Dive Com
Page 15: Application Note: Capstone Dive Com
Page 19 and 20: (2) Each active object in the appli
Page 21 and 22: eturn Q_HANDLED(); } } (11) return
Page 23 and 24: (7) The memory buffer for the “sm
Page 31: Application Note: Capstone Dive Com

AN: Capstone Dive Computer Example - Quantum Leaps

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?