QP/C++  7.1.1
Real-Time Embedded Framework
No Matches

Software Requirements Specification (SRS) More...


 State Machines
 Active Objects
 Event Delivery
 Time Management
 Software Tracing
 Cooperative Run-to-Completion Kernel
 Preemptive Run-to-Completion Kernel
 Preemptive Dual-Mode Kernel
 Quality Attributes
 QP Application Requirements

Detailed Description


This document is part of the QP Certification Pack, which has been specifically designed to aid companies in safety certification of their software based on the QP real-time embedded frameworks.

NOTE: This is just a preview. The complete QP Certification Pack can be requested from Quantum Leaps.


This Software Requirements Specification (SRS [IEEE 29148]) describes the requirements for the QP Real-Time Embedded Framework (RTEF), which is a reusable software infrastructure and a runtime environment based on the Active Object (Actor) design pattern as well as Hierarchical State Machines to specify the internal behavior of Active Objects (a.k.a. Actors ([ROOM:94], [UML 2.5])).

This SRS document specifies the intended features of the QP Framework, as well as the interfaces to other software, such as QP Applications derived from the QP Framework, as well as the lower-level software providing services to the QP Framework.

The features and requirements specified in this SRS can be ultimately implemented in various programming languages, so this document pertains to a whole family of QP RTEFs, currently consisting of QP/C and QP/C++ frameworks implemented in C and C++, respectively. Other possible implementations of these requirements and features might be added in the future.


This SRS document is primarily intended for:

QP Users and Use Cases
This SRS is designed to be most helpful to the QP Application developers, who are also the primary users of the QP Framework.

This SRS can also be of interest to:

Unique Identifiers

All work artifacts, such as requirements, architecture elements, design elements, tests, etc. have unique identifiers (UIDs), which are structured as follows:

┌──────────────── 1. item type ('R' for Requirement, 'A' for Architecture, etc.)
│ ┌┬───────────── 2. Project Unique Identifier (here 'QP' or 'QA')
│ ││ ┌─────────── 3. one-digit feature number
│ ││ │ ┌┬──────── 4. two-digit requirement number
│ ││ │ ││  ┌───── 5. optional sub-requirement letter (A, B, C...)
│ ││ │ ││  │
R QP x yy [A]

Examples: RQA001, RQP002B

  1. every work item starts with the letter:
    • 'R' Requirement
    • 'A' Architecture item
    • 'D' Design item
    • 'P' Deviation Permit (e.g. for MISRA violation)
    • 'T' Test
  2. the Project Unique Identifier (PUI), which is 'QP' for the QP Framework and 'QA' for QP Application. The PUI avoids name conflicts with other requirements corresponding to different software components in a larger system
  3. the PUI is followed by a 2-digit feature number
  4. this is followed by a 2-digit requirement number
  5. optionally, the requirement might end with a letter ('A', 'B', 'C',...), which identifies a sub-requirement of a given requirement.
The consistent use of the UIDs is the cornerstone for the full traceability of the QP Certification Pack. It is recommended that the QP Applications adopt a similar convention of applying the UIDs and the whole system of traceability offered in QP.

Document Conventions

This SRS contains two types of requirements:

  1. Requirements for the QP Framework itself; and
  2. Requirements for the QP Application.
The requirements for the QP Application cannot be satisfied by the QP Framework alone, so they are outside the scope of this SRS document. However, these requirements are still essential because they capture the assumptions made in the QP Framework as to how the QP Application needs to operate. In case a requirement for the QP Application is not satisfied, QP Framework cannot guarantee the correct execution of the QP Application.

Use of "Shall," "Should," "May," and "Must Not"

Requirement definitions use consistent terminology to indicate whether something is mandatory, desirable, or allowed.

SRS Organization

After a high-level overview, this SRS document contains sections devoted to specific feature areas. Each section starts with a description of the feature, followed by the associated requirements. The SRS ends with the summary of QP Application Requirements, which are essential assumptions made in QP for the proper functioning of the QP Applications.

The presented features are in order of relevance for the Application Developers working on QP Applications, who are the primary audience of this SRS:


[IEEE 29148]        "Requirement Specification Standard", ISO/IEC/IEEE 29148:2018
[QP-SAS] QP Framework Software Architecture Specification (SAS)
[QP-SDS] QP Framework Software Design Specification (SDS)
[ROOM:94] Bran Selic, Garth Gullekson, Paul T. Ward: Real-Time Object-Oriented Modeling,
New York, John Wiley & Sons Inc, 1994, ISBN 978-0-471-59917-3
[PSiCC:02] Miro Samek, Practical Statecharts in C/C++, CMP Books 2002.
[PSiCC2:08] Miro Samek, Practical UML Statecharts in C/C++, 2nd Edition, Newnes 2008.
[ROOM:94] Bran Selic, Garth Gullekson, Paul T. Ward: Real-Time Object-Oriented Modeling,
New York, John Wiley & Sons Inc, 1994, ISBN 978-0-471-59917-3
[CODE2:04] Steve McConnell, Code Complete, 2nd Ed,Microsoft Press 2004.
[UML 2.5] OMG, "OMG Unified Modeling Language (OMG UML) Version 2.5.1", formal/2017-12-05, 2017
[Sutter:10] Herb Sutter, "Prefer Using Active Objects Instead of Naked Threads", Dr.Dobbs Journal, June 2010.
[Cummings:10] David M. Cummings, "Managing Concurrency in Complex Embedded Systems",
2010 Workshop on Cyber-Physical Systems.
[OOP-C:08] Quantum Leaps, Object-Oriented Programming in C,
[DbC:16] Quantum Leaps, Key Concept: Design by Contract,