9.1Validation principles
In this document, the purpose of the validation is to confirm that the SCS complies with the
safety requirements specification given in Clause 5 and the information for use in 10.3.
NOTE 1In this document, the validation is limited to the designed SCS or a part of it supporting the safety functions
required from the risk reduction strategy at the machine level given in ISO 12100. The SCS validation result is
intended to be part of the overall validation of the machine.
NOTE 2 In some cases, the safety validation can only be completed after final installation (for example, when the
application software development is not finalized).
The validation activities consist of collecting and checking the availability of the evidence
demonstrating the completeness of each design activity identified in the safety plan.
The validation to be applied to the SCS includes inspection (e.g. by analysis) and testing of the
SCS to ensure that it achieves the requirements stated in the safety requirements specification (according to Clause 5).
The validation shall demonstrate that the SCS meets the requirements and, in particular, the
following:
) the specified functional requirements of the safety functions provided by that part (see 5.2),
as set out in the design rationale;
b) the requirements of the specified SIL.
Validation shall be carried out by persons who are independent from the design of the SCS.
NOTE 3 “Independent person” does not necessarily mean that a third-party test is required.
The analysis should be started as early as possible in, and in parallel with, the design process.
NOTE 4 Problems can then be corrected early while they are still relatively easy to correct, i.e. during steps “design
and technical realization of the safety function” and “evaluate the SIL”. It can be necessary for some parts of the
analysis to be delayed until the design is well developed.
Figure 15 gives an overview of the validation process: validation consists of applying analysis
(see 9.2) and executing functional tests (see 9.3) under foreseeable conditions in accordance
with the validation plan. The balance between the analysis and testing shall be justified. For
architectures with diagnostic function, the validation of the safety function shall also include
testing under fault conditions to show that the fault reaction will be initiated by the implemented
diagnostic function.
Where appropriate due to the system’s size, complexity or the effects of integrating it with the
control system (of the machinery), special arrangements should be made for
– validation of the subsystem separately before integration, including simulation of the
appropriate input and output signals, and
– validation of the effects of integrating safety-related parts into the remainder of the control
system within the context of its use in the machine.
“Modification of the design” in Figure 15 refers to the design process. If the validation cannot
be successfully completed, changes in the design are necessary. The validation of the SCS
should then be repeated as appropriate. This process should be iterated until the SCS for each
safety function is successfully validated.
9.1.1Validation plan
The validation plan shall identify and describe the requirements for carrying out the validation
process. The validation plan shall also identify the means to be employed to validate the
specified safety functions. It shall set out, where appropriate:
a) the identity of the specification documents,
b) the operational and environmental conditions during testing,
c) the analyses and tests to be applied,
d) the reference to test standards to be applied,
e) the persons or parties responsible for each step in the validation process, and
f) the required equipment.
Subsystems which have previously been validated to the same specification need only
reference to that previous validation
NOTE Information on the level of independence of validation is available in Annex J.
9.1.2 Use of generic fault lists
Validation involves consideration of the behaviour of the SCS for all faults to be considered. A
basis for fault consideration is given in the tables of fault lists of ISO 13849-2:2012, Annexes A
to D, which are based on experience and which contain:
– the components/elements to be included, e.g. conductors/cables,
– the faults to be taken into account, e.g. short circuits between conductors,
– the permitted fault exclusions, taking into account environmental, operating and application
aspects, and
– a remarks section giving the reasons for the fault exclusions.
Only permanent faults are taken into account in the fault lists.
9.1.3 Specific fault lists
If necessary, a specific product-related fault list shall be generated as a reference document
for the validation of the subsystem(s) and/or subsystem element(s).
NOTE The list can be based on the appropriate generic list(s) found in the annexes A to D in ISO 13849-2:2012.
Where the specific product-related fault list is based on the generic list(s), it shall state
a) the faults taken from the generic list(s) to be included,
b) any other relevant faults to be included but not given in the generic list (e.g. common-cause
failures),
c) the faults taken from the generic list(s) which may be excluded on the basis that the criteria
given in the generic list(s) are satisfied (see 7.3.3),
d) and exceptionally any other faults for which the generic list(s) do not permit an exclusion,
but for which justification and rationale for an exclusion is presented (see 7.3.3).
Where this list is not based on the generic list(s), the designer shall give the rationale for fault
exclusions.
9.1.4 Information for validation
The information required for validation will vary with the technology used, the architectural
constraints and SIL to be demonstrated, the design rationale of the system, and the contribution
of the SCS to the reduction of the risk. Documents containing sufficient information from the
following list shall be included as appropriate in the validation to demonstrate that the safety-
related parts perform the specified safety functions to the required SIL and architectural
constraints:
a) specification of the required characteristics of each safety function, especially the required
SIL and architectural constraints;
b) drawings and specifications, e.g. for mechanical, hydraulic and pneumatic parts, printed
circuit boards, assembled boards, internal wiring, enclosure, materials, mounting;
c) block diagram(s) with a functional description of the blocks;
d) circuit diagram(s), including interfaces/connections;
e) functional description of the circuit diagram(s);
f) time sequence diagram(s) for switching components, signals relevant for safety;
g) description of the relevant characteristics of components previously validated;
h) for safety-related parts other than those listed in g), component lists with item designations,
rated values, tolerances, relevant operating stresses, type designation, failure-rate data and
component manufacturer, and any other data relevant to safety;
i) analysis of all relevant faults according to 9.1.2 and 9.1.3, such as those listed in the tables
of ISO 13849-2:2012, Annexes A to D, including the justification of any excluded faults;
j) an analysis of the influence of processed materials;
k) information for use, e.g. installation and operation manual/instruction handbook.
Where software is relevant to the safety function(s), the software documentation shall include
– a specification which is clear and unambiguous and which states the safety integrity the
software is required to achieve,
– evidence that the software is designed to achieve the required SIL (see 9.5.4), and
– details of the verification (in particular test reports) carried out to prove that the required SIL
is achieved.
Information is required on how the SIL and PFH is determined. The documentation of the
quantifiable aspects shall include
– the basic subsystem architecture according to 7.5.2,
– the determination reliability parameters (e.g. MTTF D or λ D of subsystem elements and CCF),
and
– the determination of the architectural constraints.
Information is required for documentation on systematic aspects of the SCS. Information is
required to describe how the combination of several subsystems achieves a SIL in accordance
with the required SIL.
9.1.5 Validation record
Validation by analysis and testing shall be recorded, see also Clause 10. Appropriate
documentation shall state:
• the version of the validation plan being used, and the version of the safety function tested;
• the safety function under test (or analysis), along with the specific reference to the
requirement specified during the validation planning;
• referenced standards;
• tools and equipment used, along with calibration data;
• the results of each test;
• discrepancies between expected and actual results.
9.2 Analysis as part of validation
9.2.1General
Validation of the SCS shall be carried out by analysis. Inputs to the analysis include the
following:
– the safety function(s), their characteristics and the safety integrity specified according to
Clause 5;
– the system structure (e.g. basic subsystem architectures) according to 7.5.2;
– the quantifiable aspects (e.g. MTTF D or λ D , DC and CCF) according to 6.4.2;
– the non-quantifiable, qualitative aspects which affect system behaviour (if applicable,
software aspects);
– deterministic arguments.
NOTE 1A deterministic argument is an argument based on qualitative aspects (e.g. quality of manufacture,
experience of use). This consideration depends on the application, which, together with other factors, can affect the
deterministic arguments.
NOTE 2 Deterministic arguments differ from other evidence in that they show that the required properties of the
system follow logically from a model of the system. Such arguments can be constructed on the basis of simple, well-
understood concepts.
The selection of an analysis technique depends upon the particular object. Two basic
techniques exist, as follows.
a) Top-down (deductive) techniques are suitable for determining the initiating events that can
lead to identified top events, and calculating the probability of top events from the probability
of the initiating events. They can also be used to investigate the consequences of identified
multiple faults.
EXAMPLE Fault tree analysis (FTA, see IEC 61025), event tree analysis (ETA, see IEC 62502).
b) Bottom-up (inductive) techniques are suitable for investigating the consequence of
identified single faults.
EXAMPLE Failure modes and effects analysis (FMEA, see IEC 60812) and failure modes, effects and criticality
analysis (FMECA).
9.2.3 Verification of safety requirements specification (SRS)
The requirements specification for the safety function shall be verified to ensure consistency
and completeness and correctness for its intended use.
Verification may be performed by reviews and inspections of the SCS safety requirements and
design specification(s), in particular to prove that all aspects of
– the intended application requirements and safety needs, and
– the operational and environmental conditions and possible human errors (e.g. misuse) have
been considered.
9.3 Testing as part of validation
9.3.1General
Testing shall be carried out to complete the validation. Validation tests shall be planned and
implemented in a logical manner. In particular:
a) a test plan shall be produced before testing begins that shall include
1) the test specifications;
2) the required outcome of the tests for compliance, and
3) the chronology of the tests;
b) test records shall be produced that include
4) the name of the person carrying out the test;
5) the environmental conditions;
6) the test procedures and equipment used;
7) the date of the test, and
8) the results of the test;
c) the test records shall be compared with the test plan to ensure that the specified functional
and performance targets are achieved.
The test sample shall be operated as near as possible to its final operating configuration.
This testing can be applied manually or automatically, e.g. by computer.
Where applied, validation of the safety functions by testing shall be carried out by applying input
signals, in various combinations, to the SCS. The resultant response at the outputs shall be
compared to the appropriate specified outputs.
It is recommended that the combination of these input signals be applied systematically to the
control system and the machine. An example of this logic is power-on, start-up, operation,
directional changes, restart-up. Where necessary, an expanded range of input data shall be
applied to take into account anomalous or unusual situations, in order to see how the SCS
responds. Such combinations of input data shall take into account foreseeable incorrect
operation(s).
The objectives of the test will determine the environmental condition for that test, which can be
one or another of the following:
– the environmental conditions of intended use;
– the conditions at a particular rating;
– a given range of conditions if drift is expected.
The accuracy of measurements during the validation by testing shall be appropriate for the test
carried out. In general, these measurement accuracies shall be within 5 K for temperature
measurements and 5 % for the following:
a) time measurements;
b) pressure measurements;
c) force measurements;
d) electrical measurements;
e) relative humidity measurements;
f) linear measurements.
Deviations from these measurement accuracies shall be justified.
9.3.3 More stringent requirements
If, according to its accompanying documentation, the requirements for the SCS exceed those
within this document, the more stringent requirements shall apply.
NOTE More stringent requirements can apply if the control system has to withstand particularly adverse service
conditions, e.g. rough handling, humidity effects, hydrolysation, ambient temperature variations, effects of chemical
agents, corrosion, high strength of electromagnetic fields – for example, due to close proximity of transmitters.
9.3.4 Test samples
Test samples shall not be modified during the course of the tests.
Certain tests can permanently change the performance of some components. Where a
permanent change in a component causes the safety-related part to be incapable of meeting
the requirements of further tests, a new sample or samples shall be used for subsequent tests.
Where a particular test is destructive and equivalent results can be obtained by testing part of
SCS in isolation, a sample of that SCS may be used instead of the whole SCS for the purpose
of obtaining the results of the test. This approach shall only be applied where it has been shown
by analysis that testing of a part of SCS is sufficient to demonstrate the safety integrity of the
whole SCS that performs the safety function.
9.4 Validation of the safety function
9.4.1General
The validation of safety functions shall demonstrate that the SCS provides the safety function(s)
in accordance with their specified characteristics.
NOTE 1A loss of the safety function in the absence of a hardware fault is due to a systematic fault, which can be
caused by errors made during the design and integration stages (a misinterpretation of the safety function
characteristics, an error in the logic design, an error in hardware assembly, an error in typing the code of software,
etc.). Some of these systematic faults will be revealed during the design process, while others will be revealed during
the validation process or will remain unnoticed. In addition, it is also possible for an error to be made (e.g. failure to
check a characteristic) during the validation process.
Validation of the specified characteristics of the safety functions shall be achieved by the
application of appropriate measures from the following list:
– functional analysis of schematics, reviews of the software (see 9.5.3);
NOTE 2 Where a machine has complex or a large number of safety functions, an analysis can reduce the
number of functional tests required.
– simulation;
– check of the hardware components installed in the machine and details of the associated
software to confirm their correspondence with the documentation (e.g. manufacture, type,
version);
– functional testing of the safety functions in all required operating modes as defined in the
SRS of the machine, to establish whether they meet the specified characteristics (see
Clause 5). The functional tests shall ensure that all safety-related outputs are realized over
their complete ranges and respond to safety-related input signals in accordance with the
specification. The test cases are normally derived from the specifications but could also
include some cases derived from analysis of the schematics or software;
– extended functional testing to check foreseeable abnormal signals or combinations of
signals from any input source, including power interruption and restoration, and incorrect
operations;
– check usability of the operator–SCS interface.
NOTE 3 Consider for example an HMI for software based parameterization of the safety function. In general,
more information is available in IEC 60204-1or IEC 61310 (all parts).
NOTE 4 Other measures against systematic failures mentioned in 9.5.2 (e.g. diversity, failure detection by
automatic tests) can also contribute in the detection of functional faults.
9.4.2 Analysis and testing
Analysis and testing will require failure analysis using circuit diagrams and, where the failure
analysis does not reach a clear result:
– fault injection tests on the actual circuit and fault initiation on actual components, particularly
in parts of the system where there is doubt regarding the results obtained from failure
analysis (see 9.2); or
– a simulation of control system behaviour in the event of a fault, e.g. by means of hardware
and/or software models.
Fault injection or fault simulation tests can be performed at different levels, e.g. subsystem
element or subsystem level, considering the specific application and test setup.
When validating by testing, the tests shall include, as appropriate,
– fault injection tests into a production sample,
– fault injection tests into a hardware model,
– software simulation of faults, and
– subsystem failure, e.g. power supplies.
The precise instant at which a fault is injected into a system can be critical. The worst-case
effect of a fault injection shall be determined by analysis and by injecting the fault at this
appropriate critical time.
9.5 Validation of the safety integrity of the SCS
9.5.1General
The following steps shall be performed:
– verification for correct evaluation of SIL of the SCS based on subsystems, architecture and
reliability parameters (e.g. DC and MTTF D or λ D );
– verification that the SIL achieved by the SCS satisfies the required SIL in the safety
requirements specification for the machinery: SIL ≥ required SIL.
9.5.2 Validation of subsystem(s)
The safety integrity of each subsystem of the SCS is characterized by its SIL and shall be
validated by confirming (verification) the following:
– the used architecture (see 7.5.2), and
– the PFH (see 7.6), and
– the systematic integrity (see 7.3.2, Software, CCF).
In this context, the validation of MTTF D or λ D , DC and CCF is typically performed by analysis
and visual inspection. The MTTF D or λ D values for components (including B 10 or B 10D , T 10D and
duty cycle values) shall be checked for plausibility. For example, the value given on the
manufacturer’s datasheet is to be compared with Annex A.
NOTE 1A fault exclusion implies infinite MTTF D ; therefore, the component will not contribute to the calculation of
channel MTTF D .
The DC values for components (subsystem elements) and/or logic blocks shall be checked for
plausibility (e.g. against measures in Annex D). The correct implementation (hardware and
software) of checks and diagnostics, including appropriate fault reaction, shall be validated by
testing under typical environmental conditions in use.
The correct implementation of sufficient measures against common-cause failures shall be
validated (e.g. against Annex E). Typical validation measures are static hardware analysis and
functional testing under environmental conditions.
NOTE 2 Generally, for the specification of the MTTF D or λ D values of electronic components, an ambient
temperature of +40 °C is taken as a basis. During validation, it is important to ensure that, for MTTF D or λ D values,
the environmental and functional conditions (in particular temperature) taken as basis are met. Where a device, or
component, is operated significantly above (e.g. more than 15 °C) the specified temperature of +40 °C, it will be
necessary to use MTTF D or λ D values for the increased ambient temperature.
9.5.3 Validation of measures against systematic failures
The validation of measures against systematic failures can typically be provided by:
a) inspections of design documents which confirm the application of
– basic and well-tried safety principles (see ISO 13849-2:2012, Annexes A to D);
– further measures for avoidance of systematic failures, and
– further measures for the control of systematic failures such as hardware diversity,
modification protection or failure assertion programming;
b) failure analysis (e.g. FMEA);
c) fault injection tests/fault initiation;
d) inspection and testing of data communication, e.g. parameterization, installation;
e) checking that a quality management system avoids the causes of systematic failures in the
manufacturing process.
9.5.4 Validation of safety-related software
The validation of software shall include:
– the specified functional behaviour and performance criteria (e.g. timing performance) of the
software when executed on the target hardware,
– verification that the software measures are sufficient for the specified required SIL of the
safety function, and
– measures and activities taken during software development to avoid systematic software
faults.
As a first step, check that there is documentation for the specification and design of the safety-
related software. This documentation shall be reviewed for completeness and absence of
erroneous interpretations, omissions or inconsistencies.
NOTE In the case of small programs, an analysis of the program by means of reviews or walk-through of control
flow, procedures, etc. using the software documentation (control flow chart, source code of modules or blocks, I/O
and variable allocation lists, cross-reference lists) can be sufficient.
In general, software can be considered a “black box” or “grey box” (see Clause 8), and validated
by the black- or grey-box test, respectively.
Depending on the required SIL, the tests should include, as appropriate,
– black-box testing of functional behaviour and performance (e.g. timing performance),
– additional extended test cases based upon limit value analyses, recommended for SIL 2 or
SIL 3,
– I/O tests to ensure that the safety-related input and output signals are used properly, and
– test cases which simulate faults determined analytically beforehand, together with the
expected response, in order to evaluate the adequacy of the software-based measures for
control of failures.
Individual software functions which have already been validated do not need to be validated
again. Where a number of such safety function blocks are combined for a specific project,
however, the resulting total safety function shall be validated.
Software documentation shall be checked to confirm that sufficient measures and activities
have been implemented against systematic software faults in accordance with the simplified V-
model (see Figure 12).
The measures for software implementation and configuration and modification management
according to Clause 8, which depend on the SIL to be attained, shall be examined with regard
to their proper implementation.
Should the safety-related software be subsequently modified, it shall be revalidated on an
appropriate scale.
9.5.5 Validation of combination of subsystems
Where the safety function is implemented by two or more subsystems, validation of the
combination – by analysis and, if necessary, by testing – shall be undertaken to establish that
the combination achieves the safety integrity specified in the design. Existing recorded
validation results of subsystems can be taken into account. The following validation steps shall
be performed:
– inspection of design documents describing the overall safety function(s);
– a check that the overall SIL of the subsystem combination has been correctly evaluated,
based on the SIL of each individual subsystem (according to 6.4.2);
– consideration of the characteristics of the interfaces, e.g. voltage, current, pressure, data
format of information, signal level;
– failure analysis relating to combination/integration, e.g. by FMEA;
– for redundant systems, fault injection tests relating to combination/integration.