Viewpoint

SDS_QP_FUSA_VP

Functional Safety Viewpoint

Purpose
The Functional Safety Viewpoint focuses on ensuring that the software design is based on the recommended techniques in the functional safety standards and avoids non-recommended techniques and methods for the desired safety integrity level.

Design Views
This design viewpoint consists of the following views:

View: Design Techniques/Measures
View: Semi-Formal Techniques/Measures
View: Modular Approach
View: Object-Oriented Programming
View: Design and Coding Standards
View: Modeling

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
Not recommended	NR	"-"	Discouraged for Class B, Not allowed for Class C

This design 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: Design Techniques/Measures

Regulatory background

The following Table SDS-TBL-A4 provides a structured, SIL-dependent set of recommendations for software design and development 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).

Table SDS-TBL-A4: Design Techniques/Measures for QP/C Framework component for SIL 3 ([IEC 61508-3:2010] Table A.4).

Technique/Measure(*)		IEC 61508 Ref.	SIL 3	Specs for QP Framework
1a	Structured methods	C.3.1	HR	see choice 1b() & (*)
1b	Semi-formal methods	Table B.7	HR	SDS_QP_TECH_01B
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	SDS_QP_TECH_03
4	Modular approach	Table B.9	HR	SDS_QP_TECH_04
5	Design and coning standards	C.2.5 Table B.1	HR	SDS_QP_TECH_05
6	Structured programming	C.2.7	HR	SDS_QP_TECH_06
7	Use of trusted/verified software elements (if available)	C.2.10	HR	SDS_QP_TECH_07
8	Forward traceability between the software safety requirements specification and software design	C.2.11	HR	SDS_QP_TECH_08

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.

(**) Group 1, "Structured methods". Use measure 1a only if 1b is not suited to the domain for SIL 3+4

SDS_QP_TECH_01B

QP/C Framework shall apply semi-formal methods.

Description

Backward Traceability

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 2 level(s))

SDS_QP_SFM_01: QP/C Framework specification shall apply semi-formal method: logic/function block diagrams.
SDS_QP_SFM_02: QP/C Framework specification shall apply semi-formal method: sequence diagrams.
SDS_QP_SFM_04A: QP/C Framework specification shall support semi-formal method: state machine diagrams.
SDS_QP_SFM_07: QP/C Framework specification shall support semi-formal method: decision trees.
SDS_QP_SFM_08: QP/C Framework specification shall apply semi-formal method: UML.

SDS_QP_TECH_03

QP/C Framework shall apply defensive programming.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_TECH_04

QP/C Framework shall apply modular approach.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_TECH_05

QP/C Framework shall apply design and coning standards.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_TECH_06

QP/C Framework shall apply structured programming.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_TECH_07

QP/C Framework shall use of trusted/verified software elements.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_TECH_08

QP/C Framework shall apply forward traceability between the software safety requirements specification and software design.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

View: Semi-Formal Techniques/Measures

Regulatory background

The following Table SSRS-TBL-B7 provides a SIL-dependent set of recommendations for software verification techniques, specifically focusing on dynamic testing methods used during software integration, validation, and functional testing. It is part of Annex B, which contains the normative/informative technique tables (B.1B.7) that guide developers in selecting appropriate software verification and testing techniques to achieve the required Systematic Capability (SC) for SIL 3 in this case.

Table SSRS-TBL-B7: Semi-formal techniques/measures for QP/C Framework and QP/C Applications for SIL 3 ([IEC 61508-3:2010] Table B.7).

Technique/Measure(*)		IEC 61508 Ref.	SSIL 3 (#)	Requirements for QP/C Framework 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.

SDS_QP_SFM_01

QP/C Framework specification shall apply semi-formal method: logic/function block diagrams.

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.

Backward Traceability

SDS_QP_TECH_01B: QP/C Framework shall apply semi-formal methods.

Forward Traceability (truncated to 2 level(s))
QP/C Framework applies various types of logic/function block diagrams in the following figures:

Figure SRS-BLK Block diagram showing the context and functional decomposition of a system based on QP/C Framework.
Figure SRS-AOS Block diagram showing communicating Active Objectss in QP.
Figure SRS-EVT-SIG Block diagram showing the relationship between Event-Signals and Events.
Figure SRS-SM-DIS Block diagram showing the event dispatching to a State Machine in QP/C Framework.
Figure SRS-EDM Block diagram showing the event delivery mechanisms in the QP/C Framework.
Figure SRS-QS-SET Block diagram showing typical setup for Software Tracing.
Figure SRS-QS-STR Block diagram showing structure of the QP/Spy Software Tracing system.
Figure SAS-CTXT Block diagram showing context of use with layers and QP/C Framework interfaces.
Figure SDS-OSAL Block diagram showing QP Port implementing OS Abstraction Layer.
Figure FSM-SPEX Block diagram showing Spexygen information flow.

SDS_QP_SFM_02

QP/C Framework specification shall apply semi-formal method: sequence diagrams.

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.

Backward Traceability

SDS_QP_TECH_01B: QP/C Framework shall apply semi-formal methods.

Forward Traceability (truncated to 2 level(s))
QP/C Framework applies various types of logic/function block diagrams in the following figures:

Figure SRS-SEQ-TH Sequence diagram showing threads interacting (synchronously) with a passive object
Figure SRS-SEQ-AO Sequence diagram showing threads interacting (asynchronously) with an Active Object
Figure SDS-PUB1 Sequence diagram showing publishing event from a medium-priority Active Object (preemptive scheduler).
Figure SDS-PUB2 Sequence diagram showing publishing event WITHOUT scheduler locking (preemptive scheduler).
Figure SDS-START Sequence diagram showing QP/C Application startup sequence.
Figure SDS-POST1 Sequence diagram showing Posting event form ISR to an Active Object.
Figure SDS-POST2 Sequence diagram showing Posting event from a lower-priority Active Object to a higher-priority Active Object (preemptive scheduler).
Figure SDS-PUB1 Sequence diagram showing Publishing event from a medium-priority Active Object (preemptive scheduler).
Figure SDS-PUB2 Sequence diagram showing Publishing event WITHOUT scheduler locking (preemptive scheduler).

SDS_QP_SFM_04A

QP/C Framework specification shall support semi-formal method: state machine diagrams.

Description
Finite State Machines (FSMs) or state machine diagrams (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.

Note: The QP/C Framework internally applies state machine diagrams in its specification. However, more important is the framework's support for the advanced hierarchical state machines (HSMs) in QP/C Applications.

Backward Traceability

SDS_QP_TECH_01B: QP/C Framework shall apply semi-formal methods.

Forward Traceability (truncated to 2 level(s))
QP/C Framework applies state machine diagrams in the following figures:

Figure SRS-SM-HSM Hierarchical State Machine diagram with labeled features corresponding to the sub-requirements
Figure SDS-ERR Possible transfers of control to the Q_onError() Custom Error Handler
Figure SDS-EVT-LIFE Sequence diagram showing Mutable Event Life Cycle and Ownership Rules.
Figure SDS-SM Sequence diagram showing Example Hierarchical State Machine (a toaster oven).
Figure SDS-TE-LIFE Sequence diagram showing Time Event Life Cycle.

SDS_QP_SFM_07

QP/C Framework specification shall support semi-formal method: decision trees.

Description
Row 7 of Table B.7 lists "decision/truth tables" as the HR (highly recommended) technique that should be applied by compliant software. QP/C implements decision logic via closely related decision trees (for guard conditions in state machines), which provide the same systematic capabilities when supported by process constraints that enforce completeness, consistency, and testability.

Equivalence of intent: Decision tables and decision trees both model multi-condition, multi-action logic in a finite, explicit structure. IEC 61508 Part 7 emphasizes using structured or semi-formal methods to ensure requirements/design clarity and verifiability; decision trees meet this intent by providing a deterministic branching representation with explicit guards and outcomes.
Understandability and structure: The standard promotes techniques that enhance clarity and reduce ambiguity. Decision trees make evaluation order, guard coverage, and outcomes visually explicit in state machines, satisfying the same understandability objective attributed to "decision/truth tables" in Table B.7's semi-formal methods.
Verifiability and test derivation: IEC 61508 links semi-formal methods to improved verification and test derivation. Decision trees enable systematic derivation of test cases from branches (each path corresponds to a test scenario), analogous to decision table rule-based test extraction.
Traceability and change control: The standard stresses forward/backward traceability and controlled modification. Decision trees embedded in state machines provide traceable guard conditions linked to requirements, and changes can be controlled via configuration management and reviews, meeting the traceability and change control expectations.

Backward Traceability

SRS_QP_SM_37: All State Machine Implementation Strategies provided by QP/C Framework component shall support guard conditions to be attached to regular and internal transitions
SDS_QP_TECH_01B: QP/C Framework shall apply semi-formal methods.

Forward Traceability (truncated to 2 level(s))

SDS_QP_SFM_08

QP/C Framework specification shall apply semi-formal method: UML.

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.

Backward Traceability

SDS_QP_TECH_01B: QP/C Framework shall apply semi-formal methods.

Forward Traceability (truncated to 2 level(s))
QP/C Framework applies the UML notation throughout its documentation. Examples include the following figures:

Figure SRS-BLK UML block diagram: showing the context and functional decomposition of a system based on QP/C Framework.
Figure SDS-CLS UML class diagram showing Core classes in QP/C Framework and their relation to QP/C Application.
Figure SAS-CTXT UML package diagram showing Context of use with layers and QP/C Framework interfaces.
Figure SAS-MEM UML composite structure diagram showing Memory allocation in QP/C Framework and QP/C Application.
Figure SRS-USE UML use case diagram: Users and main use cases of QP/C Application and QP/C Framework.
Figure FSM-SDLC UML activity diagram: Software development lifecycle for SafeQP/C Framework (the V-model).
Figure SRS-SEQ-TH UML sequence diagram showing threads interacting (synchronously) with a passive object
Figure SRS-SM-HSM UML state diagram showing Hierarchical State Machine
Figure SRS-TE-JIT UML timing diagram showing Jitter of a periodic Time Event expiring every tick

View: Modular Approach

Regulatory background

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.

Table SDS-B9: Modular approach applied to QP/C Framework and QP/C Application ([IEC 61508-3:2010] Table B.9).

Technique/Measure(*)		IEC 61508 Ref.	SIL 3	Specs for QP Framework 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_02
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_04
5	One entry/one exit point in subroutines and functions	C.2.9	HR	SDS_QP_MOD_05
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.

SDS_QP_MOD_01

QP/C Framework shall apply software module size limit.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_MOD_02

QP/C Framework shall apply software complexity control.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_MOD_03

QP/C Framework shall apply information hiding/encapsulation.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_MOD_04

QP/C Framework shall apply parameter number limit / fixed number of subprogram parameters.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_MOD_05

QP/C Framework shall apply one entry/one exit point in subroutines and functions.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_MOD_06

QP/C Framework shall apply fully defined interface.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

View: Object-Oriented Programming

Regulatory background

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.

Table SDS-G2: Object-oriented detailed design applied to QP/C Framework and QP/C Application ([IEC 61508-7:2010] Table G.2, SIL 3 only).

Recommendation		SIL 3	Specs for QP Framework component
G2.1	Classes should have only one objective	HR	SDS_QP_OO_01
G2.2	Inheritance used only if the derived class is a refinement of its base class	HR	SDS_QP_OO_02
G2.3	Depth of inheritance limited by the coding standard	HR	SDS_QP_OO_03
G2.4	Overriding of operations (methods) under strict control	HR	SDS_QP_OO_04
G2.5	Multiple inheritance used only for interface classes	HR	SDS_QP_OO_05
G2.6	Inheritance from unknown classes	NR	SDS_QP_OO_06
G2.7	Verification that the reused object-oriented libraries meet the recommendations of this table	HR	SDS_QP_OO_07

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.

SDS_QP_OO_01

QP/C Framework classes should have only one objective.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_OO_02

QP/C Framework shall use inheritance only if the derived class is a refinement of its base class.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_OO_03

QP/C Framework shall apply limited depth of inheritance.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_OO_04

QP/C Framework shall apply overriding of operations (methods) under strict control.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_OO_05

QP/C Framework shall not use multiple inheritance.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_OO_06

QP/C Framework shall not inheritance from unknown classes.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_OO_07

QP/C Framework shall not use any object-oriented libraries.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

View: Design and Coding Standards

Regulatory background

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.

Table SDS-B1: Design and coding standards of QP/C Framework component ([IEC 61508-3] Table B.1).

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.

SDS_QP_DCS_01

QP/C Framework shall use of coding standards to reduce likelihood of errors.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_DCS_02

QP/C Framework shall use no dynamic objects.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_DCS_03B

QP/C Framework shall apply online checking of the installation of dynamic variables.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_DCS_05

QP/C Framework shall limit the use of pointers.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_DCS_06

QP/C Framework shall limit the use of recursion.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_DCS_07

QP/C Framework shall not use unstructured control flow in programs in higher level languages.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_DCS_08

QP/C Framework shall not use automatic type conversion.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

View: Modeling

Regulatory background

The following Table SDS-B5 provides a SIL-dependent set of recommendations for software modelling and simulation techniques. It is part of Annex B, which contains technique tables (B.1B.7) that guide developers in selecting appropriate design, analysis, modelling, and verification techniques to achieve the required Systematic Capability (SC) for SIL 3 in this case.

Table SDS-B5: Techniques/measures for modeling of QP/C Framework component ([IEC 61508-3] Table B.5).

Technique/Measure(*)		IEC 61508 Ref.	SIL 3	Specs for QP Framework component
1	Data flow diagram	C.2.2	R	—
2a	Finite state machines	B.2.3.2	HR	SDS_QP_MDL_02A
2b	Formal methods	B.2.2, C.2.4	R	see choice 2a(*)
2c	Time Petri nets	B.2.3.3	HR	see choice 2a(*)
3	Performance modeling	C.5.20	HR	SDS_QP_MDL_03
4	Prototyping/animation	C.5.17	R	—
5	Structure diagrams	C.2.3	R	—

NOTE 1 If a specific technique is not listed in the table, it should not be assumed that it is excluded form consideration. It should conform to this standard.
NOTE 2 Qualification of probabilities is not required
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-7: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.

SDS_QP_MDL_02A

QP/C Framework shall provide support for state machines to QP/C Application.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

SDS_QP_MDL_03

QP/C Framework shall apply performance modeling.

Description

Backward Traceability

Forward Traceability (truncated to 2 level(s))

About This DocumentStructure Viewpoint


QP/C 8.1.3 Real-Time Event Framework