qp/qm quick overview

QP/QM Overview 11/02/13

(c) Quantum Leaps, LLC 1

state-machine.com

Quick Overview ofQuick Overview ofQP Frameworks & QM Modeling Tool

This presentation provides a quick overview of the QP™ active object (actor) frameworks and the QM™ modeling and code-generation tool for QP.



state-machine.com 2

Presentation Outline

• What is QP?

• Active Objects (Actors) for Real-Time Embedded Systems

• Hierarchical State Machines (UML Statecharts)

• QM--Free Graphical Modeling and Code Generation Tool

• QS Software Tracing

• MISRA Compliance

What is QP?



state-machine.com 6

Who is using it?● Millions of products: medical, defense, communication,

transportation, industrial, consumer, ...

Who is using it?

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

****

NOTE: The shown logos represent just a partial list of commercial QP licensees, which has not been updated since 2010.

****



state-machine.com 8


• What is QP?






Active Objects (Actors) for RTE Systems



state-machine.com 9

Active Objects (Actors)

● Active objects (actors) automatically enforce the following best practices of concurrent programming(*):

1. Keep all of the task's data local, bound to the task itself and encapsulated from the rest of the system.

2. Communicate among tasks asynchronously via intermediary event objects. This avoids blocking tasks to wait on each other.

3. Tasks should spend their lifetime responding to incoming events, so their mainline should consist of an event loop.

4. Tasks should process events one at a time (to completion), thus avoiding any concurrency hazards within a task itself.

(*) Articles by: Herb Sutter, Edward E. Lee, dr. Dave Stewart, Jack Ganssle, ...

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.

By inherently supporting and automatically enforcing the enumerated best practices of concurrent programming , 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. 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.

Best Practices of Concurrent Programming:

Herb Sutter: “Use Threads Correctly = Isolation + Asynchronous Messages”, March 2009.

Herb Sutter: “Prefer Using Active Objects Instead of Naked Threads”, June, 2010.

Herb Sutter: “Sharing is the Root of All Contention”, February, 2009

Dr. Dave Stewart: "Fundamentals of Advanced Real-Time Operating Systems”, Wind River

Prof. Edward E. Lee: “The Problem with Threads”, January, 2006



state-machine.com 10

Active Objects for Embedded MCUs

● Active objects cannot operate in a vacuum and require a software infrastructure (framework)

QP frameworks are smaller than typical bare-bones RTOSes

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, 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● All events are delivered asynchronously:

1. Each active object has its own event queue and receives all events exclusively through this queue.

2. Event producers merely post events to the AO queues but they don't wait in line for the processing of the events.

Each active object has its own event queue and receives all events exclusively through this queue. All 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.

The asynchronous event-based communication has several beneficial implications. Some of the most important include avoiding of blocking and mitigating the need for global variables.

Blocking is avoided, because tasks don't need to wait until the recipient is ready to receive the event.

Global variables can be avoided, because events carry both the information about the nature of the event (event signal) and the data associated with this event (event parameters). Typically, the extra information in the event parameters (delivered in a thread-safe manner by the framework) allows the recipient of the event to handle the event. In contrast, un-blocking of a semaphore or setting a condition variable in a traditional RTOS does not provide sufficient information about the event and forces programmers to provide the needed information via global variables.




True Encapsulation for Concurrency

● Traditional encapsulation with synchronous methods does not encapsulate anything in terms of concurrency

→ AOs are the most stringent form of object-oriented programming

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 (RTC) Processing

● AOs process events one at a time (to completion)

→ RTC should not be confused with thread preemption

→ AOs can preempt each other

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.

The picture of runners shows that even though each runner runs to completion of the race (the finish line) they can freely overtake each other. As long as the runners don't share the lanes, accidents cannot happen.




No Blocking (!)

● Event-driven AOs don't block to wait for events

→ Therefore AOs remain responsive to events

→ Easy to add new events

→ In contrast, all RTOS inter-task communication and synchronization is based on 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()/sleep() system call, you can use a time event to arrange activation in the specific time in the future.




Super-Fast Preemptive Kernel

● Non-blocking AOs can work with non-blocking kernels

→ Preemptive multitasking with a single stack

→ Fully compatible with Rate-Monotonic Analysis (RMA)

→ Less CPU, less RAM, shorter latencies.

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. 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 picture shows the preemptive execution profile of QK. A low priority active object task is executing when an interrupt occurs. The interrupt preempts the low-priority AO and posts an event to a higher-priority AO. At the end of the interrupt the QK scheduler is called and causes the interrupt to return to the higher-priority AO. The higher-priority AO is thus activated and runs immediately after the interrupt preempting the low-priority AO. Only after the higher-priority AO runs to completion, the low-priority AO resumes.

The fixed-priority, preemptive QK kernel meets all the assumptions placed on the underlying scheduler by the RMA technique (Rate Monotonic Analysis). In other words, RMA can be used in a system running under the QK kernel to mathematically 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, which might block.





• What is QP?






Hierarchical State Machines (UML Statecharts)




Specifying Behavior of Active Objects

● Each Active Object in QP has a state machine

→ Naturally handle events based on the type and the system state

→ Avoids “spaghetti code”--No 1. problem of event-driven systems.

The biggest challenge of event-driven programming lies in responding to events correctly. In general, correct response depends both on the type of the event and on the current state of the system.

Traditionally, the dependence on the state (mode) of the system very often leads to deeply nested IF-THEN-ELSE flow of control with high complexity of logic tests performed at each branching point. This type of code is also known as "spaghetti code" .

Techniques based on state machines are capable of dramatically reducing the “spaghetti code”, by cutting down the number of different paths through the code and simplifying the conditions tested at each branching point.

State machines beautifully complement the active object model of computation. Active objects provide queuing of events and the run-to-completion execution context that state machines need. (RTC execution is universally assumed in all state machine formalisms, including UML Statecharts.)

As shown in the picture, each Active Object in QP has an encapsulated state machine that handles the events posted to the AO's event queues. In fact, most of the effort in developing QP applications goes into elaborating state machines of the active objects. To this end, QP provides very strong support for coding state machines directly in C or C++. The graphical QM modeling tool provides also support for automatic generation of the state machine code from state diagrams.




Transition Explosion in Traditional FSMs

● Traditional Finite State Machines inflict repetitions

→ There is no way to capture similar transitions

Though the traditional FSMs are an excellent tool for tackling smaller problems, it’s also generally known that they tend to become unmanageable, even for moderately involved systems. Due to the phenomenon known as transition explosion, the complexity of a traditional FSM tends to grow much faster than the complexity of the reactive system it describes. This happens because the traditional state machine formalism inflicts repetitions.

For example, if you try to represent the behavior of a basic calculator with a traditional FSM, you’ll immediately notice that many events (e.g., the Clear event) are handled identically in many states. A conventional FSM, however, has no means of capturing such a commonality and requires repeating the same actions and transitions in many states. What’s missing in the traditional state machines is the mechanism for factoring out the common behavior in order to share it across many states.




Reuse of Behavior Through State Nesting

● Hierarchical State Machines support state nesting

→ Nested states inherit the behavior from the surrounding states

The most important innovation of UML statecharts over classical FSMs is the hierarchical state nesting (that's why statecharts are also called Hierarchical State Machines).

The semantics of state nesting have been specifically designed to allow substates to define only the differences of behavior from the superstates, thus promoting sharing and reusing behavior (programming by difference).

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. For example, in the hierarchical state machine of the calculator, the multiple C (Cancel) and OFF transitions have been replaced with the equivalent single C transition and single OFF transition in the “on” state.




Manual Coding of HSMs in QP/C++QState Calc::on(Calc *me, QEvt const *e) { switch (e->sig) { case Q_ENTRY_SIG: { // entry action BSP_message("on-ENTRY"); return Q_HANDLED(); } case Q_EXIT_SIG: { // exit action BSP_message("on-EXIT"); return Q_HANDLED(); } case Q_INIT_SIG: { // initial transition BSP_message("on-INIT"); return Q_TRAN(&Calc::ready); } case C_SIG: { // state transition BSP_clear(); // clear the display return Q_TRAN(&Calc::on); } case OFF_SIG: { // state transition return Q_TRAN(&Calc::final); } } return Q_SUPER(&QHsm::top); // superstate}

From the inception, the formalism of Statecharts has been intended for automatic coding by specialized tools. Consequently, there are only very few implementations of Statecharts in C or C++ and virtually none suitable for single-chip microcontrollers.

However, the arguably most valuable subset of UML Statecharts (including state nesting) can be implemented in C or C++ and all QP frameworks have been designed to make manual coding of hierarchical state machines easy.

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, avionic systems, automotive systems, industrial control systems, etc.





• What is QP?






QM—Free Graphical and Code Generation Tool




How Does it Work?

1. Create AO classes

2. Draw state machines

3. Add actions/guard code

4. Generate code

The main benefit of using QM is that it allows you to take advantage of the very expressive graphical representation of UML Statecharts for designing your applications and then you can automatically generate code from your designs, thus eliminating the whole class of coding errors.

QM is much simpler than most UML tools, because QM is not attempting to support an open-ended number of frameworks or programming languages. QM is specialized for the QP active object frameworks, and is intentionally very close to the code. In other words, you enter the code for state machine actions and guard conditions directly in C or C++ (depending on the QP framework type). Special “action languages” or indirection layers of “platform independent models” (PIMs) are not used.




What's Special about QM?

Turning code generation“upside down”...

The main objective of QM™ is to empower your designs without standing in your way. The tool respects your design decisions and lets you determine the generated code structure, directory names, file names, and elements that go into every file.

Unlike in all other code generating tools, QM will not enforce any specific directory structure and file names. Compared to the beaten path approach, QM turns code generation “upside down” . In QM, you specify the file names and directory structure. In your files, you can use as much of your code as you need, and you can order QM to generate model elements of your choice through straightforward code-generation directives embedded in the source code.

This technique allows you to mix your own code with the synthesized code and use QM to generate as much or as little of the overall code as you see fit.

Even at the low level, QM respects your graphical layout as much as possible and will not re-attach or re-route connectors, re-size nodes, or adjust text annotations. You will find that you don't need to "fight" the tool.





• What is QP?






QS Software Tracing




Why Software Tracing?

Biggest problem: limited visibility into the embedded system

→ You need to observe the system live; not stopped in a debugger

In any real-life project, creating the code is only the first step. The system still needs to be tested, debugged, validated, and tuned for best performance. A single-step debugger is frequently not useful, because it stops the CPU and hinders observing live interactions within the system.

Traditionally, programmers have overcome this limitation by inserting printf() statements into the code to obtain visibility into the system without stopping it. But printf() is a very primitive, intrusive, and inefficient way of obtaining the run-time information, mostly because it entails very expensive formatting of binary data into ASCII in the time-critical path through the code.

Software tracing is similar to peppering the code with printf() statements for event logging and debugging, except that professional software tracing is much less intrusive and more selective than printf().

Software-tracing techniques are especially effective and powerful in combination with an event-driven, active object framework, because all important system interactions funnel through the framework.




QS Software Tracing System

QS (QP Spy ) tracing provides wealth of information:

→ All state machine activities (entering/exiting states, transitions,...)

→ All event posting, event queuing, event dispatching, …

→ Real-time Kernel scheduling, task switches, ...

QS™ (QP Spy) is a professional software-tracing system built into the QP/C and QP/C++ active object frameworks and also available to the application-level code. QS event logging is minimally intrusive, offers precise time-stamping, sophisticated run-time filtering of events, and a robust communication protocol with 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.

****

NOTE: The QS tracing instrumentation is designed to be left permanently in the source code, but is only active (generates code) in the Spy build configuration. It is completely inactive in the production code, so it does not consume any CPU cycles or memory.

*****

Because the QP frameworks control virtually all interesting occurrences within the application, the QS instrumentation in the framework alone can report the activities of all state machines (state entry/exit, initial transitions, regular transitions), event passing and queuing, time events, memory pool activity, and finally also real-time kernel activities, such as task switching, mutexes, etc.

The data log produced by QS allows you to monitor the behavior of QP applications in a live environment without degrading the application itself. It allows you to discover and document elusive, intermittent bugs that are caused by subtle interactions among concurrent components. It enables executing repeatable unit and integration tests of your system. It can help you ensure that your system runs reliably for long periods of time and gets top processor performance.




QSPY Host Application

QSPY host application receives and displays the QS data:

→ → Human-readable formatHuman-readable format

→ → Interface to MATLAB/GNU-OctaveInterface to MATLAB/GNU-Octave

→ → Interface to Message-Sequence-Chart (MSC) generator Interface to Message-Sequence-Chart (MSC) generator

The QSPY host application is provided in source code and runs on Windows, Linux, and Mac OS X.

The QSPY application receives the QS trace data from the target, decompresses it, and can generate output for further analysis:

1. Human readable format is for direct viewing of the data

2. MATLAB format allows analyzing the data in MATLAB or GNU Octave

3. MSC (Message Sequence Chart) format allows generating the MSC diagrams

Additionally, the QSPY application can be embedded directly in the QP application on Windows or Linux, which can be very useful for developing embedded applications on Windows (dual targeting).





• What is QP?





• MISRA Compliance MISRA Compliance




MISRA Compliance

Safe subset of C or C++ for use in safety critical applications

→ → MISRA Compliance Matrices for QP/C, QP/C++, and QP-nanoMISRA Compliance Matrices for QP/C, QP/C++, and QP-nano

→ → Complete suite of scripts and tools to automate checking of Complete suite of scripts and tools to automate checking of

comliance of the application-level code with PC-Lintcomliance of the application-level code with PC-Lint

Due to the numerous idiosyncrasies, pitfalls, and undefined behavior of the standard C language, most experts agree that the full, unconstrained language should not be used for programming safety-critical systems. Consequently, the main objective of the MISRA-C guidelines was to define and promote a safer subset of the C language suitable for embedded systems. The MISRA-C guidelines define this language subset by means of 141 rules that restrict the use of the known problematic aspects of the language. For each of the rules the MISRA-C guidelines provide justification and examples.

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.

qp/qm quick overview

Technology