Functional Safety for Mine Hoist—From Lilly to SIL3

Hoist Protector®

Anders Taqvist
ABB AB, Västerås, Sweden

INTRODUCTION
A disadvantage for local mine hoist regulation owners, mine hoist inspectors, mine own-
ers, consultants and hoist suppliers are that no International standard for Mine Hoist exists.
An International standard could specify hoist basic requirements, such as an approach for
Functional Safety of the Mine Hoist safety-related control functions.
It could point out a recommended Functional Safety Standard and specify a minimum
safety integrity level for controls and supervisions that monitor the mine hoist against its
most critical hazardous events. These controls and supervisions would then be developed and
designed according to this standard management plan and its required process activities.
This standard would establish a consistent approach to mine hoisting risk assessments
used to determinate safety integrity levels of safety related control functions at mine projects.
Opinions differ as to the SIL requirements for various safety critical functions such as midshaft
overspeed SIL1, some people feel SIL2; end of wind overspeed at a high speed 100 persons
drum hoist without shaft end arrestors, higher than SIL3.
Since no International standard for Mine Hoist exists, this paper reviews the safety man-
agement and technical activities, according a selected Safety of machinery standard, in the
lifecycle perspective from risk assessment to modification phases during development of a
SIL3-capable Hoist protecting system.

HISTORY
The historical development of this type of monitoring equipment goes from electromechan-
ical units as the Lilly Controller; via electronic units and standard-PLCs used together with
basic sensors and actuators; to today’s requirements to use electronic/programmable sys-
tems together with sensors and actuators that all are designed according a Functional Safety
standard.

SELECTION OF APPROPRIATE STANDARD

A Mine Hoist is classified as a machine, covered by the machinery (machine) definition
“assembly, fitted with or intended to be fitted with a drive system consisting of linked parts or
components, at least one of which moves, and which are joined together for a specific applica-
tion” (ISO 12100:2010).
The European Commission (EC) and European Free Trade Association (EFTA) have
established a single market in Europe, a free trade of products and services. For machinery

245
246 HOIST CONTROL BASED ON SIL OR PL STANDARDS

this is facilitated by the Machinery Directive 2006/42/EC, a law that must be fulfilled, it spec-
ifies the lowest technical safety level for Machines. This Machinery Directive includes lifts but
“mine winding gear” is excluded (stated in Article 1.2.i), mine lifts are also excluded from the
building Lift Directive 95/16/EC.
The official Guide to application of the Machinery Directive 2006/42/EC has some com-
ments about the exclusion of “mine winding gear.” It specifies in § 61 “It was considered that
such lifts were specific installations the characteristics of which varied according to the site and
which gave rise to few obstacles to trade” and “It should be noted that this exclusion concerns
installations in the mine shaft” (Reference 2).
Two product and application sector international standards for the machinery sector exist:

77 Safety of machinery—Safety-related parts of control systems, ISO 13849.

This standard is harmonized against the Machinery Directive 2006/42/EC
and covers electrical, hydraulic, pneumatic and mechanical safety-related control
applications.
This is probably the best standard for Functional Safety for Mine Hoists as
braking systems (also it hydraulic part) are very critical in hoisting applications. Its
disadvantage is that it is not so established outside Europe.
77 Safety of machinery—Functional safety of safety-related electronic and programma-
ble electronic control systems, IEC 62061.
This standard is also harmonized against the Machinery Directive 2006/42/EC
but covers only electrical safety-related control applications. But it allows integra-
tion of safety-related subsystems designed in accordance with ISO 13849 (hydraulic,
pneumatic or mechanical safety-related control functions).
This standard’s advantage is that an achieved safety integrity level according this
standard also fulfills the corresponding performance level in ISO 13849.
This standard also states that high demand or continuous mode should be used
for machinery, “Low demand mode of operation is not considered to be relevant for
SRECS applications at machinery” (IEC 62061:2005+A1:2012, 3.2.26).

There are also two other international safety standards that could be used:

77 Functional safety pf electrical/electronic/programmable electronic safety-related

systems, IEC 61508.
“A major objective of this standard is to facilitate the development of product
and application sector international standards by the technical committees respon-
sible for the product or application sector” and “A second objective of this standard
is to enable the development of E/E/PE safety-related systems where product or
application sector or application sector international standards do not exist” (IEC
61508-1:2010).
Two product and application sector international standards for safety of
machinery exist and therefore are applicable to mine hoist applications.
 FUNCTIONAL SAFETY FOR MINE HOIST 247

This standard could also “provide a framework for considering any safety-re-
lated system irrespective of the technology of that system” (hydraulic, pneumatic or
mechanical).
77 Functional safety—Safety instrumented systems for process industry sector, IEC
61511:2003.
This standard is not suitable for general machines as a product and application
sector international standards for Safety of machinery exists.

IEC 62061 Functional safety standard is found applicable for the development and design of
the SIL3-capable Hoist protecting system, as it best suits the application and provides the nec-
essary specific guidance for the designer.
The following sections review the safety management and technical activities according to
IEC 62061:2005+A1:2012 during development of a SIL3 Hoist protecting device.

SAFETY PLANNING
The functional safety plan shall summarize the safety activities in the safety development proj-
ect for IEC 62061 compliance. Together with the verification and validation plan and the con-
figuration/maintenance plan it shall cover all process and quality requirements of IEC 62061.
In essence, the safety plan shall be written with the ambition that the two main goals can
be achieved:

1. Build a sufficiently safe Safety-Related Control System (SRECS) for the mine hoist
machine.
–– What hazards exist?
–– Identify requirements for a safe design.
–– Evaluate the appropriateness of the safety measures.
–– Produce necessary work products for hazard closure.
–– Evaluate planned modifications.
–– Examine accidents and incidents.
2. Prove that it is sufficiently safe.
–– Provide rigorous process arguments.
–– Provide product specific evidence that integrity is sufficient.

The content of the safety plan should depend upon the specific circumstances, which could be:

77 Size of project.
77 Degree of complexity.
77 Degree of novelty of design and technology (new certified components).
77 Degree of standardization of the design (a product with well proven standardized
components and SW function blocks).
77 Possible consequences in the event of failure.

Figure 1 illustrates a Lifecycle V-Model with the essential safety lifecycle activates that have to
be performed during: the concept phase, SRECS and Software design and development pro-
cesses, and during operation.
248 HOIST CONTROL BASED ON SIL OR PL STANDARDS

Figure 1.  Safety lifecycle V-model

The development project shall be governed by an organization with good safety culture,
where safety is the highest priority. Processes provide adequate and independent checks and
balances, intellectual diversity is sought in all processes and that a defined, documented, disci-
plined process is followed at all levels.
Identify persons (departments) and resources that are responsible for carrying out and
reviewing each of the activities specified. The organization selected and used for this type of
project should (for the technical development part) be personnel that worked or is working
daily with mine hoist applications. The personnel with safety-related system design expertise
normally have no experience in the mine hoist application.

CONCEPT PHASE
Safety Concept
First step is to create a documented concept of what shall be developed and designed, to
develop a description of the intended SRECS basic functionality.
This could be to create a SIL3 Hoist Monitor, which supervises the hoist against speed and
position-related hazardous events. Monitor tripping outputs shall be connected into the hoist’s
(ultimate/primary) safety circuit.
This could also include supervisions such as; midshaft overspeed, end of wind overspeed,
overwind, underwind, wrong direction of rotation and stall, broken motor–pulley/drum drive
chain, rope slip (for friction hoist) and slack rope switch (for drum hoist) supervisions.
Alternatively, an extended version of a SIL3 Hoist Monitor called SIL3 Hoist Protector®
which also includes monitoring against all other identified hazardous hoisting events, identi-
fied by the performed preliminary risk assessment. The SIL3 Hoist Protector® could include a
software based (ultimate/primary) safety circuit that directly controls the safety braking sub-
system and the drive torque disconnecting subsystem (Figure 2).
The SIL3 Hoist Protector® could include supervisions such as; emergency stop pushbut-
tons (hoist room, electrical room, in tower and at shaft landings and maintenance locations),
 FUNCTIONAL SAFETY FOR MINE HOIST 249

®
Figure 2.  SIL3 Hoist Monitor and SIL Hoist Protector  Concept

tail rope movement (for friction hoist), and conveyance shaft obstruction from movable shaft
side objects.
Other control interlocks could include hoist start prevention when embarking at shaft
landings by hoist blocking device and shaft gate closed/locked switch, shaft landings gate open
interlock device, and lockable hoist start prevention switches used during hoist mechanical
maintenance (located in tower and at shaft maintenance locations).
The SIL3 Hoist Protector® will be scalable, in terms of, providing supervision and control
functionality for different types of Mine Hoist and type of transport (personnel and material),
Inputs/Outputs channels and used field devices.

Risk Identification and Assessment

The risk reduction strategy is outlined in ISO 12100 and ISO14121 and a number of different
methods for determining safety integrity level requirements are shown in these standards and
in the already mentioned ISO 13849, IEC 62061 and IEC 61508 standards, they are all shown
as informative annex in these standards.
The accident scenarios with hazards, hazardous situations and hazardous events shall be
identified for the mine hoists (friction, drum) all lifecycle phases:

77 During operation
77 Installation, transport and commissioning
77 Maintenance
77 Decommissioning / dismantling

The hazardous events related to hoist machinery or its control system shall be risk assessed.
The preliminary risk assessment is made by a risk graph qualitative method described in
IEC 61508-5 Annex E according Figure E.1 (Figure 3) and Table E.1. This method has been
used extensively within the machinery sector, see ISO 14121-2 and Annex A of ISO 13849-1,
and enables the safety integrity level to be determined from knowledge of risk factors associ-
ated with the hoist machinery and it control system.
Some of the parameters descriptions have been assigned numeric values to fit the mine
hoist application, the risk graph is then per definition calibrated. But the calibration is not
250 HOIST CONTROL BASED ON SIL OR PL STANDARDS

Figure 3.  Risk graph Figure E.1 of IEC 61508-5 Annex E

made against a tolerability risk criteria, as “experience has shown that use of the calibrated risk
graph method can result in high safety integrity levels,” according IEC 61508-5 B.4.
Below is provided a suggested Mine Hoist calibration of Table E.1:

77 CA/C1 = Minor injury, CB/C2 ≤ 1 death, CC/C3 > 1 death, CD/C4 > 10 death
77 FA/F1 ≤ 6 h/day (rare to more often), FB/F2 > 6 h/day (frequent to permanent)
77 PA/P1 = Possible under certain conditions, PB/P2 = almost impossible
77 W1 < 1/10 years (to ≥ 1/100 years), W2 < 1/year (to ≥ 1/10 years), W3 ≥ 1/year
(W-parameter including use of “any other risk reduction measures,” such as
arrestors)

A quantitative approach “is particularly applicable when the risk model is as in indicated in
Figures A.1 and A.2” (both for low demand applications), according IEC 61508-5 D.1.
Table 1, shows a part of the risk assessment outcome, made for the worst case scenario
(more or less continuous hoisting with more than 10 people).

SAFETY REQUIREMENTS SPECIFICATION

The Safety Requirements Specification, SRS, is a specification of all Safety Related Control
Functions, SRCFs, implemented by the Safety-Related Control System, SRECS. The SRECS
could be the SIL3 Hoist Monitor system or the SIL3 Hoist Protector® system.
This SRS is the prime document specification for the SRECS, and would be that the docu-
ment the final validation will be made against after the design and all SW and HW verification
analysis and tests are done.
Each SRCF is specified in the SRS according IEC 62061 Clause 5 requirements, including
a specified integrity level (determined by the preliminary risk assessment or stated in a local
regulation for mine hoist).
The functional requirements specification for each SRCF shall include, as applicable, fol-
lowing information:
 FUNCTIONAL SAFETY FOR MINE HOIST 251

Table 1.  Required SIL-levels for some mine hoist high-risk exposure conditions
Supervision / Control SIL-level
Midshaft overspeed 3
End of wind overspeed 3
Overwind 3
Underwind 3
Wrong direction of rotation and stall 1
Broken motor–pulley/drum drive chain 3
Rope slip (for friction hoist) a
Slack rope switch (for drum hoist) 3
Emergency stop pushbuttons (a complementary protective equipment) 3
Tail rope movement (for friction hoist) a
Conveyance shaft obstruction by movable shaft side objects (at shaft landings) 2
Hoist start prevention when embarking at shaft landings by hoist blocking device (SIL2) 3
and gate closed/locked switch (SIL2)
Shaft landings gate open interlock device 2
Lockable hoist start prevention switches used at hoist mechanical maintenance 2

77 Target Safety Integrity Level (SIL) and it probability of dangerous failure per hour
value
77 Modes of operation of the machine where SRECS is active or disabled
77 Priority against other functions that can be simultaneously active, could cause a
conflict
77 Intended frequency of operation and rate of duty cycles (per hour) of the SRCF
77 Required response time of the SRCF, the processing time (electrical and mechanical)
77 Required response time e.g. on included input and output devices
77 Description of the SRCF
77 Description of fault reaction function(s)
77 Description of operating environment
77 Tests and any associated facilities (test equipment, test access ports)
77 Interface between SRCFs
77 Interface to any other function (commonly used diagnostics, hoist control system,
user interface, SW tuning parameters)
77 Maintenance and testability possibilities
77 Preventive measures to achieve electromagnetic (EM) immunity

The specified requirements in the safety related specification should be “shall requirements” and
marked with a requirement number for easier implementation and to trace these requirements
in the validation test specification. The SRS-document shall not include any proposed design
252 HOIST CONTROL BASED ON SIL OR PL STANDARDS

Figure 4.  SRCF-subsystems, SIL3 Hoist Monitor and SIL3 Hoist Protector  ®
solutions, they will be documented in the later produced HW-design and SW-requirement
documentation.
This specification can be required to be updated during the design process, due to the
interactive design process of the SRECS.

DESIGN AND INTEGRATION OF SRECS

The SRECS shall be hardware designed and developed in accordance with the SRECS safety
requirements specification (SRS).

System Architecture Design

Each specified SRCF shall be decomposed and allocated to an initial structure of function
blocks and each of these function block safety requirements shall be as specified in the SRS
specification.
Each function block shall then be allocated to a subsystem within the structure.
These two allocation steps shall be graphically documented with functional informa-
tion, SIL capability level and definition of inputs and outputs for each functional block and
subsystem.
Figure 4, illustrates two general results of such SRCF allocation via function blocks to
subsystems. First a set of subsystems for a SIL3 Hoist Monitor SRCF. Then a second set of sub-
systems for a corresponding SRCF with the SIL3 Hoist Protector® approach, which includes
safety rating of the overall safety braking system (also the safety solenoid valves and safety
hydraulic controlled valves).
The two allocation steps for the Midshaft Overspeed supervision SRCF1 is graphical
viewed according the principle in IEC 62061 Annex B (Figure 5).

Realization of a Subsystem
In general, subsystem or subsystem element calculations should be based on figures from the
component supplier.
Following information shall be available for each subsystem:

77 Manufacturer data for the selected component(s), the subsystem or it elements.

77 Functional specification of function and interfaces which can be used by the SRCF.
77 Estimated rates of failure, λ = 1 / MTTF or λ = 0.1*C / B10.
 FUNCTIONAL SAFETY FOR MINE HOIST 253

77 Constraints on the subsystem.

–– Environment and operating conditions.
–– Lifetime or proof test interval (T1 or T10d).
77 Test and/or maintenance requirements.
77 Diagnostic functions external to the subsystem.
–– Diagnostic Coverage (DC). According to TR 62061-1:2010 the diagnostic mea-
sure and its DC value can be taken from the simplified approach in ISO 13849-1
Table E.1.
–– Test interval (T2). An analysis of the used diagnostic measure and its behavior in
event of error should be made, especially at SIL3 claim.
77 Additional information (e.g. at design with online repair).
77 SILCL due to architectural constrains.
–– All failure modes, safe–dangerous, for derivation of the Safe Failure Fraction,
–– Hardware fault tolerance N = x.
77 Any limits on the application of the subsystem, to avoid systematic failure.
77 Measures and techniques used to prevent systematic faults being introduced during
design and implementation of the subsystem. In addition also a design review, simu-
lation or analysis measure shall be applied.
77 Design features that make the subsystem tolerant against systematic faults.
77 Information required to identify the HW and SW configuration of the subsystem, in
order to enable the configuration management.
77 Probability of dangerous transmission errors on digital data communication (PTE).

Realization of a Subsystem Element

Some required information could be required both as a subsystem and as a subsystem element,
then only specify at the most suitable place.
Following information shall be available for each subsystem element:

77 Functional specification of the subsystem element.

77 Specification of the interfaces of the subsystem element.
77 Each failure mode and its probability of occurrence or PFHD and DC values at a
complex component.
77 Constraints on the subsystem element.
–– Environment and operating conditions.
–– Lifetime (T1 or T10d).
77 Periodic proof test and/or maintenance requirements.
77 Features that can contribute to diagnostics (e.g., mechanically linked contact
elements).
77 Additional information (e.g., at design with online repair).
77 Any limits on the application of the subsystem element, to avoid systematic failure.
77 Hardware fault tolerance N = x.
254 HOIST CONTROL BASED ON SIL OR PL STANDARDS

Estimation of a Subsystem SFF, SILCL, CCF, and PFHD

For each subsystem without a built-in diagnostic the SFF is estimated. The (FMEA) analysis
determines all relevant faults and corresponding failure modes and show all dangerous failure
ratios. SFF s= (λS + λDD) / λ where λS = λ – λD, λD = λ * “dangerous failures ratio” and λDD = λD
* DC.
The subsystems architectural constraints, SILCL, is determined by use of Table 5 in IEC
62061. The SFF and hardware fault tolerance gives the claimed SIL level in the table, also a
use of two parallel (N=1) connected systems/elements gives a “one step” increase of the single
component SILCL level.
The subsystems determined SILCL level shall be equal or higher than the required SIL
level.
The estimation of contribution of common cause failures (CCF, β) for the subsystems is
made by following the simplified approach in IEC62061 Annex F.
Calculation of subsystems PFHD (Probability of dangerous random hardware Failure per
Hour) value is made by the proposed simplified approach for estimation. Four different sub-
system architectures with five formulas available to use:

77 Basic subsystem A, zero fault tolerance without a diagnostic function

77 Basic subsystem B, single fault tolerance without a diagnostic function
77 Basic subsystem C, zero fault tolerance with a diagnostic function
77 Basic subsystem D, single fault tolerance with a diagnostic function, elements with
same design.
77 Basic subsystem D, single fault tolerance with a diagnostic function, elements with
different design.

When a subsystem is built-up by one or more complex components that already are SIL-
certified to the required level, it’s possible to use these components PFHD values and summing
them up, instead of using above five formulas.
If digital data communication is used between these complex components or against other
subsystem (elements), the calculated PTE value could be included in this summing-up.

SRECS Safety Function SRCF1 PFHD Value

All included subsystems PFHD values are summarized and the sum shall be less than the SRCF
target PFHD value.
The summarized PFHD value for the SRCF1 subsystems configuration shown in Figure 5
is 9.68×10–09 /h which is less than the SIL3 limit, 1×10–7, SRCF1 have fulfilled the specified
target level (Figure 6).

SOFTWARE DESIGN AND DEVELOPMENT

Software Safety Requirements Specification
The specification of the requirements for (application) software safety for each subsystem is
derived from:
 FUNCTIONAL SAFETY FOR MINE HOIST 255

Figure 5.  Allocation from SRCF1 via function blocks to subsystems

Figure 6.  SRCF1 subsystems estimated PFHD values

77 The specified safety requirements of the SRCF in the SRS document.

77 The requirements resulting from the SRECS system architecture design.
77 Any requirements of the functional safety plan.

This software safety requirements specification is the software design prime specification doc-
ument for the SRECS, and would be the document that the software validation will be made
against after the software design and verification analysis and tests are done.
The software safety requirements specification for each (application) software-based sub-
system (in all SRCFs) shall include, as applicable, following information:

77 The logic (i.e., the functionality) of all function blocks assigned to each subsystem.
77 Input and output interfaces assigned for each function block.
256 HOIST CONTROL BASED ON SIL OR PL STANDARDS

77 Format and value ranges of input and output data and their relation to function
blocks.
77 Relevant data to describe any limits of each function block, for example maximum
response time, limit values for plausibility checks.
77 Diagnostic functions of other devices within the SRECS (e.g., sensors and final ele-
ments) to be implemented by that subsystem.
77 Functions that enable the machine to achieve or maintain a safe state.
77 Functions related to the detection, annunciation and handling of faults.
77 Functions related to the periodic testing of SRCF’s on-line and off-line.
77 Functions that prevent unauthorized modification of the SRECS.
77 Interface to non SRCFs.
77 Capacity and response time performance.

Above requirements shall be expressed so that they are testable.

The software based parameterizing (programming tool and HMI-panel settings by SIL
trained users) shall be described in the specification.
The application software developer shall review the information in the specification and
the outcome of the design activities during the software development shall be verified at appro-
priate stages.
Only Limited Variability Languages (LVL) are allowed for the application software
according IEC 62061 and if previously developed software library functions are used in the
design, their suitability in satisfying the specification of requirements for software safety shall
be justified.

Software Safety Architecture

The software architecture design specification shall be based on the software safety require-
ment specification within the constraints of the system architecture of the SRECS and the
subsystems design.
The documentation of this software architecture design phase could be the document the
verification SW Integration Testing will be made against.
The software architecture defines the major components and subsystems of system and
application software, how they are interconnected, and how the required attributes should be
achieved. The software architecture is also affected by the underlying architecture of the sub-
system provided by the supplier.
The (application) software architecture design shall:

77 Provide a comprehensive description of the internal structure and of the operation of

the SRECS and its components.
77 Include the specification of all identified software components, and the descrip-
tion of connection and interactions between identified components (software and
hardware).
77 Include the internal design and architecture of all identified components that are not
black boxes.
 FUNCTIONAL SAFETY FOR MINE HOIST 257

77 Identify the software modules included in the SRECS but not used in any mode of
safety related operation.

Software Safety Module Design

The following information shall be available before start of detailed application software design:

77 The software safety requirement specification

77 The (application) software safety architecture design specification including:
–– Identification of the application logic and fault tolerant functionality
–– A list of input and output data
–– The generic software modules and support tools to be used
–– Procedures
77 The plan for validation of the software safety

Each application software module shall be specified with following information:

77 The design of the module

77 The structural tests to be applied

The design of each major component/subsystem in the application architecture design specifi-
cation shall be refined based on:

77 Functions which are repeatedly used throughout the design

77 Mapping of the input/output information of application software modules
77 Realization of the application functions from the generic software functions and I/O
mapping

The application software shall be produced in a structured way to achieve:

77 Modularity of application functionality and of I/O control data.

77 Testability of safe functionality (including fault tolerance features) and of the internal
structure.
77 The capacity for safe modification through provision of adequate traceability and
explanation of application functions and associated constraints.

Appropriate software and SRECS integration tests shall to be specified to ensure that the appli-
cation program satisfies the specified requirements for application software safety. The follow-
ing shall be considered:

77 Division of application software into manageable integration sets

77 Test cases
77 Types of tests to be performed
77 Test environment, tools, configuration and programs
77 Test criteria on which the completion of the test shall be judged
77 Procedures for corrective action on failure of test
258 HOIST CONTROL BASED ON SIL OR PL STANDARDS

Software Coding
The application software shall:

77 Be readable, understandable and testable

77 Satisfy the relevant design principles
77 Satisfy the relevant requirements specified during safety planning

The application software shall be reviewed to ensure it follows the specified design, the coding
rules and the requirements of safety planning.

VERIFICATION AND TESTING

Application Software Module Testing
Testing that the application software correctly satisfies its test specification is a verification
activity. It is the combination of code review and structural testing that provides that the appli-
cation software module satisfies its associated specification, i.e., it is verified.
The configuration of each input and output shall be checked through review, testing, or
simulation that the I/O data is mapped correct to the application logic.
Each software module shall be checked with a process review, simulation and testing (i.e.,
dynamic analysis and white box testing when the source code is available with test cases from
boundary value analysis) to determine that the intended function is correctly executed and
unintended functions not are executed.
The tests shall:

77 Ensure each branch of any application software modules is exercised

77 Ensure boundary data is exercised
77 Ensure sequences are correctly implemented

The tests of the application software module testing shall be documented.

Application Software Integration Testing

The application software tests shall verify that all of the application software modules and com-
ponents/subsystem interact correctly with each other and with underlying embedded software
to perform their intended function and do not perform unintended functions.
Functional black box testing of the integrated software modules.
The results of the application software integration testing shall be documented. If there
is a failure, the reason for the failure and corrective action shall be included in the test results
documentation. Any change to the software shall be subject to a safety impact analysis.

Application Software Validation Testing

The validation of the SRECS application safety software shall be carried out in accordance with
a prepared plan.
Each SRCF specified in the software safety requirements specification, and all the appli-
cation software based SRECS operation and maintenance procedures shall be validated by test
and/or analysis.
 FUNCTIONAL SAFETY FOR MINE HOIST 259

Following measures shall be applied at the application software validation of SRECS sys-
tematic safety integrity:

77 Functional testing to reveal failures during the specification, software design and
integration phases. Validate the specified functional behavior and performance
criteria (e.g., timing performance) by a black box or grey box test, according ISO
13849-2:2012.
77 Code review (i.e., inspection, walk-trough) of application software can be sufficient,
according ISO 13849-2:2012.

Appropriate documentation of the SRECS application safety software validation testing shall
be produced, which shall state for each SRCF:

77 The version of the safety validation plan being used.

77 The SRCF under test or analysis, with specific references to the requirements speci-
fied during the SRECS application safety software validation planning.
77 Tools and equipment used, along with calibration data.
77 The results of the test.
77 Discrepancies between expected and actual results.

When discrepancies occur, corrective action and re-testing shall be carried out as necessary.

SRECS Integration Testing

The SRECS shall be integrated according to the specified SRECS design. As part of the inte-
gration of all subsystems and subsystem elements into the SRECS, the SRECS shall be tested
according to the specified integration tests. These tests shall verify that all modules interact
correctly to perform their intended function and not perform unintended functions.
The integration of safety-related application software into SRECS shall include tests that
are specified during the design and development phase to ensure the compatibility of the appli-
cation software with hardware and embedded software platform such that the functional and
safety performance requirements are satisfied.
The use of static analysis, dynamic analysis or failure analysis to form all equivalence
classes (black box test data), which can reduce number of test cases. Also the use of structured
design or semi-formal methods or statistical evidence can permit a reduced depth and number
of test cases.
Following tests shall be applied:

77 Functional grey box test where input data adequately characterizes the operation are
applied to the SRECS, the output shall be observed and their response is compared
with that given by the specification.
77 Dynamic tests to verify the dynamic behavior under realistic conditions and reveal
failures to meet the SRECS functional specification.

The results of the integration testing of the SRECS shall be documented. If there is a failure, the
reason for the failure and corrective action shall be included in the test results documentation.
Any change to the integration and testing shall be subject to a safety impact analysis.
260 HOIST CONTROL BASED ON SIL OR PL STANDARDS

SRECS VALIDATION TESTING

The validation of the SRECS shall be carried out in accordance with a prepared plan.
Each SRCF specified in the SRECS safety requirement specification, and all the SRECS
operation and maintenance procedures shall be validated by test and/or analysis.
Following measures shall be applied at the validation of SRECS systematic safety integrity:

77 Functional testing to reveal failures during the specification, design and integration
phases, and to avoid failures during validation of SRECS software and hardware. This
shall include verification (e.g., by inspection or test) to assess whether the SRECS is
protected against adverse environmental influences and shall be based upon the SRS.
77 Interference immunity testing, SRECS should, wherever practicable, be loaded with
a typical application program, and all the peripheral lines are subjected to standard
noise signals. Testing for immunity to EM-interference need not be performed
where adequate immunity of the SRECS for its intended application can be shown by
analysis.
77 Fault insertion testing shall be performed where required SFF ≥ 90%, introduce or
simulate faults in the SRECS hardware.
77 In addition, one or more of following groups of analytical techniques shall be
applied:
–– Static and failure analysis (e.g., FMEA), recommended when assigned to SIL1 or
SIL2.
–– Static, dynamic and failure analysis, recommended when assigned to SIL2 or
SIL3.
–– Simulation and failure analysis, recommended when assigned to SIL1 or SIL2.
77 In addition one or more of following groups of testing techniques shall be applied:
–– Black-box tests of the dynamic behavior under real functional conditions to
reveal failures to meet the SRECS safety functional specification.
–– Fault insertion (injection) testing shall be performed where required SFF < 90 %.
–– “Worst-case” testing shall be performed to assess the extreme (i.e., worst) cases
specified by the application of analytical technique.
–– Use of field experience from different applications as one of the measures to
avoid faults during SRECS validation.

Appropriate documentation of the SRECS safety validation testing shall be produced, which
shall state for each SRCF:

77 The version of the safety validation plan being used and the version of SRECS tested.
77 The SRCF under test or analysis, with specific references to the requirements speci-
fied during the SRECS safety validation planning.
77 Tools and equipment used, along with calibration data.
77 The results of the test.
77 Discrepancies between expected and actual results.

When discrepancies occur, corrective action and re-testing shall be carried out as necessary.
 FUNCTIONAL SAFETY FOR MINE HOIST 261

Table 2.  Example of a test case (step 1) in the SRECS validation test specification
Test Case Hoist Transportation Validation
Test Case ID Name Type Mode Environment Note
Material hoisting Material,
TS-SRCF1.1-1 overspeed limit All Combined Test room
Initial state/preparation
Make sure hoist is synchronized and material hoisting is chosen.
Make sure the hoist is in normal operation mode:
▪ ▪ no monitoring bypassed
▪ ▪ not in Shaft inspection mode or Roping-up mode
▪ ▪ no friction linings worn-out
Hoist is in duty and the conveyance position is in the mid shaft, not in full speed retardation zone.
Step Action Reaction Comments
1 Check that the DO signal “Reduce speed” is not Signal is not
active to the hoist controller. active

3RD PARTY FUNCTIONAL SAFETY ASSESSMENT

Functional Safety Assessment is according to IEC 61508 an “investigation, based on evidence,
to judge the functional safety achieved by one or more E/E/PE safety-related systems and/or
other risk reduction measures.”
In IEC 62061 it’s possible for a SRECS supplier to “self-assess” a Safety Related Electrical
Control System, but when developing a safety system such as SIL3 Hoist Monitor or the SIL3
Hoist Protector® the use of a 3rd party organization to make a Functional Safety Assessment
against IEC 62061: 2005+A1:2012 is recommended. The 3rd party organization should be
involved already when the development project starts, when the safety plan is established.

MODIFICATION AND CONFIGURATION

Modification Procedure
Modification procedures shall be applied when modifying the SRECS during design, integra-
tion and validation.
The modification procedure of the SRECS shall include:

77 Request for modification (requirement specification changed, condition of actual

use, incident/accident experience or modification of the machine or its operation.
77 The reason(s) for the request of modification shall be documented.
77 The effect of the requested modification shall be analyzed to establish the effect on
the functional safety of the SRECS. The impact analysis and the effect on the SRECS
shall be documented.
77 All accepted modifications that have an effect on the SRECS shall initiate a return to
an appropriate design phase for its hardware and/or for its software. All subsequent
phases shall then be carried out in accordance with the procedures specified for
the specific phases. All relevant documents shall be revised, amended and reissued
accordingly.
262 HOIST CONTROL BASED ON SIL OR PL STANDARDS

77 Based on those revised documents, a complete action plan shall be prepared and
documented before carrying out any modification.

Interventions (e.g., adjustment, setting, repairs) on the SRECS made in accordance with the
information for use or maintenance, Safety User Manual, for the SRECS are not considered to
be a modification.

Configuration Management Procedures

The configuration management procedures shall be implemented in accordance whit the func-
tional safety plan taking into account following:

77 A plan of each modification process.

77 A documentation of the decision making process and each SRECS-relevant decision.
77 A chronological documentation (e.g., a logbook) of the change request procedures
(identified hazards, change request description, reason for change request, decision
made, impact analysis, re-verification and revalidation, all documents affected, all
activities carried out and responsible persons).
77 Documentation to permit a subsequent audit.

The procedure for an appropriate change-control-process shall be established with defining a

unique baseline of the version of the SRECS and a definition of all configuration items (e.g.,
specifications, design documents, hardware/software modules, test plans and results, verifica-
tion and validation reports, tools, change control procedures and effect analyses) of a baseline.

DOCUMENTATION
Information on the SRECS shall be provided to enable the user to develop procedures to ensure
that required functional safety of the SRECS is maintained during use and maintenance of the
mine hoist.
The documentation for installation, use and maintenance of the SRECS, Safety User
Manual, shall include:

77 A comprehensive description of the information of the equipment, installation and

mounting.
77 A statement of the intended use of the SRECS and any measures that can be neces-
sary to prevent reasonably foreseeable misuse.
77 Information of the physical environment where appropriate.
77 Overview block diagram(s) where appropriate.
77 Circuit diagram(s).
77 Pre-defined lifetime or proof test interval of subsystems or it elements, and lifetime
of released SW.
77 Description and interconnection diagrams of the interconnection between the
SRECS and the hoist control system.
77 Description of necessary measures to ensure the separation of the SRECS functions
from the hoist control system.
 FUNCTIONAL SAFETY FOR MINE HOIST 263

77 Description of the safeguarding and means to maintain safety where it is necessary to

suspend the SRCF(s).
77 Programming information, where relevant.
77 Description of the maintenance requirements applicable for the SRECS including:
–– Log for recording the maintenance history.
–– Routine actions which need to be carried out to maintain the functional safety of
the SRECS, including routine replacement of components with a pre-defined life.
–– Maintenance procedures to be followed when faults or failure occurs in the
SRECS (procedures for fault diagnostic, repair and conforming correct operation
after repairs).
–– The tool necessary for maintenance and re-commissioning, and the procedures
for maintaining the tools and equipment.
–– A specification for periodic testing, preventive maintenance and corrective
maintenance.

CONCLUSIONS
In conclusion it can be seen that the SIL requirements for the SIL3 Hoist Protector® are met by
adhering to the following guidelines:

77 A hoist is defined as a machine and not a plant in terms of the international

standards.
77 The Design incorporates the complete SIL supervision loop according to the interna-
tional SIL standards, and are defined from sensor–safety PLC–Interface relay/contac-
tor-to safety braking system and driving torque disconnection (actuators).
77 The functional safety process must be documented and controlled in terms of a
defined safety management process.
77 The safety related control function requirements must be specified at the beginning
of the design process.
77 A well-defined design and integration process for the safety related hardware and
control system (incl. software) is required.
77 A Safety User Manual containing information pertaining to the installation, use and
maintenance of the safety-related control system is required.
77 All designs including analysis and testing must be verified and validated by a compe-
tent third party.
77 Procedures for any modification of the safety-related system must be established
during both the development and implementation phases.
77 Mine hoists safety-related control systems must be designed by competent persons
that have worked with or work regularly with mine hoisting applications.

REFERENCES
1. ISO 12100:2010. Safety of machinery—General principles for design—Risk assessment and
risk reduction, a type-A (basic) standard.
264 HOIST CONTROL BASED ON SIL OR PL STANDARDS

2. Guide to application of the Machinery Directive 2006/42/EC, 2nd Edition, June 2010.
3. IEC 62061:2005+A1:2012. Safety of machinery—Functional safety of safety-related elec-
tronic and programmable electronic control systems, a type B (generic safety) standard.
4. IEC 61508-1:2010. Functional safety of electrical/electronic/programmable electronic safety-
related systems—General requirements, a type-B (generic safety) standard.