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 | A | 2024-07-30 | MMS | Updated for QP 7.4.0. |
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).
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 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:
This Software Requirements Specification is primarily intended for:
This requirements specification can also be of interest to:
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.
Requirement definitions use consistent terminology to indicate whether something is mandatory, desirable, or allowed.
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
Shall is used to denote mandatory behavior.
Shall is used to denote prohibited 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.
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. 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 |