Feature Highlights

  • World's smallest active object (actor) frameworks suitable for embedded single-chip microcontrollers (MCUs)
  • Safer RTOS alternative based on modern, extensible, and highly responsive event-driven architecture.
  • Thread-safe execution of state machine objects (actors) with zero-copy event passing, direct event posting, and publish- subscribe event delivery.
  • Highly maintainable and traceable mapping of UML hierarchical state machines to C or C++
  • Free, QM modeling tool for drawing UML statecharts and automatic code generation based on QP
  • Compliant with MISRA-C:2004 (QP/C and QP-nano) and MISRA-C++:2008 (QP/C++)
  • Built-in cooperative and fully preemptive real-time kernels
  • Built-in software tracing instrumentation (Q-Spy) for analyzing live system performance
  • Book "Practical UML Statecharts in C/C, 2nd Ed." with detailed design study of the QP framework.
  • Ready-to-use QP Development Kits (QDKs)
  • Complete toolkit for prototyping QP applications on Windows and with Qt
  • Active free support forum
  • Moderated and strictly quality-controlled open source distribution
  • Closed-source licensing option with commercial support and accountability for the licensed intellectual property
  • Some feature missing? Make a feature request

QP/C Reference Manual QP/C++ Reference Manual QP-nano Reference Manual QSPY Reference Manual

If you'd like to make a short presentation of QP™/QM™ to your colleagues and/or managers, here are the slides and class notes in PDF:

QP-QM Quick Overview Slides (2MB PDF)
QP-QM Quick Overview Notes (2.3MB PDF)

new! See what's new in QP5!

Welcome to the 21st century!

About QP™

What is it?

QP™ (Quantum Platform) is a family of lightweight, open source software frameworks for building responsive and modular real-time embedded applications as systems of cooperating, event-driven active objects (actors). The QP™ family consists of QP/C, QP/C++, and QP-nano frameworks, which are all strictly quality controlled, superbly documented, and commercially licensable.

Why active objects?

Active objects (actors) are encapsulated state machines that run in their own thread of execution and process events asynchronously using an event-driven receive loop. They inherently support and automatically enforce the best practices of concurrent programming, such as: keeping the thread's data local and bound to the thread itself, asynchronous inter-thread communication without blocking, and using state machines instead of convoluted IF-ELSE logic (a.k.a. "spaghetti" code). In contrast, raw RTOS-based threading lets you do anything and offers no help or automation for the best practices.

Where does it run?

All QP™ frameworks can run on "bare-metal" single-chip microcontrollers, completely replacing a traditional RTOS. Ports and ready-to-use examples are provided for most major CPU families. QP/C and QP/C++ can also work with a traditional OS/RTOS, such as: POSIX (Linux, QNX, INTEGRITY), Win32 (Windows, Windows Embedded, Windows CE), ThreadX, embOS, MicroC/OS-II, etc.

How does it handle behavior?

The behavior of active objects is specified in QP by means of hierarchical state machines (UML statecharts). The frameworks support manual coding of UML state machines in C or C++ as well as fully automatic code generation by means of the free graphical QM™ modeling tool.

Who is using it?

The QP™ frameworks are used in millions of products worldwide in consumer electronics, telecommunications, industrial automation, transportation, medical devices, aerospace, robotics, and many more. The QP™ frameworks and the QM™ modeling tool receive over 45,000 downloads a year (not even counting downloads of QP ports).

How is it licensed?

The QP™ frameworks are licensed under the dual licensing model, which combines the best of the open source and proprietary software worlds to make open source a safe choice for the embedded systems vendors. For the commercial licensees this means the accountability for the licensed intellectual property, professional documentation and technical support expected of a traditional software vendor as well as transparent development, availability of source code and active community inherent in open source projects.

NOTE: If your company has a policy forbidding open source in your product, all QP™ frameworks can be licensed commercially, in which case you don't use any open source license and you do not violate your policy.

Active Objects (Actors)

Raw RTOS tasks and numerous blocking mechanisms, such as semaphores, event flags, etc., are complex and error-prone to work with directly, which means they waste your time. Active objects provide a more productive architecture, which is safer to use, more efficient, and easier to understand, extend, test, and maintain.

Active objects (a.k.a. actors) are event-driven, strictly encapsulated software objects endowed with their own threads of control that communicate with one another asynchronously by exchanging events. The UML specification further proposes the UML variant of hierarchical state machines (UML statecharts) with which to model the behavior of event-driven active objects.

Active objects inherently support and automatically enforce the following best practices of concurrent programming:

  • Keep all of the task's data local, bound to the task itself and hidden from the rest of the system.
  • Communicate among tasks asynchronously via intermediary event objects. Using asynchronous event posting keeps the tasks running truly independently without blocking on each other.
  • Tasks should spend their lifetime responding to incoming events, so their mainline should consist of an event loop.
  • Tasks should process events one at a time (to completion), thus avoiding any concurrency hazards within a task itself.

Active objects dramatically improve your ability to reason about the concurrent software. In contrast, using raw RTOS tasks directly is trouble for a number of reasons, particularly because raw tasks are undisciplined and offer you no help or automation for the best practices. As with all good patterns, active objects raise the level of abstraction above the naked threads and let you express your intent more directly thus improving your productivity.

QP Components

Historical Note: The concept of autonomous software objects communicating by message passing dates back to the 1970s, when Carl Hewitt at MIT developed a notion of an actor. In the 1990s, methodologies like ROOM adapted actors for real-time computing. More recently, UML has introduced the concept of active objects that is essentially synonymous with the ROOM actor. Today, the actor model is all the rage in the enterprise computing, because it can deliver levels of reliability and fault tolerance unachievable really with the "free threading" approach. A number of actor programming languages (e.g., Erlang, Scala, D) as well as actor libraries and frameworks (e.g., Akka, Killim, Jetlang) are in extensive use. In the real-time embedded space, active objects frameworks provide the backbone of various modeling and code generation tools. Examples include: IBM Rational Rhapsody (with OXF/SXF frameworks) and National Instruments LabVIEW (with LabVIEW Actor Framework).

QP ROM-RAM footprint

Active Object Frameworks for Microcontrollers

Active objects cannot operate in a vacuum and require a software infrastructure (framework) that provides, at a minimum, an execution thread for each active object, queuing of events, and event-based timing services. In the resource-constrained embedded systems, the biggest concern has always been about scalability and efficiency of such frameworks, especially that the frameworks accompanying various modeling tools have traditionally been built on top of a conventional RTOS, which adds memory footprint and CPU overhead to the final solution.

The QP frameworks have been designed for efficiency and minimal footprint from the ground up and do not need an RTOS in the stand-alone configuration. In fact, when compared to conventional RTOSes shown on the left, QP frameworks provide the smallest footprint especially in RAM (data space), but also in ROM (code space). This is possible, because active objects don't need to block, so most blocking mechanisms (e.g., semaphores) of a conventional RTOS are not needed.

All these characteristics make event-driven active objects a perfect fit for single-chip microcontrollers (MCUs). Not only you get the productivity boost by working at a higher level of abstraction than raw RTOS tasks, but you get it at a lower resource utilization and better power efficiency, because event-driven systems use the CPU only when processing events and otherwise can put the MCU in a low-power sleep mode.

Asynchronous Communication

Asynchronous Communication

Each active object has its own event queue and receives all events exclusively through this queue. Events are delivered asynchronously, meaning that an event producer merely posts an event to the event queue of the recipient active object but doesn't wait in line for the actual processing of the event. The event processing occurs always in the thread context of the recipient active object. The QP framework is responsible for delivering and queuing the events in a thread-safe and deterministic manner.


True Encapsulation for Concurrency

In a sense active objects are the most stringent form of object-oriented programming (OOP), because the asynchronous communication enables active objects to be truly encapsulated. In contrast, the traditional OOP encapsulation, as provided by C++, C# or Java, does not really encapsulate anything in terms of concurrency. Any operation on an object runs in the caller's thread and the attributes of the object are subject to the same race conditions as global data, not encapsulated at all. To become thread-safe, operations need to be explicitly protected by a mutual exclusion mechanism, such as a mutex or a monitor, but this reduces parallelism dramatically, causes contention, and is a natural enemy of scalability.

In contrast, all private attributes of an active object are truly encapsulated without any mutual exclusion mechanism, because they can be only accessed from the active object's own thread. Note that this encapsulation for concurrency is not a programming language feature, so it is no more difficult to achieve in C as in C++, but it requires a programming discipline to avoid sharing resources (shared-nothing principle). However, the event-based communication helps immensely, because instead of sharing a resource, a dedicated active object can become the manager of the resource and the rest of the system can access the resource only via events posted to this manager active object.


Run-to-Completion Event Processing

Each active object handles events in run-to-completion (RTC) fashion, which also is exactly the semantics universally assumed by all state machine formalisms, including UML statecharts. RTC simply means that an active object handles one event at a time, that is, the active object must complete the processing of an event before it can start processing of the next event from its queue.

In the case of active objects, where each object runs in its own thread, it is important to clearly distinguish the notion of RTC from the concept of thread preemption. In particular, RTC does not mean that the active object thread has to monopolize the CPU until the RTC step is complete. Under a preemptive kernel, an RTC step can be preempted by another thread executing on the same CPU. This is determined by the scheduling policy of the underlying kernel, not by the active object model. When the suspended thread is assigned CPU time again, it resumes from the point of preemption and, eventually, completes its event processing. As long as the preempting and the preempted threads don't not share any resources, there are no concurrency hazards.

No Blocking

Most conventional RTOS kernels manage the tasks and all inter-task communication based on blocking, such as waiting on a semaphore. However, blocking is problematic, because while a task is blocked waiting for one type of event, the task is not doing any other work and is not responsive to other events. Such a task cannot be easily extended to handle new events.

In contrast, event-driven active objects don't need to block, because in event-driven systems the control is inverted compared to traditional RTOS tasks. Instead of blocking to wait for an event, an active object simply finishes its RTC step and returns to the framework to be activated when the next event arrives. This arrangement allows active objects to remain responsive to events of all types, which is central to the unprecedented flexibility and extensibility of active object systems.

The QP frameworks provide all mechanisms you might need for non-blocking operation. For example, instead of delaying an active object with a blocking delay() call, you can use a time event to arrange activation in the specific time in the future.


Super-Fast Preemptive Kernel

While the active object model can work with a traditional blocking RTOS, it can also work with a much simpler non-blocking, run-to-completion kernel (see also basic tasks in OSEK/VDX). The QP frameworks provide such a super-simple and super-fast kernel called QK, which provides fully preemptive multitasking using a single stack for all active object threads.

The fixed-priority, preemptive QK kernel meets all the assumptions of the Rate Monotonic Analysis (RMA) to ensure schedulability of active object's threads. In fact, the non-blocking execution model makes the RMA method much simpler to apply to a system of active objects than to a set of RTOS tasks.

Hierarchical State Machines

Hierarchical State Machines

The behavior of each active object in QP is specified by means of a hierarchical state machine (UML statechart), which is the most effective and elegant technique of decomposing event-driven behavior. The most important innovation of UML state machines over classical FSMs is the hierarchical state nesting. The value of state nesting lies in avoiding repetitions, which are inevitable in the traditional "flat" FSM formalism and are the main reason for the "state-transition explosion" in FSMs. The semantics of state nesting allow substates to define only the differences of behavior from the superstates, thus promoting sharing and reusing behavior.

The hallmark of the QP implementation technique is traceability, which is direct, precise, and unambiguous mapping of every state machine element to human-readable C or C++ code. Preserving the traceability from requirements through design to code is essential for mission-critical systems, such as medical devices or avionic systems.

freeware QM tool

Freeware Graphical Modeling and Code Generation Tool

The QP state machine frameworks make also excellent targets for automatic code generation, which is provided by a graphical modeling tool called QM (QP Modeler). QM is a freeware, cross-platform, graphical UML modeling tool for designing and implementing real-time embedded applications based on the QP active object frameworks. QM is available for 64-bit Windows, 64-bit Linux, and Mac OS X.

QM provides intuitive diagramming environment for creating good looking hierarchical state machine diagrams and hierarchical outline of your entire application. QM eliminates coding errors by automatic generation of compact, production-quality, MISRA-compliant C or C++ code that is 100% traceable from your design.

QS software tracing

QS Software Tracing

QS™ (QP Spy) is a real-time tracing instrumentation built into the QP/C and QP/C++ active object frameworks and available also to the applications. QS allows you to gain unprecedented visibility into your application by selectively logging almost all interesting events occurring within state machines, the framework, the kernel, and your application code. QS event logging is minimally intrusive, offers precise time-stamping, sophisticated runtime filtering of events, and good data compression. QS can be configured to send the real-time data out of the serial or Ethernet port of the target device, or even write the data to a file.

MSRA compliance

Motor Industry Software Reliability Association (MISRA) Compliance

The QP/C and QP-nano frameworks comply with most of the MISRA-C:2004 rules while the QP/C++ framework complies with most of the MISRA-C++:2008 rules. All deviations are carefully limited into very specific contexts and are documented with the MISRA Compliance Matrices. The QP frameworks go even beyond MISRA, by complying with the strict type checking of PC-Lint and a very consistent, documented Quantum Leaps Coding Standard.

All QP framework types come with extensive support for automatic rule checking by means of PC-Lint, which is designed not just for proving compliance of the QP framework code, but more importantly, to aid in checking compliance of the application-level code. Any organization engaged in designing safety-related embedded software could benefit from the unprecedented quality infrastructure built around the QP frameworks.

(NOTE: MISRA and MISRA C are registered trademarks of MIRA Ltd, held on behalf of the MISRA Consortium.)


Documentation and Support

The QP family of active object frameworks comes with the most thorough documentation in the industry. In fact, we have literally written books on active object frameworks and state machines for embedded systems.

The latest book, Practical UML Statecharts in C/C++, 2nd Edition: Event-Driven Programming for Embedded Systems by Miro Samek, is the most popular text on UML statecharts, event-driven programming, and active objects for embedded systems. This ultimate resource describes all the related concepts and provides a very detailed design study of the QP frameworks.

The book is augmented by the extensive library of Application Notes, Articles and a popular "State Space" blog. Additionally, QP Development Kits (QDKs) for specific boards and compilers are accompanied by detailed User Manuals.

Free support is provided through the very active QP discussion forum hosted at SourceForge.net. Posts to this forum are typically answered the same day. Commercial technical support is provided with each commercial license. Training and consulting are available upon request.

QP Family Feature Comparison

QP/C QP/C++ QP-nano
UML-Compliant Event Processor (QEP™)
Feature QEP/C QEP/C++ QEP-nano
Highly maintainable and traceable boilerplate state machine mapping to C or C++
Yes Yes Yes
Full support for hierarchical state nesting
Yes Yes Yes
Full support for automatic entry/exit action execution on arbitrary state transition topology
Yes Yes Yes
Full support of nested initial transitions
Yes Yes Yes
Number of states limited only by code space in ROM
Yes Yes Yes
Support for events with parameters
Extremely small data requirements (RAM footprint) 1 pointer-to-
function per
state machine
1 pointer-to-
function per
state machine
plus the VPTR
1 pointer-to-
function per
state machine
Very small code size (ROM footprint) 0.6-1.5 KB2 0.8-2.0 KB2 0.5-1.0 KB2
Support for simpler non-hierarchical Finite State Machines with entry/exit actions
Yes Yes Yes
Fully reentrant event processor code with minimal stack requirements
Yes Yes Yes
Source code compliant with MISRA-C:2004 guidelines and passing strict analysis with PC-lint
Yes Yes Yes
QSPY software tracing instrumentation for testability
Yes Yes No
Real-Time Framework (QF®)
Feature QF/C QF/C++ QF-nano
Support for active object computing with the following number of active objects:
up to 63 up to 63 up to 8
Deterministic thread-safe execution of active objects
Yes Yes Yes
Inherently low-power architecture
Yes Yes Yes
Direct event delivery with first-in-first-out (FIFO) policy
Yes Yes Yes
Direct event delivery with last-in-first-out (LIFO) policy
Yes Yes No
Publish-subscribe event delivery with event multicasting capabilities
Yes Yes No
Dynamic events with zero-copy event passing policy for maximum performance
Yes Yes No3
Automatic recycling of dynamic events (garbage collection for events)
Yes Yes No4
Efficient zero-copy deferring and recalling events
Yes Yes No
One-shot time events (one-shot timers)
Yes5 Yes5 Yes6
Periodic time events (periodic timers)
Yes5 Yes5 No
Thread-safe event queues for task-to-ISR communication
Yes7 Yes7 No
Thread-safe memory partitions (fixed size heaps) for application use
Yes Yes No
Platform Abstraction Layer (PAL) for ease of portability
Yes Yes Yes
PAL supports integration with a traditional OS/RTOS
Yes Yes No
Cooperative kernel with prioritized execution of active objects
Yes Yes Yes
Small, scalable code size (ROM footprint)
2-4 KB2 2-4 KB2 0.5-2 KB2
Source code 98% compatible with MISRA guidelines and passing strict analysis with PC-lint
Yes Yes Yes
Assertion-based error handling
Yes Yes Yes
QSPY™ software tracing instrumentation for testability
Yes Yes No
Preemptive Run-to-Completion Kernel (QK™)
Feature QK/C QK/C++ QK-nano
Preemptive, priority-based, deterministic execution of one-shot tasks (active objects)
up to 63
up to 63
up to 8
Extremely fast run-to-completion event processing without blocking
Yes Yes Yes
Single stack for all tasks and interrupts
Yes Yes Yes
Allows using compiler-generated interrupt service routines
Yes Yes Yes
Highly portable to most CPUs and compilers
Yes Yes Yes
Priority-ceiling mutexes
Yes Yes Yes
Extended context switch for coprocessors
Yes Yes No
Thread-local storage
Yes Yes No
QSPY software tracing instrumentation for testability
Yes Yes No
Software Tracing (QS™)
Feature QS/C QS/C++
Minimally intrusive, thread-safe software tracing for all QP components
Yes Yes
Good data compression minimizing the buffering and bandwidth requirements
Yes Yes
Generic mechanisms for logging of application-level activity
Yes Yes
Sophisticated runtime filtering of records based on record-type and object type
Yes Yes
Precise time-stamping of trace records
Yes Yes
Robust HDLC-like data protocol
Yes Yes
Decoupled data logging and transmission for flexibility and portability
Yes Yes
Portable host-based application (QSPY) with full source code
Yes Yes
QSPY MATLAB® interface
Yes Yes
1 QEP-nano supports only fixed-size event parameter(s) of 0 (no parameter), 1, 2, or 4 bytes
2 The actual code size depends on the processor and the compiler, but the given ranges are representative
3 QF-nano copies entire fixed-size events
4 QF-nano does not need automatic event recycling
5 In QF/C and QF/C++ time events are allocated by the application and there is no limit how many could be used
6 QF-nano provides one time event per active object
7 In QF/C and QF/C++ thread-safe event queues are allocated by the application and there is not limit how many could be used

Last updated: June 08, 2015