QP/C Real-Time Event Framework 8.1.5
QP/C Real-Time Event Framework 8.1.5
Architectural viewpoint: Systematic Capability (SC).
Purpose
The Systematic Capability Viewpoint defines how the QP/C Framework architecture applies the techniques and measures required to achieve the desired systematic capability, defined as the measure of the confidence that the systematic safety integrity of the software meets the requirements of the specified SIL ([IEC 61508] SIL-3, [IEC 62304] Class-C, and [ISO 26262] ASIL-D). This architectural viewpoint cross-checks the QP/C architecture against the recommended techniques and measures specified in [IEC 61508-3] Annexes A-C, [IEC 62304] Class-C expectations, and [ISO 26262-6] software development guidance, ensuring that:
Functional safety standards make recommendations about techniques and measures to be applied at different safety integrity levels. The following table harmonizes the recommendation levels across standards: IEC 61508, ISO 26262, and IEC 62303:| Recommendation Level | IEC 61508 | ISO 26262 | IEC 62304 |
|---|---|---|---|
| Highly recommended | HR | "++" | Advised for Class B, Mandatory for Class-C |
| Recommended | R | "+" | Advised for Classes B/C |
| Neutral / optional | — | "o" | Optional for Classes B/C |
| Noth recommended | NR | "-" | Discouraged for Class B, Not allowed for Class-C |
In functional safety standards, such as IEC 61508, the designations HR (highly recommended) and NR (not recommended) have a specific technical meaning. For a given SIL, techniques marked as HR are expected to be applied unless a documented and justified rationale demonstrates that they are unnecessary or that an alternative measure provides equivalent risk reduction.
Architectural Views
This architectural viewpoint frames the following views:
QP/C functional safety management is architecturally separated from the nominal functional behavior of the QP/C Framework component. This separation ensures that safety mechanisms remain easily identifiable, reviewable, and traceable, and that they can be assessed independently of the application-specific logic built on top of the framework.
Architectural view: QP/C Functional Safety Subsystem (fault management).
Description
The QP/C Functional Safety Subsystem (QP/C FuSa) defines the general internal safety mechanisms applied consistently throughout the QP/C Framework component. The QP/C Functional Safety Subsystem provides the following mechanisms:
Backward Traceability
Forward Traceability (truncated to 2 level(s))
Architectural view: State-machine support for QP/C Applications (semi-formal methods).
Description
Backward Traceability
Forward Traceability (truncated to 2 level(s))
This view defines the architectural techniques and measures (SAS_QP_SCT_xx) that implement the systematic capability expectations of:
The following Table SAS-TBL-A2 lists the systematic capability techniques and measures for software architecture required by [IEC 61508-3:2010] Table A.2 to achieve SIL-3. The last columns defines which of the selectable techniques are chosen in the QP/C Framework component and how they are addressed. | Technique/Measure(*) | IEC 61508 Ref. | SIL 3 | Specs for QP framework | |
|---|---|---|---|---|
| 1 | Fault detection | C.3.1 | HR | SAS_QP_SCT_01 |
| 2 | Error detecting codes | C.3.2 | R | SAS_QP_SCT_02 |
| 3a | Failure assertion programming (*) | C.3.3 | R | SAS_QP_SCT_03A |
| 3b | Diverse monitor techniques (*) (with independence between the monitor and the monitored function in the same computer) | C.3.4 | R | see choice 3a(*) |
| 3c | Diverse monitor techniques (*) (with separation between the monitor computer and the monitored computer) | C.3.5 | R | see choice 3a(*) |
| 3d | Diverse redundancy, implementing the same software safety requirement specification (*) | C.3.5 | — | see choice 3a(*) |
| 3e | Functionally diverse redundancy, implementing different software safety requirement specifications (*) | C.3.5 | R | see choice 3a(*) |
| 3f | Backward recovery | C.3.6 | — | see choice 3a(*) |
| 3g | Stateless software design (or limited state design) | C.2.12 | R | see choice 3a(*) |
| 4a | Re-try fault recovery mechanism | C.3.7 | — | see choice 4b(*) |
| 4b | Graceful degradation | C.3.8 | HR | SAS_QP_SCT_04B |
| 5 | Artificial intelligence - fault correction | C.3.9 | NR | SAS_QP_SCT_05 |
| 6 | Dynamic reconfiguration | C.3.10 | NR | SAS_QP_SCT_06 |
| 7 | Modular approach | Table B.9 | HR | SAS_QP_SCT_07 |
| 8 | Use of trusted/verified software elements (if available) | C.2.10 | HR | SAS_QP_SCT_08 |
| 9 | Forward traceability between the software safety requirements specification and software architecture | C.2.11 | HR | SAS_QP_SCT_09 |
| 10 | Backward traceability between the software safety requirements specification and software architecture | C.2.11 | HR | SAS_QP_SCT_10 |
| 11a | Structured diagrammatic methods (*) | C.2.1 | HR | SAS_QP_SCT_11A |
| 11b | Semi-formal methods (*) | Table B.7 | HR | SAS_QP_SCT_11B |
| 11c | Formal design and refinement methods (*) | B.2.2, C.2.4 | R | see choice 11b(*) |
| 11d | Automatic software generation (*) | C.4.6 | R | SAS_QP_SCT_11D |
| 12 | Computer-aided specification and design tools | B.2.4 | HR | SAS_QP_SCT_12 |
| 13a | Cyclic behavior, with guaranteed maximum cycle time (*) | C.3.11 | HR | SAS_QP_SCT_13A |
| 13b | Time-triggered architecture (*) | C.3.11 | HR | SAS_QP_SCT_13B |
| 13c | Event-driven, with guaranteed maximum response time (*) | C.3.11 | HR | SAS_QP_SCT_13C |
| 14 | Static resource allocation | C.2.6.3 | HR | SAS_QP_SCT_14 |
| 15 | Static synchronization of access to shared resources | C.2.6.3 | R | SAS_QP_SCT_15 |
Architectural view: QP/C fault detection shall be based on failure assertion programming
Description
Fault detection shall be implemented in the QP/C Functional Safety Subsystem (SAS_QP_FUSA_00) using failure assertion programming technique. Support for failure-assertion programming means that QP/C fault-detection mechanisms shall not only detect the presence of a fault but also provide diagnostic information indicating which subsystem is the likely source. To achieve this, the framework shall supply specialized assertions for:
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: QP/C Framework component shall apply error detection codes based on Duplicate Inverse Storage and Duplicate Storage.
Description
Error-detecting codes are software techniques that add redundant information to data so that accidental corruption can be detected before the data is used. Techniques like Duplicate Sotrage or Duplicate Inverse Storage are capable of detecting data corruption caused by software (e.g., runaway pointer or buffer overflow), which are not detectable by hardware mechanisms (e.g., Error-Correcting Codes.)
QP/C Framework component shall implement the following error-detecting code techniques in the indicated contexts:
Duplicate Inverse Storage (DIS)
Duplicate Storage (no bitwise inversion)
Duplicate Inverse Storage and Duplicate Storage techniques are only applied in the SafeQP/C and SafeQP/C++ editions. Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: QP/C Framework shall apply failure assertion programming free of side effects on normal functionality.
Description
QP/C software component shall apply failure assertion programming as the recommended fault detection techniques (IEC 61508-7 C.3). The assertion facilities shall be defined in the QP Functional Safety (FuSa) Subsystem with the following safety specifications:
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Mechanisms for graceful degradation in QP/C Framework component.
Description
Graceful degradation aims to maintain more critical system functions available, despite failures, by dropping the less critical functions. QP/C Framework component supports graceful degradation by providing mechanisms to protect the more critical functions from interference by the less critical ones. The main such mechanisms are:
Forward Traceability (truncated to 1 level(s))
Architectural view: NO use of artificial intelligence for fault correction in QP/C Framework component.
Description
QP/C Framework shall avoid the NR recommendation for AI-based fault correction (IEC 61508-3 Table A.2 row 5) and aligns with conservative interpretations in ISO 26262 and IEC 62304 for non-deterministic techniques.
Forward Traceability (truncated to 1 level(s))
Architectural view: QP/C Framework shall avoid dynamic reconfiguration.
Description
Dynamic reconfiguration aims to maintain system functionality despite an internal fault by various recovery attempts. Unfortunately, fault-recovery often leads to hard-to-foresee complications and eventual failure, but in an unpredictable way (which contradicts the functional safety principle).
For these reasons, and for compliance with the NR (Not-Recommended) classification, QP/C Framework shall avoid dynamic reconfiguration and instead apply the simple Crash-Only Model
Forward Traceability (truncated to 1 level(s))
Architectural view: Modular approach in QP/C Framework component.
Description
QP/C Framework component architecture shall apply the following rules for modularity:
Forward Traceability (truncated to 1 level(s))
Architectural view: Only trusted/verified software elements in QP/C Framework component.
Description
QP/C Framework component implementation shall NOT use any 3rd-party software elements. The reliance on standard libraries shall be limited to header-only facilities (e.g., <stdint.h>), but not any standard library code. All dependencies on external components (such as real-time kernel) shall be abstracted and restricted to the well-defined Operating System Abstraction Layer (OSAL).
Forward Traceability (truncated to 1 level(s))
Architectural view: Consistent forward traceability between Safety Requirements and Software Architecture in QP/C Framework component.
Forward Traceability (truncated to 1 level(s))
Architectural view: Consistent backward traceability between Safety Requirements and Software Architecture in QP/C Framework component.
Forward Traceability (truncated to 1 level(s))
Architectural view: Structured diagrammatic methods in QP/C Framework component.
Description
QP/C Framework component documentation shall use the well-defined UML diagrams whenever applicable. Non-UML diagrams shall have legends explaining the symbols and semantics.
Forward Traceability (truncated to 1 level(s))
Architectural view: Semi-formal methods in QP/C Framework component.
Description
QP/C Framework component shall use the following semi-formal methods (see [IEC 61508-7:2010] Table C.17)
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Automatic code generation in QP/C Framework component.
Description
QP/C Framework component does not take advantage of automatic code generation, but it supports automatic code generation, as the highly recommended (HR) semi-formal technique for QP/C Applications. Specifically, all state machine strategies supported by the framework are excellent targets for automatic code generation.
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Computer-aided specification and design tools use in QP/C Framework component.
Description
Forward Traceability (truncated to 1 level(s))
Architectural view: Cyclic behavior with guaranteed maximum cycle time in QP/C Framework component.
Description
The QP/C framework includes the non-preemptive, run-to-completion (RTC) QV kernel, which can provide a repetitive event-processing cycle. By an intentional QP/C Application design, the following constraints can be enforced:
Under these constraints, the worst-case duration of one complete event-processing cycle can be determined and justified. This satisfies the [IEC61508-3] Table A.2 row 13a technique cyclic behavior, with guaranteed maximum cycle time and supports the timing requirements of the safety functions.
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Time-triggered architecture (TTA) in the QP/C Framework component .
Description
QP/C Framework with the cooperative QV kernel can support a lightweight single-node time-triggered cooperative (TTC) and time-triggered hybrid (TTH) scheduling described by Pont ([Pont:2001] and [Pont:2017]), provided that the QP/C Application implements and enforces timing discipline described in SAS_QP_FFI_QVTT.
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Event-driven architecture with guaranteed maximum response time in QP/C Framework component.
Description
QP/C Framework component provides the preemptive, non-blocking kernel (QK), which is fully compliant with the requirements of the Rate-Monotonic Scheduling/Analysis (RMS/RMA) method. By choosing this kernel and implementing the assumptions of RMS/RMA, the QP/C Application can provide the desired guaranteed maximum response time.
Backward Traceability
Forward Traceability (truncated to 1 level(s))
Architectural view: Static resource allocation in QP/C Framework component.
Description
The QP/C Framework component applies exclusively static resource allocation and strictly avoids any form of dynamic resource allocation within the framework itself. All framework-managed resources — such as Active Objects, event queues, event pools, priorities, and time events — are created, sized, and bound at design time. This ensures deterministic memory usage, eliminates allocation failures, prevents fragmentation, and supports tractable WCET and schedulability analysis, in accordance with IEC 61508-3 C.2.6.3 and IEC 61508-7 Table A.2 row 14.
This static-allocation discipline is strongly recommended for QP/C Applications as well. While the QP/C architecture does not prohibit an application from allocating memory in any manner it chooses (including dynamic allocation), any safety-critical deployments should allocate all memory intended to be managed by the QP/C framework statically. This preserves determinism and ensures that the frameworks timing and safety guarantees remain valid.
Forward Traceability (truncated to 1 level(s))
Architectural view: Static synchronization of access to shared resources in QP/C Framework component.
Description
IEC 61508-7 Table A.2 row 15 and IEC 61508-3 C.2.6.3 identify static synchronization of access to shared resources as a recommended architectural technique. The intent is to prevent nondeterministic blocking, deadlocks, and priority inversion by ensuring that access policies for shared resources are fixed at design time rather than negotiated dynamically at runtime.
The QP/C framework supports this technique through its Active Object (AO) model, which explicitly enforces the shared-nothing principle. Each Active Object encapsulates its own data and resources, and all interactions occur strictly through event exchanges. As a result, resources are generally not shared, and concurrency hazards are avoided by architectural design based on ownership rather than by runtime locking. This satisfies the core requirement of static synchronization: the access policy is predetermined and enforced structurally.
In the rare cases where an application chooses to share a resource (a practice not encouraged in QP/C), the framework provides static, design-time synchronization mechanisms appropriate to the selected kernel:
Forward Traceability (truncated to 1 level(s))
This architectural view frames the following concerns:
The following Table SDS-A3 lists the techniques and measures for programming language and support tools required by [IEC 61508-3:2010] Table A.3 to achieve SIL-3. The last column of the table defines how these techniques are to be addressed in the architecture of QP/C Framework component.| Technique/Measure(*) | IEC 61508 Ref. | SIL 3 | Specs for QP Framework | |
|---|---|---|---|---|
| 1 | Suitable programming language | C.4.5 | HR | SAS_QP_PL_01 |
| 2 | Strongly typed programming language | C.4.1 | HR | SAS_QP_PL_02 |
| 3 | Language subset | C.4.2 | HR | SAS_QP_PL_03 |
| 4a | Certified tools and certified translators (*) | C.4.3 | HR | see choice 4b(*) |
| 4b | Tools and translators: increased confidence from use (*) | C.4.4 | HR | SAS_QP_PL_04B |
Architectural view: Suitable programming language for QP/C Framework component.
Description
The QP/C Framework component shall be implemented in the ISO C11 programming language, which has the following properties recommended by [IEC 61508-3] C.4.5:
However, at the same time, the full C programming language also includes many constructs classified as NR (Not Recommended) for SIL-3 (IEC 61508-3 Table C.1). Therefore, the QP/C Framework must use a restricted safe subset, enforced by coding standards and static analysis tools.
Because of the undesired properties of the full ISO C standard, according to IEC 61508-3 Table C.1 reproduced below, the full C programming language is NR (not recommend) for SIL-3. However, C with subset, coding standard, and use of static analysis tools is HR (highly recommended). Therefore this architectural specification for the suitable programming language necessarily includes architectural specification SAS_QP_PL_03.| Programming language | SIL 3 | |
|---|---|---|
| ... | ... | ... |
| 9 | C | NR |
| 10 | C with subset and coding standard, and use of static analysis tools | HR |
| ... | ... | ... |
Backward Traceability
Forward Traceability (truncated to 2 level(s))
Architectural view: Strongly typed programming language for QP/C Framework component.
Description
QP/C Framework component shall be implemented in the ISO C11 programming language version, which supports many features to enforce type safety, but is not a strongly typed language as defined in IEC 61508 Annex C.4.5. To mitigate this, QP/C Framework component shall adopt a restricted subset of QP C11 (aligned with MISRA-C:2025, see SAS_QP_PL_03) and enforce coding guidelines that ensure type safety through explicit conversions, static analysis, and compiler diagnostics.
Backward Traceability
Forward Traceability (truncated to 2 level(s))
Architectural view: Safe language subset for QP/C Framework component.
Description
The QP/C Framework component shall comply with a safe ISO C11 subset, aligned with MISRA-C:2025 and the restrictions described in the MISRA Compliance Report.
These rules ensure compatibility with the QP/C Framework's infrastructure for static analysis described in the Guideline Enforcement Plan (GEP) and Deviation Permits of the MISRA Compliance Report.
Backward Traceability
Forward Traceability (truncated to 2 level(s))
Architectural view: Tools and translators: increased confidence from use for QP/C Framework component.
Description
The QP/C Framework source code shall be compiled and statically analyzed using tools that provide Increased Confidence from Use (ICFU), as defined in IEC 61508-3 C.4.4.
Forward Traceability (truncated to 2 level(s))