QP/C++
8.0.0
Real-Time Embedded Framework
The architectural Safety Viewpoint consists of various aspects of the software systematic capability defined as the measure of the confidence that the systematic safety integrity of the software meets the requirements of the specified SIL 3, in respect of the specified software safety function, when the software is applied in accordance with the instructions specified in the compliant item Safety Manual [DOC_SSM_QP] for the software ([IEC 61508-4:2010] 3.5.9). This viewpoint is intended as a cross-check of all techniques and measures required by [IEC 61508-3:2010] against the architecture of QP/C++ Framework. The Safety Viewpoint frames the following concerns:
The rigor of the required design process and control measures are a function of a Safety Integrity Level (SIL). This is evaluated through a detailed assessment of the design and the quality and safety management system against the requirements in [IEC 61508:2010]. The following Table SAS-FUSA 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 two columns of the table define how these techniques are to be addressed in the architecture of QP/C++ Framework and QP/C++ Applications, respectively.
| Technique/Measure(*) | IEC 61508 Ref. | SIL 3 (#) | Specs for QP Framework | Specs for QP Application | |
|---|---|---|---|---|---|
| 1 | Fault detection | C.3.1 | HR | SAS_QP_FUSA_01 | SAS_QA_FUSA_01 |
| 2 | Error detecting codes | C.3.2 | R | SAS_QP_FUSA_02 | — |
| 3a | Failure assertion programming | C.3.3 | R | SAS_QP_FUSA_03A | — |
| 3b | Diverse monitor techniques (with independence between the monitor and the monitored function in the same computer) | C.3.4 | R | — | — |
| 3c | Diverse monitor techniques (with separation between the monitor computer and the monitored computer) | C.3.5 | R | — | — |
| 3d | Diverse redundancy, implementing the same software safety requirement specification | C.3.5 | — | — | — |
| 3e | Functionally diverse redundancy, implementing different software safety requirement specification | C.3.5 | R | — | — |
| 3f | Backward recovery | C.3.6 | — | — | — |
| 3g | Stateless software design (or limited state design) | C.2.12 | R | — | — |
| 4a | Re-try fault recovery mechanism | C.3.7 | — | — | — |
| 4b | Graceful degradation | C.3.8 | HR | SAS_QP_FUSA_04B | SAS_QA_FUSA_04B |
| 5 | Artificial intelligence - fault correction | C.3.9 | NR | SAS_QP_FUSA_05 | SAS_QA_FUSA_05 |
| 6 | Dynamic reconfiguration | C.3.10 | NR | SAS_QP_FUSA_06 | SAS_QA_FUSA_06 |
| 7 | Modular approach | Table B.9 | HR | SAS_QP_FUSA_07 | SAS_QA_FUSA_07 |
| 8 | Use of trusted/verified software elements (if available) | C.2.10 | HR | SAS_QP_FUSA_08 | SAS_QA_FUSA_08 |
| 9 | Forward traceability between the software safety requirements specification and software architecture | C.2.11 | HR | SAS_QP_FUSA_09 | — |
| 10 | Backward traceability between the software safety requirements specification and software architecture | C.2.11 | HR | SAS_QP_FUSA_10 | — |
| 11a | Structured diagrammatic methods | C.2.1 | HR | SAS_QP_FUSA_11A | — |
| 11b | Semi-formal methods | Table B.7 | HR | SAS_QP_FUSA_11B | SAS_QA_FUSA_11B |
| 11c | Formal design and refinement methods | B.2.2, C.2.4 | R | — | — |
| 11d | Automatic software generation | C.4.6 | R | SAS_QP_FUSA_11D | SAS_QA_FUSA_11D |
| 12 | Computer-aided specification and design tools | B.2.4 | HR | SAS_QP_FUSA_12 | SAS_QA_FUSA_12 |
| 13a | Cyclic behavior, with guaranteed maximum cycle time | C.3.11 | HR | — | — |
| 13b | Time-triggered architecture | C.3.11 | HR | SAS_QP_FUSA_13B | SAS_QA_FUSA_13B |
| 13c | Event-driven, with guaranteed maximum response time | C.3.11 | HR | SAS_QP_FUSA_13C | SAS_QA_FUSA_13C |
| 14 | Static resource allocation | C.2.6.3 | HR | SAS_QP_FUSA_14 | SAS_QA_FUSA_14 |
| 15 | Static synchronization of access to shared resources | C.2.6.3 | R | SAS_QP_FUSA_15 | SAS_QA_FUSA_15 |
| (#) Acronym | Description |
|---|---|
| HR | (Highly Recommended) — the technique or measure is highly recommended for this safety integrity level. If this technique or measure is not used then the rationale behind not using it should be detailed with reference to [IEC 61508-3:2010] Annex C during the safety planning and agreed with the assessor. |
| R | (Recommended) — the technique or measure is recommended for this safety integrity level as a lower recommendation to a HR recommendation. |
| — | (Neutral) — the technique or measure has no recommendation for or against being used. |
| NR | (NOT Recommended) — the technique or measure is positively not recommended for this safety integrity level. If this technique or measure is used then the rationale behind using it should be detailed with reference to [IEC 61508-3:2010] Annex C during the safety planning and agreed with the assessor. |
| SAS_QP_FUSA_01 : Fault detection based on assertion programming in QP/C++ Framework. |
|---|
| Backward Traceability QP/C++ Framework implements assertion-based fault detection as part of the QP Functional Safety (FuSa) Subsystem. The assertion facilities have the following architectural specifications:
|
| Example The following pseudocode shows the use of the general-purpose assertion as well as specialized assertion facilities, illustrating the compact, idiomatic, and easily identifiable format: void foo(void *ptr,...) {
. . .
// the following code can safely assume that 'ptr' is not nullptr
ptr->foo = ...
. . .
Q_ASSERT(y != 0); // <=== general-purpose assertion
// the following code can safely assume that 'y' is not 0
r = x / y;
. . .
}
|
| Forward Traceability |
| SAS_QA_FUSA_01 : Fault detection based on assertion programming in QP/C++ Application. |
|---|
Backward Traceability
|
| Example The following pseudocode illustrates a no-return custom error handler defined in QP/C++ Application: // NOTE: the following error handler executes within a critical section
// (preemption disabled).
// place the system in a safe state
// log the error
// perform system reset (possibly into a different mode)
}
Q_NORETURN Q_onError(char const *const module, int_t const id) |
| Example The following pseudocode illustrates a non-compliant assertion with side effects: void foo(...) {
. . .
Q_ASSERT(ptr = &event123); // <=== assertion with side effect NON-COMPLIANT!
. . .
}
|
| Forward Traceability |
| SAS_QP_FUSA_02 : Error detecting codes mechanisms to protect critical variables. |
|---|
| Backward Traceability QP/C++ Framework shall implement the following error detecting code techniques in the indicated contexts:
|
| Forward Traceability |
| SAS_QP_FUSA_03A : Failure assertion programming. |
|---|
| Backward Traceability Failure assertion programming is a specialized form of assertion programming aimed at detecting faulty interfacing between components (preconditions, postconditions) as well as data corruption (invariants). QP/C++ Framework implements failure assertion programming as part of the QP Functional Safety (FuSa) Subsystem. The following assertion types are implemented (traceability:
|
| Example The following pseudocode illustrates precondition, invariant, error, and postcondition: void FooClass_bar(FooClass * const me, uint8_t x) {
. . .
Q_REQUIRE((me != NULL) && (0U < x)); // <=== precondition
. . .
Q_INVARIANT(FooClass_verify(me)); // <=== invariant
. . .
switch (...) {
. . .
default:
Q_ERROR(); // <=== error
break;
}
// traverse a linked-list of Elements...
int_fast8_t lbound = 10; // fixed upper loop bound
for (Element el = list_head;
(el != nullptr) && (lbound > 0);
el = el->next, --lbound)
{
. . .
}
Q_ENSURE(lbound > 0); // <=== postcondition
}
|
| Forward Traceability |
| SAS_QP_FUSA_04B : Mechanisms for graceful degradation in QP/C++ Application. |
|---|
| Description Graceful degradation aims to maintain more critical system functions available, despite failures, by dropping the less critical functions. QP/C++ Framework supports graceful degradation by providing mechanisms to protect the more critical functions from interference by the less critical ones. The main such mechanisms are:
|
| Example The following pseudocode illustrates unreliable event allocation and delivery to a less-important functionality: if (echoEvt != (QEvt *)0) { // event allocated successfully?
QACTIVE_POST_X((QActive *)&l_cruncher, echoEvt, 2U, (void *)0); // unreliable posting (margin==2)
}
|
| Forward Traceability |
| SAS_QA_FUSA_04B : Safe graceful degradation in QP/C++ Application. |
|---|
| Description QP/C++ Applications shall implement system-specific graceful degradation by applying the following mechanisms provided by QP/C++ Framework:
|
| Forward Traceability |
| SAS_QP_FUSA_05 : NO use of artificial intelligence for fault correction in QP/C++ Framework. |
|---|
| Forward Traceability |
| SAS_QA_FUSA_05 : NO use of artificial intelligence for fault correction in QP/C++ Application. |
|---|
| Description QP/C++ Application can use artificial intelligence, but NOT for fault correction. |
| Forward Traceability |
| SAS_QP_FUSA_06 : NO dynamic reconfiguration for fault correction in QP/C++ Framework. |
|---|
| Forward Traceability |
| SAS_QA_FUSA_06 : NO dynamic reconfiguration for fault correction in QP/C++ Application. |
|---|
| Description Avoiding dynamic reconfiguration for fault correction means, among others, that QP/C++ Application shall not dynamically stop and start Active Objects at runtime. Instead, of changing the identity of Active Objects, the recommended method is for the QP/C++ Application to design and implement change of Active Object behavior by changing its state. |
| Forward Traceability |
| SAS_QP_FUSA_07 : Modular approach in QP/C++ Framework. |
|---|
| Description QP/C++ Framework architecture shall apply the following rules for modularity (traceability: SRS_QP_NF_03 ):
|
| Forward Traceability |
| SAS_QA_FUSA_07 : Modular approach in QP/C++ Application. |
|---|
| Description Safety-related QP/C++ Application shall follow rules similar to SAS_QP_FUSA_07 . |
| Forward Traceability |
| SAS_QP_FUSA_08 : Only trusted/verified software elements in QP/C++ Framework. |
|---|
| Description QP Framewrok 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 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 |
| SAS_QA_FUSA_08 : Only trusted/verified software elements in QP/C++ Application. |
|---|
| Description QP/C++ Application shall combine QP/C++ Framework only with trusted/verified software elements, such as:
|
| Forward Traceability |
| SAS_QP_FUSA_09 : Consistent forward traceability between Safety Requirements and Software Architecture in QP/C++ Framework. |
|---|
| Forward Traceability |
| SAS_QP_FUSA_10 : Consistent backward traceability between Safety Requirements and Software Architecture in QP/C++ Framework. |
|---|
| Forward Traceability |
| SAS_QP_FUSA_11A : Structured diagrammatic methods in QP/C++ Framework. |
|---|
| Description QP/C++ Framework documentation shall use the well-defined UML diagrams, whenever applicable. Non-UML diagrams shall have legends explaining the symbols. |
| Forward Traceability |
| SAS_QP_FUSA_11B : Semi-formal methods in QP/C++ Framework. |
|---|
| Description QP/C++ Framework shall use the following semi-formal methods (see [IEC 61508-7:2010] Table C.17)
|
| Forward Traceability |
| SAS_QA_FUSA_11B : Semi-formal methods in QP/C++ Application in form of hierarchical state machines. |
|---|
Description
|
| Forward Traceability |
| SAS_QP_FUSA_11D : Automatic code generation in QP/C++ Framework. |
|---|
| Description QP/C++ Framework source code shall be automatically generated from the QP/C++ Framework model (see also SAS_QP_FUSA_12 ). This eliminates large classes of human error, enforces coding conventions, and ensures consistency. |
| Forward Traceability |
| SAS_QA_FUSA_11D : Automatic code generation in QP/C++ Application. |
|---|
| Description QP/C++ Application shall apply automatic code generation, especially from state diagrams (see also SAS_QA_FUSA_12 ). This eliminates large classes of human error, enforces coding conventions, and ensures consistency. |
| Forward Traceability |
| SAS_QP_FUSA_12 : Computer-aided specification and design tools use in QP/C++ Framework. |
|---|
| Description QP/C++ Framework source code shall be modeled with the QM model-based design tool [QM-Tool:2024]. |
| Forward Traceability |
| SAS_QA_FUSA_12 : Computer-aided specification and design tools use in QP/C++ Application. |
|---|
| Description QP/C++ Application shall leverage the QM model-based design tool [QM-Tool:2024] to model the application components, especially the hierarchical state machines of Active Objects. |
| Forward Traceability |
| SAS_QP_FUSA_13B : Time-triggered architecture in QP/C++ Framework. |
|---|
| Description While the QP/C++ Framework architecture is inherently event-driven (see SAS_QA_FUSA_13C ), the non-preemptive kernel built into QP/C++ Framework can be used to implement many aspects of time-triggered architecture (see SAS_QA_FUSA_13B ). |
| Forward Traceability |
| SAS_QA_FUSA_13B : Time-triggered architecture in QP/C++ Application. |
|---|
| Description It is highly recommended for QP/C++ Application to restrict the use of interrupts to just a single, periodic, system clock-tick interrupt. With this restriction plus the use of the non-preemptive kernel built into QP/C++ Framework, the execution profile of QP/C++ Application acquires many characteristics of time-triggered architecture. |
| Forward Traceability |
| SAS_QP_FUSA_13C : Event-driven architecture with guaranteed maximum response time in QP/C++ Framework. |
|---|
| Description QP/C++ Framework implements precisely the highly recommended event-driven architecture. Moreover, the preemptive, non-blocking kernel is fully compliant with the requirements of Rate-Monotonic Scheduling/Analysis (RMS/RMA) method, by which hard-real time execution can be guaranteed. |
| Forward Traceability |
| SAS_QA_FUSA_13C : Event-driven architecture with guaranteed maximum response time in QP/C++ Application. |
|---|
| Description QP/C++ Application shall apply event-driven architecture with guaranteed maximum response time. Specifically, QP/C++ Application should use the preemptive, non-blocking kernel and apply the Rate-Monotonic Scheduling/Analysis (RMS/RMA) method to quantify the CPU utilization and keep it under the schedulability bound. |
| Forward Traceability |
| SAS_QP_FUSA_14 : Static resource allocation in QP/C++ Framework. |
|---|
| Description QP/C++ Framework shall apply exclusively static resource allocation and shall strictly avoid dynamic resource allocation. |
| Forward Traceability |
| SAS_QA_FUSA_14 : Static resource allocation in QP/C++ Application. |
|---|
| Description The memory allocation policy of QP/C++ Framework requires QP/C++ Applications to provide the memory for all application-specific objects to the framework (traceability: SAS_QP_MEM ). QP/C++ Application can apply any policy to allocate such memory, but safety-related application shall apply exclusively static resource allocation and shall avoid dynamic resource allocation.
|
| Forward Traceability |
| SAS_QP_FUSA_15 : Static synchronization of access to shared resources in QP/C++ Framework. |
|---|
| Description QP/C++ Framework shall apply only the non-blocking critical section mutual exclusion mechanism to protect its internal shared resources. |
| Forward Traceability |
| SAS_QA_FUSA_15 : Static synchronization of access to shared resources in QP/C++ Application. |
|---|
| Description QP/C++ Application shall strictly follow the shared-nothing principle, in which case QP/C++ Application does not need to use any shared resources. The only allowed form is sharing of events.
|
| Forward Traceability |