Background Image
Previous Page  19 / 40 Next Page
Information
Show Menu
Previous Page 19 / 40 Next Page
Page Background

17

Chemical Technology • March 2015

dangerous failure of a component (not the entire subsys-

tem) within the service life of that component.

3. Diagnosticcoverage(DC)

The level of safety can be increased

if fault detection is implemented in the subsystem. The

diagnostic coverage (DC) is a measure of capability of

detecting dangerous faults.

4. Common cause failure (CCF)

External influencing factors

(eg, voltage level, over-temperature) can render identical

components unusable regardless of how rarely they fail or

how well they are tested. These common cause failures

must always be prevented.

5. Process

The process for the correct implementation of

safety-relevant topics is a management task and includes

appropriate quality management, including thorough test-

ing and counter-checking, as well as version and change

history documentation.

Achieving functional safety

Through the combination of the considerations above, the

PL achieved can be probabilistically determined to be a spe-

cific level. The combination of component selection (MTTFd),

diagnostic coverage (DC), and circuit architecture (Category)

combine together to achieve various PL outcomes, with con-

sideration for common cause failures (CCF).

Validation of functional safety

As with any risk reduction measure, it is essential to verify

that the PL achieved is at least as high as the PL required

(PLr). This can be easily represented as PL ≥ PLr.

The confirmation that adequate PL has been achieved is

covered in the overall process applied to the design of SRP/

CS. The primary features include:

• Organization and competence

• Rules governing design (eg, specification templates, cod-

ing guidelines)

• Test concept and test criteria

• Documentation and configuration management.

All lifecycle activities of safety-related embedded or appli-

cation software must primarily consider the avoidance of

faults introduced during the software lifecycle. The main

objective is to have readable, understandable, testable and

maintainable software. The ISO 13849-1 standard outlines

a V-model as shown in Figure 5, which has proven particu-

larly effective in practice for software design.

In common language (outside of safety standards), there

is little difference between the terms ‘verification’ and ‘valida-

tion.’ In essence, the goal is to test and check that the overall

reliability of each subsystem of the SRP/CS is adequate for

the associated risk, and that accurate documentation is col-

lected for future revalidation throughout the entire life cycle

of the machine.

Confirmation of functional safety

Over the past ten to 15 years, industry has been progres-

sively adopting the concepts of evaluating risks based on

a systematic methodology and reducing identified risks

through the application of multiple layers of protective

measures from an orderly list of options based on their

CONTROL &

INSTRUMENTATION

Figure 5: V-Model for Software Validation

Some notes regarding the standards and references used in the article

Please note that the specific standards and references mentioned in the above article

are derived from European and American (USA) standards and references. Most of

these standards are derived from the Machinery Directive, which forms the basis of

requirements for factory machines placed on the market in these regions.

While South Africa uses many of the standards derived from European directives

as the sources of our own standards, we do not directly make use of the Machinery

Directive and related standards for the purposes of machine safety.

We have two local documents which are mostly applicable; the Driven Machinery

Regulations and the Electrical Machinery Regulations. According to our regulations,

the onus is on the designer, manufacturer, operator, maintenance personnel and

any inspectors or testers of driven machinery to evaluate the danger presented by

any hazardous areas on the machine and take any required precautionary actions

deemed reasonable to prevent harm to personnel. This, in effect, means that it is up

to the instigator of the safety system to explain the parameters of the system they

implemented, especially in the event of an accident.

Therefore, while the standards and protocols mentioned in the article are not a

legal requirement in our country, I would propose that adherence to them would

provide a clear and direct reference supporting the decisions made in the selection

and implementation of the safety system. This also ensures that we conform to the

standards of best practice being used world-wide.

For more information,

you are welcome to contact our local Safety Specialist,

Stephen Eltze at

Stephen.eltze@sickautomation.co.za

.