Purpose and Scope

This document (Unique Identifier: DOC-QP-SRS) describes the general software requirements for the QP Framework as well as the most important concepts and context of use of the QP Framework. This requirements specification is designed to be most helpful to the QP Application developers, who are also the primary users of the QP Framework.

Remarks: This document is part of the QP Certification Kit, which 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.

Revision History

The revision history of the document DOC-QP-SRS is as follows:

Revision	QP/C version	Date (YYYY-MM-DD)	By	Description
0.0	7.3.0	2023-06-30	MMS	Initial Release

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. QP 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 [ROOM:94], [UML 2.5],[Sutter:10]. The QP Framework can be viewed as a truly event-driven, "reactive" real-time operating system (RTOS).

Remarks: The features and requirements specified in this requirements specification 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.

Audience

This requirements specification is primarily intended for:

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

Remarks: This requirements specification is designed to be most helpful to the QP Application developers, who are also the primary users of the QP Framework.

This requirements specification can also be of interest to:

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

Figure 00_01: Users and main use cases of QP Framework

Document Conventions

This requirements specification contains general requirements for the QP Framework. The separate Safety Requirement Specification contains requirements related to functional safety.

Note: The Software Safety Requirements typically cannot be satisfied by the QP Framework alone because they capture the assumptions made in the QP Framework as to how the QP Application needs to operate. In case such safety requirements for the QP Application are not satisfied, QP Framework cannot guarantee the correct execution of the QP Application.

General Requirement UIDs

This requirements specification uses the Unique Identifiers (UIDs) with the following structure:

+++--------------- 1. work artifact class ('REQ' for Requirement)
||| ++------------ 2. Project identifier (here 'QP' for QP Framework or 'QA' for QP Application)
||| || ++-+++----- 3. work artifact ID (see note below)
||| || || ||  +--- 4. optional variant letter ('A', 'B', 'C'...)
||| || || ||  |+-- 5. optional version number (1, 2, 3...)
||| || || ||  ||
REQ-QP-xx-yy[-A2]

Examples: REQ-QP-01_30, REQ-QP-02_32

Use of Shall/Should/etc.

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

"shall"

Shall is used to denote mandatory behavior.

"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.

"may"

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

"must not"

Must not is used to denote a constraint – behavior that is not allowed.

Document Organization

After a high-level overview, this requirements specification contains sections devoted to specific feature areas. Each section starts with a description of the feature, followed by the associated requirements.

Remarks: 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:

References

[IEEE 29148]	"Requirement Specification Standard", ISO/IEC/IEEE 29148:2018
[DOC-QP-SAS]	Software Architecture Specification
[DOC-QP-SDS]	Software Design Specification
[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. https://www.state-machine.com/psicc
[PSiCC2:08]	Miro Samek, Practical UML Statecharts in C/C++, 2nd Edition, Newnes 2008. https://www.state-machine.com/psicc2
[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]	OMG, "OMG Unified Modeling Language (OMG UML) Version 2.5.1", formal/2017-12-05, 2017 https://www.omg.org/spec/UML.
[Sutter:10]	Herb Sutter, "Prefer Using Active Objects Instead of Naked Threads", Dr.Dobbs Journal, June 2010. https://www.state-machine.com/doc/Sutter2010a.pdf)
[Cummings:10]	David M. Cummings, "Managing Concurrency in Complex Embedded Systems", 2010 Workshop on Cyber-Physical Systems. https://www.state-machine.com/doc/Cummings2006.pdf
[OOP-C:08]	Quantum Leaps, Object-Oriented Programming in C, https://www.state-machine.com/oop
[DbC:16]	Quantum Leaps, Key Concept: Design by Contract, https://www.state-machine.com/dbc

Overview