QP/C++
7.3.4
Real-Time Embedded Framework
This document (Unique Identifier: DOC-QP-SRS) describes the software requirements for the QP Real-Time Embedded Framework (RTEF) 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.
The revision history of the document DOC-QP-SRS is as follows:
| Revision | QP/C version | Date (YYYY-MM-DD) | By | Description |
|---|---|---|---|---|
| 0.0.0 | 7.3.0 | 2023-06-30 | MMS | Initial Release |
| 0.0.1 | 7.3.2 | 2024-01-08 | MMS | Updated |
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].
In the context of functional safety standards and certification, QP/C++ offers numerous advantages over the traditional "shared state concurrency" based on a "naked" Real-Time Operating System (RTOS). QP/C++ implements an inherently safer model of concurrency and many best practices recommended by functional safety standards (e.g., IEC 61508-7) such as:
This requirements specification is primarily intended for:
This requirements specification can also be of interest to:
This requirements specification contains general requirements for the QP Framework. The separate Functional Safety Requirements [DOC-QP-FSR] contains requirements related to functional safety.
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. Requirement ID
||| || || || +--- 4. Optional variant letter ('A', 'B', 'C'...)
||| || || || |+-- 5. Optional version number (1, 2, 3...)
||| || || || ||
SRS-QP-xx-yy[-A2]
Examples: SRS-QP-01_30, SRS-QP-02_32
Requirement definitions use consistent terminology to indicate whether something is mandatory, desirable, or allowed.
Shall is used to denote mandatory behavior.
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.
Mayis used to denote allowed behavior that is optional but possible.
Must not is used to denote a constraint – behavior that is not allowed.
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.
| [IEEE 29148] | Requirement Specification Standard, ISO/IEC/IEEE 29148:2018 |
| [DOC-QP-SSR] | Software Safety Requirements |
| [DOC-QP-SAS] | Software Architecture Specification |
| [DOC-QP-SDS] | Software Design Specification |
| [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 |
| [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 |
| [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 |
| [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 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. |
| [Spolsky:02] | Joel Spolsky, The Law of Leaky Abstractions, https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions |
| [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 |