IEC 61511 (2003)

Alternating current/direct current

As low as reasonably practicable

American National Standards Institute

Basic process control system

Diagnostic coverage

Electrical/electronic/programmable electronic

Electrical/electronic/programmable electronic system

Electro-magnetic compatibility

Factory acceptance testing

Fixed program language

Fault tree analysis

Full variability language

Hardware fault tolerance

Human machine interface

Hazard and risk assessment

Human reliability analysis

Hardware

 International Electrotechnical Commission

International Electrotechnical Vocabulary

Instrumentation, Systems and Automation Society

International Organization for Standardization

Limited variability language

“M” out of “N” (see 3.2.45)

Non-programmable

Programmable electronics

Programmable electronic system

Probability of failure on demand

Average probability of failure on demand

Programmable logic controller

Site acceptance test

Safe failure fraction

Safety instrumented function

Safety integrity level

Safety instrumented system

Safety requirement specification

Software

arrangement of hardware and/or software elements in a system, for example

(1) arrangement of safety instrumented system (SIS) subsystems;

(2) internal structure of an SIS subsystem;

(3) arrangement of software programs

NOTE This term differs from the definition in IEC 61508-4 to reflect differences in the process sector terminology.

function allocated to system design for the purpose of preventing loss to assets

system which responds to input signals from the process, its associated equipment, other
programmable systems and/or an operator and generates output signals causing the process
and its associated equipment to operate in the desired manner but which does not perform
any safety instrumented functions with a claimed SIL ? 1
NOTE See Clause A.2.

element or group of elements that independently perform(s) a function
NOTE 1 The elements within a channel could include input/output (I/O) modules, logic systems (see 3.2.40),
sensors, final elements.
NOTE 2 A dual channel (i.e., a two-channel) configuration is one with two channels that independently perform
the same function.
NOTE 3 The term can be used to describe a complete system or a portion of a system (for example, sensors or
final elements).

see “programming”

failure, which is the result of one or more events, causing failures of two or more separate
channels in a multiple channel system, leading to system failure

failure of two or more channels in the same way, causing the same erroneous result

one of the parts of a system, subsystem, or device performing a specific function

see “architecture”

dangerous failure
failure which has the potential to put the safety instrumented system in a hazardous or failto-
function state
NOTE Whether or not the potential is realized may depend on the channel architecture of the system; in systems
with multiple channels to improve safety, a dangerous hardware failure is less likely to lead to the overall
hazardous or fail-to-function state.

failure whose probability cannot be expressed as the simple product of the unconditional probabilities of the individual events which caused it

NOTE 1 Two events A and B are dependent, where P(z) is the probability of event z, only if P(A and B) > P(A) × P(B).

NOTE 2 See 9.5 as an example of dependent failure consideration between layers of protection.

NOTE 3 Dependent failure includes common cause (see 3.2.6).

revealed overt in relation to hardware failures and software faults, detected by the diagnostic tests or through
normal operation

functional unit of hardware or software, or both, capable of accomplishing a specified purpose
(for example, field devices; equipment connected to the field side of the SIS I/O terminals;
such equipment includes field wiring, sensors, final elements, logic solvers, and those
operator interface devices hard-wired to SIS I/O terminals)

ratio of the detected failure rate to the total failure rate of the component or subsystem as
detected by diagnostic tests. Diagnostic coverage does not include any faults detected by
proof tests.
 

NOTE 1 The diagnostic coverage is used to compute the detected (?detected) and undetected failure rates (?undected)
from the total failure rate (?total f ai l ure rate) as follows: ?detected = DC × ?tot al f ailure rat e and ?undected = (1-DC) × ?total failure rate .

NOTE 2 Diagnostic coverage is applied to components or subsystems of a safety instrumented system. For
example, the diagnostic coverage is typically determined for a sensor, final element or a logic solver.

NOTE 3 For safety applications the diagnostic coverage is typically applied to the safe and dangerous failures of a component or subsystem. For example, the diagnostic coverage for the dangerous failures of a component
or subsystem is DC = ?DD/?DT , where ?DD is the dangerous detected failure rate and ?DT is the total dangerous failure rate.

existence of different means performing a required function

NOTE Diversity may be achieved by different physical methods or different design approaches.

based on electrical (E) and/or electronic (E) and/or programmable electronic (PE) technology

NOTE The term is intended to cover any and all devices or systems operating on electrical principles and would include                                          - electro-mechanical devices (electrical);
- solid-state non-programmable electronic devices (electronic);
- electronic devices based on computer technology (programmable electronic) (see 3.2.55).

discrepancy between a computed, observed or measured value or condition and the true,
specified or theoretically correct value or condition

NOTE Adapted from IEV 191-05-24 by excluding the notes.
3.2.19 external risk reduction facilities measures to reduce or mitigate the risks, which are separate and distinct from the SIS

NOTE 1 Examples include a drain system, fire wall, bund (dike).

NOTE 2 This term deviates from the definition in IEC 61508-4 to reflect differences in the process sector
terminology.

termination of the ability of a functional unit to perform a required function

NOTE 1 This definition (excluding these notes) matches ISO/IEC 2382-14-01-09:1997.

NOTE 2 For further information, see IEC 61508-4.

NOTE 3 Performance of required functions necessarily excludes certain behaviour, and some functions may be
specified in terms of behaviour to be avoided. The occurrence of such behaviour is a failure.
NOTE 4 Failures are either random or systematic (see 3.2.62 and 3.2.85).

abnormal condition that may cause a reduction in, or loss of, the capability of a functional unit
to perform a required function

NOTE IEV 191-05-01 defines “fault” as a state characterized by the inability to perform a required function, excluding the inability during preventive maintenance or other planned actions, or due to lack of external resources. [ISO/IEC 2382-14-01-09]

use of techniques and procedures which aim to avoid the introduction of faults during any phase of the safety life cycle of the safety instrumented system

ability of a functional unit to continue to perform a required function in the presence of faults or errors

NOTE The definition in IEV 191-15-05 refers only to sub-item faults. See the note for the term fault in 3.2.21. [ISO/IEC 2382-14-04-06]

part of a safety instrumented system which implements the physical action necessary to
achieve a safe state

NOTE Examples are valves, switch gear, motors including their auxiliary elements, for example, a solenoid valve and actuator if involved in the safety instrumented function.

part of the overall safety relating to the process and the BPCS which depends on the correct functioning of the SIS and other protection layers

NOTE This term deviates from the definition in IEC 61508-4 to reflect differences in process sector terminology.

investigation, based on evidence, to judge the functional safety achieved by one or more protection layers

NOTE This term deviates from the definition in IEC 61508-4 to reflect differences in process sector terminology.

systematic and independent examination to determine whether the procedures specific to the
functional safety requirements comply with the planned arrangements, are implemented
effectively and are suitable to achieve the specified objectives

NOTE A functional safety audit may be carried out as part of a functional safety assessment.

entity of hardware or software, or both, capable of accomplishing a specified purpose

NOTE 1 In IEV 191-01-01 the more general term “item” is used in place of functional unit. An item may sometimes include people.

NOTE 2 This is the definition given in ISO/IEC 2382-14-01-01.

part of the safety integrity of the safety instrumented function relating to random hardware failures in a dangerous mode of failure

NOTE 1 The term relates to failures in a dangerous mode. That is, those failures of a safety instrumented function that would impair its safety integrity. The two parameters that are relevant in this context are the overall dangerous failure rate and the probability of failure to operate on demand.

NOTE 2 See 3.2.86.

NOTE 3 This term deviates from the definition in IEC 61508-4 to reflect differences in process sector terminology.

physical injury or damage to the health of people, either directly or indirectly, as a result of damage to property or to the environment

NOTE This definition matches ISO/IEC Guide 51.

potential source of harm

NOTE 1 This definition (without notes) matches 3.4 of ISO/IEC Guide 51.

NOTE 2 The term includes danger to persons arising within a short time scale (for example, fire and explosion) and also those that have a long-term effect on a person's health (for example, release of a toxic substance).

mistake
human action or inaction that produces an unintended result

NOTE This is the definition found in ISO/IEC 2382-14-02-03 and differs from that given in IEV 191-05-25 by the addition of “or inaction”.

activity of determining the effect that a change to a function or component will have to other
functions or components in that system as well as to other systems

department which is separate and distinct from the departments responsible for the activities
which take place during the specific phase of the safety life cycle that is subject to the
functional safety assessment or validation

organization which is separate and distinct, by management and other resources, from the
organizations responsible for the activities which take place during the specific phase of the
safety life cycle that is subject to the functional safety assessment or validation

person who is separate and distinct from the activities which take place during the specific
phase of the safety life cycle that is subject to the functional safety assessment or validation
and does not have direct responsibility for those activities

function which monitors the process and its associated equipment in order to provide input
information for the logic solver

NOTE An input function could be a manual function.

function which performs the transformations between input information (provided by one or
more input functions) and output information (used by one or more output functions); logic
functions provide the transformation from one or more input functions to one or more output
functions

NOTE For further guidance, see IEC 61131-3 and IEC 60617-12.
61511-1 ? IEC:2003(E) – 21 –

that portion of either a BPCS or SIS that performs one or more logic function(s)

NOTE 1 In IEC 61511 the following terms for logic systems are used:
- electrical logic systems for electro-mechanical technology;
- electronic logic systems for electronic technology;
- PE logic system for programmable electronic systems.

NOTE 2 Examples are: electrical systems, electronic systems, programmable electronic systems, pneumatic
systems, hydraulic systems. Sensors and final elements are not part of the logic solver.

general purpose industrial grade PE logic solver which is specifically configured for use in
safety applications in accordance with 11.5

maintenance/engineering interface is that hardware and software provided to allow proper SIS
maintenance or modification. It can include instructions and diagnostics which may be found
in software, programming terminals with appropriate communication protocols, diagnostic
tools, indicators, bypass devices, test devices, and calibration devices

action that reduces the consequence(s) of a hazardous event

NOTE Examples include emergency depressurization on detection of confirmed fire or gas leak.

way in which a safety instrumented function operates

where a specified action (for example, closing of a valve) is taken in response to process
conditions or other demands. In the event of a dangerous failure of the safety instrumented
function a potential hazard only occurs in the event of a failure in the process or the BPCS

where in the event of a dangerous failure of the safety instrumented function a potential
hazard will occur without further failure unless action is taken to prevent it

NOTE 1 Continuous mode covers those safety instrumented functions which implement continuous control tomaintain functional safety.

NOTE 2 In demand mode applications where the demand rate is more frequent than once per year, the hazardrate will not be higher than the dangerous failure rate of the safety instrumented function. In such a case, it willnormally be appropriate to use the continuous mode criteria.

NOTE 3 The target failure measures for safety instrumented functions operating in demand mode and continuous mode are defined in Tables 3 and 4.

NOTE 4 This term deviates from the definition in IEC 61508-4 to reflect differences in process sector terminology.
– 22 – 61511-1 ? IEC:2003(E)

self-contained assembly of hardware components that performs a specific hardware function
(i.e., digital input module, analogue output module), or reusable application program (can be
internal to a program or a set of programs) that support a specific function, for example,
portion of a computer program that carries out a specific function

NOTE 1 In the context of IEC 61131-3, a software module is a function or function block.

NOTE 2 This term deviates from the definition in IEC 61508-4 to reflect differences in the process sector.

safety instrumented system, or part thereof, made up of “N” independent channels, which are
so connected, that “M” channels are sufficient to perform the safety instrumented function

risk reduction required to ensure that the risk is reduced to a tolerable level

means by which information is communicated between a human operator(s) and the SIS (for
example, CRTs, indicating lights, push-buttons, horns, alarms); the operator interface is
sometimes referred to as the human-machine interface (HMI)

safety related systems that are based on a technology other than electrical, electronic, or
programmable electronic

NOTE A relief valve is “another technology safety related system”. “Other technology safety related systems” may
include hydraulic and pneumatic systems.

function which controls the process and its associated equipment according to final actuator
information from the logic function

period within the safety life cycle where activities described in this standard take place

action that reduces the frequency of occurrence of a hazardous event

see “proven-in-use”
61511-1 ? IEC:2003(E) – 23 –

risk arising from the process conditions caused by abnormal events (including BPCS malfunction)

NOTE 1 The risk in this context is that associated with the specific hazardous event in which SIS are to be used to provide the necessary risk reduction (i.e., the risk associated with functional safety).

NOTE 2 Process risk analysis is described in IEC 61511-3. The main purpose of determining the process risk is to establish a reference point for the risk without taking into account the protection layers.

NOTE 3 Assessment of this risk should include associated human factor issues.

NOTE 4 This term equates to “EUC risk” in IEC 61508-4.

electronic component or device forming part of a PES and based on computer technology.
The term encompasses both hardware and software and input and output units
NOTE 1 This term covers micro-electronic devices based on one or more central processing units (CPU) togetherwith associated memories.

Examples of process sector programmable electronics include
- smart sensors and final elements;
- programmable electronic logic solvers including
- programmable controllers;
- programmable logic controllers.
- loop controllers.

NOTE 2 This term differs from the definition in IEC 61508-4 to reflect differences in process sector terminology.

system for control, protection or monitoring based on one or more programmable electronicdevices, including all elements of the system such as power supplies, sensors and other inputdevices, data highways and other communication paths, actuators and other output devices

process of designing, writing and testing a set of instructions for solving a problem or
processing data

NOTE In this standard, programming is typically associated with PE.

test performed to reveal undetected faults in a safety instrumented system so that, if
necessary, the system can be restored to its designed functionality

any independent mechanism that reduces risk by control, prevention or mitigation

NOTE It could be a process engineering mechanism such as the size of vessels containing hazardous chemicals,a mechanical engineering mechanism such as a relief valve, a safety instrumented system or an administrativeprocedure such as an emergency plan against an imminent hazard. These responses may be automated or initiated by human actions.

when a documented assessment has shown that there is appropriate evidence, based on the
previous use of the component, that the component is suitable for use in a safety
instrumented system.

NOTE This term deviates from IEC 61508 to reflect differences in process sector technology.

totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs

NOTE See ISO 9000 for more details.

failure, occurring at a random time, which results from a variety of degradation mechanisms in
the hardware

NOTE 1 There are many degradation mechanisms occurring at different rates in different components and since manufacturing tolerances cause components to fail due to these mechanisms after different times in operation, failures of a total equipment comprising many components occur at predictable rates but at unpredictable (i.e.,random) times.

NOTE 2 A major distinguishing feature between random hardware failures and systematic failures is
that system failure rates (or other appropriate measures), arising from random hardware failures, can be predictedbut systematic failures, by their very nature, cannot be predicted. That is, system failure rates arising from random hardware failures can be quantified but those arising from systematic failures cannot be statistically quantified because the events leading to them cannot easily be predicted.

use of multiple elements or systems to perform the same function; redundancy can be
implemented by identical elements (identical redundancy) or by diverse elements (diverse
redundancy)

NOTE 1 Examples are the use of duplicate functional components and the addition of parity bits.

NOTE 2 Redundancy is used primarily to improve reliability or availability.

NOTE 3 The definition in IEV 191-15-01 is less complete [ISO/IEC 2382-14-01-11].

NOTE 4 This term deviates from the definition in IEC 61508-4 to reflect differences in process sector terminology.

combination of the frequency of occurrence of harm and the severity of that harm

NOTE For more discussion on this concept, see Clause 8.
61511-1 ? IEC:2003(E) – 25 –

failure which does not have the potential to put the safety instrumented system in a hazardous
or fail-to-function state

NOTE 1 Whether or not the potential is realized may depend on the channel architecture of the system.

NOTE 2 Other names used for safe failure are nuisance failure, spurious trip failure, false trip failure or failto- safe failure.

fraction of the overall random hardware failure rate of a device that results in either a safe
failure or a detected dangerous failure

state of the process when safety is achieved

NOTE 1 In going from a potentially hazardous condition to the final safe state, the process may have to gothrough a number of intermediate safe-states.

For some situations, a safe state exists only so long as the process
is continuously controlled.

Such continuous control may be for a short or an indefinite period of time.

NOTE 2 This term deviates from the definition in IEC 61508-4 to reflect differences in process sector terminology.

freedom from unacceptable risk

NOTE This definition is according to ISO/IEC Guide 51.

function to be implemented by an SIS, other technology safety related system or external risk,
reduction facilities, which is intended to achieve or maintain a safe state for the process, with
respect to a specific hazardous event

NOTE This term deviates from the definition in IEC 61508-4 to reflect differences in process sector terminology.

safety instrumented function with a specified SIL operating in continuous mode which is
necessary to prevent a hazardous condition from arising and/or to mitigate its consequences

instrumented system used to implement one or more safety instrumented control functions

NOTE Safety instrumented control systems are rare within the process industries. Where such systems are
identified, they will need to be treated as a special case and designed on an individual basis.

The requirements
within this standard should apply but further detailed analysis may be required to demonstrate that the system is
capable of achieving the safety requirements.

safety function with a specified safety integrity level which is necessary to achieve functional
safety and which can be either a safety instrumented protection function or a safety
instrumented control function

average probability of a safety instrumented system satisfactorily performing the required
safety instrumented functions under all the stated conditions within a stated period of time

NOTE 1 The higher the safety integrity level, the higher the probability that the required safety instrumentedfunction (SIF) will be carried out.

NOTE 2 There are four levels of safety integrity for safety instrumented functions.

NOTE 3 In determining safety integrity, all causes of failures (both random hardware failures and systematicfailures) which lead to an unsafe state should be included; for example, hardware failures, software inducedfailures and failures due to electrical interference. Some of these types of failure, in particular random hardwarefailures, may be quantified using such measures as the failure rate in the dangerous mode of failure or the probability of a safety instrumented function failing to operate on demand. However, the safety integrity of an SIF also depends on many factors, which cannot be accurately quantified but can only be considered qualitatively.

NOTE 4 Safety integrity comprises hardware safety integrity and systematic safety integrity.

discrete level (one out of four) for specifying the safety integrity requirements of the safety
instrumented functions to be allocated to the safety instrumented systems. Safety integrity
level 4 has the highest level of safety integrity; safety integrity level 1 has the lowest

NOTE 1 The target failure measures for the safety integrity levels are specified in Tables 3 and 4.

NOTE 2 It is possible to use several lower safety integrity level systems to satisfy the need for a higher levelfunction (for example, using a SIL 2 and a SIL 1 system together to satisfy the need for a SIL 3 function).

NOTE 3 This term differs from the definition in IEC 61508-4 to reflect differences in process sector terminology.

specification that contains the safety integrity requirements of the safety instrumented
functions that have to be performed by the safety instrumented system(s)

NOTE 1 This specification is one part (the safety integrity part) of the safety requirements specification.

NOTE 2 This term deviates from the definition in IEC 61508-4 to reflect differences in process sector terminology.

necessary activities involved in the implementation of safety instrumented function(s)
occurring during a period of time that starts at the concept phase of a project and finishes when all of the safety instrumented functions are no longer available for use

NOTE 1 The term ?functional safety life cycle? is strictly more accurate, but the adjective ?functional? is not considered necessary in this case within the context of this standard.

manual which defines how the device, subsystem or system can be safely applied

NOTE This could be a stand-alone document, an instructional manual, a programming manual, a standard document, or included in the user document(s) defining application limitations.

specification that contains all the requirements of the safety instrumented functions that have
to be performed by the safety instrumented systems

software in a safety instrumented system with application, embedded or utility software
functionality

device or combination of devices, which measure the process condition (for example,
transmitters, transducers, process switches, position switches)

intellectual creation comprising the programs, procedures, data, rules and any associated documentation pertaining to the operation of a data processing system

NOTE 1 Software is independent of the medium on which it is recorded.

NOTE 2 This definition without note 1 differs from ISO 2382-1, and the full definition differs from ISO 9000-3 by the addition of the word data.

in this type of language, the user is limited to adjustment of a few parameters (for example,
range of the pressure transmitter, alarm levels, network addresses).

NOTE Typical examples of devices with FPL are: smart sensor (for example, pressure transmitter), smart valve, sequence of events controller, dedicated smart alarm box, small data logging systems.

this type of language is designed to be comprehensible to process sector users, and provides
the capability to combine predefined, application specific, library functions to implement the
safety requirements specifications. An LVL provides a close functional correspondence with
the functions required to achieve the application.

NOTE 1 Typical examples of LVL are given in IEC 61131-3. They include ladder diagram, function block diagram and sequential function chart.

NOTE 2 Typical example of systems using LVL: standard PLC (for example, programmable logic controller for burner management).

this type of language is designed to be comprehensible to computer programmers and
provides the capability to implement a wide variety of functions and applications

NOTE 1 Typical example of systems using FVL are general purpose computers.

NOTE 2 In the process sector, FVL is found in embedded software and rarely in application software.

NOTE 3 FVL examples include: Ada, C, Pascal, Instruction List, assembler languages, C++, Java, SQL. ? 28 ? 61511-1 ? IEC:2003(E)

software specific to the user application. In general, it contains logic sequences, permissives,
limits and expressions that control the appropriate input, output, calculations, decisions
necessary to meet the safety instrumented functional requirements. See fixed and limited
variability language

software that is part of the system supplied by the manufacturer and is not accessible for
modification by the end-user. Embedded software is also referred to as firmware or system
software.

software tools for the creation, modification, and documentation of application programs.
These software tools are not required for the operation of the SIS

activities occurring during a period of time that starts when software is conceived and ends
when the software is permanently disused

NOTE 1 A software life cycle typically includes a requirements phase, development phase, test phase, integration phase, installation phase and modification phase.

NOTE 2 Software cannot be maintained; rather, it is modified.

see ?system?

set of elements, which interact according to a design; an element of a system can be another
system, called a subsystem, which may be a controlling system or a controlled system and
may include hardware, software and human interaction

NOTE 1 A person can be part of a system.

NOTE 2 This definition differs from IEV 351-01-01.

NOTE 3 A system includes the sensors, the logic solvers, final elements, communication and ancillary equipment
belonging to SIS (for example, cables, tubing, power supply).

failure related in a deterministic way to a certain cause, which can only be eliminated by a
modification of the design or of the manufacturing process, operational procedures,
documentation or other relevant factors

NOTE 1 Corrective maintenance without modification would usually not eliminate the failure cause.

NOTE 2 A systematic failure can be induced by simulating the failure cause.

NOTE 3 This definition (up to note 2) matches IEV 191-04-19.

NOTE 4 Examples of systematic failure causes including human error in
- the safety requirements specification;
- the design, manufacture, installation and operation of the hardware;
- the design and/or implementation of the software.
61511-1 ? IEC:2003(E) ? 29 ?

that part of the safety integrity of safety instrumented function relating to systematic failures in a dangerous mode of failure

NOTE 1 Systematic safety integrity cannot usually be quantified (as distinct from hardware safety integrity).

instrumented system used to implement one or more safety instrumented functions. An SIS is
composed of any combination of sensor (s), logic solver (s), and final elements(s)

NOTE 1 This can include either safety instrumented control functions or safety instrumented protection functions or both. ? 26 ? 61511-1 ? IEC:2003(E)

NOTE 2 Manufacturers and suppliers of SIS devices should refer to Clause 1 a) through d) inclusive.

NOTE 3 A SIS may or may not include software.

NOTE 4 See Clause A.2.

NOTE 5 When a human action is a part of an SIS, the availability and reliability of the operator action must be specified in the SRS and included in the performance calculations for the SIS. See IEC 61511-2 for guidance on how to include operator availability and reliability in SIL calculations.

intended probability of dangerous mode failures to be achieved in respect of the safety
integrity requirements, specified in terms of either the average probability of failure to perform
the design function on demand (for a demand mode of operation) or the frequency of a
dangerous failure to perform the SIF per hour (for a continuous mode of operation)

NOTE The numerical values for the target failure measures are given in Tables 3 and 4.

software template
structured non-specific piece of application software that can be easily altered to support
specific functions while retaining the original structure; for example, an interactive screen
template controls the process flow of the application screens, but is not specific to the data
being presented; a programmer may take the generic template and make function-specific
revisions to produce a new screen for the users

NOTE The related term ?software template? is sometimes used. Typically, it refers to an algorithm or collection of algorithms that have been programmed to perform a desired function or set of functions and is constructed so it can be used in many different instances. In the context of IEC 61131-3, it is a program that can be selected for use in many applications.

risk which is accepted in a given context based on the current values of society
NOTE See IEC 61511-3.
[ISO/IEC Guide 51]

unrevealed covert in relation to hardware and software faults not found by the diagnostic tests or during normal operation

NOTE This term deviates from the definition in IEC 61508-4 to reflect differences in process sector terminology.

activity of demonstrating that the safety instrumented function(s) and safety instrumented
system(s) under consideration after installation meets in all respects the safety requirements
specification

activity of demonstrating for each phase of the relevant safety life cycle by analysis and/or
tests, that, for specific inputs, the outputs meet in all respects the objectives and requirements set for the specific phase

NOTE Example verification activities include
- reviews on outputs (documents from all phases of the safety life cycle) to ensure compliance with the objectives and requirements of the phase taking into account the specific inputs to that phase;
- design reviews;
? 30 ? 61511-1 ? IEC:2003(E)
- tests performed on the designed products to ensure that they perform according to their specification;
- integration tests performed where different parts of a system are put together in a step-by-step manner and by the performance of environmental tests to ensure that all the parts work together in the specified manner.

combination of diagnostics and an output device (typically a switch) for monitoring the correct
operation of the programmable electronic (PE) device and taking action upon detection of an incorrect operation

NOTE 1 The watchdog confirms that the software system is operating correctly by the regular resetting of an external device (for example, hardware electronic watchdog timer) by an output device controlled by the software.

NOTE 2 The watchdog can be used to de-energize a group of safety outputs when dangerous failures are detected in order to put the process into a safe state. The watchdog is used to increase the on-line diagnostic coverage of the PE logic solver