The following annotated directory tree lists the top-level directories provided in the standard QP-nano distribution.
The QP-nano active object framework is comprised of the following components:
QEP-nano is a universal, UML-compliant event processor that enables developers to code UML state machines in highly readable ANSI-C, in which every state machine element is mapped to code precisely, unambiguously, and exactly once (traceability). QEP-nano fully supports hierarchical state nesting, which is the fundamental mechanism for reusing behavior across many states instead of repeating the same actions and transitions over and over again. (See also QEP-nano).
QF-nano is a portable, event-driven, active-object (actor) framework for execution of active objects (concurrent state machines) specifically designed for real-time embedded (RTE) systems. (See also QF-nano).
QV-nano is a simple cooperative kernel (previously called "Vanilla" kernel). This kernel executes active objects one at a time, with priority-based scheduling performed before processing of each event. Due to naturally short duration of event processing in state machines, the simple QV kernel is often adequate for many real-time systems. (See also QV-nano).
QK-nano is a tiny preemptive, priority-based, non-blocking, real-time kernel designed specifically for executing active objects. QK-nano meets all the requirement of the Rate Monotonic Scheduling (a.k.a. Rate Monotonic Analysis — RMA) and can be used in hard real-time systems. (See also QK-nano).
The figure below shows the main classes comprising the QP-nano framework and their relation to the application-level code, such as the "Fly 'n' Shoot" Game example application.
0 The QEvt class represents events, possibly with a parameter (the existence of event parameter is configured by the macro #Q_PARAM_SIZE).
1 The abstract QHsm class represents a Hierarchical State Machine (HSM) with full support for hierarchical nesting of states, entry/exit actions, initial transitions, and transitions to history in any composite state. This class is designed for ease of manual coding of HSMs in C, but it is also supported by the QM modeling tool. The class is abstract, meaning that it is not designed to be instantiated directly, but rather only for inheritance. The "Fly 'n' Shoot" Game application provides an example of application-level classes deriving directly from QHsm (see [5]).
2 The abstract QActive class represents an active object that uses the QHsm style state machine implementation strategy. This strategy is tailored to manual coding, but it is also supported by the QM modeling tool. The "Fly 'n' Shoot" Game application provides an example of application-level classes deriving directly from QActive (see [4]).
3 QActiveCB (QActive Control Block) represents the read-only (constant) information that the QF-nano needs to manage the active object. QActiveCB objects are grouped in the array QF_active, which typically can be placed in ROM.
4 Active Objects in the application derive from the QActive base class.
5 Applications can also use classes derived directly from the QHsm base class to represent "raw" state machines that are not active objects, because they don't have event queue and execution thread. Such "raw" state machines are typically used as "Orthogonal Components".
The behavior of each active object in QP-nano is specified by means of a hierarchical state machine (UML statechart), which is the most effective and elegant technique of describing event-driven behavior. The most important innovation of UML state machines over classical finite state machines (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 Quantum Leaps Application Note A Crash Course in UML State Machines introduces the main state machine concepts backed up by examples.
The QP-nano framework has been developed in strict adherence to the documented Quantum Leaps Coding Standard.
The QP-nano framework complies with most of the Motor Industry Software Reliability Association (MISRA) MISRA-C:2004 rules.
All deviations are carefully limited into very specific contexts and are documented with the Application Note: QP-nano MISRA-C:2004 Compliance Matrix.
The MISRA guidelines place great emphasis on the use of static code analysts tools to check compliance with the MISRA-C language subset. To this end, QP-nano comes with an extensive support for automatic rule checking with PC-Lint. The QP frameworks go even beyond MISRA, by complying with the strict type checking of PC-Lint.
The QP-nano framework comes with extensive support for automatic rule checking by means of PC-Lint, which is designed not just for proving compliance of the QP-nano 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-nano framework.