This section lists and explains non-functional requirements (a.k.a., quality attributes) of the QP/C++ Framework.

Standards Compliance

SRS_QP_NF_01

SRS_QP_NF_01 : QP/C++ Framework shall be implemented in a standardized programming language.
Description A standardized programming language means a language specified by an international standard, such as C99, C11, C++11, C++14, etc.
Rationale A standardized programming language provides a well-defined, documented, and stable set of programming constructs and features.
Forward Traceability

SRS_QP_NF_02 : QP/C++ Framework shall be implemented in a programming language recommended for safety-critical software.
Description Recommended for safety-critical software means a programming language that is highly recommended for SIL3 and SIL4 according to IEC-61508. For example, the full programming languages like C99 or C++11 are generally not recommended for higher SILs. However, safe subsets of these languages, such as MISRA-C:2023 or MISRA-C++:2023 are highly recommended (see [IEC-61508-3] Table A.3, [IEC-61508-7] C.4.6 Table C.1).
Rationale QP/C++ Framework shall be certifiable to the international functional safety standards, which require an appropriate implementation programming language.
Forward Traceability

SRS_QP_NF_03 : QP/C++ Framework shall be modular.
Description QP/C++ Framework shall apply the following rules: information hiding/encapsulation fully defined interface with explicit specification of function signatures fully documented interfaces modules shall guarantee correct use by preconditions and postconditions (see failure assertion programming) all subprograms (functions) shall have a single entry and a single exit all subprograms (functions) shall have number of parameters limited to 4 all subprograms (functions) shall have complexity limited to 20 (cyclomatic complexity) global variables shall be limited to less than 10 for the whole QP/C++ Framework
Rationale Modularity is highly recommended by the international functional safety standards.
Forward Traceability SAS_QP_FRM : QP/C++ Framework layer SDS_QP_QEP : QEP Event Processor SDS_QP_QF : QF Active Object Framework SAS_QP_OSAL : OS abstraction layer (OSAL) SAS_QP_OS : OS layer

SRS_QP_NF_04 : QP/C++ Framework shall be layered.
Description
Rationale Layered design is highly recommended by the international functional safety standards.
Forward Traceability SAS_QP_FRM : QP/C++ Framework layer SDS_QP_QEP : QEP Event Processor SDS_QP_QF : QF Active Object Framework SAS_QP_OSAL : OS abstraction layer (OSAL) SAS_QP_OS : OS layer SDS_QP_QEP : QEP Event Processor SDS_QP_QF : QF Active Object Framework

SRS_QP_NF_20 : All services provided by QP/C++ must be deterministic.
Description Deterministic services means that the service has a well-defined upper bound on the CPU and memory utilization.
Rationale QP/C++ Framework shall be certifiable to the international functional standards, which require determinism.
Forward Traceability

SRS_QP_NF_21 : All services provided by QP/C++ shall use limited and known amount of call stack
Description The call stack (or multiple call stacks, if used) is a limited resource taking up a significant portion of the precious RAM in deeply embedded applications targeted by QP/C++ Framework.
Rationale The stack is a critical resource in that its exhaustion (a.k.a. stack overflow) represents a system failure, rather than merely some degradation of performance. Therefore, it is imperative for QP/C++ Framework (and QP/C++ Application by extension) to use the call stack efficiently and deterministically.
Forward Traceability

SRS_QP_NF_40 : QP/C++ Framework shall be portable to 16-/32-/64-bit CPUs.
Description QP/C++ Framework shall be implemented such that
Rationale QP/C++ Framework shall internally be implemented without implicit assumptions about the CPU register size for correctness of the internal algorithms. Among others, the bit-widths of integer variables must be specified in the implementation, so that they provide adequate dynamic range. Also, integer overflows and underflows (e.g., "wrap-arounds"), if relevant for a given algorithm, need to be handled without assumptions on the CPU register size.
Forward Traceability SAS_OSAL_API : OSAL API

SRS_QP_NF_41 : QP/C++ Framework shall be portable to a wide range of real-time kernels.
Description As an implementation of the Active Object model of computation, QP/C++ Framework shall preserve the inherent ability of Active Objects work with a variety of real-time kernels. This includes traditional blocking RTOS kernels, special non-blocking kernels (e.g., QV, QK, QXK), and general-purpose operating systems (POSIX, Windows).
Rationale Portability of QP/C++ Framework (and QP/C++ Applications based on the framework) to a wide range of kernels allows applications to use the most appropriate kernel for the job at hand. Additionally, portability to GP-OS allows running and developing and testing QP/C++ Applications on the host computers.
Forward Traceability SAS_OSAL_API : OSAL API

SRS_QP_NF_50 : All State Machine Implementation Strategies provided by QP/C++ Framework shall be easy to debug.
Description "Easy to debug" state machine implementation means that it should always be possible to set a single debugger breakpoint in the code to stop upon the execution of a given state machine element, such as a state transition or entry to a given state, exit from a given state, a given guard condition, etc. An example of a hard to debug implementation would be one in which a given transition or entry to a state would be represented more than once in the code. A single breakpoint would not necessarily be sufficient to guarantee that the breakpoint is reached when that element is executed. Hard to debug state machine implementations are often the result of "flattening" the hierarchical state machine to the non-hierarchical representation, which causes repetitions of transitions.
Rationale The ease of debugging is essential for effective development and maintenance of the state machine code.
Forward Traceability

SRS_QP_NF_10 : QP/C++ Framework implementation shall NOT depend on any standard libraries.
Description
Forward Traceability

SRS_QP_NF_11 : QP/C++ Framework implementation shall NOT use floating point.
Description
Forward Traceability

SRS_QP_NF_12 : QP/C++ Framework shall NOT use multiple inheritance.
Description Multiple inheritance is complex and can lead to problems (e.g., problematic diamond-shaped inheritance). Therefore, safe subsets of OO programming languages often disallow use of multiple inheritance.
Forward Traceability

SRS_QP_NF_13 : All services provided by QP/C++ must NOT use the standard heap.
Description QP/C++ Framework must not force Applications to use potentially unsafe and indeterministic memory allocation policies, like the standard heap. In other words, the QP/C++ Framework should internally use only static memory with worst-case memory consumption known at compile-time.

SRS_QP_NF_14 : QP/C++ Framework shall NOT internally pre-allocate memory for application-specific objects such as event-queue buffers; event-pool buffers; tracing-buffers etc.
Description
Forward Traceability