Functional Safety Viewpoint
Purpose
This Functional Safety 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 architecture and design 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.
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))
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 | see choice 13c(*) |
| 13b | Time-triggered architecture (*) | C.3.11 | HR | see choice 13c(*) |
| 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 |
QP/C fault detection shall be based on assertion programming and failure assertion programming
Description
Fault detection shall be implemented in the QP/C Functional Safety Subsystem (SAS_QP_FUSA_00) using assertion programming and failure assertion programming techniques. The support for failure-assertion programming means that QP/C fault-detection mechanisms must not only detect the presence of a fault but also provide 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))
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)
Backward Traceability
Forward Traceability (truncated to 1 level(s))
QP/C Framework shall apply failure assertion programming free of side effects on normal functionality.
Description
QP/C software component shall apply assertion programming and 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))
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))
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))
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))
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))
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))
Consistent forward traceability between Safety Requirements and Software Architecture in QP/C Framework component.
Forward Traceability (truncated to 1 level(s))
Consistent backward traceability between Safety Requirements and Software Architecture in QP/C Framework component.
Forward Traceability (truncated to 1 level(s))
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))
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))
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))
Computer-aided specification and design tools use in QP/C Framework component.
Description
Forward Traceability (truncated to 1 level(s))
Event-driven architecture with guaranteed maximum response time in QP/C Framework component.
Description
QP/C Framework component implements precisely the highly recommended event-driven architecture. Moreover, the preemptive, non-blocking kernel is fully compliant with the requirements of the Rate-Monotonic Scheduling/Analysis (RMS/RMA) method, by which hard-real-time execution can be guaranteed.
Forward Traceability (truncated to 1 level(s))
Static resource allocation in QP/C Framework component.
Description
QP/C Framework component shall apply exclusively static resource allocation and shall strictly avoid dynamic resource allocation.
Forward Traceability (truncated to 1 level(s))
Static synchronization of access to shared resources in QP/C Framework component.
Description
QP/C Framework component shall apply only the non-blocking critical section mutual exclusion mechanism to protect its internal shared resources.
Backward Traceability
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 |
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))
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))
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))
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))
