QP/C++ 8.1.2
Real-Time Event Framework
Loading...
Searching...
No Matches
Structure Viewpoint

Safety ViewpointInteraction Viewpoint

Viewpoint


SDS_QP_STR_VP

Structure Viewpoint

Purpose
The Structure Viewpoint elaborates the base classes and interfaces identified in the architecture Context Viewpoint with their design details and structural static relationships. The Structure Design Viewpoint also provides examples of using the QP/C++ Framework classes in QP Applications.

Design Concerns

  • packages and classes
  • layering
  • class hierarchies
  • class interfaces
  • class functionality and responsibilities
  • data structures
  • concurrency and parallelism

Model Kind
The model kind used to illustrate the Structure Viewpoint is the UML class diagram shown in Figure SDS-CLS (static view). It depicts base classes comprising the QP/C++ Framework and their specializations in the QP/C++ Application shown at the bottom of @ Figure SDS-CLS.

Figure SDS-CLS: Core classes in QP/C++ Framework and their relation to QP/C++ Application.


Sub-Layer View

The Sub-Layer View in the Structure Viewpoint focuses on the internal layering of the QP/C++ Framework, which has the following objectives:

  • promote modularity.
  • separation of concerns into passive and active elements.
  • enable QP/C++ Application to use only the passive layer without pulling in any of the Active Object layer.

SDS_QP_QEP

QEP Event Processor

Description
QEP Event Processor sub-layer of QP/C++ Framework (see Figure SDS-CLS [10]) implements Events and passive State Machines.

Note
QEP Event Processor is intentionally separated out to allow QP Applications to directly use just the passive state machines (without Active Objects). QP Applications that use just the QEP Event Processor can still benefit from the QM modeling tool↑, which can generate code that requires only passive state machines.

Backward Traceability

Forward Traceability (truncated to 1 level(s))



SDS_QP_QF

QF Active Object Framework

Description
QF Active Object Framework sub-layer of QP/C++ Framework (see Figure SDS-CLS [20]) implements Active Objects and Time Events.

Note
QF Active Object Framework requires the QEP Event Processor to provide events and implement the state machine behavior of Active Objects.

Backward Traceability

Forward Traceability (truncated to 1 level(s))


Class View

The Class View in the Structure Viewpoint focuses on the following key design concerns:

  • describing the logical structure and organization of the system, including the identification of classes and their relationships.
  • defining the QP/C++ Framework base classes that are the basis for derivation of QP Applications from the framework.
  • describing the responsibilities of each class to achieve high cohesion within a class and loose coupling among classes.
  • defining the inheritance hierarchies and polymorphic behavior to promote reuse and flexibility.
  • ensuring data encapsulation within classes to maintain safety, integrity, and security.

SDS_QP_QEvt

QEvt event class.

Description
The QP::QEvt class (see Figure SDS-CLS [11]) represents both immutable and mutable events in the QP/C++ Framework. It can be instantiated directly (concrete class), in which case it represents events without parameters. QP Applications can also inherit and extend QP::QEvt to add custom event parameters.

Attention
Event parameters must be included in the event instance directly (as opposed to being referenced by pointers or references). Therefore, the QP::QEvt subclasses are restricted to have both "standard layout" and be "trivially copyable". In the QP/C++ Framework, this means that QP::QEvt subclasses should:
  • NO pointers or references; The only exception is passing opaque pointer(s) to Active Objects intended as recipients of future events.
  • contain NO virtual functions (consequence of no virtual pointer);
  • contain NO access specifiers (protected, and private);
  • contain NO non-trivial copy or move constructor.
  • contain NO non-trivial copy or move assignment operator;
  • contain NO destructor.

Event Attributes
The QP::QEvt class has the following data attributes:

  • event signal in the range 0 .. 64K. The lowest 4 signals (values 0..3) are reserved for internal use.
  • event-pool number:
    • for mutable (dynamic) events, event-pool number is in the range 1 .. QF_MAX_EPOOL. For immutable (static) events, the event-pool number is 0.
  • event reference counter with dynamic range 0 .. (2 * QF_MAX_ACTIVE). For mutable events, the reference counter stores the number of outstanding references to that event instance. For immutable events and time events (see SDS_QP_QTimeEvt), the reference counter attribute is not used for counting but instead indicates the origin of the event.

Backward Traceability

Forward Traceability (truncated to 2 level(s))

  • QP::QEvt: Event class
    • DVP_QP_PCLP_1790: public base has no non-destructor virtual functions
    • DVR_QP_PCLP_1801: Base class has a destructor that is not public virtual; public override or protected non-virtual
    • QSignal: The signal of event QP::QEvt



SDS_QP_QAsm

QAsm Abstract state machine class.

Description
The QP::QAsm class (see Figure SDS-CLS [12]) is the abstract base class (ABC) for all state machines in the QP/C++ Framework. The QP::QAsm class specifies the abstract state machine interface.

State Machine Interface
The state machine interface defined in the QP::QAsm class consists of:

  • init() operation executes the top-most initial transition. It must be executed only once.
  • dispatch() operation dispatches a given event to the state machine for RTC processing. It must be executed for every event.
  • isIn() (is in-state) operation returns 'true' if the state machine is in the given state. Note that being "in a state" also means being in all the superstates of that state.

State Machine Attributes

  • current state (state variable): stores the current state of the state machine.
  • temporary attribute: stores transition target during a state transition. Also used to implement the Safety Function described below.

Safety Function
In the stable state configuration (between the RTC steps), the subclasses of QP::QAsm use the temporary attribute for the Duplicate Inverse Storage of the QP::QAsm::state attribute.

Backward Traceability

Forward Traceability (truncated to 2 level(s))



SDS_QP_QHsm

QHsm State machine class.

Description
The QP::QHsm class (see Figure SDS-CLS [13]) derived from QP::QAsm implements the state machine interface init() and dispatch() according to the State Machine Implementation Strategy optimized for manual coding. QP::QHsm provides support for hierarchical nesting of states, entry/exit actions, initial transitions, and transitions to history in any composite state. This class is designed for ease of manual coding, but it is also supported by the QM modeling and code-generation tool↑.

Safety Function
The QP::QHsm class implements the Fixed Loop Bound technique for all not explicitly terminated loops. This prevents malformed state machine specifications (from the QP/C++ Application layer) from "hanging" or crashing the event processor.

Backward Traceability

Forward Traceability (truncated to 2 level(s))



SDS_QP_QMsm

QMsm State machine class.

Description
The QP::QMsm class (Figure SDS-CLS [14]) derived from QP::QAsm implements the state machine interface init() and dispatch() according to the State Machine Implementation Strategy optimized for automatic code generation. QP::QMsm provides support for all hierarchical state machine features listed in SRS_QP_SM_20. This class is designed for automatic code generation, and requires the QM modeling and code-generation tool↑.

Safety Function
The QP::QMsm class implements the Fixed Loop Bound technique for all not explicitly terminated loops. This prevents malformed state machine specifications (from the QP/C++ Application layer) from "hanging" or crashing the event processor.

Backward Traceability

Forward Traceability (truncated to 2 level(s))



SDS_QP_QActive

QActive Active Object class.

Description
The QP::QActive class (Figure SDS-CLS [23]) is a base class for the derivation of concrete Active Objects in the QP/C++ Application. QP::QActive inherits QP::QAsm, which means that an Active Object in QP can be treated as a state machine with the standard interface. QP::QActive implements this interface by delegating to the QP::QHsm state machine implementation.

Active Object Priority
QP::QActive owns the unique priority attribute, which must be in the range 1..QF_MAX_ACTIVE, inclusive, and conforms to the QP/C++ Framework priority numbering scheme.

Auxiliary Priority
QP::QActive has the auxiliary priority attribute, which is a number in the range 0..255, and its use depends on the underlying real-time kernel.

Event Queue
QP::QActive owns the event-queue attribute, whose type depends on the underlying real-time kernel. Therefore, the event-queue type is compile-time configurable. When QP is used with one of the built-in kernels (QV, QK, QXK), the QActive event queue is configured to be QP::QEQueue. However, when the QP/C++ Framework runs on a 3rd-party RTOS, typically the RTOS's message queue is adapted as an event queue.

The event queue for Active Objects requires multiple-write, but only single-read capability. Also, blocking the queue is only needed when the event queue is empty, but not when it is full. Finally, the Active Object queue in the QP/C++ Framework passes only pointers to events. Standard RTOS message queues are significantly more complex than required by Active Objects because they typically allow multiple-write as well as multiple-read access and often support variable-length data (not only pointer-sized data). Usually, message queues also allow blocking when the queue is empty and when the queue is full, and both types of blocking can be timed out. Naturally, all this extra functionality, which you don't need in the QP/C++ Framework, comes at an additional cost in CPU and memory usage.

Thread of Execution
QP::QActive has the compile-time configurable thread attribute, whose type depends on the underlying real-time kernel. When QP is used with one of the built-in kernels (QV, QK, QXK), the QP::QActive thread attribute can be used to hold the MPU settings. When the QP/C++ Framework runs on a 3rd-party RTOS, the thread attribute might hold the RTOS-specific thread object, which could be the Thread Control Block, or just a thread handle.

OS-object
QP::QActive has the compile-time configurable OS Object attribute. The OS-object attribute is

Backward Traceability

  • SRS_QP_AO_10: Active Object abstraction shall provide the unique priority for each Active Object instance
  • SRS_QP_AO_11: Active Object priority shall use the direct priority numbering scheme
  • SAS_QP_FRM: QP/C++ Framework layer
  • SAS_QP_FBC: QP/C++ Framework base classes

Forward Traceability (truncated to 2 level(s))

  • QP::QActive: Active object class (based on the QP::QHsm implementation strategy)
    • DVR_QP_PCLP_1801: Base class has a destructor that is not public virtual; public override or protected non-virtual



SDS_QP_QMActive

QMActive Active Object class.

Description
The QP::QMActive class (Figure SDS-CLS [24]) derives from the QP::QActive base class, so it inherits all its properties. The only difference is that QP::QMActive implements the state machine interface by delegating to the QP::QMsm state machine implementation.

Backward Traceability

Forward Traceability (truncated to 2 level(s))

  • QP::QMActive: Active object class (based on QMsm implementation strategy)



SDS_QP_QTimeEvt

QTimeEvt time event class.

Description
The QP::QActive class (Figure SDS-CLS [23]) is a base class for the derivation of concrete Active Objects in the QP/C++ Application. QP::QActive encapsulates the unique priority, event-queue, execution context, and state machine for the Active Object. QP::QActive inherits QP::QAsm, which means that an Active Object in QP can be treated as a state machine with the standard interface. QP::QActive implements this interface by delegating to the QP::QHsm state machine implementation.

Backward Traceability

Forward Traceability (truncated to 2 level(s))


Safety ViewpointInteraction Viewpoint