QP/C  7.2.2
Real-Time Embedded Framework
No Matches
QP Certification Kit
This QP Certification Kit has been specifically designed to aid companies in safety certification of their software based on the QP Framework treated as commercial off-the-shelf (COTS) software. Also, independently of the desired certification level, the QP Certification Kit is the best source of information about the functionality, architecture, and design of the QP Framework and the QP Applications based on the framework.

Requirements (SRS)

Documents Comprising the QP Certification Kit:

QP Certification Kits in PDF are available for commercial licensees.

Acronyms and Abbreviations

AO Active Object
ARC Architecture artifact (in UIDs for traceability)
BCET Best-Case Execution Time
CPU Central Processor Unit
COTS Commercial Off-The-Shelf Software
CUT Code Under Test
DMF Dangerous Mode of Failure
DBC Design By Contract
DES Design artifact (in UIDs for traceability)
DVP Deviation Permit (in UIDs for traceability)
DVR Deviation Record (in UIDs for traceability)
EUC Equipment Under Control
FAP Failure Assertion Programming ([IEC-61508-7])
FME Failure Mode and Effects (in UIDs for traceability)
FMEA Failure Mode and Effects Analysis
FS Functional Safety
FSM Finite State Machine
GPOS General-Purpose Operating System
HSM Hierarchical State Machine
MCU Microcontroller Unit
MISRA Motor Industry Software Reliability Association
OOP Object-Oriented Programming
PCLP PC-Lint Plus (static analysis tool)
PE Programmable Electronics
POSIX Portable Operating System Interface (operating system standard)
PUI Project Specific Identifier (part of UID)
QA QP Application (also PID for traceability)
QP QP Framework (also PID for traceability)
QK Preemptive, priority-based, non-blocking kernel (QP component)
QS "Quantum Spy" software tracing, target-resident component
QSPY "Quantum Spy" software tracing, host-based component
QXK Preemptive, priority-based, dual-mode kernel (QP component)
QV Cooperative, priority-based kernel (QP component)
QUTEST Unit testing harness for QP Framework
REQ Requirement artifact (in UIDs for traceability)
RMA Rate Monotonic Analysis
RMS Rate Monotonic Scheduling
RTC Run To Completion (execution model)
RTEF Real-Time Embedded Framework
RTOS Real-Time Operating System (kernel)
SAS Software Architecture Specification
SDS Software Design Specification
SIL Safety Integrity Level ([IEC-61508-4])
SSM Software Self-Monitoring ([IEC-61508-7])
SRS Software Requirements Specification
TST Test artifact (in UIDs for traceability)
UID Unique Identifier (for traceability)
UML Unified Modeling Language
USF Uncontrolled System Failure
WCET Worst-Case Execution Time


The cornerstone of the QP Certification Kit is traceability, which enables product teams to associate every work artifact (e.g., a specific requirement) with all the related project artifacts, both upstream and downstream. Traceability enables everyone to see how every work artifact relates to the requirement—and vice versa—at any point during development. This ability fosters team collaboration and enables early detection of possible production risks.

Unique Identifiers (UIDs)

Traceability is enabled by the consistent use of Unique Identifiers (UIDs), which are short text labels associated with all work artifact, such as requirements, architecture elements, design elements, coding standard deviations, tests, etc.

The most important feature of UIDs is their uniqueness within the whole system under consideration. To avoid name conflicts, it is advantageous to establish general rules for constructing the UIDs. In this QP Certification Kit, the UIDs have the general structure consisting of fields separated by dashes:

+++--------------- [1] Work artifact class (e.g., 'REQ' for Requirement)
||| ++------------ [2] Project identifier (here 'QP' for QP Framework or 'QA' for QP Application)
||| || ++-++------ [3] Work artifact ID
||| || || ||  +--- [4] Optional variant letter ('A', 'B', 'C'...)
||| || || ||  |+-- [5] Optional version number (1, 2, 3...)
||| || || ||  ||


  • REQ-QP-01_30 - requirement for the QP Framework, group 1, sub-group 30
  • REQ-QA-01_10 - requirement for the QP Application, group 1, sub-group 10

The various "fields" in the UID are as follows:

[1] the UID starts with a fields corresponding to the class of the work artifact:

  • REQ Requirement
  • SREQ Safety Requirement
  • ARC Architecture artifact
  • DES Design artifact
  • FME Failure Mode and Effect artifact
  • DVR Deviation Record (e.g. coding standard violation)
  • DVP Deviation Permit (e.g. coding standard violation)
  • TST Test

[2] the Project Unique Identifier (PUI), which is QP for the QP Framework and QA for QP Application. The PUI should be unique enough to avoid name conflicts with other software components in a larger system

[3] "Artifact ID" field identifies the artifact within the "work artifact class" [1]. This is the most flexible part in the UID to accommodate other existing conventions, such as MISRA conventions for directives and rules. For example, for MISRA deviations, the work artifact ID field should be easily identifiable with the MISRA Rule/Directive ID, such as D04_01 for "Directive 4.1", or R10_04 for "Rule 10.4". Still, please note that the more structured UID convention of using two-digits for feature groups (e.g., D04_10 instead of D4_10) provide additional benefits, such as correct order under a simple alphabetical sort. This property is missing in the original MISRA IDs (e.g., a simple alphabetical sort will place Rule 10.8 before Rule 8.10).

[4] optionally, the UID might contain a variant letter ('A', 'B', 'C',...)

[5] optionally, the UID might end with a single-digit version number (0..9).

The structure of UIDs is flexible to accommodate various existing naming conventions. But for compatibility with the widest possible range of cross-referencing systems and tools, the UIDs are restricted to contain only upper-case letters (A..Z), numbers (0..9), dashes ('-'), and underscores ('_'). Among others, UIDs cannot contain spaces, punctuation, parentheses, or any special characters.

Upstream Traceability

Upstream traceability begins at a specific work artifact and links it to the original artifact. For example, architecture element can be linked with an original requirement. Upstream traceability gives visibility into why specific artifacts were created and how different pieces of a system fit together. Tracing in this way also allows testers to find gaps or missing work artifacts.

Upstream traceability is the most efficient way of specifying hierarchical relationships, such as superclass-subclass in OOP. Class inheritance is universally represented in the subclasses, which store their superclass (upstream traceability). In contrast, superclasses don't show their subclasses (downstream traceability). The QP Certification Kit generalizes this approach to all work artifacts, starting with the requirements at the top, through architecture, design, source code, tests, etc.

As illustrated in the diagram below, upstream traceability is provided explicitly in the Certification Kit and QP source code. Specifically, the downstream work artifacts provide trace information to the related upstream artifact by means of Unique Identifier (UIDs).

Schematic View of Upstream Traceability in the QP Certification Kit
The QP Certification Kit traceability system includes the source code. This is achieved by placing special traceability links, such as @tr{REQ-QP-01_23} or @tr{DVR-QP-R04_11}, inside the doxygen comments in the code.

Downstream Traceability

Downstream traceability begins at the original artifact and links it with all the resulting downstream work items. For example, a requirement can be linked with source code elements that implement that requirement. This type of trace ensures that each original artifact (e.g., requirement) is not only satisfied but verified and validated.

Downstream traceability allows the teams to perform impact analysis to identify the potential consequences of a change of a given artifact.

In the QP Certification Kit, the downstream traceability can be achieved quite simply by automatically searching the project for the UID of the specific work artifact. For example, the following grep command shows the downstream traceability for the requirement REQ-QP-01_21.

C:\qp-dev\qpc>grep -r -n @tr{REQ-QP-02_00} ../cert . --exclude=3rd_party
./include/qep.h:344:* @tr{REQ-QP-02_00}, @tr{REQ-QP-02_10}
./include/qep.h:472:* @tr{REQ-QP-02_00}, @tr{REQ-QP-02_10}

Bidirectional Traceability

Bidirectional traceability is the ability to perform both downstream and upstream traceability. Bidirectional traceability is the optimal type of traceability because it gives teams full visibility from requirements through architecture, design, source code, tests, and back again. The system implemented in the QP Certification Kit provides such bidirectional traceability.

The whole system of traceability offered in QP is extensible and it is highly recommended that the QP Applications adopt it as well.


[IEC-61508-1] IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety- related systems – Part 1: General Requirements, 2010
[IEC-61508-2] IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety- related systems – Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems, 2010
[IEC-61508-3] IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety- related systems – Part 3: Software requirements, 2010
[IEC-61508-3] IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety- related systems – Part 4: Definitions and abbreviations, 2010
[IEC-61508-7] IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety- related systems – Part 7: Overview of techniques and measures, 2010
[ISO-C99] ISO/IEC 9899:1999, Programming languages — C, International Organization for Standardization, 1999

Requirements (SRS)