This section contains quality attributes (a.k.a., non-functional requirements) of the QP Framework.

Standards Compliance

SRS-QP-20_01

SRS-QP-20_01
QP 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.

SRS-QP-20_02
QP 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 Framework shall be certifiable to the international functional standards, which require an appropriate implementation programming language.

SRS-QP-20_10
QP Framework implementation shall NOT depend on any standard libraries.
Description

SRS-QP-20_11
QP Framework implementation shall NOT depend on or use floating point.
Description

SRS-QP-20_20
All services provided by QP must be deterministic.
Description Deterministic services means that the service has a well-defined upper bound on the CPU and memory utilization.
Rationale QP Framework shall be certifiable to the international functional standards, which require determinism.

SRS-QP-20_21
All services provided by QP 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 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 Framework (and QP Application by extension) to use the call stack efficiently and deterministically.

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

SRS-QP-20_31
QP Framework shall NOT internally pre-allocate memory for application-specific objects such as event-queue buffers; event-pool buffers; tracing-buffers etc.
Description

SRS-QP-20_40
QP Framework shall be portable to 16-/32-/64-bit CPUs.
Description QP Framework shall be implemented such that
Rationale QP 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.

SRS-QP-20_41
QP Framework shall be portable to a wide range of real-time kernels.
Description As an implementation of the Active Object model of computation, QP 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 Framework (and QP 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 Applications on the host computers.

SRS-QP-20_50
All State Machine Implementation Strategies provided by QP 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.