QP/C++  7.4.0-rc.1
Real-Time Embedded Framework
No Matches
Software Requirements Specification
This document is part of the QP Certification Kit , which has been specifically designed to help companies in safety certification of their software based on the QP Framework treated as commercial off-the-shelf (COTS) software.


Revision History

Revision QP/C
By Description
0.0.0 7.3.0 2023-06-30 MMS Initial Release
1.0.0 7.3.2 2024-01-08 MMS Updated for IEC-61508 SIL-3 and IEC-62304 Class-C

Purpose and Scope

This Software Requirements Specification (Unique Identifier: DOC-SRS-QP) defines the software requirements for the QP Framework as well as the most important concepts and context of use of the QP Framework and QP Applications derived from the framework.

The scope of this SRS document is to define what the QP Framework shall do under the normal operating conditions (the success view point). However, equally important is specifying what the QP Framework as well as QP Application shall NOT do to avoid failures and what the software shall do under the identified failure conditions (the failure view point). The failure space is the focus of the separate document Software Safety Requirements (DOC-SSR-QP).

This document is the best source of information about the underlying concepts and functionality of the QP Framework and the QP Applications based on the framework.

About QP Framework

QP Real-Time Embedded Framework (QP Framework) is a lightweight implementation of the Active Object model of computation specifically tailored for real-time embedded (RTE) systems (such as ARM Cortex-M based MCUs). QP Framework is both a software infrastructure for building QP Applications consisting of Active Objects (Actors) and a runtime environment for executing the Active Objects in a deterministic fashion. Additionally, QP Framework supports Hierarchical State Machines with which to specify the behavior of Active Objects [UML-2.5], [Sutter:10], [ROOM:94].

The features and requirements specified in this document can be ultimately implemented in various programming languages, so this document pertains to a whole family of QP Real-Time Embedded Frameworks (RTEFs), currently consisting of QP/C and QP/C++ frameworks implemented in C and C++, respectively. Other possible implementations (e.g., QP/Rust) of these requirements and features might be added in the future.

Functional Safety

In the context of functional safety standards and certification, QP Framework offers numerous advantages over the traditional "shared state concurrency" based on a "naked" Real-Time Operating System (RTOS). QP Framework implements an inherently safer model of concurrency and many best practices recommended by functional safety standards (e.g., [IEC 61508-7:2010]) such as:

  • Structured methods ([IEC 61508-7:2010] C.2.1)
  • Semi-formal methods, such as Hierarchical State Machines ([IEC 61508-7:2010] Table.B.7)
  • Computer-aided design tools ([IEC 61508-7:2010] B.3.5)
  • Defensive programming, including Failure Detection and Failure Assertion Programming ([IEC 61508-7:2010] C.2.5)
  • Modular approach ([IEC 61508-7:2010] Table.B.9)
  • Design and coding standards, including safe subsets of C or C++ ([IEC 61508-7:2010] C.2.6)
  • Structured programming ([IEC 61508-7:2010] C.2.7)
  • Traceability between requirements and software design ([IEC 61508-7:2010] C2.11)
This Software Requirements Specification contains general requirements for the QP Framework operating under the normal conditions. The separate Software Safety Requirements [DOC-SSR-QP] contains requirements for the QP Framework and QP Application operating under various failure conditions. The SSR document also specifies the Functional Safety Subsystem of the QP Framework.


This Software Requirements Specification is primarily intended for:

  • Application Developers who develop QP Applications based on the QP Framework.

This requirements specification can also be of interest to:

  • Quality-Assurance Engineers,
  • Test Engineers,
  • Software Architects,
  • System Engineers,
  • Hardware Engineers, as well as
  • Managers who oversee the software development.

Document Organization

After a high-level overview, this requirements specification contains sections devoted to specific feature areas:

Each section starts with an introduction of the relevant concepts and the description of the feature, followed by the associated requirements.

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

Document Conventions

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

General Requirement UIDs

For traceability, this Software Requirements Specification uses the Unique Identifiers (UIDs) with the following structure:

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

Examples: SRS-QP-EVT_30, SRS-QP-SM_32

Use of "shall"

Shall is used to denote mandatory behavior.

Use of "shall not"

Shall is used to denote prohibited behavior.

Use of "should"

Should is used to denote a desirable behavior that should typically occur but might not happen all the time or might be optional in exceptional cases. The special cases are typically clarified in sub-requirements.

Use of "may"

May is used to denote allowed behavior that is optional but possible.


[IEEE 29148] Requirement Specification Standard, ISO/IEC/IEEE 29148:2018
[IEC 61508-3:2010] IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems- Part 3: Software requirements
[IEC 62304:2015] IEC 62304:2006, Medical device software - Software life-cycle process, IEC 62304:2006 + IEC 62304:2006/Amd1:2015
[ISO 26262-6:2018] ISO 26262-6:2018(en) Road vehicles - Functional safety - Part 6: Product development at the software level. International Standardization Organization.
[DOC-SSR-QP] Software Safety Requirements
[DOC-SAS-QP] Software Architecture Specification
[DOC-SDS-QP] Software Design Specification
[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.
[Cummings:10] David M. Cummings, "Managing Concurrency in Complex Embedded Systems",
2010 Workshop on Cyber-Physical Systems.
[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
[Samek:07] Miro Samek, "Use an MCU's low-power modes in foreground/background systems", Embedded Systems Design, 2007, https://www.state-machine.com/doc/Samek0710.pdf
[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.
[SRP:90] Theodore P. Baker, "A Stack-Based Resource Allocation Policy for Realtime Processes", IEEE Real-Time Systems Symposium, 1990
[OSEK:03] OSEK/VDX, "Operating System Specification 2.2.1", osek-vdx.org, 2003
[PTS:07] Rony Ghattas and Alexander G. Dean, "Preemption Threshold Scheduling: Stack Optimality, Enhancements and Analysis", Conference Paper, April 2007
[RMS/RMA:91] Lui Sha Mark H. Klein John B. Goodenough, "Rate Monotonic Analysis for Real-Time Systems", Technical Report CMU/SEI-91-TR-6 ESD-91-TR-6, 2017
[DMS:91] N. C. Audsley A. Burns M. F. Richardson A. J. Wellings, "Hard Real-Time Scheduling: The Deadline-Monotonic Approach", 1991
[Yiu:14] Joseph Yiu, "The De?nitive Guide to ARM Cortex M3 and Cortex-M4 Processors Third Edition", ARM Ltd., Cambridge, UK, June 2014.
[OOP-C:08] Quantum Leaps, Object-Oriented Programming in C,
[DbC:16] Quantum Leaps, Key Concept: Design by Contract,