sds-qp_osal

Viewpoint

SDS_QP_FUSA

SDS_QP_FUSA : Functional Safety Viewpoint
Purpose The Functional Safety Viewpoint focuses on ensuring that the software design is based on the recommended techniques and avoids non-recommended techniques and methods for the desired safety integrity level.
Design Concerns The safety design viewpoint is used to address the following concerns: use of safe subset of programming language, trusted translators, checkers, and tools use of recommended detailed design techniques and measures use of recommended design and coding standards use of recommended tools and approaches, such as modeling and code generation

View: Support Tools & Programming Language

The following Table SDS-LANG lists the recommended techniques and measures for software design required by [IEC 61508-3:2010] Table A.3 to achieve SIL 3. The last two columns of the table define how these techniques shall be applied (or avoided) in the design of QP/C++ Framework and QP/C++ Applications.

Table SDS-LANG: Support tools & programming language applied to QP/C++ Framework and QP/C++ Applications.

Technique/Measure(*)		IEC 61508 Ref.	SIL 3 (#)	Specs for QP Framework	Specs for QP Application
1	Suitable programming language	C.4.5	HR	SDS_QP_LANG_01	SDS_QA_LANG_01
2	Strongly typed programming language	C.4.1	HR	SDS_QP_LANG_02	SDS_QA_LANG_02
3a	Language subset	C.4.2	R	SDS_QP_LANG_03	SDS_QA_LANG_03
4a	Certified tools and certified translators	C.4.3	HR	SDS_QP_LANG_04	SDS_QA_LANG_04
4b	Tools and translators: increased confidence from use	C.4.4	HR	SDS_QP_LANG_04	SDS_QA_LANG_04

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

Remarks: See [IEC 61508-3:2010] Table C.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-8:2010]

Note: (*) 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 in accordance with the properties, given in [IEC 61508-3:2010] Annex C, desirable in the particular application.

SDS_QP_LANG_01

SDS_QP_LANG_01 : Suitable programming language.
Description
Traceability
Forward Traceability

View: Detailed Design Techniques/Measures

Safety ViewpointView: Design and Coding Standards

Table SDS-TECH: Techniques/measures for detailed design of QP/C++ Framework and QP/C++ Applications.

Technique/Measure(*)		IEC 61508 Ref.	SIL 3 (#)	Specs for QP Framework	Specs for QP Application
1a	Structured methods	C.3.1	HR	SDS_QP_TECH-01	SDS_QA_TECH_01
1b	Semi-formal methods	Table B.7	HR	SDS_QP_TECH-01	SDS_QA_TECH_01
1c	Formal design and refinement methods	B.2.2 C.2.4	R	SDS_QP_TECH-01	SDS_QA_TECH_01
2	Computer-aided design tools	B.3.5	R	SDS_QP_TECH-02	SDS_QA_TECH_02
3	Defensive programming	C.2.5	HR	SDS_QP_TECH-03	SDS_QA_TECH_03
4	Modular approach	Table B.9	HR	SDS_QP_TECH-04	SDS_QA_TECH_04
5	Design and coning standards	C.2.5 Tale B.1	HR	SDS_QP_TECH-05	SDS_QA_TECH_05
6	Structured programming	C.2.7	HR	SDS_QP_TECH-06	SDS_QA_TECH_06
7	Use of trusted/verified software elements (if available)	C.2.10	HR	SDS_QP_TECH-07	SDS_QA_TECH_07
8	Forward traceability between the software safety requirements specification and software design	C.2.11	HR	SDS_QP_TECH-08	SDS_QA_TECH_08

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

Remarks: See [IEC 61508-3:2010] Table C.4; See [IEC 61508-7:2010] Annex G; 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-8:2010]

Note: (*) 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 in accordance with the properties, given in [IEC 61508-3:2010] Annex C, desirable in the particular application.

View: Design and Coding Standards

Table SDS-STD: Techniques/measures for detailed and coding standards of QP/C++ Framework and QP/C++ Applications.

Technique/Measure(*)		IEC 61508 Ref.	SIL 3 (#)	Specs for QP Framework	Specs for QP Application
1	Use of coding standards to reduce likelihood of errors	C.2.6.2	HR	SDS_QP_STD_01	SDS_QA_STD_01
2	No dynamic objects	Table B.7	HR	SDS_QP_STD_01	SDS_QA_STD_01
3a	No dynamic variables	B.2.2 C.2.4	R	SDS_QP_STD_01	SDS_QA_STD_01
3b	Online checking of the installation of dynamic variables	B.3.5	R	SDS_QP_STD_02	SDS_QA_STD_02
4	Limited use of interrupts	C.2.5	HR	SDS_QP_STD_03	SDS_QA_STD_03
5	Limited use of pointers	Table B.9	HR	SDS_QP_STD_04	SDS_QA_STD_04
6	Limited use of recursion	C.2.5 Tale B.1	HR	SDS_QP_STD_05	SDS_QA_STD_05
7	No unstructured control flow in programs in higher level languages	C.2.7	HR	SDS_QP_STD_06	SDS_QA_STD_06
8	No automatic type conversion	C.2.10	HR	SDS_QP_STD_07	SDS_QA_STD_07

Note

NOTE1 Measures 2, 3a and 5. The use of dynamic objects (for example on execution stack or on a heap) may impose requirements on both available memory and also exectution time. Measures 2, 3a and 5 do not need to be applied if a compiler is used which ensures a) that sufficent 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.

NOTE2 See [IEC 61508-3:2010] Table C.11

NOTE3 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-8: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 in accordance with the properties, given in [IEC 61508-3:2010] Annex C, desirable in the particular application.

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

View: Modeling

View: Design and Coding Standards

Table SDS-MOD: Techniques/measures for modeling of QP/C++ Framework and QP/C++ Applications.

Technique/Measure(*)		IEC 61508 Ref.	SIL 3 (#)	Specs for QP Framework	Specs for QP Application
1	Data flow diagram	C.2.6.2	R	SDS_QP_MODEL_01	SDS_QA_MODEL_01
2	Finite state machines	Table B.7	HR	SDS_QP_MODEL_01	SDS_QA_MODEL_01
3a	Formal methods	B.2.2 C.2.4	R	SDS_QP_MODEL_01	SDS_QA_MODEL_01
3b	Time Petri nets	B.3.5	R	SDS_QP_MODEL_02	SDS_QA_MODEL_02
4	Performance modeling	C.2.5	HR	SDS_QP_MODEL_03	SDS_QA_MODEL_03
5	Prototyping/animation	Table B.9	R	SDS_QP_MODEL_04	SDS_QA_MODEL_04
6	Structure diagrams	C.2.5 Tale B.1	R	SDS_QP_MODEL_05	SDS_QA_MODEL_05

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

Remarks: Measures 2, 3a and 5. The use of dynamic objects (for example on execution stack or on a heap) may impose requirements on both available memory and also exectution time. Measures 2, 3a and 5 do not need to be applied if a compiler is used which 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.; See [IEC 61508-3:2010] Table C.11; NOTE3 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-8:2010]

Note: (*) 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 in accordance with the properties, given in [IEC 61508-3:2010] Annex C, desirable in the particular application.

sds-qp_osal