– 152 – 60335-1  IEC:2010+A1:2013

Annex R
(normative)

Software evaluation

Programmable electronic circuits requiring software incorporating measures to control the

fault/error conditions specified in Table R.1 or Table R.2 shall be validated in accordance with
the requirements in this annex.

NOTE Tables R.1 and R.2 are based on Table H.11.12.7 of IEC 60730-1 that is, for the purpose of this annex,
divided in two tables, Table R.1 for general fault/error conditions and Table R.2 for specific fault/error conditions.

R.1 Programmable electronic circuits using software

Programmable electronic circuits requiring software incorporating measures to control the

fault/error conditions specified in Table R.1 or Table R.2 shall be constructed so that the
software does not impair compliance with the requirements of this standard.

Compliance is checked by the inspections and tests, according to the requirements of this
annex, and by examination of the documentation as required by this annex.

R.2 Requirements for the architecture

R.2.1 General

Programmable electronic circuits requiring software incorporating measures to control the

fault/error conditions specified in Table R.1 or Table R.2 shall use measures to control and
avoid software-related faults/errors in safety-related data and safety-related segments of the
software.

Compliance is checked by the inspections and tests in R.2.2 to R.3.3.3 inclusive.

R.2.1.1 Programmable electronic circuits requiring software incorporating measures to

control the fault/error conditions specified in Table R.2 shall have one of the following
structures:

– single channel with periodic self-test and monitoring (see IEC 60730-1, H.2.16.7);
– dual channel (homogenous) with comparison (see IEC 60730-1, H.2.16.3);
– dual channel (diverse) with comparison (see IEC 60730-1, H.2.16.2).
NOTE 1 Comparison between dual channel structures may be performed by:
• use of a comparator (see IEC 60730-1 H.2.18.3), or
• reciprocal comparison (see IEC 60730-1 H.2.18.15).

Programmable electronic circuits requiring software incorporating measures to control the

fault/error conditions specified in Table R.1 shall have one of the following structures:

– single channel with functional test (see IEC 60730-1, H.2.16.5);

– single channel with periodic self-test (see IEC 60730-1, H.2.16.6);
– dual channel without comparison (see IEC 60730-1, H.2.16.1).
NOTE 2 Software structures incorporating measures to control the fault/error conditions specified in Table R.2 are
also acceptable for programmable electronic circuits with functions requiring software measures to control the
fault/error conditions specified in Table R.1.

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
60335-1  IEC:2010+A1:2013 – 153 –

Compliance is checked by the inspections and tests of the software architecture in R.3.2.2.

R.2.2 Measures to control faults/errors

R.2.2.1 When redundant memory with comparison is provided on two areas of the same
component, the data in one area shall be stored in a different format from that in the other
area (see software diversity, IEC 60730-1 H.2.18.19).

Compliance is checked by inspection of the source code.

R.2.2.2 Programmable electronic circuits with functions requiring software incorporating

measures to control the fault/error conditions specified in Table R.2 and that use dual channel
structures with comparison shall have additional fault/error detection means (such as periodic
functional tests, periodic self tests, or independent monitoring) for any fault/errors not
detected by the comparison.

Compliance is checked by inspection of the source code.

R.2.2.3 For programmable electronic circuits with functions requiring software

incorporating measures to control the fault/error conditions specified in Table R.1 or Table R.2 ,
means shall be provided for the recognition and control of errors in transmissions to external
safety-related data paths. Such means shall take into account errors in data, addressing,
transmission timing and sequence of protocol.

Compliance is checked by inspection of the source code.

R.2.2.4 For programmable electronic circuits with functions requiring software

incorporating measures to control the fault/error conditions specified in Table R.1 or Table R.2 ,
the programmable electronic circuits shall incorporate measures to address the fault/errors
in safety-related segments and data indicated in Table R.1 or Table R.2 as appropriate.

Compliance is checked by inspection of the source code.

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
 – 154 – 60335-1  IEC:2010+A1:2013

e
Table R.1 – General fault/error conditions
b, c
Component a Fault/error Acceptable measures Definitions
See
IEC 60730-1
1
Central
processing unit
(CPU)
1.1
Registers Stuck at Functional test, or H.2.16.5
periodic self-test using either: H.2.16.6
– static memory test, or H.2.19.6
– word protection with single bit redundancy H.2.19.8.2

1.2 VOID
1.3
Functional test, or H.2.16.5
Programme Stuck at periodic self-test, or H.2.16.6
counter independent time-slot monitoring, or H.2.18.10.4
logical monitoring of the programme sequence H.2.18.10.2

2
Interrupt No interrupt Functional test, or H.2.16.5
handling and or too time-slot monitoring H.2.18.10.4
execution frequent
interrupt

3
Clock Frequency monitoring, or H.2.18.10.1
time slot monitoring H.2.18.10.4
Wrong
frequency
(for quartz
synchronized
clock:
harmonics/
sub-harmonics
only)
4
Memory
4.1
Invariable All single bit Periodic modified checksum, or H.2.19.3.1
memory faults multiple checksum, or H.2.19.3.2
word protection with single bit redundancy H.2.19.8.2

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
60335-1  IEC:2010+A1:2013 – 155 –

e
Table R.1 (continued)
a b, c
Component Fault/error Acceptable measures Definitions
See
IEC 60730-1
4.2
Variable DC fault Periodic static memory test, or H.2.19.6
memory word protection with single bit redundancy H.2.19.8.2

4.3
Addressing Stuck at Word protection with single bit redundancy H.2.19.8.2
(relevant to including the address
variable and
invariable
memory)

5
Internal data Stuck at Word protection with single bit redundancy H.2.19.8.2
path
5.1 VOID
5.2 Addressing Wrong Word protection with single bit redundancy H.2.19.8.2
address including the address

6
External Hamming Word protection with multi-bit redundancy, or H.2.19.8.1
communication distance 3 CRC – single word , or H.2.19.4.1
transfer redundancy, or H.2.18.2.2
protocol test H.2.18.14
6.1 VOID
6.2 VOID
6.3 Wrong point Time-slot monitoring, or H.2.18.10.4
Timing in time scheduled transmission H.2.18.18
Time-slot and logical monitoring, or H.2.18.10.3
comparison of redundant communication
channels by either:
– reciprocal comparison H.2.18.15
– independent hardware comparator H.2.18.3
Wrong Logical monitoring, or H.2.18.10.2
sequence time-slot monitoring, or H.2.18.10.4
scheduled transmission H.2.18.18

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
 – 156 – 60335-1  IEC:2010+A1:2013

e
Table R.1 (concluded)
a b, c
Component Fault/error Acceptable measures Definitions
See
IEC 60730-1
7
Input/output Fault Plausibility check H.2.18.13
periphery conditions
specified in
19.11.2

7.1 VOID
7.2
Analog I/O
7.2.1 A/D- and Fault Plausibility check H.2.18.13
D/A- convertor conditions
specified
in 19.11.2

7.2.2 Analog Wrong Plausibility check H.2.18.13

multiplexer addressing

8 VOID

9
Custom Any output Periodic self test H.2.16.6
d
chips outside the
e.g. ASIC, static and
GAL, gate dynamic
array functional
specification
NOTE A Stuck-at fault model denotes a fault model representing an open circuit or a non-
varying signal level. A DC fault model denotes a stuck-at fault model incorporating short
circuits between signal lines.
a For fault/error assessment, some components are divided into their sub-functions.
b For each sub-function in the table, the Table R.2 measure will cover the software fault/error.
c Where more than one measure is given for a sub-function, these are alternatives.
d To be divided as necessary by the manufacturer into sub-functions.
e Table R.1 is applied according to the requirements of R.1 to R.2.2.9 inclusive.

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
60335-1  IEC:2010+A1:2013 – 157 –

e
Table R.2 – Specific fault/error conditions

Component a Fault/error Acceptable measures b, c

Definitions
See
IEC 60730-1
1
Central
Processing Unit
(CPU)
1.1 DC fault Comparison of redundant CPUs by either:
Registers – reciprocal comparison H.2.18.15
– independent hardware comparator, or H.2.18.3
internal error detection, or H.2.18.9
redundant memory with comparison, or H.2.19.5
periodic self-tests using either
– walkpat memory test H.2.19.7
– Abraham test H.2.19.1
– transparent GALPAT test; or H.2.19.2.1
word protection with multi-bit redundancy, or H.2.19.8.1
static memory test and H.2.19.6
word protection with single bit redundancy H.2.19.8.2

1.2
Instruction Wrong Comparison of redundant CPUs by either:
decoding and decoding – reciprocal comparison H.2.18.15
execution and execution – independent hardware comparator, or H.2.18.3
internal error detection, or H.2.18.9
periodic self-test using equivalence class test H.2.18.5
1.3 DC fault Periodic self-test and monitoring using either: H.2.16.7
Programme – independent time-slot and logical H.2.18.10.3
counter monitoring
– internal error detection, or H.2.18.9
comparison of redundant functional channels
by either:
– reciprocal comparison H.2.18.15
– independent hardware comparator H.2.18.3
1.4
Addressing DC fault Comparison of redundant CPUs by either:
– reciprocal comparison H.2.18.15
– independent hardware comparator; or H.2.18.3
internal error detection; or H.2.18.9
periodic self-test using
H.2.16.7
– a testing pattern of the address lines; or H.2.18.22
– a full bus redundancy H.2.18.1.1
– a multi bus parity including the address H.2.18.1.2

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
 – 158 – 60335-1  IEC:2010+A1:2013

e
Table R.2 (continued)
a
Component Fault/error Acceptable measures b, c Definitions
See
IEC 60730-1
1.5
Data paths DC fault Comparison of redundant CPUs by either:
instruction and – reciprocal comparison, or H.2.18.15
decoding execution – independent hardware comparator, or H.2.18.3
– internal error detection, or H.2.18.9
– periodic self-test using a testing pattern, or H.2.16.7
– data redundancy, or H.2.18.2.1
– multi-bit bus parity H.2.18.1.2

2 No interrupt Comparison of redundant functional

Interrupt or too channels by either
handling and
frequent – reciprocal comparison, H.2.18.15
execution
interrupt – independent hardware comparator, or H.2.18.3
related to – independent time-slot and logical monitoring H.2.18.10.3
different
sources

3 Wrong Frequency monitoring, or H.2.18.10.1

Clock frequency time-slot monitoring, or H.2.18.10.4
(for quartz comparison of redundant functional channels
synchronized by either:
clock: – reciprocal comparison H.2.18.15
harmonics/ – independent hardware comparator H.2.18.3
subharmonics
only)

4. Memory
4.1 99,6 % Comparison of redundant CPUs by either:
Invariable coverage of – reciprocal comparison H.2.18.15
memory all information – independent hardware comparator, or H.2.18.3
errors redundant memory with comparison, or H.2.19.5
periodic cyclic redundancy check, either
– single word H.2.19.4.1
– double word, or H.2.19.4.2
word protection with multi-bit redundancy H.2.19.8.1
4.2 DC fault Comparison of redundant CPUs by either:
Variable and dynamic – reciprocal comparison H.2.18.15
memory cross links – independent hardware comparator, or H.2.18.3
redundant memory with comparison, or H.2.19.5
periodic self tests using either:
– walkpat memory test H.2.19.7
– Abraham test H.2.19.1
– transparent GALPAT test, or H.2.19.2.1
word protection with multi-bit redundancy H.2.19.8.1

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
60335-1  IEC:2010+A1:2013 – 159 –

e
Table R.2 (continued)
a b, c
Component Fault/error Acceptable measures Definitions
See
IEC 60730-1
4.3 DC fault Comparison of redundant CPUs by either:
Addressing – reciprocal comparison, or H.2.18.15
(relevant to – independent hardware comparator, or H.2.18.3
variable and full bus redundancy H.2.18.1.1
invariable testing pattern, or H.2.18.22
memory) periodic cyclic redundancy check, either:
– single word H.2.19.4.1
– double word, or H.2.19.4.2
word protection with multi-bit redundancy H.2.19.8.1
including the address

5
Internal data
path
5.1 Data DC fault Comparison of redundant CPUs by either
– reciprocal comparison H.2.18.15
– independent hardware comparator, or H.2.18.3
word protection with multi-bit redundancy H.2.19.8.1
including the address, or data redundancy, or H.2.18.2.1
testing pattern, or H.2.18.22
protocol test H.2.18.14
5.2 Addressing Wrong Comparison of redundant CPUs by:
address and – reciprocal comparison H.2.18.15
multiple – independent hardware comparator, or H.2.18.3
addressing word protection with multi-bit redundancy, H.2.19.8.1
including the address, or full bus redundancy; H.2.18.1.1
or testing pattern including the address H.2.18.22

6
External
communication

6.1
Data Hamming CRC – double word, or H.2.19.4.2
distance 4
data redundancy or H.2.18.2.1
comparison of redundant functional channels
by either:
– reciprocal comparison H.2.18.15
– independent hardware comparator H.2.18.3

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
 – 160 – 60335-1  IEC:2010+A1:2013

e
Table R.2 (continued)
a b, c
Component Fault/error Acceptable measures Definitions
See
IEC 60730-1
6.2 Wrong Word protection with multi-bit redundancy, H.2.19.8.1
Addressing address including the address, or CRC single word H.2.19.4.1
including the addresses, or
transfer redundancy or H.2.18.2.2
protocol test H.2.18.14
Wrong and CRC – double word, including the address, or H.2.19.4.2
multiple full bus redundancy of data and address, or H.2.18.1.1
addressing comparison of redundant communication channels by either:
– reciprocal comparison H.2.18.15
– independent hardware comparator H.2.18.3
6.3 Wrong point in Time-slot monitoring, or H.2.18.10.4
Timing time scheduled transmission H.2.18.18

7
Input/output
periphery

7.1 Fault Comparison of redundant CPUs by either:

Digital I/O conditions – reciprocal comparison H.2.18.15
specified in – independent hardware comparator, or H.2.18.3
19.11.2 input comparison, or H.2.18.8
multiple parallel outputs, or H.2.18.11
output verification, or H.2.18.12
testing pattern, or H.2.18.22
code safety H.2.18.2
7.2
Analog I/O

7.2.1 A/D- and Fault

conditions
D/A- convertor
specified Comparison of redundant CPUs by either:
in 19.11.2 – reciprocal comparison H.2.18.15
– independent hardware comparator, or H.2.18.3
input comparison, or H.2.18.8
multiple parallel outputs, or H.2.18.11
output verification, or H.2.18.12
testing pattern H.2.18.22

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
60335-1  IEC:2010+A1:2013 – 161 –

e
Table R.2 (concluded)
a b, c
Component Fault/error Acceptable measures Definitions
See
IEC 60730-1

7.2.2 Analog Wrong Comparison of redundant CPUs by either:

multiplexer addressing H.2.18.15
– reciprocal comparison
H.2.18.3
– independent hardware comparator, or

H.2.18.8
input comparison or
H.2.18.22
testing pattern

8
Monitoring Any output Tested monitoring, or H.2.18.21
outside the
devices and static and redundant monitoring and comparison, or H.2.18.17
comparators dynamic error recognizing means H.2.18.6
functional
specification

9
Custom Any output Periodic self-test and monitoring, or H.2.16.7
d
chips outside the dual channel (diverse) with comparison, or H.2.16.2
e.g. ASIC, static and error recognizing means H.2.18.6
GAL, gate dynamic
array functional
specification
NOTE A DC fault model denotes a stuck-at fault model incorporating short circuits between
signal lines.

a For fault/error assessment, some components are divided into their sub-functions.
b For each sub-function in the table, the software measure will cover the Table R.1 fault/error.
c Where more than one measure is given for a sub-function, these are alternatives.
d To be divided as necessary by the manufacturer into sub-functions.
e Table R.2 is applied according to the requirements of R.1 to R.2.2.9 inclusive, only if
required by a part 2.

R.2.2.5 For programmable electronic circuits with functions requiring software

incorporating measures to control the fault/error conditions specified in Table R.1 or Table R.2 ,
detection of a fault/error shall occur before compliance with Clause 19 is impaired.

Compliance is checked by inspection and testing of the source code.

NOTE The loss of dual channel capability is deemed to be an error in a programmable electronic circuit using a
dual channel structure required for software to control the fault/error conditions specified in Table R.2.

R.2.2.6 The software shall be referenced to relevant parts of the operating sequence and the
associated hardware functions.

Compliance is checked by inspection of the source code.

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
 – 162 – 60335-1  IEC:2010+A1:2013

R.2.2.7 Where labels are used for memory locations, these labels shall be unique.

Compliance is checked by inspection of the source code.

R.2.2.8 The software shall be protected from user alteration of safety-related segments and
data.

Compliance is checked by inspection of the source code.

R.2.2.9 The software and safety-related hardware under its control shall be initialized and
shall terminate before compliance with Clause 19 is impaired.

Compliance is checked by testing of the source code.

R.3 Measures to avoid errors

R.3.1 General

For programmable electronic circuits with functions requiring software incorporating

measures to control the fault/error conditions specified in Table R.1 or Table R.2, the following
measures to avoid systematic faults in the software shall be applied.

Software that incorporates measures used to control the fault/error conditions specified in
Table R.2 is inherently acceptable for software required to control the fault/error conditions
specified in Table R.1 .

NOTE The content of these requirements is extracted from IEC 61508-3 and adapted to the needs of this
Standard.

R.3.2 Specification

R.3.2.1 Software safety requirements

The specification of the software safety requirements shall include:

– a description of each safety related function to be implemented, including its response

time(s):
• functions related to the application including their related software faults required to
be controlled;
• functions related to the detection, annunciation and management of software or
hardware faults;
– a description of interfaces between software and hardware;
– a description of interfaces between any safety and non-safety related functions;
– a description of any compiler used to generate the object code from the source code,
including details of any compiler switch settings used such as library function options,
memory model, optimization, SRAM details, clock rate and chip details;
– a description of any linker used to link the object code to executable library routines.

Compliance is checked by inspection of the documentation and as specified in R.3.2.2.2.

NOTE Examples of some techniques/measures to meet these requirements can be found in Table R.3.

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
60335-1  IEC:2010+A1:2013 – 163 –

Table R.3 – Semi-formal methods

Technique / Measure Informative references

Semi-formal methods
Logical/functional block diagrams
Sequence diagrams
Finite state machines/state transition diagrams IEC 61508-7, B.2.3.2
Decision/truth tables IEC 61508-7, C.6.1

R.3.2.2 Software architecture

R.3.2.2.1 The specification of the software architecture shall include the following aspects:

– techniques and measures to control software faults/errors (refer to R.2.2);

– interactions between hardware and software;
– partitioning into modules and their allocation to the specified safety functions;
– hierarchy and call structure of the modules (control flow);
– interrupt handling;
– data flow and restrictions on data access;
– architecture and storage of data;
– time-based dependencies of sequences and data.

Compliance is checked by inspection of the documentation and as specified in R.3.2.2.2.

NOTE Examples of some techniques/measures to meet these requirements can be found in Table R.4.

Table R.4 – Software architecture specification

Technique / Measure Informative references

Fault detection and diagnosis IEC 61508-7, C.3.1
Semi-formal methods:
• Logic/function block diagrams
• Sequence diagrams
• Finite state machines / state transition diagrams IEC 61508-7, B.2.3.2
• Data flow diagrams IEC 61508-7, C.2.2

R.3.2.2.2 The architecture specification shall be validated against the specification of the
software safety requirements by static analysis.

NOTE Example methods for static analysis are:

• control flow analysis; (IEC 61508-7, C.5.9);
• data flow analysis; (IEC 61508-7, C.5.10);
• walk-throughs/design reviews. (IEC 61508-7, C.5.16).

R.3.2.3 Module design and coding

R.3.2.3.1 Based on the architecture design, software shall be suitably refined into modules.
Software module design and coding shall be implemented in a way that is traceable to the
software architecture and requirements.

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
 – 164 – 60335-1  IEC:2010+A1:2013

Compliance is checked by R.3.2.3.3 and by inspection of the documentation.

NOTE 1 The use of computer aided design tools is accepted.

NOTE 2 Defensive programming (IEC 61508-7, Subclause C.2.5) is recommended (e.g. range checks, check for
division by 0, plausibility checks).

NOTE 3 The module design shall specify:

• function(s),
• interfaces to other modules,
• data.

NOTE 4 Examples of some techniques/measures to meet these requirements can be found in Table R.5.

Table R.5 – Module design specification

Technique / Measure Informative references

Limited size of software modules IEC 61508-7, C.2.9
Information hiding / encapsulation IEC 61508-7, C.2.8
One entry / one exit point in subroutines and functions IEC 61508-7, C.2.9
Fully defined interface IEC 61508-7, C.2.9
Semi-formal methods:
• Logic/function block diagrams
• Sequence diagrams
• Finite state machines / state transition diagrams IEC 61508-7, B.2.3.2
• Data flow diagrams IEC 61508-7, C.2.2

R.3.2.3.2 Software code shall be structured.

Compliance is checked by R.3.2.3.3 and by inspection of the documentation.

NOTE 1 Structural complexity can be minimized by applying the following principles:

• keep the number of possible paths through a software module small, and the relation between the input and
output parameters as simple as possible;
• avoid complicated branching and, in particular, avoid unconditional jumps (GOTO) in higher level languages;
• where possible, relate loop constraints and branching to input parameters;
• avoid using complex calculations as the basis of branching and loop decisions.

NOTE 2 Examples of some techniques/measures to meet these requirements can be found in Table R.6.

Table R.6 – Design and coding standards

Technique / Measure Informative references

Use of coding standard (see NOTE) IEC 61508-7, C.2.6.2
No use of dynamic objects and variables (see NOTE) IEC 61508-7, C.2.6.3
Limited use of interrupts IEC 61508-7, C.2.6.5
Limited use of pointers IEC 61508-7, C.2.6.6
Limited use of recursion IEC 61508-7, C.2.6.7

No unconditional jumps in programs in higher level IEC 61508-7, C.2.6.2

languages
NOTE Dynamic objects and/or variables are allowed if a compiler is used which ensures that sufficient memory
for all dynamic objects and/or variables will be allocated before runtime, or which inserts runtime checks for the
correct online allocation of memory.

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11
60335-1  IEC:2010+A1:2013 – 165 –

R.3.2.3.3 Coded software shall be validated against the module specification by static
analysis. The module specification shall be validated against the architecture specification by
static analysis.

R.3.3.3 Software validation

The software shall be validated with reference to the requirements of the software safety
requirements specification.

NOTE 1 Validation is confirmation by examination and provision of objective evidence that the particular
requirements for a specific intended use are fulfilled. Therefore, for example, software validation means confirming
by examination and provision of objective evidence that the software satisfies the software safety requirements
specification.

Compliance is checked by simulation of

– input signals present during normal operation,

– anticipated occurrences,
– undesired conditions requiring system action.

Test cases, test data and test results shall be reported.

NOTE 2 Examples of some techniques/measures to meet these requirements can be found in Table R.7.

Table R.7 – Software safety validation

Technique / Measure Informative references

Functional and black-box testing: IEC 61508-7, B.5.1, B.5.2
• Boundary value analysis IEC 61508-7, C.5.4
• Process simulation IEC 61508-7, C.5.18
Simulation, modelling:
• Finite state machines IEC 61508-7, B.2.3.2
• Performance modelling IEC 61508-7, C.5.20

NOTE 3 Testing should be the main validation method for software; modelling may be used to supplement the
validation activities.

Customer: Arlindo Corrent - No. of User(s): 1 - Company: PUCRS Biblioteca Central

Order No.: WS-2014-002154 - IMPORTANT: This file is copyright of IEC, Geneva, Switzerland. All rights reserved.
This file is subject to a licence agreement. Enquiries to Email: [email protected] - Tel.: +41 22 919 02 11