QP real-time event frameworks (RTEFs) form a family of lightweight implementations of the Active Object model of computation specifically designed for real-time embedded (RTE) systems (such as ARM Cortex-M based MCUs). QP/C++ Frameworks provide both a software infrastructure for building QP/C++ Applications consisting of Active Objects (Actors) and a runtime environment for executing the Active Objects in real-time. Additionally, QP/C++ Framework supports Hierarchical State Machines with which to specify the behavior of Active Objects [UML-2.5], [Sutter:10], [ROOM:94].
The main goals of the QP/C++ Framework are:
In the context of functional safety standards and certification, QP/C++ Frameworks offer numerous advantages over the traditional "shared state concurrency" based on a "naked" Real-Time Operating System (RTOS). QP/C++ Frameworks implement an inherently safer model of concurrency and many best practices recommended by functional safety standards (e.g., [IEC 61508-7:2010]) such as:
The following block diagram shows the context of use and the high-level functional decomposition of a system built with the QP/C++ Framework.
[1] QP/C++ Application:
[2] QP/C++ Framework:
[3a] Real-Time Kernel provides scheduling and execution context for the Active Objects. This could be one of the kernels built-into QP/C++ Frameworks (QV, QK, or QXK); or
[3b] Alternatively, QP/C++ Framework can run on top of a 3-rd party RTOS kernel; or
[3c] Alternatively, QP/C++ Framework can run on top of a General-Purpose OS (e.g., Linux/POSIX or Windows);
[4] Board Support Package (BSP) consists of the low-level support code;
[5] Target Hardware (MCU + external components).
Like most event-driven systems, the QP/C++ Framework is based on inversion of control, which means that the control of code execution resides in the QP/C++ Framework rather than the QP/C++ Application based on QP. Specifically, to handle events, QP/C++ Framework calls the QP/C++ Application, and not the other way around. Of course, QP/C++ Applications can also call services provided in QP/C++ Framework, but the main flow of control always begins with the QP/C++ Framework.
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).
The mechanism for deriving an application from a software framework, such as QP, is by inheriting the base classes provided by the framework and specializing them for the application at hand. (See also the extensibility characteristics of a framework enumerated above.)
The use case diagram depicted in Figure SRS-USE shows the main users and typical use cases they engage in.
[1] QP/C++ Application use cases (use QP/C++ Framework [2] use cases):
[2] QP/C++ Framework use cases:
A reusable architecture, like QP/C++ Framework, 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 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:
Run-time configurability means that the specific configuration option is chosen at run-time. Unlike compile-time configurability, run-time configurability has a finer granularity, usually on an object-by-object basis. It is typically used for:
