QP™ (Quantum Platform) is a family of real-time event frameworks (RTEFs), which provide reusable architecture and runtime environment based on event-driven asynchronous Active Objects (a.k.a. Actors) and Hierarchical State Machines. This modern, non-blocking architecture is inherently safer, more extensible, and more responsive (more “real-time”) than the “free threading” approach of a traditional, blocking real-time operating system (RTOS).

Real-Time Event Frameworks for MCUs

The QP™ real-time event frameworks (RTEFs) inherently support and automatically enforce the best practices of concurrent programming. This results in applications that are safer, more responsive, and easier to manage than the “naked” threads and the myriad of blocking mechanisms of a traditional Real-Time Operating System (RTOS). The QP™ frameworks also provide a higher level of abstraction and the right abstractions to effectively apply graphical modeling and code generation to deeply embedded systems, such as MCUs based on ARM Cortex-M.

QP™ Framework Structure and Components

QP Application consists of event-driven Active Objects that collectively deliver the intended functionality.

QP Framework: executes Active Objects

delivers Events;
dispatches Events to the internal State Machines of Active Objects;
manages memory for the mutable events;
provides timing services;
provides Functional Safety Subsystem for self-monitoring, error handling, and fault prevention both for QP Framework and QP Application;
provides software tracing system for debugging, optimizing, and testing.

Real-Time Kernel: provides scheduling and execution context for the Active Objects. This could be:

One of the kernels built-into QP Frameworks (see Standalone Operation):

non-preemptive QV kernel
preemptive, non-blocking QK kernel
preemptive, non-blocking/blocking QXK kernel

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

Board Support Package (BSP) consists of the low-level support code.

Target Hardware CPU, MCU, or DSP, such as ARM Cortex-M, ARM Cortex-R, MSP430, or any hardware supported by the real-time kernel used.

QP™ Framework Editions

The architecture just described can be implemented in various programming languages and optimized in various ways. Therefore, to address different market segments, QP™ is a family of frameworks, currently consisting of the following QP™ editions:

QP Framework Edition	Programming Language	API Compatibility	Safety Functions	Certification Artifacts	Licensing
Standard QP editions
QP/C	C (C11)	Same as SafeQP/C	Assertions	Requirements, Architecture & Design Specifications	Dual-licensing (Open-source & Commercial)
QP/C++	C++ (C++17)	Same as SafeQP/C++	Assertions	Requirements, Architecture & Design Specifications	Dual-licensing (Open-source & Commercial)
SafeQP editions engineered for functional safety
SafeQP/C	C (C11)	Same as QP/C	All identified	Complete Certification Kit	Commercial only
SafeQP/C++	C++ (C++17)	Same as QP/C++	All identified	Complete Certification Kit	Commercial only

The SafeQP editions are fully API-compatible with the corresponding standard QP frameworks. This ensures existing QP Applications can transition seamlessly to SafeQP without requiring any modifications. The SafeQP frameworks contain safety features required to achieve the higher safety integrity levels and come with much extensive Certification Kits.

QP™ Highlights

Lightweight

QP™ applications consisting of event-driven Active Objects consume less memory, especially RAM, than equivalent solutions based on traditional RTOS threads.

Hard Real-Time

QP™ RTEFs combined with a preemptive, priority-based kernel are suitable for hard real-time applications. In fact, the non-blocking Active Objects are better suited for the RMS/RMA methods than the traditional blocking RTOS threads.

Market Leadership

With 20+ years of continuous refinement, the QP™ frameworks are the most established and popular offering of this type on the embedded software market.

Functional Safety Focus

All QP™ framework editions are a natural fit for safety-related applications because they implement a number of best practices highly recommended by the functional safety standards, such as strictly modular design (Active Objects) or hierarchical state machines (semi-formal methods). Indeed, for decades the standard QP/C and QP/C++ Frameworks have been widely used in safety-related applications, such as medical, aerospace, and industrial.

SafeQP Editions

The SafeQP editions take the functional safety focus to the next level by addressing the safety market explicitly. The SafeQP/C and SafeQP/C++ frameworks were originally derived from QP/C and QP/C++, respectively, but were extensively reengineered using compliant Software Safety Lifecycle (SSL). In this process, the QP framework functional model has been subjected to a full Hazard and Risk Analysis, which identified all areas of weakness within the functional model and API. These findings led to creation of Safety Requirements and risk mitigation by Safety Functions, which were subsequently implemented, verified, and validated in the SafeQP editions. Some of the Safety Functions implemented in the SafeQP/C and SafeQP/C++ frameworks include:

Software Systematic Capability, including:
- bi-directional end-to-end traceability (from requirements to source code and tests)
- MISRA-C:2023 Compliance (SafeQP/C)
- MISRA-C++:2023 Compliance (SafeQP/C++)
Assertion Programming and Failure Assertion Programming
Data Flow Self-Monitoring
Data Integrity Self-Monitoring
- Duplicate Inverse Storage
- High Watermark (for event-queues and event-pools)
Control Flow Self-Monitoring
- Fixed Upper Loop Bounds
- Invalid Control Flow
Event Delivery Guarantee
Spatial Isolation (dynamic MPU reconfiguration)

The SafeQP editions retain QP Frameworks' hallmark features, including small memory footprint, excellent efficiency, and hard real-time performance, while adding Safety Functions and the complete Safety Case required for higher safety integrity levels.

SafeQP Certification Kits

The SafeQP frameworks are accompanied by the SafeQP Certification Kits, which provide developers with ready-to-use artifacts, enabling them to save time, mitigate risks, and reduce costs during application certification for safety-critical devices in the industrial, medical, aerospace, and automotive industries. The SafeQP Certification Kits consist of the following documents and artifacts:

Requirements

Software Requirements Specification (DOC_SRS_QP) — Defines the underlying concepts and specifies the features of SafeQP frameworks.

Architecture and Design

Software Architecture Specification (DOC_SAS_QP) — Provides a master plan for the overall organization, layering, operation, and interfaces of SafeQP frameworks.
Software Design Specification (DOC_SDS_QP) — Describes the main aspects of SafeQP frameworks design.

Implementation (SafeQP/C)

MISRA-C:2023 Coding Standard Compliance (DOC_MISRA_QPC) — Describes the compliance of SafeQP/C framework source code with the MISRA-C:2023 safe subset of C11. Also provides system for checking MISRA-C:2023 compliance of SafeQP/C applications.

Implementation (SafeQP/C++)

MISRA-C++:2023 Coding Standard Compliance (DOC_MISRA_QPCPP) — Describes the compliance of SafeQP/C++ framework source code with the MISRA-C++:2023 safe subset of C++17. Also provides system for checking MISRA-C:2023 compliance of SafeQP/C++ applications.

Safety Case

Documents in this section are designed to provide a structured argument (Safety Case), supported by body of evidence, that the system is safe for a given application in a given environment. This Safety Case is the basis for claiming conformance to functional safety standards and integrity levels: IEC 61508 SIL 3, IEC 62304 Class C, ISO 26262 ASIL D.

Functional Safety Management Plan (DOC_FSM_QP) — Specifies a systematic plan to manage activities necessary for SafeQP frameworks software to achieve the required safety integrity levels. This document contains the following parts:
- Traceabilty
- Software Safety Lifecycle
- Software Development Process
- Software Operation & Maintenance
- Documentation Management
Software Hazard and Risk Analysis (DOC_SHR_QP) — Describes the functional safety analysis of the SafeQP frameworks.
Software Safety Requirements Specification (DOC_SSR_QP) — Defines the software safety requirements for SafeQP frameworks in terms of software Safety Functions.
Software Safety Manual (DOC_SSM_QP) — Provides comprehensive guidelines for ensuring safe use and integration of SafeQP frameworks into SafeQP/C Applications.
Software Safety Validation Plan (DOC_SVP_QP) — Specifies the activities and methods used to validate that SafeQP frameworks meet Safety Requirements and perform as intended in their operational environment.
Software Test Suite (code) — Test suite accompanying the Software Safety Validation Plan to be executed on target.
Test (Unit) Results (DOC_TUR_QP) — Provides unit testing logs and other testing evidence.
Test (Integration) Results (DOC_TIR_QP) — Provides integration testing logs and other testing evidence.
Test (Validation) Results (DOC_TVR_QP) Provides validation testing logs and other testing evidence.

Some of the artifacts comprising the SafeQP Certification Kit are still under active development and are currently provided in their preliminary versions.

Functional Safety Certification

Selecting software components for products requiring functional safety certification can be challenging. Application developers may have to choose between an already “pre-certified” component or one still needing certification as part of the project. While the already “pre-certified” component can be a quick, short-term solution, it is expensive and does not automatically solve all the problems. On the other hand, in-house certification of a component not designed for certification can be immensely time-consuming and risky to the project schedule. The SafeQP/C Framework with the SafeQP/C Certification Kit provide a third alternative — a “sweet spot” between these two extremes.

Pre-Certified Approach

It is sometimes believed that buying pre-certified components ensures a successful final product certification or at least reduces the manufacturer’s liability. However, the functional safety standards make it clear that this is not the case because the device manufacturer takes the ultimate responsibility for all the components that make up the device, whether developed in-house or bought from external suppliers.

Another common misconception is that a pre-certified software component can be just “plugged into” any system without impacting the component’s certification status. However, all safety-related software components (e.g., RTOS kernels) are specific to the processor/compiler combination, down to the specific variants of the processor and versions of the compiler and even specific compiler configuration. For these reasons, vendors of “pre-certified” components offer additional services to adapt the components to the customer’s specifications. However, such outsourcing critical safety aspects reduces the in-house safety expertise while significantly adding to project cost and schedule. It is also inflexible and requires re-hiring the original component vendor for every change.

Certification Kit Approach

The primary advantages of the SafeQP Certification Kit are flexibility and cost-effectiveness. The SafeQP Frameworks have been specifically designed and developed for certification using a compliant Software Safety Lifecycle (SSL) and is accompanied by extensive evidence of compliance — the SafeQP Certification Kit.

Regulatory background:
All this allows the SafeQP Frameworks to be certified according to the "route 1s" for certification (the same as the "pre-certified" component) and avoiding the cumbersome "route 2s" and "route 3s".

At the same time, the SafeQP Certification Kits can be adapted to fit the project needs precisely. Without the constraints of existing “pre-certification” boundaries, the in-house team can customize the kit for the specific hardware (e.g., MCU), compiler version, and specific compiler options.

Of course, the in-house customization of the SafeQP Certification Kit requires effort, but if done correctly, this activity can actually speed up the overall project development due to the reuse of the processes and templates provided in the SafeQP Certification Kit. For example, the SafeQP Application incorporating SafeQP Framework can reuse the Functional Safety Management, traceability, testing infrastructure (QUTest), MISRA compliance, and adapt other parts of the “Cert Kit” as templates for the rest of the project.

Standalone (Bare-Metal) Operation

The QP™ RTEFs can run standalone, completely replacing the traditional RTOS. The frameworks contain a selection of built-in real-time kernels, such as the cooperative QV kernel, the preemptive non-blocking QK kernel, and the unique preemptive, dual-mode (blocking/non-blocking) QXK kernel. Standalone QP ports and ready-to-use examples are provided for ARM Cortex-M (M0-M7) as well as other CPUs.

You do not need to use a traditional RTOS just to achieve preemptive multitasking with QP. The built-in, preemptive QK and QXK kernels, support preemptive priority-based multitasking that is fully compatible with Rate Monotonic Scheduling to achieve guaranteed, hard real-time performance. These preemptive kernels perfectly match the run-to-completion execution semantics of active objects, yet are simpler, faster, and more efficient than the traditional blocking RTOS kernels.

Traditional RTOS Integration

The QP™ RTEFs can also work with many traditional third-party RTOSes. QP ports and ready-to-use examples are provided for several RTOSes:

embOS
FreeRTOS
ThreadX
uC/OS-II
Zephyr

The most important reason why you might consider using a traditional RTOS kernel for executing event-driven QP™ applications is compatibility with the existing software. For example, many communication stacks (TCP/IP, USB, CAN, etc.) are designed for a traditional blocking kernel. In addition, a lot of legacy code requires blocking mechanisms, such as semaphores or time-delays. A traditional RTOS allows you to run the existing software components as regular blocking threads in parallel to the event-driven, non-blocking QP™ Active Objects.

General-Purpose Operating Systems

The QP™ RTEFs have been ported to General-Purpose Operating Systems:

POSIX, such as embedded Linux and other (RT)OSs with POSIX API, like QNX, INTEGRITY; and
Windows (Win32).

These QP™ ports can be used in the final devices or for the development and testing QP Applications on the host computers.

Example Evaluation Boards

EK-TM4C123GXL (ARM Cortex-M4)

EFM32-SLSTK3401A Pearl Gecko (ARM Cortex-M4)

STM32F4-Discovery (ARM Cortex-M4)

STM32 NUCLEO-L152RE board (ARM Cortex-M3)

STM32 NUCLEO-L053R8 (ARM Cortex-M0+)

STM32F746G-Discovery (ARM Cortex-M7)

STM32 NUCLEO-H743ZI (ARM Cortex-M7)

mbed LPC1768 ( (ARM Cortex-M4)

LAUNCHXL2-TMS57012 (ARM Cortex-R4)

MSP-EXP430G2 (MSP430)

MSP-EXP430F5529LP (MSP430)

Microstick-II (PIC24 and PIC32)

QP™/C and QP™/C++ Feature Comparison

Feature	QP/C	QP/C++
Most Recent Version (Revision History) Latest Release Date	8.0.0 2024-10-31	8.0.0 2024-10-31
Intended target systems (Representative hardware)	32-bit/16-bit MCUs (ARM Cortex-M)	32-bit/16-bit MCUs (ARM Cortex-M)
Supported by the free QM™ Model-Based Design tool
Maximum number of active objects	64	64
Dynamic events with arbitrary parameters
Automatic event recycling
Direct event posting (FIFO)
Direct event posting (LIFO)
Publish-Subscribe event delivery
Event deferral
Number of system clock tick rates	configurable (0..15)	configurable (0..15)
Number of time events per active object	Unlimited	Unlimited
----------------------------------------------- State Machines -----------------------------------------------
Hierarchical State Machines (QHsm-strategy)
Hierarchical State Machines (QMsm-strategy)
Sub-machines and sub-machine states
----------------------------------------------- Built-in Kernels -----------------------------------------------
Preemptive non-blocking kernel (QK)
Preemptive blocking dual-mode kernel (QXK)
----------------------------------------------- 3rd-Party RTOS/OS -----------------------------------------------
Portable to 3rd-party RTOS kernels
Available port to POSIX (Linux, QNX, INTEGRITY, etc.)
Available port to Windows
----------------------------------------------- Testing/Profiling -----------------------------------------------
QP/Spy™ software tracing
QUTest™ Unit Testing Harness
MISRA compliance	MISRA-C:2012
AUTOSAR-C++ compliance		AUTOSAR-C++14
PC-Lint-Plus support package
-----------------------------------------------Licensing -----------------------------------------------
Open Source Licensing (GPL)
Closed Source (Commercial) Licensing

QP Development Kits (QDKs) were separate QP ports and examples for various embedded processors, toolsets and boards.

Why "Legacy"?

Starting with QP release 5.4.0, all officially supported ports and examples are bundled into the QP downloads, as opposed to being distributed as separate QP Development Kits (QDKs). The QDKs released for earlier QP versions are called “legacy-QDKs” and are available for download from SourceForge.

The "legacy-QDKs" are not recommended for new projects. The "legacy-QDKs" do not come with commercial support from Quantum Leaps, although questions about "legacy-QDKs" are welcome on the Free QP Support Forum

How to Find QDK You Want?

All “legacy QDKs” are distributed in ZIP archives named according to the following general convention:

qdkxxx_<cpu/rtos>-<toolset>-<board>_<version>.zip

qdkxxx denotes the QP framework type, whereas qdkc stands for QDK for QP/C, qdkcpp for QP/C++, and qdkn for QP-nano
<cpu> denotes a QDK for standalone QP for the given embedded CPU type, such as AVR, M16C, R8C, etc.
<rtos> denotes a QDK for QP running on top of a given RTOS, such as eCos, VxWorks, etc.
<toolset> denotes a port to specific toolset, such a IAR, GNU, Renesas, etc.
<board> denotes that the examples are for the specified boards, such as SKP3607, YRDKRX62N, etc.
<version> denotes the compatible version of the QP framework.

All QDKs have been developed and tested with the specified <version> of the QP framework. A QDK might work with the newer QP version as well, but might require some modifications.

QDK Installation

The installation procedure for most “legacy QDKs” is as follows:

Download the QDK that you like and check its <version> number.
Download and install (unzip) the corresponding QP <version>. For example, if your QDK file starts with qdkcpp_ and ends with _4.5.02, you should download and install QP/C++ version 4.5.02.
Unzip the QDK to a temporary directory.
Copy the contents of the QDK directory to the QP installation directory. For example, if your QDK unzipped into directory qdkcpp_avr-iar_4.5.02, you should copy the content of this directory inside the QP/C++ installation folder (typically, inside C:/qp/qpcpp/). Note that you will need to give your consent to overwrite the already existing directories examples/ and ports/.

QDK Documentation

Every “legacy QDK” contains the “QDK Manual” in PDF in the main directory of the ZIP archive.

QP™ Real-Time Event Frameworks (RTEFs)