Reference Manual For QP/C++ 8.1.5
Loading...
Searching...
No Matches
Algorithm Viewpoint

State Dynamics ViewpointInterface Viewpoint

Design Viewpoint


[SDS_QP_ALG]

Design Viewpoint: Algorithms.

Purpose

The Algorithm Viewpoint addresses the design concerns related to computational logic, control flow, data transformations, and decision-making mechanisms within the QP/C++ framework component. It provides a precise, implementation-oriented description of how the software operates, ensuring that the logic is correct, efficient, deterministic, analyzable, and traceable to requirements.

Design Concerns

The Algorithm Viewpoint frames the following concerns:

  • Explanation of algorithms applied
  • Analysis of algorithms regarding their correctness under various scenarios
  • Analysis of algorithms about their efficiency and time-space performance
  • Analysis of algorithms about their testability

QHsm Implementation View

The QP::QHsm class (see Figure SDS-CLS [13]) implements the state machine strategy optimized for "manual coding", but it is also supported by the QM modeling tool↑. This section describes the internal design of the QP::QHsm class, with the particular focus on the algorithms used for dispatching events to hierarchical state machines.

Remarks
This design viewpoint assumes understanding of dispatching events to a state Machine, explained in SRS Annex A. The QHsm Implementation View focuses on the State Machine Processor inside the QP/C++ Framework component. The related State Machine Specification (provided by the QP/C++ Application) is described in the QHsm Design View of this SDS document.

[SDS_QP_ALG_QHsm_dispatch]

Design view: QHsm event dispatching

Description

Dispatching events to a hierarchical state machine requires implementing the UML state nesting semantics, that is, propagating the event through all the levels of state nesting until it is handled or reaches the top state. To explain this process, it is convenient to represent the state nesting in a tree-structure, which is illustrated in SDS-SM-TRAN.

Figure SDS-SM-TRAN: Left: traditional state machine diagram. Right: corresponding tree representation.


To understand the general transition processing steps, consider the transition TRIG from state s1 to s2 in SDS-SM-TRAN while state s11 is active. The QHsm dispatch() operation must then perform the following steps:

Step [1] scan the state hierarchy, starting from the current state (s11), and check which state handles the current event (TRIG)

Step [2] if regular transition, exit the current state configuration to the transition source. This is the implicit transition segment labeled A in SDS-SM-TRAN.

Step [3] take the transition by exiting the source state configuration and entering the target state configuration. This is the implicit transition segment labeled B in SDS-SM-TRAN and its complexity depends on the transition topology.

Step [4] enter the target (s2) by recursively executing any nested initial transitions, if present (e.g., s2->s22). This is the transition segment labeled C in SDS-SM-TRAN.

Algorithm Step [1]

This portion is implemented as a loop, which calls the state-handler functions as long as they return the "superstate" status. The series of visited states is stored in an automatic array path[], as shown in SDS-SM-XPATH. NOTE: the depth of the path[] array limits the number of state nesting levels in QHsm-type state machines. This maximum nesting is also the natural limit for testing such state machines.

Figure SDS-SM-XPATH: Array path[] storing the path from the current state to transition source.


Algorithm Step [2]

This portion is implemented as a loop that over the path[] array to exit all states from the current state to transition source.

Algorithm Step [3]

This portion requires detecting the transition topology. The optimization criterion used in the transition algorithm is to minimize the number of invocations of state-handler functions, in particular the invocations with the reserved "empty" event, which serve only for eliciting the superstate of a given state handler. The strategy is to order the possible source-target state combinations in such a way that the information about the state hierarchy gained from earlier steps can be used in later states.

Algorithm Step [3a]

First, the algorithm attempts to identify one of the simple transitions depicted in Figure SDS-SM-STRAN. These also happen to be the most frequently used kinds of transitions. NOTE: this step is implemented as a separate QHsm operation tran_simple_() to reduce the cyclomatic complexity of the already complex dispatch() operation required for systematic capability (see [SDS_QP_MOD_01]).

Figure SDS-SM-STRAN: Simple transitions in the QHsm dispatch algorithm.


Decision/truth table [3a]

The following decision/truth table specifies the criteria for selecting the simple transition type A-D. The notation used in the table is as follows:

  • s — immediate transition source state
  • t — immediate transition target state
  • sup(s) — superstate of source state
  • sup(t) — superstate of target state
  • x — condition does not matter (no need to check)
s==t s==sup(t) sup(s)==sup(t) sup(s)==t transition type
TRUE x x x A
FALSE TRUE x x B
FALSE FALSE TRUE x C
FALSE FALSE FALSE TRUE D
FALSE FALSE FALSE FALSE Step [3b]
Table SDS-TBL-TRU3A: Decision/truth table for detecting simple transitions (types A-D).

Algorithm Step [3b]

If the transition turns out to be not simple, the algorithm attempts one of the complex transitions depicted in Figure SDS-SM-CTRAN. Unlike the simple transitions, complex transitions require iterative checking the state hierarchy (indicated by ... in the diagram). NOTE: this step is implemented as a separate QHsm operation tran_complex_() to reduce the cyclomatic complexity of the already complex dispatch() operation required for systematic capability (see [SDS_QP_MOD_01]).

Figure SDS-SM-CTRAN: Complex transitions in the QHsm dispatch algorithm.


Decision/truth table [3b]

The following decision/truth table specifies the criteria for selecting the simple transition type A-D. The notation used in the table is as follows:

  • s — immediate transition source state
  • t — immediate transition target state
  • sup(s) — immediate superstates of source state
  • sup...(s) — scan superstates of source state up to top state
  • sup...(t) — scan superstates of target state up to top state
  • x — condition does not matter (no need to check)
s==sup...(t) sup(s)==sup...(t) sup...(s)==sup...(t) transition type
TRUE x x E
FALSE TRUE x F
FALSE FALSE TRUE G, H
FALSE FALSE FALSE FAULT (see NOTE)
Table SDS-TBL-TRU3B: Decision/truth table for detecting complex transitions (types E-H).


Note
Condition indicated by FAULT should not occur in properly formed hierarchical state machine. Reaching this condition indicates that the QP/C++ Application specified a malformed state machine or exceeded the nesting level limit.

Algorithm Step [4]

Per the UML semantics, recursive entry to the target state configuration requires executing state entry actions into the target state configuration in the opposite order to the natural navigability through the QHsm state hierarchy. The applied algorithm reuses the path[] array to first store the sequence of target superstates in the natural order, and then "play it back" in the reverse order, as shown in Figure SDS-SM-EPATH. NOTE: this step is implemented as a separate QHsm operation enter_target_() to reduce the cyclomatic complexity of the already complex dispatch() operation required for systematic capability (see [SDS_QP_MOD_01]).

Figure SDS-SM-EPATH: Array path[] storing the entry path to the target state configuration.


Backward Traceability

  • [SRS_QP_REQ_220] QP/C++ Framework component shall provide a State Machine Implementation Strategy optimized for "manual coding."
  • [SDS_QP_QHsm] Design view: QP::QHsm State machine class.
  • [SDS_QP_SFM_07] Design view: QP/C++ Framework specification shall support semi-formal method: decision/truth tables (HR).

Forward Traceability

QMsm Implementation View

The QP::QMsm class (see Figure SDS-CLS [14]) implements the state machine strategy optimized for "automatic code generation" (see SRS_QP_REQ_221), which requires the QM modeling tool↑. This section describes the internal design of the QP::QMsm class, with the particular focus on the algorithms used for dispatching events to hierarchical state machines.

Remarks
This design viewpoint assumes understanding of Dispatching Events to a State Machine, explained in SRS Annex A. The QMsm Implementation View focuses on the State Machine Processor inside the QP/C++ Framework component. The related State Machine Specification (provided by the QP/C++ Application) is described in the QMsm Design View of this SDS document.

[SDS_QP_ALG_QMsm_dispatch]

Design view: QMsm Event Dispatching

Description

Dispatching events to QMsm-style state machines can be more efficient than the QHsm dispatching because the determination of the transition chains (exit from source and entry to the target state configuration) can be performed at code-generation time rather than runtime. To store such information, QMsm-style state machine add new data structures that are initialized at the code-generation time (see also QMsm Design View).

State representation

A QMsm-style state machine represents each state as a conglomerate of following elements:

  • state handler function,
  • state entry action function (if present in the state),
  • state exit action function (if present in the state),
  • state initial transition function (if present in the state).
  • static and const object (allocated in ROM) containing:
    • pointer to the superstate, or NULL
    • pointer to the state handler function
    • pointer to the state entry action function, or NULL
    • pointer to the state exit action function, or NULL
    • pointer to the initial action function

Figure SDS-SM-QMSTATE: State object (const in ROM).


Transition-action tables

Additionally, each state transition is associated with a transition-action table that stores:

  • the target state
  • a table (array) of pointers to action functions
    • exit actions from the source state configuration
    • exit actions to the target state configuration
    • NULL terminator to mark the end of the table

Figure SDS-SM-QMACT: Transition-action table object (const in ROM).


Note
Transition-action tables are a specialized form of decision tables, corresponding to the Highly Recommended (HR) technique identified in IEC 61508-3:2010, TableB.7 (row7). They explicitly capture the actions associated with each state transition. All logical conditions and decisions required to select the correct transition actions are resolved at code-generation time, ensuring deterministic and fully traceable behavior in the generated implementation.

Algorithm Steps

The QMsm dispatch() operation must then perform the following steps:

Step [1] scan the state hierarchy, starting from the current state, and check which state handles the current event

Step [2] if regular transition, exit the current state configuration to the transition source. This is the implicit transition segment labeled A in SDS-SM-TRAN.

Step [3] take the transition by executing the transition-action table associated with the transition. This is the implicit transition segment labeled B in SDS-SM-TRAN.

Step [4] if transition to history, enter the recorded history state dynamically (the history state is not known at code generation time, so a static transition-action table cannot be generated).

Backward Traceability

  • [SRS_QP_REQ_221] QP/C++ Framework component should provide a State Machine Implementation Strategy optimized for "automatic code generation"
  • [SDS_QP_QMsm] Design view: QP::QMsm State machine class.
  • [SDS_QP_SFM_07] Design view: QP/C++ Framework specification shall support semi-formal method: decision/truth tables (HR).

Forward Traceability

State Dynamics ViewpointInterface Viewpoint