QP Framework is a lightweight implementation of the Active Object model of computation specifically tailored for real-time embedded (RTE) systems. QP is both an event-driven software infrastructure for building applications consisting of Active Objects (Actors) and a runtime environment for executing the Active Objects in a safe and deterministic fashion. Additionally, QP Framework supports Hierarchical State Machines with which to specify the behavior of Active Objects [ROOM:94], [UML 2.5],[Sutter:10].

Goals

The main goals of the QP Framework are:

to provide a modern, event-driven model of concurrency based on the best practices of concurrent programming [Sutter:10], [Cummings:10], [ROOM:94], collectively known as the Active Object (Actor) model of computation, which is inherently safer than the traditional "shared-state concurrency, mutual-exclusion, and blocking" approach based on a conventional Real-Time Operating System (RTOS);
to provide a higher-level of abstraction closer to the problem domain than the "naked" RTOS threads;
to provide the right abstractions for applying modern techniques like Hierarchical State Machines, visual modeling, and automatic code generation;
to bridge the semantic gap between the higher level UML concepts (such as Events, Hierarchical State Machines, and Active Objects) and the traditional programming languages like C or C++.

Object-Orientation

QP is fundamentally an object-oriented framework (regardless of the implementation language), which means that the QP Framework (Figure SRS-02[2]) itself and QP Applications (Figure SRS-02[1]) derived from the framework are fundamentally composed of classes and only classes can have state machines associated with them.

Context and Functional Decomposition

The following block diagram shows the context of use and the high-level functional decomposition of a system built with the QP Framework.

Figure SRS-02: Context and Functional Decomposition of a System Based on QP

[1] QP Application consists of multiple event-driven Active Objects.

[2] QP Framework (shown in yellow) executes the internal State Machines of the Active Objects, delivers events to the Active Objects, provides timing and other services.

[3a] Real-Time Kernel is responsible for scheduling the Active Object execution. This could be one of the kernels built-into QP Frameworks (QV, QK, or QXK); or

[3b] Alternatively, QP Framework can run on top of a 3-rd party RTOS kernel or a General-Purpose OS (e.g., Linux/POSIX or Windows).

[4] Target System consists of the hardware and basic software (Board Support Package).

Active Objects

QP Application (Figure SRS-02[1]) consists of event-driven Active Objects (Actors), which are strictly encapsulated software objects conceptually running in their own threads of execution and communicating with each other asynchronously by exchanging events.

State Machines

Each Active Object in QP has a state machine that specifies the event-driven behavior of the Active Object. The main effort of QP Application developers goes into elaborating the internal state machines of the Active Objects as well as other (passive) event-driven components.

Event-Driven Paradigm

The essential characteristic of the QP Framework is that it is event-driven. That means that any processing is determined in QP by events, which are handled without blocking (or busy-polling).

Inversion of Control

Like most event-driven systems, QP Framework is based on inversion of control, which means that the control of code execution resides in the QP Framework rather than the QP Application based on QP. Specifically, to handle events, QP Framework calls the QP Application, and not the other way around. Of course, QP Applications can also call services provided in QP Framework, but the main flow of control always begins with the QP Framework.

Framework, NOT a Library

That inversion of control gives the event-driven infrastructure (QP) all the defining characteristics of a framework rather than a library.

The main difference between a framework and a library is that when you use a library, such as a conventional RTOS, you write the main body of each thread, and you call the library code that you want to reuse (e.g., a semaphore). When you use a framework, such as QP, you reuse the main body and write the code it calls (inversion of control).

Portability & Configurability

A reusable architecture for embedded systems, like QP, needs to be adaptable to a wide range of application areas and target hardware selections. For that, QP needs to be highly configurable. Whenever this requirements specification mentions "configurability", it explicitly specifies which of the following types of configurability is required:

Compile-Time Configurability

Compile-time configurability means that the specific configuration option (out of a given range of possibilities) is chosen at compile-time and cannot be changed later (e.g., at run-time). Compile-time configurability is typically used for:

Turning features on or off
Determining the size (and dynamic range) of various data types
Determining the maximum numbers of various objects in the framework or Application
Determining the presence (or absence) of class members

Remarks: In C or C++, compile-time configurability is typically implemented with the preprocessor macros, but can also be achieved by composition of the selected modules.

Run-Time Configurability

Run-time configurability means that the specific configuration option is chosen at run-time. Unlike compile-time configurability, run-time configurability is finer granularity, usually on an object-by-object basis. It is typically used for:

Choosing a specific implementation of a class operation based on the object type (polymorphism)
Selecting features by calling or not calling the specific QP API
Selecting features by passing parameters to the specific QP API

Purpose and ScopeEvents