This section lists and explains non-functional requirements (a.k.a., quality attributes) of the QP/C++ Framework component.
QP/C++ Framework component shall have the systematic capabilities required by functional safety standards.
Description
QP/C++ Framework component shall be certifiable to the international functional safety standards such as IEC 61508, ISO 26262, and IEC 62304.
The following table summarizes the Systematic Capability (SC) of the QP/C++ Framework component required for compliance: | Aspect | IEC 61508 (baseline FS) | ISO 26262 (automotive) | IEC 62304 (medical) |
|---|---|---|---|
| Systematic Capability (SC) concept | SC concept introduced in Edition 2 | SC concept present, term not used | No SC concept |
| Primary focus | Capability of an element to meet SIL wrt systematic faults | Avoidance & control of systematic faults through ASIL-based lifecycle | Control of software faults through risk-based lifecycle & safety Class (A/B/C) |
| Quantified SC levels | SC 1-4, aligned with SIL 1-4 | ASIL A-D, mapping similar to SIL rigor in IEC 61508 | Classes A-C (C most critical) - no numeric SC |
| Typical use | Reuse/selection of pre-existing HW/SW elements with defined SC in Part-3 | Demonstrating ASIL-compliant software process and reuse arguments | Showing process completeness for software items; reuse via risk management |
| Main mechanism | Techniques/measures + assessment of elements development process | ASIL-based dev process, safety analysis, tool confidence, reuse criteria | 62304 lifecycle processes + integration with ISO 14971 risk management |
Forward Traceability (truncated to 2 level(s))
QP/C++ Framework component shall be implemented in a programming language recommended for safety-critical software.
Description
Functional safety standards require the implementation programming language to have certain features and properties.
The following table summarizes the general requirements for the appropriate implementation programming language across the standards IEC 61508,ISO 26262, and IEC 62304: | Aspect | IEC 61508 (baseline FS) | ISO 26262 (automotive) | IEC 62304 (medical) |
|---|---|---|---|
| Domain | Generic E/E/PE functional safety | Road vehicles, based on IEC 61508 | Medical device software lifecycle |
| Direct language requirements | Explicit measures/tables in Part3, SIL-based | Derived from IEC 61508, ASIL-based | No explicit per-language rules; process-focused |
| Emphasis | Language choice, subsets, avoidance of unsafe features | Language subsets, coding guidelines (e.g., MISRA), ASIL-based rigor | Having and applying coding standards; tool & environment control |
| Safety level driver | SIL 1-4 | ASIL A-D | Classes A-C (C most critical) |
| Typical practice | Strongly typed, restricted subset, structured | Same as IEC 61508 plus automotive specifics | Any language, but with documented rules, reviews, tests proportional to the safety class |
Forward Traceability (truncated to 2 level(s))
QP/C++ Framework component implementation shall NOT depend on any standard libraries.
Description
Forward Traceability (truncated to 1 level(s))
QP/C++ Framework component implementation shall NOT use floating point.
Description
Forward Traceability (truncated to 2 level(s))
All services provided by QP must NOT use the standard heap.
Description
QP/C++ Framework component must not force Applications to use potentially unsafe and indeterministic memory allocation policies, like the standard heap. In other words, the QP/C++ Framework component should internally use only static memory with worst-case memory consumption known at compile-time.
QP/C++ Framework component shall NOT internally pre-allocate memory for application-specific objects such as event-queue buffers; event-pool buffers; tracing-buffers etc.
Description
Forward Traceability (truncated to 2 level(s))
QP/C++ Framework component shall be free of non-deterministic concurrency hazards.
Description
The QP/C++ Framework component shall adequately protect its internal state from concurrency hazards, such as race conditions, data races, and any other form of internal state corruption due to concurrent operation. The QP/C++ Framework component shall also avoid any shared but unprotected resources (such as the standard heap).
Rationale
QP/C++ Framework component shall be certifiable to the international functional standards, which require determinism.
Forward Traceability (truncated to 2 level(s))
QP/C++ Framework component shall be deterministic in CPU utilization.
Description
Deterministic CPU utilization means that all QP/C++ Framework component services have a well-defined upper bound on the CPU utilization. It also means that the QP/C++ Framework component does not use non-deterministic constructs or services, such as the standard, dynamic memory allocation, which might behave non-deterministically.
Rationale
QP/C++ Framework component shall be certifiable to the international functional standards, which require determinism.
Forward Traceability (truncated to 2 level(s))
QP/C++ Framework component shall be deterministic in memory (RAM) utilization.
Description
Deterministic memory utilization means that all QP/C++ Framework component services have a well-defined upper bound on the memory utilization. It also means that the QP/C++ Framework component does not use non-deterministic constructs or services (such as the standard, dynamic memory allocation, which is subject to fragmentation).
Rationale
QP/C++ Framework component shall be certifiable to the international functional standards, which require determinism.
Forward Traceability (truncated to 2 level(s))
All services provided by QP shall use a limited and known amount of call stack.
Description
This requirement is a special case of deterministic memory (RAM) utilization. However, specifically the call stack (or multiple call stacks, if used) is a critical resource taking up a significant portion of the precious RAM in deeply embedded applications targeted by the QP/C++ Framework component.
Rationale
The stack exhaustion (a.k.a. stack overflow) represents a system failure, rather than merely some degradation of performance. Therefore, it is imperative for the QP/C++ Framework component (and the QP/C++ Application by extension) to use the call stack efficiently and deterministically.
Backward Traceability
Forward Traceability (truncated to 2 level(s))
QP/C++ Framework component shall facilitate deterministic real-time performance analysis (such as Rate-Monotonic Scheduling/Analysis).
Description
Facilitating deterministic real-time performance analysis (such as Rate-Monotonic Scheduling/Analysis) means that the QP/C++ Framework component shall be compatible with the methods of real-time analysis. For example, QP/C++ Framework component shall provide a compatible real-time kernel with deterministic real-time performance (e.g., preemptive, priority-based kernel for RMS/RMA). Additionally, QP/C++ Applications shall be easier to analyze than traditional RTOS applications due to the avoidance of blocking, which is known to immensely complicate CPU utilization calculations.
Rationale
QP/C++ Framework component shall be certifiable to the international functional standards, which require determinism.
Forward Traceability (truncated to 2 level(s))
QP/C++ Framework component shall be portable to 16-/32-/64-bit CPUs.
Description
QP/C++ Framework component shall be implemented such that it operates correctly on 16-bit, 32-bit, and 64-bit CPUs.
Rationale
QP/C++ Framework component shall internally be implemented without implicit assumptions about the CPU register size for the 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 overflow and underflow (e.g., "wrap-around"), if relevant for a given algorithm, need to be handled without assumptions on the CPU register size.
Forward Traceability (truncated to 2 level(s))
QP/C++ Framework component 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 component shall preserve the inherent ability of Active Objects to 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 the QP/C++ Framework component (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, developing, and testing QP/C++ Applications on the host computers.
Forward Traceability (truncated to 2 level(s))
All State Machine Implementation Strategies provided by the QP/C++ Framework component shall be bidirectionally traceable to the basic state machine elements.
Description
"Bidirectionally traceable to the basic state machine elements" means that every element in the state machine implementation shall correspond one-to-one to the state machine element. For example, every state entry, exit, transition, and guard condition should be represented only once in the implementation. The implication of this requirement for the ease of development is that it is always 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.
In contrast, 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 a non-hierarchical representation, which causes repetitions.
Rationale
The ease of debugging is essential for the effective development and maintenance of the state machine code.
Forward Traceability (truncated to 2 level(s))
The QP/C++ Framework component should support a debug build configuration that would facilitate QP/C++ Application development.
Description
The debug build configuration should allow applying low-optimization compilation and single-step debuggers to easily step through the application code and correlate it with the generated disassembly. If the system supports hardware-based memory isolation (e.g., by means of a Memory Protection Unit), the debug configuration should allow compile-time switching of the memory protection on and off.
Rationale
The ease of debugging is essential for the effective development and maintenance of the state machine code.
Forward Traceability (truncated to 2 level(s))
