Reference Manual For QP/C++ 8.1.5
Reference Manual For QP/C++ 8.1.5
Design viewpoint: Systematic Capability (SC).
Purpose
The Systematic Capability Viewpoint defines how the QP/C++ Framework design 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 viewpoint addresses only design-level concerns that is, the internal design principles, modeling methods, coding constraints, and structural techniques used to prevent, detect, or control systematic faults within the QP/C++ Framework itself.
Design Views
The design views in this viewpoint is aligned with the design-time techniques applied in QP/C++ to meet SIL-3/Class-C/ASIL-D expectations. These techniques correspond to IEC 61508-3 Annex A and Annex C recommendations and are implemented directly in the framework's design.
The following Table SDS-TBL-A4 provides a structured, SIL-dependent set of recommendations for software design and implementation techniques that help prevent, detect, or control systematic faults in safety-related software. It is part of the Annex A technique tables (A.1A.5), which collectively guide developers toward achieving the required Systematic Capability (SC) for a given Safety Integrity Level (SIL-3 in this case).
| Technique/Measure(*) | IEC 61508 Ref. | SIL 3 | QP/C++ Design View | |
|---|---|---|---|---|
| 1a | Structured methods | C.3.1 | HR | see choice 1b(<i>) & (</i>*) |
| 1b | Semi-formal methods | Table B.7 | HR | View: Semi-Formal Methods |
| 1c | Formal design and refinement methods | B.2.2 C.2.4 | R | see choice 1b(*) |
| 2 | Computer-aided design tools | B.3.5 | R | not used |
| 3 | Defensive programming | C.2.5 | HR | Design View: Defensive Programming |
| 4 | Modular approach | Table B.9 | HR | View: Modular Approach |
| 5 | Design and coning standards | C.2.5 Table B.1 | HR | View: Design and Coding Standards |
| 6 | Structured programming | C.2.7 | HR | Design View: Structured Programming |
| 7 | Use of trusted/verified software elements (if available) | C.2.10 | HR | Design View: Trusted/Verified Elements |
| 8 | Forward traceability between the software safety requirements specification and software design | C.2.11 | HR | Design View: Design Traceability |
NOTE 1 See [IEC 61508-3:2010] Table C.4
NOTE 2 There is still debate about the suitability of OO software development for safety-related systems. See [IEC 61508-7:2010] Annex G for guidance on object-oriented architecture and design.
NOTE 3 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-7:2010] Annex C, desirable in the particular application.
(<i></i>) Group 1, "Structured methods". Use measure 1a only if 1b is not suited to the domain for SIL-3+4
The following Table SSRS-TBL-B7 provides a set of recommended semi-formal methods with their recommendation levels for SIL-3. Semi-formal methods are more rigorous than informal descriptions but less strict than fully formal methods.| Technique/Measure(*) | IEC 61508 Ref. | SSIL 3 (#) | Requirements for QP/C++ component | |
|---|---|---|---|---|
| 1 | Logic/function block diagrams | see NOTE 1 | HR | [SDS_QP_SFM_01] |
| 2 | Sequence diagrams | see NOTE 2 | HR | [SDS_QP_SFM_02] |
| 3 | Data flow diagrams | C.2.2 | R | not used |
| 4a | Finite state machines/state transition diagrams | B.3.2 | HR | [SDS_QP_SFM_04A] |
| 4b | Timed Petri nets | B.3.3 | HR | see choice 4a(*) |
| 5 | Entity-relationship-attribute data models | B.2.4.4 | R | not used |
| 6 | Message sequence charts | C.2.14 | R | see 2 "Sequence diagrams" |
| 7 | Decision/truth tables | C.6.1 | HR | [SDS_QP_SFM_07] |
| 8 | UML | C.3.12 | R | [SDS_QP_SFM_08] |
NOTE 1 Logic/function block diagrams and sequence diagrams as described in IEC 61131-3
NOTE 2 See IEC 61508-3 Table C.17
NOTE 3 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.
(*) Appropriate techniques/measures shall be selected according to the safety integrity level. Alternative or equivalent techniques/measures are indicated by a letter following the number. It is intended the only one of the alternative or equivalent techniques/measures should be satisfied. The choice of alternative technique should be justified in accordance with the properties, given in Annex C, desirable in the particular application.
Design view: QP/C++ Framework specification shall apply semi-formal method: logic/function block diagrams (HR).
Description
Logic/function block diagrams (Table B.7 row 1) are a graphical method used to represent control logic by interconnecting standardized function blocks. Each block performs a specific operation (e.g., logic, arithmetic, timing, or control), and the diagram shows how data flows between them. QP/C++ Framework applies various types of logic/function block diagrams in the following figures:
Backward Traceability
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework specification shall apply semi-formal method: sequence diagrams (HR).
Description
Sequence diagrams (Table B.7 row 2) are a semi-formal graphical method used to represent the temporal order of operations and interactions within a control system. They describe how actions, events, or function blocks are executed step by step, showing the sequence and dependencies between them. This makes them useful for specifying control flows, verifying timing behavior, and ensuring deterministic execution in safety-related applications. QP/C++ Framework applies various types of logic/function block diagrams in the following figures:
Backward Traceability
Forward Traceability (truncated to 2 level(s))
QP/C++ Application shall apply semi-formal method finite state machines. QP/C++ Application shall apply semi-formal method decision/truth tables.Design view: QP/C++ Framework specification shall support semi-formal method: finite state machines (HR).
Description
Finite State Machines (FSMs) (Table B.7 row 4a) are a semi-formal graphical method for modeling the discrete states of a control system and the transitions between them. They represent how a system behaves depending on its current state and external events, with transitions triggered by defined conditions. This approach makes system dynamics explicit, supports deterministic control, and is widely used in safety-related applications to ensure predictable behavior. The QP/C++ Framework internally applies state machine diagrams in its specification. QP/C++ Framework applies state machine diagrams in the following figures:
Backward Traceability
Forward Traceability (truncated to 2 level(s))
QP/C++ Application shall apply semi-formal method finite state machines. QP/C++ Application shall apply semi-formal method decision/truth tables. QP/C++ Application shall apply semi-formal method finite state machines. All application-level state machines shall be well-formed and conform to the state-machine implementation strategy provided in the QP/C++ Framework. Design view: QP/C++ Framework specification shall support semi-formal method: decision/truth tables (HR).
Description
Decision/truth tables are a semi-formal method for specifying software behavior by exhaustively listing condition combinations and the required system response. They are classified as Highly Recommended (HR) in Table B.7 row 7 because they reduce ambiguity, expose missing cases, and support systematic verification. Decision/truth tables express logic in a structured, tabular form where columns represent input conditions or predicates, rows represent all meaningful combinations of those conditions, and cells define the required action or outcome for each combination. The QP/C++ Framework applies decision/truth tables in the design of the state machine processing algorithms:
Backward Traceability
Forward Traceability (truncated to 2 level(s))
QP/C++ Application shall apply semi-formal method finite state machines. QP/C++ Application shall apply semi-formal method decision/truth tables. QP/C++ Application shall apply semi-formal method decision/truth tables.Design view: QP/C++ Framework specification shall apply semi-formal method: UML (R).
Description
Unified Modeling Language (UML) is recognized as a semi-formal graphical modeling method that can complement IEC 61131-3 control specifications. UML provides standardized diagram types (e.g., class, sequence, state, activity, and timing diagrams) to describe system structure and behavior. In the context of functional safety standards, UML can be used to model software structure (package and class diagrams), event flows (sequence diagrams), state transitions (discrete behavior), and timing (timing diagrams), supporting clarity and consistency due to well-defined, formal semantics. QP/C++ Framework applies the UML notation throughout its documentation. Examples include the following figures:
Backward Traceability
Forward Traceability (truncated to 2 level(s))
QP/C++ Application shall apply semi-formal method finite state machines. QP/C++ Application shall apply semi-formal method decision/truth tables.Defensive programming is a design technique that anticipates abnormal, unexpected, or invalid conditions and ensures the software responds safely rather than relying on ideal inputs or perfect operating conditions. According to IEC 61508-7, defensive programming requires the developer to:
The goal is to prevent systematic faults by making the software robust against misuse, unexpected events, and internal failures, thereby supporting the required systematic capability for the target SIL.
Design view: QP/C++ Framework shall apply defensive programming to detect systematic faults in the QP/C++ Application.
Description
The QP/C++ Framework incorporates defensive programming techniques to anticipate, detect, and mitigate systematic faults in the QP/C++ Application. These include explicit checks for invalid states, controlled use of assertions, avoidance of undefined behavior, and strict separation between nominal and fault-handling paths. Defensive programming is applied consistently across state machines, event delivery, and kernel services to ensure predictable behavior under abnormal conditions.
Backward Traceability
Forward Traceability (truncated to 2 level(s))
The following Table SDS-B9 lists the recommended techniques and measures for software design required by [IEC 61508-3:2010] Table B.9 to achieve SIL-3. The last two columns of the table define how these techniques shall be applied (or avoided) in the design of the QP/C++ Framework and QP Applications.| Technique/Measure(*) | IEC 61508 Ref. | SIL 3 | Specs for QP/C++ component | |
|---|---|---|---|---|
| 1 | Software module size limit | C.2.9 | HR | SDS_QP_MOD_01 |
| 2 | Software complexity control | C.5.13 | HR | SDS_QP_MOD_01 |
| 3 | Information hiding/encapsulation | C.2.8 | HR | SDS_QP_MOD_03 |
| 4 | Parameter number limit / fixed number of subprogram parameters | C.2.9 | R | SDS_QP_MOD_01 |
| 5 | One entry/one exit point in subroutines and functions | C.2.9 | HR | SDS_QP_MOD_01 |
| 6 | Fully defined interface | C.2.9 | HR | SDS_QP_MOD_06 |
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.
NOTE 1 [IEC 61508-3:2010] Table C.19
NOTE 2 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-7:2010] Annex C, desirable in the particular application.
| Topics | ASIL-C | Specs for QP/C++ component | |
|---|---|---|---|
| 1a | Enforcement of low complexity | ++ | [SDS_QP_MOD_01] |
| 1e | Use of established design principles | + | Table SDS-TBL-A4 |
| 1g | Use of style guides | ++ | [SAS_QP_PL_03] |
Legend:
++ = Highly Recommended (must justify if not used)
+ = Recommended (no need to justify if not used)
Design view: QP/C++ Framework shall collect metrics and apply HIS limits.
Description
The QP/C++ Framework source code shall collect and adopt the Hersteller Initiative Software (HIS) source code quality metrics and limits ([EMENDA-HIS], [EXIDA-METRICS]), which are stricter and more specific than the recommendations of Table SDS-B9. The following table lists the HIS metrics and the adopted limits (cross-referenced with the modularity recommendations in Table SDS-B9 and Table SDS-T1) in the QP/C++ Framework component:
| HIS Metric | Purpose | IEC 61508 guideline | HIS Limits | QP/C++ Limits |
|---|---|---|---|---|
| v(G) | McCabe cyclomatic complexity | Table-B.9(2) | ≤ 10 | ≤ 16 |
| PATH | Number of Paths | Table-B.9(1) | ≤ 80 | < 99 |
| STMT | Number of Statements | Table-B.9(1) | ≤ 50 | ≤ 55 |
| LEVEL | Depth of nesting of a function | Table-B.9(1) | ≤ 4 | ≤ 4 |
| CALLS | Called Functions | Table-B.9(1) | ≤ 7 | ≤ 7 |
| PARAM | Function Parameters | Table-B.9(4) | ≤ 5 | ≤ 7 |
| RETURN | Number of return points per function | Table-B.9(5) | ≤ 1 | ≤ 1 |
| GOTO | Number of goto Statements | Table-B.9(2) | 0 | 0 |
| COMF | Comment Density | Table-B.9(6) | ≥ 0.2 | ≥ 0.2 |
| NOMV | MISRA HIS Subset violations | N/A | 0 | 0 |
| NOMVPR | MISRA violations per rule | N/A | 0 | 0 |
Backward Traceability
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework shall apply information hiding/encapsulation.
Description
The following Table SDS-G2 lists the recommended techniques and measures for object-oriented software design by [IEC 61508-7:2010] Table G.2 to achieve SIL-3. The last two columns of the table define how these techniques shall be applied (or avoided) in the design of the QP/C++ Framework component.| Recommendation | SIL 3 | QP/C++ component | |
|---|---|---|---|
| G2.1 | Classes should have only one objective | HR | see Single Responsibility |
| G2.2 | Inheritance used only if the derived class is a refinement of its base class | HR | see Liskov Substitution Principle |
| G2.3 | Depth of inheritance limited by the coding standard | HR | see Inheritance Depth Limit |
| G2.4 | Overriding of operations (methods) under strict control | HR | see Operation Overriding |
| G2.5 | Multiple inheritance used only for interface classes | HR | see No Multiple Inheritance |
| G2.6 | Inheritance from unknown classes | NR | see No Unknown Inheritance |
| G2.7 | Verification that the reused object-oriented libraries meet the recommendations of this table | HR | see No Libraries |
NOTE 1 In other words: One class is characterized by having one responsibility, i.e., taking care of closely connected data and the operations on these data
NOTE 2 Care is required to avoid circular dependencies between objects.
Single Responsibility
Each based class in QP/C++ encapsulates a single responsibility (e.g., QActive for active objects, QEvt for events, QTimeEvt for timers). This reduces complexity and supports analyzability.
Liskov Substitution Principle
QP/C++ uses a controlled form of inheritance through struct embedding. Derived types (e.g., QActive inheriting QHsm) refine behavior without altering base semantics. No unrelated inheritance is permitted.
Inheritance Depth Limit
The inheritance hierarchy is intentionally shallow (typically 12 levels). This ensures analyzability and prevents excessive coupling.
Operation Overriding
Overriding is limited to state-machine polymorphism (state handlers). All overrides follow strict signature and behavior rules enforced by the framework.
No Multiple Inheritance
Multiple inheritance is prohibited. QP/C++ uses composition instead.
No Unknown Inheritance
All base types are defined within the QP/C++ codebase. No external OO libraries or unknown base classes are used.
No Libraries
QP/C++ Framework shall not use any object-oriented libraries.
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework shall apply fully defined interface.
Description
Backward Traceability
Forward Traceability (truncated to 2 level(s))
The following Table SDS-B1 provides a SIL-dependent set of recommendations for software architecture design methods. It is the first table in Annex B, which contains the normative/informative technique tables (B.1B.7) that guide developers in selecting appropriate software design, analysis, and verification techniques to achieve the required systematic capability (SC) for SIL-3 in this case.| Technique/Measure(*) | IEC 61508 Ref. | SIL 3 | Specs for QP Framework component | |
|---|---|---|---|---|
| 1 | Use of coding standards to reduce likelihood of errors | C.2.6.2 | HR | SDS_QP_DCS_01 |
| 2 | No dynamic objects | C.2.6.3 | HR | SDS_QP_DCS_01 |
| 3a | No dynamic variables | C.2.6.3 | R | see choice 3b(*) |
| 3b | Online checking of the installation of dynamic variables | C.2.6.4 | R | SDS_QP_DCS_03B |
| 4 | Limited use of interrupts | C.2.6.5 | HR | — |
| 5 | Limited use of pointers | C.2.6.6 | HR | SDS_QP_DCS_05 |
| 6 | Limited use of recursion | C.2.6.7 | HR | SDS_QP_DCS_06 |
| 7 | No unstructured control flow in programs in higher level languages | C.6.2 | HR | SDS_QP_DCS_07 |
| 8 | No automatic type conversion | C.2.6.2 | HR | SDS_QP_DCS_08 |
NOTE 1 Measures 2, 3a, and 5. The use of dynamic objects (for example, on the execution stack or a heap) may impose requirements on both available memory and execution time. Measures 2, 3a, and 5 do not need to be applied if a compiler is used that ensures a) that sufficient memory for all dynamic variables and objects will be allocated before runtime, or which guarantees that in case of memory allocation error, a safe state is achieved; b) that response times meet the requirements.
NOTE 2 See [IEC 61508-3:2010] Table C.11
NOTE 3 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-7:2010] Annex C, desirable in the particular application.
Design view: QP/C++ Framework shall use of coding standards to reduce likelihood of errors.
Description
The framework adheres to MISRA-C and HIS metrics to ensure predictable, analyzable code.
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework shall use no dynamic objects.
Description
The framework allocates all objects statically. Dynamic allocation is prohibited.
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework shall apply online checking of the installation of dynamic variables.
Description
QP/C++ does not allocate dynamic variables internally. However, if the Application uses dynamic memory (e.g., OS services), the Application must perform online checks. This requirement is documented in the Safety Manual.
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework shall limit the use of pointers.
Description
Pointer usage is restricted to well-defined interfaces (events, state handlers). No pointer arithmetic is used.
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework shall limit the use of recursion.
Description
Recursion is prohibited. All control flow is iterative and bounded.
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework shall not use unstructured control flow in programs in higher level languages.
Description
QP/C++ Framework shall not use unstructured control flow. The framework avoids goto, longjmp, and other unstructured constructs.
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework shall not use automatic type conversion.
Description
QP/C++ Framework shall not use automatic type conversion. Implicit conversions are prohibited. All casts are explicit and justified.
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ framework adheres to structured programming principles.
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework shall use trusted/verified software elements.
Description
The framework uses only internally developed, verified components. If the Application integrates external libraries (e.g., RTOS), the Application must verify them per SSM obligations.
Forward Traceability (truncated to 2 level(s))
Design view: QP/C++ Framework code and documentation shall provide traceability.
QP/C++ Framework code and documentation shall provide forward traceability between:
Traceability ensures that all safety-related design elements are justified by requirements and that all requirements are implemented in the design.
Forward Traceability (truncated to 2 level(s))