QEP Brochure (700KB)
| Application | ||||||
 |
||||||
| Quantum Event Processor (QEP) | ||||||
|
||||||
| Quantum | Framework™ (QF) | Quantum | Spy™ (QS) | |||
|
||||||
| Quantum Kernel (QK) or other Kernel/RTOS | ||||||
|
||||||
| Target Hardware | ||||||
Quantum Event Processor (QEP) is a generic, portable, and reusable state machine engine that processes events according to the general semantics of UML™ state machines. QEP provides facilities for executing Hierarchical State Machines (HSMs) as well as the simpler traditional Finite State Machines (FSMs). QEP is a passive component, which means that it needs to be externally called to handle events. The event processor is designed to operate with almost any event queuing and dispatching mechanisms, which are also necessary components of a hypothetical state machine [OMG 01]. For example, QEP can be used with virtually all existing event-driven environments, such as Quantum Framework™ (QF), GUI systems (e.g., Microsoft Windows™), Java™ event model, and many others. Currently QEP is available in C, C++, Java, C#, ActionScript, and other languages. QEP has been described in Part 1 of the book Practical Statecharts in C/C++.
Features
Full support for hierarchical state nesting.
Full support for automatic entry/exit action execution on arbitrary state transition topology.
Full support of nested initial transitions.
Number of states limited only by code space (ROM).
Extremely small footprint. A hierarchical state machine requires only one pointer and a byte of flags in RAM. The QEP code requires about 1.5KB code space (ROM).
Highly maintainable "cookie cutter" state machine representation in C or C++ that is very easy to modify/extend at any stage of the development cycle.
Support for events with arbitrary parameters.
Support for "static" state transition optimization for unparalleled speed.
Support for simpler Finite State Machines, , which require only about 100 bytes in of code space.
Easy to integrate with any event queueing and dispatching mechanisms (e.g., GUI systems like Windows™)
Comprehensive Programmer's Manual
Sample applications included in the distributions and explained in the manual
Very clean source code passing strict static analysis with PC-Lint™.
Source code 99%-compliant with the Motor Industry Software Reliability Association (MISRA) Guidelines For The Use of The C Language in Vehicle Based Software [MISRA 98].
Dual-license model with choice between open source and flexible, royalty-free commercial licensing.
Open source development model as well as commercial support options.
Top of pageHigh Portability
QEP is a passive component that does not make any operating system calls. Porting QEP is just a matter of recompilation.
Top of pageExplanation of Internals
The internals of QEP are described in Part 1 of the book: Practical Statecharts in C/C++, which is available worldwide from most technical bookstores and through online retailers, such as www.amazon.com. The quantum-leaps.com website provides ample coding "recipes", state design patterns, and application examples.
Top of pageVersions of QEP
Currently, versions of Quantum Event Processor are available in ANSI-C and Embedded C++. These are completely separate code sets, not merely a C++ interface to C.
Top of pageClean, Portable, Source Code
All versions of QEP come with complete, very clean, portable, source code. The source code strictly complies with Quantum Leaps C/C++ Coding Standard, has been thoroughly "combed" with PC-Lint™, and is 99% compliant with the Motor Industry Software Reliability Association (MISRA) Guidelines For The Use of The C Language in Vehicle Based Software [MISRA 98]. All data types, constants, and functions in QEP start with the prefix 'Q' or 'QEP', which should make it easier to recognize that the services belong to the event processor and should minimize name compile-time and link-time conflicts with other software.
Top of pageSmall Footprint
QEP is deployed as a very-fine granularity library for "self configuration", which is automatic elimination of unused features at link-time as opposed to hand-configuration at compile-time via preprocessor macros. Therefore QEP scales down automatically to include only code for features actually used.
QEP uses no standard C-runtime library (e.g., string manipulation, printf(), malloc(), etc.). Obviously, the event processor doesn't use any floating point operations, but even fixed-point division is carefully avoided (which might be important for ARM processors). This means that the standard C-runtime can be trimmed down drastically further reducing the code space requirements.
QEP does not use any RAM-intensive implementation techniques, such as state-tables. A state machine in QEP requires only a few bytes of RAM to store the current active state, but states are represented as pure code (ROM).
The event processor has been very carefully designed to conserve the stack space, which is particularly important in multitasking environments, where each task (active object) runs on it's own stack.
Top of pagePerformance
QEC event dispatching is very fast and requires de-referencing only a single function pointer. However, for complicated transitions between arbitrarily nested states the event processor must find and execute correct chain of exit/entry actions and initial transitions, which can be somewhat expensive. To speed up frequently executed time-critical transitions, QEP offers an optional "static state transition" optimization. At the cost of several bytes in RAM, the transition chain can be evaluated only once and stored for quick "playback" on subsequent executions of the transition.
Top of pageObject Orientation
The basic architecture of QEP is fundamentally object-oriented, which means that QEP uses encapsulation (classes) and inheritance (deriving new classes from the existing ones).
Object-orientation of the C version of QEP might be perceived as an obstacle to some C programmers. However, the way encapsulation and inheritance are used in QEP/C should, in fact, come as very familiar to any C programmer. A Quantum Leaps coding recipe "Simple Encapsulation and Inheritance in C" describes how QF/C implements these object-oriented concepts. Earlier versions of QEP (v.2.x) used more advanced OOP techniques in C, called "C+". Starting from version 3.0 QEP/C does not use "C+", although it is fully compatible with "C+".
Top of pageDesign by Contract™
An important aspect of QEP that you, as the event processor user, need to understand is the way it uses assertions. In this respect, the QEP applies elements of the Design by Contract™ (DBC) methodology pioneered by Bertrand Meyer [Meyer 97]. (See also C/C++ Users Journal Article "An Exception or a Bug".)
DBC is a different, much more modern philosophy compared to traditional technique of returning error status from API calls. You'll see no error returns from QEP. Instead, QEP uses assertions internally to help you detect errors, not so much inside the event processor, but in the state machines implemented with it. The assertion facilities used inside QEP are simple, but highly customizable to the domain of RTE systems.
Top of page
Version: April 20, 2006