Remarks: This Software Requirements Specification is part of the SafeQP Certification Kit↑, but applies to the whole QP Framework family↑. This document is the best source of information about the underlying concepts and functionality of the QP Frameworks and the QP Applications based on the frameworks.

Revision History

QP version	Document revision	Date (YYYY-MM-DD)	By	Description
7.3.4	A	2024-05-05	MMS	Initial release for IEC-61508 SIL-3 and IEC-62304 Class-C.
7.4.0	B	2024-07-30	MMS	Updated for QP 7.4.0.
8.0.0	C	2024-11-17	MMS	Updated for QP 8.0.0.
8.0.3	D	2025-03-27	MMS	Updated for QP 8.0.3.

About this Document

DOC_SRS_QP

Software Requirements Specification (SRS)

Description: This Software Requirements Specification, with Unique Identifier: DOC_SRS_QP, defines the software requirements for the QP Frameworks as well as the most important concepts and context of use of the QP Frameworks and QP Applications derived from the frameworks.

Scope: The scope of this SRS document is to define what the QP Frameworks shall do under the normal operating conditions (the success view point). However, equally important is specifying what the QP Frameworks as well as QP Applications 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, available in the SafeQP editions).

Audience

This Software Requirements Specification is primarily intended for:

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

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:

Overview
Active Objects
Events
State Machines
Event Delivery Mechanisms
Event Memory Management
Time Management
Software Tracing
Non-Preemptive Kernel
Preemptive Non-Blocking Kernel
Preemptive Dual-Mode Kernel
Non-Functional Requirements
Each section starts with an introduction of the relevant concepts and the 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:

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...)
 |  |  |  |   ||
SRS_QP_xx_yy[-A2]

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.

References

[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_SRS_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. 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
[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
[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 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)
[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 https://www.osek-vdx.org/mirror/os221.pdf
[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 https://insights.sei.cmu.edu/documents/1021/1991_005_001_15923.pdf.
[DMS:91]	N. C. Audsley A. Burns M. F. Richardson A. J. Wellings, "Hard Real-Time Scheduling: The Deadline-Monotonic Approach", 1991 https://www.cs.cmu.edu/~ssaewong/research/audsley_DMS.pdf.
[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, https://www.state-machine.com/oop
[DbC:16]	Quantum Leaps, Key Concept: Design by Contract, https://www.state-machine.com/dbc

Overview