QP (framework): Difference between revisions
m added reference to actor model |
language |
||
(39 intermediate revisions by 27 users not shown) | |||
Line 1: | Line 1: | ||
{{ |
{{Advert|date=May 2024}}{{Infobox OS |
||
| name = QP real-time embedded frameworks (RTEFs) |
|||
{{Infobox OS |
|||
| |
| logo = [[Image:Logo qp 256.png|256px|QP-framework]] |
||
| |
| developer = [https://www.state-machine.com Quantum Leaps] |
||
⚫ | |||
| source_model = [[Open source software|Open source]] |
| source_model = [[Open source software|Open source]] |
||
| kernel_type = |
| kernel_type = |
||
Line 12: | Line 11: | ||
| latest_release_date = |
| latest_release_date = |
||
| marketing_target = [[Embedded system]]s |
| marketing_target = [[Embedded system]]s |
||
| programmed_in = QP/C |
| programmed_in = QP/C in [[C (programming language)|C]], QP/C++ in [[C++]] |
||
| prog_language = |
| prog_language = |
||
| language = |
| language = |
||
| updatemodel = [ |
| updatemodel = [https://github.com/QuantumLeaps/ GitHub] |
||
| package_manager = |
| package_manager = |
||
| working_state = Mature |
| working_state = Mature |
||
| license = [[GNU General Public License|GPL]] and [[Commercial open source applications|Commercial]] ([[Dual licensing]]) |
| license = [[GNU General Public License|GPL]] and [[Commercial open source applications|Commercial]] ([[Dual licensing]]) |
||
| website = [ |
| website = [https://www.state-machine.com/ state-machine.com] |
||
}} |
}} |
||
'''QP''' ('''Quantum Platform''') is a family of [[open-source software|open source]] real-time embedded frameworks (RTEFs) and [[runtime environment]]s based on [[actor model|active objects (actors)]] and [[UML state machine|hierarchical state machines]] ([[UML state machine|UML statecharts]]). The QP family consists of the lightweight QP/C and QP/C++ frameworks, written in C ([[C99]]) and C++ ([[C++11]]), respectively.<ref name="PSiCC2"> |
|||
'''QP''' (Quantum Platform) is a family of lightweight, [[Open source|open source]] [[Software framework|software frameworks]] for building responsive and modular real-time [[Embedded system|embedded applications]] as systems of cooperating, [[Event-driven programming|event-driven]] [[Actor model|active objects (actors)]]. |
|||
== Overview == |
|||
The QP family consists of QP/C, QP/C++, and QP-nano frameworks, which are all strictly quality controlled, superbly documented<ref name=PSiCC2> |
|||
{{Cite book |
{{Cite book |
||
| |
| author = Miro Samek |
||
| first1 = Miro |
|||
| title = Practical UML Statecharts in C/C++, Second Edition: Event-Driven Programming for Embedded Systems |
| title = Practical UML Statecharts in C/C++, Second Edition: Event-Driven Programming for Embedded Systems |
||
| publisher = Newnes |
| publisher = Newnes |
||
| year = 2008 |
| year = 2008 |
||
| isbn = 978-0-7506-8706-5 |
| isbn = 978-0-7506-8706-5 |
||
⚫ | |||
| page = 728}}</ref>, and [[#Licensing|commercially licensable]]. |
|||
}}</ref> |
|||
All QP frameworks can run on "bare-metal" single-chip [[Microcontroller|microcontrollers]], completely replacing a traditional [[RTOS|Real-Time Operating System (RTOS)]]. Ports and ready-to-use examples are provided for all major [[#Supported Processors|CPU families]]. QP/C and QP/C++ can also work with a traditional [[OS|operating system]]/[[RTOS|RTOS]], such as: [[POSIX]] ([[Linux]], [[QNX]]), [[Microsoft Windows|Windows]], [[VxWorks]], [[ThreadX]], [[MicroC/OS-II|MicroC/OS]], [[FreeRTOS]], etc. |
|||
== Active Objects (Actors) For Real-Time == |
|||
⚫ | The behavior of [[Actor model|active objects (actors)]] is specified in QP by means of [[UML state machine|hierarchical state machines]] ([[UML state machine|UML statecharts]]). The frameworks support manual coding of UML state machines in [[C (programming language)|C]] or [[C++]] as well as fully [[Automatic programming|automatic code generation]] by means of the free graphical QM modeling tool<ref name=QM>{{Cite web |
||
The QP RTEFs are an implementation of the [[Actor model|Active Object (Actor)]] model of computation, specifically tailored for real-time embedded (RTE) systems. |
|||
⚫ | |||
| url = http://www.state-machine.com/qm}}</ref>. |
|||
Active Objects (Actors) can be combined with a wide variety of threading models, including [[Real-time operating system|real-time kernels]] (RTOS kernels). In the latter case, the combination, designed for deterministic performance, is called the '''Real-Time Embedded Framework''' (RTEF). This framework uses higher level abstractions than [[Real-time operating system|Real-Time Operating System (RTOS)]] in graphical modelling and code generation to embedded systems, which create safer{{Citation needed|date=July 2024}} and more responsive{{Citation needed|date=July 2024}} applications. |
|||
⚫ | |||
== |
=== Comparison to RTOS === |
||
Compared to a (real-time) framework, when using an [[Real-time operating system|RTOS]], the main part of each individual thread can be written in the application itself and the various RTOS services can be called from there (e.g. a time delay or a semaphore). <ref>{{Cite web |last=Sutter |first=Herb |title=Use Threads Correctly = Isolation + Asynchronous Messages |url=http://www.drdobbs.com/parallel/use-threads-correctly-isolation-asynch/215900465 |access-date=2022-09-27 |website=Dr. Dobb's}}</ref> |
|||
[[Actor model|Active objects]] inherently support and automatically enforce the following best practices of concurrent programming<ref>{{Cite web |
|||
| title = Use Threads Correctly = Isolation + Asynchronous Messages |
|||
| author = Herb Sutter |
|||
| url = http://www.drdobbs.com/parallel/use-threads-correctly-isolation-asynch/2159004655 |
|||
| date = March 16, 2009}}</ref>: |
|||
When you use a framework, you reuse the overall architecture (such as the event loop for all private threads of Active Objects) and you only write the code that the RTEF calls. This leads to inversion of control, which allows the RTEF to automatically enforce the best practices of concurrent programming. |
|||
* Keep all of the [[Task (computing)|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 [[Thread (computing)#Concurrency and data structures|concurrency hazards]] within a task itself. |
|||
== Hierarchical State Machines == |
|||
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 let you do anything and offer you no help or automation for the best practices<ref>{{Cite web |
|||
⚫ | The behavior of [[Actor model|active objects (actors)]] is specified in QP by means of [[UML state machine|hierarchical state machines]] ([[UML state machine|UML statecharts]]). The frameworks support manual coding of UML state machines in [[C (programming language)|C]] or [[C++]] as well as fully [[Automatic programming|automatic code generation]] by means of the free graphical QM modeling tool.<ref name="QM">{{Cite web |
||
| title = Prefer Using Active Objects Instead of Naked Threads |
|||
⚫ | |||
| author = Herb Sutter |
|||
| url = |
| url = https://www.state-machine.com/qm}}</ref> |
||
| date = June 14, 2010}}</ref>. As with all good patterns, active objects rise the level of abstraction above the naked threads and let you express your intent more directly thus improving your productivity. |
|||
⚫ | |||
Active objects cannot operate in a vacuum and require a software infrastructure ([[Software framework|framework]]) that provides, at a minimum: an execution [[Thread (computing)|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 [[UML tool|modeling tools]] have traditionally been built on top of a conventional [[RTOS]], which adds memory footprint and CPU overhead to the final solution. |
|||
== QP architecture and components == |
|||
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, QP frameworks provide smaller footprint especially in [[Random-access memory|RAM]] (data space), but also in [[Read-only memory|ROM]] (code space). This is possible, because active objects don't need to [[Blocking (computing)|block]], so most blocking mechanisms (e.g., [[Asynchronous semaphore|semaphores]]) of a conventional RTOS are not needed. |
|||
⚫ | |||
[[Image:QP block diagram.jpg|center|Figure 1: Block diagram showing QP components and their relationship to the hardware and the application]] |
|||
All these characteristics make [[[[Event-driven programming|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 chip in a low-power sleep mode. |
|||
⚫ | '''QEP''' (QP Event Processor) is a universal UML-compliant event processor that enables direct coding of [[UML state machine]]s (UML state charts) in highly maintainable C or C++, in which every state machine element is mapped to code precisely, unambiguously, and exactly once ([[traceability]]). QEP fully supports '''hierarchical state nesting''', which enables reusing behavior across many states instead of repeating the same actions and transitions over and over again. |
||
== QP Architecture and Components == |
|||
⚫ | |||
⚫ | |||
[[Image:Qp components.jpg|518px|QP components]] |
|||
'''QV''' (Cooperative Kernel) is a tiny [[Cooperative multitasking|cooperative]] kernel designed for executing active objects in a [[run-to-completion]] (RTC) fashion. |
|||
⚫ | '''QEP''' ( |
||
'''QK''' (Preemptive Kernel) is a tiny [[Preemptive multitasking|preemptive]] non-blocking run-to-completion kernel designed specifically for executing state machines in a [[run-to-completion]] (RTC) fashion. |
|||
⚫ | |||
''' |
'''QXK''' (Dual-Mode Kernel) is a tiny [[Preemptive multitasking|preemptive]] blocking kernel designed for hybrid applications consisting of active objects and traditional blocking threads. |
||
'''QS''' ( |
'''QS''' (QP/Spy) is a [[Tracing (software)|software tracing]] system that enables live monitoring of event-driven QP applications with minimal target system resources and without stopping or significantly slowing down the code. |
||
== Standalone (Bare-Metal) Operation == |
|||
== Supported Processors == |
|||
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-Mas, as well as other CPUs. |
|||
All types of QP frameworks (QP/C, QP/C++, and QP-nano) can be easily adapted to various microprocessor architectures and compilers. Adapting the QP software is called porting and all QP frameworks have been designed from ground up to make the porting easy. |
|||
== Traditional RTOS Integration == |
|||
Currently, bare-metal QP ports exist for the following processor architectures: |
|||
The QP RTEFs can also work with many traditional third-party RTOSes. QP ports and ready-to-use examples are provided for several RTOSes (such as [[Segger Microcontroller Systems#embOS]], [[ThreadX]], [[FreeRTOS]], [[Micro-Controller Operating Systems|uC/OS-II]], etc.) |
|||
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 QP™ active objects. |
|||
* [[ARM Cortex-M3]] (TI Stellaris, ST [[STM32]], NXP LPC) |
|||
* [[ARM Cortex-M0]] (NXP LPC1114) |
|||
* [[ARM architecture|ARM]]7/9 (Atmel AT91R4x, AT91SAM7, NXP LPC, ST STR912) |
|||
* [[Atmel AVR]] Mega/Xmega |
|||
* [[TI MSP430]] |
|||
* [[Texas Instruments TMS320|TI TMS320C28x]] |
|||
* [[Renesas Electronics|Renesas M32C/M16C/R8C]] |
|||
* [[Renesas Electronics|Renesas H8]] |
|||
* [[Freescale Coldfire]] |
|||
* [[Freescale 68HC08]] |
|||
* [[Nios II|Altera Nios II]] |
|||
* [[Intel MCS-51|8051]] (Silicon Labs) |
|||
* [[Intel MCS-51|80251]] (Atmel) |
|||
* [[PIC microcontroller|Microchip PIC18]] |
|||
* [[PIC microcontroller|Microchip PIC24/dsPIC]] |
|||
* [[PSoC|Cypress PSoC1]] |
|||
* [[80x86|80x86 real mode]] |
|||
== General Purpose OS Integration == |
|||
== Supported Operating Systems == |
|||
The QP |
The QP RTEFs can also work with general purpose OSes, such as [[Linux]] ([[POSIX]]), [[Windows]], and [[macOS]]. |
||
The QP ports to the general purpose operating systems are interested in their own right. For example, the QP port to [[POSIX]] supports real-time extensions and works with embedded Linux, and POSIX subsystems of such RTOSes as: [[QNX]], [[INTEGRITY]], [[VxWorks]], etc. Similarly, QP port to [[Windows]] can work with Windows IoT or Windows Embedded Compact. |
|||
Currently, QP ports exist for the following OSes/RTOSes: |
|||
But the OS support can be also interesting for developing of deeply embedded code on the desktop workstations, which is called "dual-targeting".<ref name="Dual-Targeting">{{Cite web |
|||
* [[Linux]] (POSIX) |
|||
| title = Dual Targeting and Agile Prototyping of Embedded Software |
|||
* [[Microsoft Windows|Win32]] (all desktop Windows and WindowsCE) |
|||
| url = https://www.state-machine.com/dual-targeting-and-agile-prototyping-of-embedded-software-on-windows}}</ref> |
|||
* [[VxWorks]] |
|||
* [[ThreadX]] |
|||
* [[FreeRTOS]] |
|||
* [[MicroC/OS-II]] |
|||
* [[QNX]] (POSIX) |
|||
* [[Integrity (operating system)|Integrity]] (POSIX) |
|||
== Licensing == |
== Licensing == |
||
QP framework are [[Multi-licensing|dual-licensed]] under the [[Open-source software|open source]] [[GNU General Public License|GPLv3]] and a selection of traditional, closed-source licenses. Users who wish to distribute QP (e.g. embedded inside devices) can retain the proprietary status of their code by applying for a commercial license. |
|||
== See also == |
== See also == |
||
*[[Actor model]] |
|||
*[[UML state machine]] |
|||
*[[Embedded operating system]] |
*[[Embedded operating system]] |
||
*[[Real-time operating system]] |
*[[Real-time operating system]] |
||
Line 130: | Line 93: | ||
== External links == |
== External links == |
||
*[ |
*[https://www.state-machine.com state-machine.com] |
||
*[ |
*[https://github.com/QuantumLeaps QP frameworks on GitHub] |
||
*[https://sourceforge.net/projects/qpc: QP frameworks on SourceForge] |
|||
*[http://www.hessmer.org/dev/qhsm qf4net: Quantum Framework for .Net] |
*[http://www.hessmer.org/dev/qhsm qf4net: Quantum Framework for .Net] |
||
*[http://sourceforge.net/projects/qfj qfj: Quantum Framework for Java on SourceForge.net] |
*[http://sourceforge.net/projects/qfj qfj: Quantum Framework for Java on SourceForge.net] |
||
*[ |
*[https://github.com/jjjesus/miros_py Miros: a hierarchical state machine module in Python] |
||
*[ |
*[https://github.com/jjjesus/miros Miros: a hierarchical state machine module in Lua] |
||
*[http://homepages.fh-regensburg.de/~mpool/mpool08/submissions/Sterkin.pdf State-Oriented Programming (Groovy)] |
*[https://web.archive.org/web/20110719004558/http://homepages.fh-regensburg.de/~mpool/mpool08/submissions/Sterkin.pdf State-Oriented Programming (Groovy)] |
||
*[http://accu.org/index.php/journals/252 ACCU Overload Journal #64 "Yet Another Hierarchical State Machine"] |
*[http://accu.org/index.php/journals/252 ACCU Overload Journal #64 "Yet Another Hierarchical State Machine"] |
||
*[http://www.drdobbs.com/184401643 C/C++ Users Journal "Who Moved My State?"] |
*[http://www.drdobbs.com/184401643 C/C++ Users Journal "Who Moved My State?"] |
||
*[http://www.drdobbs.com/184401665 C/C++ Users Journal "Deja Vu"] |
*[http://www.drdobbs.com/184401665 C/C++ Users Journal "Deja Vu"] |
||
*[http://www.scientific.net/KEM.392-394.309 Research on Open CNC System Based on Quantum Framework] |
*[http://www.scientific.net/KEM.392-394.309 Research on Open CNC System Based on Quantum Framework] |
||
*[https://web.archive.org/web/20120722180050/http://www.cs.wustl.edu/%7Eschmidt/PDF/Act-Obj.pdf Active Objects by Schmidt] |
|||
<!-- [[QP (framework)]] --> |
<!-- [[QP (framework)]] --> |
||
{{DEFAULTSORT: |
{{DEFAULTSORT:QP (Framework)}} |
||
[[Category:Real-time operating systems]] |
[[Category:Real-time operating systems]] |
||
[[Category:Embedded operating systems]] |
[[Category:Embedded operating systems]] |
||
[[Category:Free software operating systems]] |
[[Category:Free software operating systems]] |
||
[[Category:Embedded Linux]] |
[[Category:Embedded Linux]] |
||
[[Category: |
[[Category:Programming tools for Windows]] |
||
[[Category:Cross-platform software]] |
[[Category:Cross-platform software]] |
||
[[Category:Free software programmed in C++]] |
[[Category:Free software programmed in C++]] |
Latest revision as of 11:52, 1 August 2024
This article contains promotional content. (May 2024) |
Developer | Quantum Leaps |
---|---|
Written in | QP/C in C, QP/C++ in C++ |
OS family | Framework / RTOS |
Working state | Mature |
Source model | Open source |
Marketing target | Embedded systems |
Update method | GitHub |
License | GPL and Commercial (Dual licensing) |
Official website | state-machine.com |
QP (Quantum Platform) is a family of open source real-time embedded frameworks (RTEFs) and runtime environments based on active objects (actors) and hierarchical state machines (UML statecharts). The QP family consists of the lightweight QP/C and QP/C++ frameworks, written in C (C99) and C++ (C++11), respectively.[1]
Active Objects (Actors) For Real-Time
[edit]The QP RTEFs are an implementation of the Active Object (Actor) model of computation, specifically tailored for real-time embedded (RTE) systems.
Active Objects (Actors) can be combined with a wide variety of threading models, including real-time kernels (RTOS kernels). In the latter case, the combination, designed for deterministic performance, is called the Real-Time Embedded Framework (RTEF). This framework uses higher level abstractions than Real-Time Operating System (RTOS) in graphical modelling and code generation to embedded systems, which create safer[citation needed] and more responsive[citation needed] applications.
Comparison to RTOS
[edit]Compared to a (real-time) framework, when using an RTOS, the main part of each individual thread can be written in the application itself and the various RTOS services can be called from there (e.g. a time delay or a semaphore). [2]
When you use a framework, you reuse the overall architecture (such as the event loop for all private threads of Active Objects) and you only write the code that the RTEF calls. This leads to inversion of control, which allows the RTEF to automatically enforce the best practices of concurrent programming.
Hierarchical State Machines
[edit]The behavior of active objects (actors) 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.[3]
The QP frameworks and the QM modeling tool are used in medical devices, defense & aerospace, robotics, consumer electronics, wired and wireless telecommunication, industrial automation, transportation, and many more.
QP architecture and components
[edit]QP consists of a universal UML-compliant event processor (QEP), a portable, event-driven, real-time framework (QF), a selection of built-in real-time kernels (QV, QK, or QXK), and a software tracing system (QS).
QEP (QP Event Processor) is a universal UML-compliant event processor that enables direct coding of UML state machines (UML state charts) in highly maintainable C or C++, in which every state machine element is mapped to code precisely, unambiguously, and exactly once (traceability). QEP fully supports hierarchical state nesting, which enables reusing behavior across many states instead of repeating the same actions and transitions over and over again.
QF (QP Active Object Framework) is a highly portable, event-driven, real-time application framework for concurrent execution of Active Objects specifically designed for real-time embedded systems.
QV (Cooperative Kernel) is a tiny cooperative kernel designed for executing active objects in a run-to-completion (RTC) fashion.
QK (Preemptive Kernel) is a tiny preemptive non-blocking run-to-completion kernel designed specifically for executing state machines in a run-to-completion (RTC) fashion.
QXK (Dual-Mode Kernel) is a tiny preemptive blocking kernel designed for hybrid applications consisting of active objects and traditional blocking threads.
QS (QP/Spy) is a software tracing system that enables live monitoring of event-driven QP applications with minimal target system resources and without stopping or significantly slowing down the code.
Standalone (Bare-Metal) Operation
[edit]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-Mas, as well as other CPUs.
Traditional RTOS Integration
[edit]The QP RTEFs can also work with many traditional third-party RTOSes. QP ports and ready-to-use examples are provided for several RTOSes (such as Segger Microcontroller Systems#embOS, ThreadX, FreeRTOS, uC/OS-II, etc.)
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 QP™ active objects.
General Purpose OS Integration
[edit]The QP RTEFs can also work with general purpose OSes, such as Linux (POSIX), Windows, and macOS.
The QP ports to the general purpose operating systems are interested in their own right. For example, the QP port to POSIX supports real-time extensions and works with embedded Linux, and POSIX subsystems of such RTOSes as: QNX, INTEGRITY, VxWorks, etc. Similarly, QP port to Windows can work with Windows IoT or Windows Embedded Compact.
But the OS support can be also interesting for developing of deeply embedded code on the desktop workstations, which is called "dual-targeting".[4]
Licensing
[edit]QP framework are dual-licensed under the open source GPLv3 and a selection of traditional, closed-source licenses. Users who wish to distribute QP (e.g. embedded inside devices) can retain the proprietary status of their code by applying for a commercial license.
See also
[edit]References
[edit]- ^ Miro Samek (2008). Practical UML Statecharts in C/C++, Second Edition: Event-Driven Programming for Embedded Systems (PDF). Newnes. ISBN 978-0-7506-8706-5.
- ^ Sutter, Herb. "Use Threads Correctly = Isolation + Asynchronous Messages". Dr. Dobb's. Retrieved 2022-09-27.
- ^ "freeware graphical QM modeling tool".
- ^ "Dual Targeting and Agile Prototyping of Embedded Software".
External links
[edit]- state-machine.com
- QP frameworks on GitHub
- QP frameworks on SourceForge
- qf4net: Quantum Framework for .Net
- qfj: Quantum Framework for Java on SourceForge.net
- Miros: a hierarchical state machine module in Python
- Miros: a hierarchical state machine module in Lua
- State-Oriented Programming (Groovy)
- ACCU Overload Journal #64 "Yet Another Hierarchical State Machine"
- C/C++ Users Journal "Who Moved My State?"
- C/C++ Users Journal "Deja Vu"
- Research on Open CNC System Based on Quantum Framework
- Active Objects by Schmidt