本條目存在以下問題 ，請協助
改善本條目 或在
討論頁 針對議題發表看法。
此條目需要
精通或熟悉相关主题的编者 参与及协助编辑。
(2018年10月14日 ) 請邀請 適合的人士改善本条目 。更多的細節與詳情請參见討論頁 。
QP ("Quantum Platform ") 是一个用来构建模块化实时应用程序的开源框架。它采取事件驱动 的方式来调度系统中的各个操作发起者。
QP编程框架家族包括了QP/C，QP/C++，和QP-nano。它们都经由良好的质量控制，并且既有GPLv2开源协议，也可以进行商业许可[ 1] POSIX (Linux , QNX )，Windows ， VxWorks ，ThreadX ，uC/OS ，FreeRTOS 等等。
QP中各个活动对象 （actors）是由层次化状态机（UML状态图 ）来表征的。QP框架支持由C或者C++编写的UML状态机 ，也支持由免费的QM建模工具直接进行自动代码生成。[ 2]
活动对象原生支持并自动保证以下并发编程 中的最佳实践：[ 3]
保证所有的任务数据都应当是本地的，私有的，并且无法从系统的其他部分访问。
任务键的通信应当使用中间事件对象异步进行。使用异步通信可以使各任务真正互相独立并不互相阻塞。
在任务的整个生命周期中它都应当响应事件，因此其主要部分应该是一个事件循环 。
任务应当每次处理一个事件，并在处理完毕之前不应响应其他事件，因此在任务之中没有竞争冒险 。 使用活动对象使得思考并发编程变得容易。相反，直接使用RTOS任务有很多不利之处，尤其因为他们对使用方式不加限制，也不提供自动进行并发最佳实践的机制。[ 4]
活动对象并不能凭空产生，这往往需要一个软件框架来为每个活动对象提供一个线程，提供事件排队服务以及基于事件的定时服务。在资源受限的嵌入式系统中，可扩展性和效率是此类框架的最大着力点之一。那些传统上建立在RTOS之上的建模工具和各类框架增加了内存消耗和CPU开销。
QP框架在设计时就着眼于效率和小内存占用，而且在独立构型中不需要一个RTOS。事实上，和传统的RTOS比起来，QP框架提供较少的RAM和ROM占用。这是有可能的；因为活动对象不需要阻塞，因此传统RTOS中的大部分阻塞机制（如信号量 等）是不需要的。
这些特性使得事件驱动框架适用于单片机 。比起原始的RTOS任务，事件驱动框架 是一个更高层次的抽象，并且资源占用率和能量消耗也低。这是由于事件驱动模型仅在处理事件时激活CPU，而在绝大多数时间CPU处于低功耗模式。
QP由一个合乎UML规范的事件处理器（QEP），一个可移植的事件驱动实时框架（QF），一个小型化的运行至完成的内核（QK）和一个软件跟踪系统（QS）组成.
QEP （Quantum Event Processor）是一个合乎UML规范的事件处理器。它使得UML状态机的直接编码（使用UML状态图）成为可能，并能生成高度可维护的C/C++代码。每一个状态机元素都精确无歧义地对应到唯一的代码片段。QEP完全支持层次化状态嵌套，这方便了子状态机的复用而无需重复进行编码。
QF （Quantum Framework）是一个高度可移植的、事件驱动的实时应用程序框架。它是专为实时嵌入式系统 中状态机 的并发执行设计的。
QK （Quantum Kernel）是一个小型的、非阻塞式的运行至完成 （Run-to-completion）的内核。它是专门为执行运行至完成的状态机 设计的。
QS （Quantum Spy）是一个软件跟踪系统，它能在只占用极少系统资源的前提下监视事件驱动的QP应用程序，并不会导致应用程序出线显著速度降低或者卡顿。
所有的QP框架（QP/C，QP/C++和QP-nano）都可以很容易地被移植到各种微处理器 和编译器 ，这是由于QP框架从设计之初就考虑到方便移植。下列的移植现在可用：
QP/C和QP/C++框架可以和下列的传统操作系统和实时操作系统 一起使用。当前，QP支持下列操作系统和实时操作系统：
所有的QP框架都采取双重授权，既可以采取GPLv2也可以采取传统的闭源商业授权。那些希望在嵌入式设备中闭源使用QP的公司可以获得一个商业授权。
