Viewpoint

SAS_QP_FUSA_VP

Functional Safety Viewpoint

Purpose
The Functional Safety Viewpoint focuses on cross-checking all techniques and measures required by [IEC 61508-3:2010] against the architecture of the QP/C Framework component. The rigor of the required design process and control measures is a function of a Safety Integrity Level (SIL 3 in this case). This is evaluated through a detailed assessment of the architecture and the quality and safety management system against the requirements in [IEC 61508-3:2010] 7.4.3 and 7.4.4:

addressing all "highly recommended" techniques and measures
selecting the "alternative or equivalent" techniques/measures
avoiding all "not recommended" techniques and measures

Architectural Views
This architectural viewpoint frames the following views:

View: Software Systematic Capability
View: Programming Language & Support Tools

Recommendation Levels

Regulatory background

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

This architectural viewpoint applies the recommendation levels from the foundational standard [IEC 61508:2010]:

HR 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 during the safety planning and agreed with the assessor.
R the technique or measure is recommended for this safety integrity level as a lower recommendation than an HR recommendation.
— the technique or measure has no recommendation for or against being used.
NR 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 during the safety planning and agreed with the assessor.

Attention: 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. Conversely, techniques marked as NR are generally not suitable for use at that SIL; if they are applied, the development team must provide a documented justification demonstrating that their use does not compromise the required safety integrity.

View: Software Systematic Capability

Software Systematic Capability is 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 by the instructions specified in the compliant item Safety Manual [DOC_SSM_QP] for the software.

Regulatory background

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 columns defines how these techniques are to be addressed in the architecture of QP/C Framework component component.

Table SAS-TBL-A2: Systematic capability techniques and measures ([IEC 61508-3:2010] Table A.2, SIL 3 only).

Technique/Measure(*)		IEC 61508 Ref.	SIL 3	Specs for QP framework
1	Fault detection	C.3.1	HR	SAS_QP_SSC_01
2	Error detecting codes	C.3.2	R	SAS_QP_SSC_02
3a	Failure assertion programming (*)	C.3.3	R	SAS_QP_SSC_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_SSC_04B
5	Artificial intelligence - fault correction	C.3.9	NR	SAS_QP_SSC_05
6	Dynamic reconfiguration	C.3.10	NR	SAS_QP_SSC_06
7	Modular approach	Table B.9	HR	SAS_QP_SSC_07
8	Use of trusted/verified software elements (if available)	C.2.10	HR	SAS_QP_SSC_08
9	Forward traceability between the software safety requirements specification and software architecture	C.2.11	HR	SAS_QP_SSC_09
10	Backward traceability between the software safety requirements specification and software architecture	C.2.11	HR	SAS_QP_SSC_10
11a	Structured diagrammatic methods (*)	C.2.1	HR	SAS_QP_SSC_11A
11b	Semi-formal methods (*)	Table B.7	HR	SAS_QP_SSC_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_SSC_11D
12	Computer-aided specification and design tools	B.2.4	HR	SAS_QP_SSC_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_SSC_13C
14	Static resource allocation	C.2.6.3	HR	SAS_QP_SSC_14
15	Static synchronization of access to shared resources	C.2.6.3	R	SAS_QP_SSC_15

(*) Alternative or equivalent techniques/measures are indicated by a letter following the number. It is intended that only one of the alternative or equivalent techniques/measures should be satisfied. The choice of alternative technique should be justified by the properties, given in [IEC 61508-3:2010] Annex C, desirable in the particular application.

In the reference columns (entitled Ref), the informative references "B.x.x.x", "C.x.x.x" refer to descriptions of techniques in [IEC 61508-7:2010] Annexes B and C, while "Table A.x", "Table B.x" refer to tables of techniques in [IEC 61508-3:2010] Annexes A and B.

SAS_QP_SSC_01

Fault detection: QP/C Framework component shall apply assertion-based fault detection policy.

Description
Fault detection is the activity of checking a system for erroneous states (caused by a fault within the (sub)system to be checked). The primary goal of fault detection is to inhibit the effect of wrong results. Fault detection is based on the principles of redundancy. In software, special methods include: assertion programming, n-version programming, and the diverse monitor technique.

The method elected for the QP/C Framework component is the assertion programming and failure assertion programming methods. The assertion facilities shall be defined in the QP Functional Safety (FuSa) Subsystem with the following safety specifications:

All software Safety Functions involved in fault detection shall be implemented with assertions
All assertions shall be applied correctly, meaning to diagnose faults and never to implement exceptional conditions
All assertions shall have no side effects
All assertions shall be protected from concurrency hazards
All assertions shall be easily identifiable in the source code, including preconditions, postconditions, invariants, and erroneous paths through the code (failure assertion programming)
Upon failure, all assertions shall invoke the user-defined Custom Error Handler
The Custom Error Handler shall be invoked correctly (within a critical section)

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,...) {
    . . .
    Q_REQUIRE(ptr != nullptr); // <=== precondition assertion
    // 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;
    . . .
    Q_ENSURE(r > 0); // <=== postcondition assertion
    return r;
}

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.
SSRS_QP_FDM_00: QP/C software component shall provide uniform fault detection and management mechanisms.
SSRS_QP_FDM_00: QP/C software component shall provide uniform fault detection and management mechanisms.
SSRS_QP_FDM_40: The fault detection mechanisms provided in QP/C software component shall be protected from concurrency hazards.
SSRS_QP_FDM_20: The assertion-based mechanisms provided in QP/C software component shall manage the detected faults by passing control to the custom error handler defined in QP/C Application.
SSRS_QP_FDM_10: The Boolean expressions checked in QP/C software component assertions shall have no side effects..

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_02

Error detecting codes: QP/C Framework component shall apply error detection based on Duplicate Inverse Storage and Duplicate Storage.

Description
QP/C Framework component shall implement the following error-detecting code techniques in the indicated contexts:

Duplicate Inverse Storage (DIS)

Event instances (DIS covering event signal, reference-count, and pool-ID)
Current-state variable in the state machine instances
Event queue (head/tail/free-entries counters)
Event/memory pool ( counters)
Time event (linked-list links, counters)
Publish-subscribe lists
Internal variables of the non-preemptive real-time kernel
Internal variables of the preemptive non-blocking real-time kernel
Internal variables of the preemptive dual-mode kernel

Duplicate Storage (no bitwise inversion)

Event pool buffers (free block linked-list links)

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.
SSRS_QP_DIM_10: QP/C software component shall apply self-monitoring SSFs based on "Duplicate Inverse Storage" to critical variables.
SAS_QP_MEM_02: Event queue allocation policy and responsibilities
SAS_QP_MEM_04: Event pool allocation policy and responsibilities
SAS_QP_MEM_05: Subscription lists allocation policy and responsibilities
SAS_QP_EVT_00: Event management policy

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_04B

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:

reliable event posting with delivery guarantee for critical system functions (traceability: SRS_QP_EDG-10)
best-effort-only event delivery (for less critical functions) but with the mechanism to ensure non-interference with reliable event delivery (traceability: SRS_QP_EDG-10). This non-interference mechanism shall work as follows:
- When allocating a dynamic event, QP/C API shall provide a safety margin of the event pool from which the event is allocated. In case the safety margin is reached, the best-effort allocation should fail and convey this failure to the caller (see Safety Manual DOC_SSM_QP for application-level responsibilities). That way, some space in the pool remains available to the reliable (default) event allocation mechanism.
- When using the best-effort direct event posting mechanism, QP/C Framework accepts a safety margin of the event queue to which it posts events that can be lost. In case the safety margin is reached, the best-effort posting should fail and convey this failure to the caller (see Safety Manual DOC_SSM_QP for application-level responsibilities). That way, some space in the queue remains available to the reliable (default) event posting mechanism.

Example
The following pseudocode illustrates unreliable event allocation and delivery to a less-important functionality:

QEvt const *echoEvt = Q_NEW_X(QEvt, 3U, ECHO_SIG, 0U); //<== unreliable allocation (margin==3)
if (echoEvt != (QEvt *)0) { // event allocated successfully?
    QACTIVE_POST_X((QActive *)&l_cruncher, echoEvt, 2U, (void *)0); // unreliable posting (margin==2)
}

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_05

NO use of artificial intelligence for fault correction in QP/C Framework component.

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_06

NO dynamic reconfiguration for fault correction in QP/C Framework component.

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_07

Modular approach in QP/C Framework component.

Description
QP/C Framework component architecture shall apply the following rules for modularity (traceability: SRS_QP_NF_01):

Information hiding/encapsulation (see Object-Oriented Architecture Model)
Fully defined interface with explicit specification of function signatures
Fully documented interfaces
Modules shall guarantee correct use by preconditions and postconditions (see failure assertion programming)
All subprograms (functions) shall have a single entry and a single exit
All subprograms (functions) shall have several parameters limited to 4
All subprograms (functions) shall have complexity limited to 20 (cyclomatic complexity)
Global variables shall be limited to fewer than 10 for the whole QP/C Framework component

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_08

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).

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_09

Consistent forward traceability between Safety Requirements and Software Architecture in QP/C Framework component.

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_10

Consistent backward traceability between Safety Requirements and Software Architecture in QP/C Framework component.

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_11A

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))

SAS_QP_SSC_11B

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)

logic/function block diagrams (traceability: e.g., Figure SRS-BLK, Figure SAS-CTXT)
sequence diagrams (traceability:e.g., Figure SRS-SEQ-TH, Figure SRS-SEQ-AOS, Figure SAS-START)
data flow diagrams (traceability: Figure SRS-AOS)
finite state machines (traceability: Support For State Machines)
entity-relationship-attribute data models (traceability: Figure SAS-MEM, Figure SAS-EMM)
message sequence charts (see sequence diagrams)
decision/truth tables
UML

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.
SSRS_QP_SSC_01A: QP/C software component shall apply and support semi-formal methods listed in [IEC 61508-3:2010] Table B.7.

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_11D

Automatic code generation in QP/C Framework component.

Description
QP/C Framework component design and implementation shall support automatic code generation.

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.

Forward Traceability (truncated to 1 level(s))

SSM_COSU__11D: Automatic code generation in QP/C Application.

SAS_QP_SSC_12

Computer-aided specification and design tools use in QP/C Framework component.

Description
QP/C Framework component source code shall be modeled with the QM model-based design tool [QM-Tool:2024].

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_13C

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.

Backward Traceability

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.

Forward Traceability (truncated to 1 level(s))

SAS_QP_SSC_14

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))

SAS_QP_SSC_15

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

SRS_QP_NF_01: QP/C Framework component shall have the systematic capabilities required by functional safety standards.

Forward Traceability (truncated to 1 level(s))

View: Programming Language & Support Tools

This architectural view frames the following concerns:

The choice of the programming language to support the production of software with the required properties

The programming language safe subset (coding standard) to achieve the required SIL 3

Regulatory background

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.

Table SDS-A3: Programming language & support tools applied to QP/C Framework component ([IEC 61508-3:2010] Table A.3, SIL 3 only).

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

NOTE1 [IEC 61508-3:2010] Table C.3

NOTE2 The references (which are informative, not normative) "B.x.x.x", "C.x.x.x" in column ("Ref.") indicate detailed descriptions of techniques given in Annexes B and C of [IEC 61508-3:2010].

(*) Alternative or equivalent techniques/measures are indicated by a letter following the number. It is intended that only one of the alternative or equivalent techniques/measures should be satisfied. The choice of alternative technique should be justified by the properties, given in [IEC 61508-3:2010] Annex C, desirable in the particular application.

SAS_QP_PL_01

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:

internationally standardized and widely used language
supports strong typing, structured programming, and assertions (see ssrs-qp_ap)
is verifiable, facilitates program development, verification, and maintenance
is general-purpose, user/problem-oriented rather than processor/platform machine-oriented
supports block structure, translation-time checking

However, at the same time, the full ISO C11 programming language also exhibits the following undesirable properties:

allows unconditional jumps (e.g., goto)
allows recursion
allows implicit type conversions
allows pointers, heaps, and dynamic variables and objects
allows multiple entries and exits of loops, (e.g., break, continue)
allows implicit variable initialization
allows many cases of undefined behavior or platform-dependent behavior
does not automatically check array bounds

Regulatory background
Because of the undesired properties listed above, 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.

Table SDS-C1: Recommendations for specific programming languages ([IEC 61508-3:2010] Table C.1, SIL 3 only).

Programming language SIL 3

... ... ...

9 C NR

10 C with subset and coding standard, and use of static analysis tools HR

... ... ...

Backward Traceability
SRS_QP_NF_02: QP/C Framework component shall be implemented in a programming language recommended for safety-critical software.
SAS_QP_PL_03: Safe language subset for QP/C Framework component.

Forward Traceability (truncated to 2 level(s))

SAS_QP_PL_03: Safe language subset for QP/C Framework component.
- DOC_MISRA_QPC: QP/C MISRA-C:2025 Compliance Report

SAS_QP_PL_02

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 and enforce coding guidelines that ensure type safety through explicit conversions, static analysis, and compiler diagnostics.

Backward Traceability

SRS_QP_NF_02: QP/C Framework component shall be implemented in a programming language recommended for safety-critical software.

Forward Traceability (truncated to 2 level(s))

SAS_QP_PL_03: Safe language subset for QP/C Framework component.
- SAS_QP_PL_01: Suitable programming language for QP/C Framework component.
- DOC_MISRA_QPC: QP/C MISRA-C:2025 Compliance Report

SAS_QP_PL_03

Safe language subset for QP/C Framework component.

Description

Backward Traceability

SRS_QP_NF_02: QP/C Framework component shall be implemented in a programming language recommended for safety-critical software.
SAS_QP_PL_01: Suitable programming language for QP/C Framework component.
SAS_QP_PL_02: Strongly typed programming language for QP/C Framework component.

Forward Traceability (truncated to 2 level(s))

SAS_QP_PL_01: Suitable programming language for QP/C Framework component.
DOC_MISRA_QPC: QP/C MISRA-C:2025 Compliance Report

SAS_QP_PL_04B

Tools and translators: increased confidence from use for QP/C Framework component.

Description

Forward Traceability (truncated to 2 level(s))

View: Functional Safety Architecture

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.

Note: The system integrator is responsible for configuring and using these mechanisms according to the QP/C Safety Manual (DDOC_SSM_QP).

SAS_QP_FUSA_01

QP/C Functional Safety Subsystem.

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:

fault detection and management
data flow self-monitoring
data integrity self-monitoring
control flow self-monitoring
memory isolation
architectural constraints that support non-interference between software elements

Note: Functional safety is a cross-cutting aspect of software architecture because safety must be considered at multiple levels and Safety Functions must be present in virtually every software component. Therefore, the QP Functional Safety Subsystem (QP FuSa) cannot be collocated in a cleanly separated software module, but instead must be necessarily distributed among the software components. Still, the safety aspects of the design and implementation can and should be clearly identifiable, which is the goal in the specification of the QP FuSa.

Forward Traceability (truncated to 2 level(s))

About this DocumentTechnology Viewpoint

Programming language		SIL 3
...	...	...
9	C	NR
10	C with subset and coding standard, and use of static analysis tools	HR
...	...	...


QP/C 8.1.3 Real-Time Event Framework