Nof S.Y. Springer Handbook of Automation

Подождите немного. Документ загружается.

735

Reliability, M

42. Reliability, Maintainability, and Safety

Gérard Morel, Jean-François Pétin, Timothy L. Johnson

Within the last 20 years, digital automation has

increasingly taken over manual control functions

in manufacturing plants, as well as in products.

With this shift, reliability, maintainability, and

safety responsibilities formerly delegated to skilled

human operators have increasingly shifted to au-

tomation systems that now close the loop.Inorder

to design highly dependable automation systems,

the original concept of design for reliability has

been reﬁned and greatly expanded to include new

engineering concepts such as availability, safety,

maintainability, and survivability. Technical deﬁ-

nitions for these terms are provided in this chapter,

as well as an overview of engineering methods

that have been used to achieve these properties.

Current standards and industrial practice in the

design of dependable systems are noted. The in-

tegration of dependable automation systems in

multilevel architectures has also evolved greatly,

and new concepts of control and monitoring,

remote diagnostics, software safety, and auto-

mated reconﬁgurability are described. An extended

exampleoftheroleofdependableautomation

42.1 Deﬁnitions ........................................... 736

42.2 RMS Engineering .................................. 738

42.2.1 Predictive RMS Assessment ............ 738

42.2.2 Towards a Safe Engineering Process

for RMS ....................................... 739

42.3 Operational Organization

and Architecture for RMS....................... 741

42.3.1 Integrated Control

and Monitoring Systems................ 741

42.3.2 Integrated Control, Maintenance,

and Technical Management

Systems ...................................... 743

42.3.3 Remote and e-Maintenance.......... 743

42.3.4 Industrial Applications.................. 745

42.4 Challenges, Trends, and Open Issues ...... 745

References .................................................. 746

systems at the enterprise level is also provided.

Finally, recent research trends, such as automated

veriﬁcation, are cited, and many citations from the

extensive literature on this topic are provided.

Industrial automation systems are intensively embed-

ding infotronics and mechatronics technology (IMT)

in order to fulﬁl complex applications required by

the increasing customization of both services and

goods [42.2–6]. The resulting behavior of these IMT-

based automation systems is shifting system depend-

ability responsibility [42.7] from the human operator to

the automation software.

Management, engineering, and maintenance per-

sonnel have a primary responsibility to assure re-

liability [42.8, 9], maintainability, and safety of all

automated systems, and manufacturing systems in par-

ticular. Therefore, safety, reliability, and availability as

performance attributes to access the dependability of

a system are threatened by a rapid growth in software

0246810

Normalized value

Availability

Hardware reliability

Software complexity

Year

1.6

1.4

1.2

0.8

0.6

0.4

0.2

Complexity growth with availability decline

Fig. 42.1 Growth of software complexity and its impact on system

availability (after [42.1])

Part E 42

736 Part E Automation Management

Maintainability Safety SurvivabilityAvailabilityReliability

Dependability

Fig. 42.2 The dependability tree (after [42.10])

complexity that could limit further automation progress

(Fig.42.1).

Section 42.1 provides deﬁnitions of dependability

key concepts (Fig.42.2) that enlarge reliability, main-

tainability, and safety (RMS) concepts [42.11, 12]by

characterizing the ability of a device or system to de-

liver the correct service that can justiﬁably be trusted by

all stakeholders in the automated process.

Then, methods for design of highly dependable

automation systems are outlined in Sect.42.2. Sec-

tion 42.3 discusses the methods for achieving long-term

dependable operation for an existing system.

Finally, dependability has evolved from reliabil-

ity/availability concerns to information control con-

cerns, as an outgrowth of the technological deployment

of information-intensive systems and the economical

pressure for cost-effective automation [42.13]. Sec-

tion 42.4 concludes with challenges, trends, and open

issues related to system resilience, aiming to cope with

system dependability in the presence of active faults,

i.e., system survivability. Chapter 39 of this handbook

contains information related to the concepts covered in

this Chapter.

42.1 Deﬁnitions

Dependability is an integrative concept that encom-

passes required attributes (qualities) of a system

assessed by quantitative measures (reliability, maintain-

ability) or qualitative ones (safety) in order to cope with

the chain of fault–error–failure threats of an operational

system, by combining a set of means related to fault

prevention, fault tolerance,fault removal,and faultfore-

casting [42.14].

Reliability is the ability of a device or system to

perform a required function under stated conditions for

a speciﬁed period of time. This property is often meas-

ured by the probability R(t) that a system will operate

without failure before time t, often deﬁned according to

the failure rate (λ(t)) as

R(t) =exp

⎛

⎝

−



λ(u)du

⎞

⎠

meaning

R(t) =Pr(TTF > t) ,

where TTF is the time to failure.

This deﬁnition of reliability is concerned with the

following four key elements:

1. First, reliability is a probability. This means that

there is always some chance for failure. Reliability

engineering is concerned with achieving a speci-

ﬁed probability of success, at a speciﬁed statistical

conﬁdence level.

2. Second, reliability is predicated on intended func-

tion. The system requirements speciﬁcation is the

criterion against which reliability is measured.

3. Third, reliability applies to a speciﬁed period of

time. In practical terms, this means that a system

has a speciﬁed chance that it will operate without

failure before a ﬁnal time (e.g., 0 < t < T).

4. Fourth, reliability is restricted to operation un-

der stated conditions. This constraint is necessary

because it is impossible to design a system for

unlimited conditions. Both normal and abnormal

operating environments must be addressed during

design and testing.

Maintainability is the ease with which a device

or system can be repaired or modiﬁed to correct and

prevent faults, anticipate degradation, improve perfor-

mance or adapt to a changed environment. Beyond

simple physical accessibility, it is the ability to reach

a component to perform the required maintenance

task: maintainability should be described [42.15]asthe

characteristic of material design and installation that

determines the requirements for maintenance expendi-

tures, including time, manpower, personnel skill, test

equipment, technical data, and facilities, to accomplish

operational objectives in the user’s operational environ-

ment. Like reliability, maintainability can be expressed

as a probability M(t) based on the repair rate (μ(t)) as

M(t) =1−exp

⎛

⎝

−



μ(u)du

⎞

⎠

Part E 42.1

Reliability, Maintainability, and Safety 42.1 Deﬁnitions 737

meaning

M(t) =Pr(TTR < t) ,

where TTR is the time to repair.

Availability characterizes the degree to which a sys-

tem or equipment is operable and in a committable state

at the start of a mission, when the mission lasts for an

unknown, i.e., random, time. A simple representation

for availability is the proportion of time a system is

in a functioning condition, and this can be expressed

mathematically [42.17]by

A(t) =

μ +λ

−(μ+λ)t

where λ is the constant failure rate and μ the constant

repair rate, meaning

A(t) ≡Pr(Z(t) =1),

with

Z(t) ≡

⎧

⎨

⎩

1 if the system is up at time t

0 if the system is down at time t .

System availabilityis important in achieving production

rate goals, but additional processes must be invoked to

SIL1

(1)

SIL2

SIL3

SIL4

(2)

(1)

SIL1

SIL2

SIL3

SIL4

(1)

SIL1

SIL2

SIL3

(1): no special safety

requirements

(2): single safety function

insufficient

Consequence severity

C1 → minor injury

C2 → minor injury or

single death

C3 → multiple deaths

C4 → a very high

number of deaths

Exposure time

F1 → rare to frequent

F2 → frequent to

continuous

Probability of undesirable

occurrences

W1 → very slight

probability

W2 → low probability

W3 → high probability

Possibility of avoidance

P1 → possible

P2 → not likely

Fig. 42.3 Determining safety integrity level according to IEC [42.16]

assure a high level of product quality. Historically (be-

fore 1960), a quality laboratory would draw samples

from the production line and subjectthem to a battery of

material, dimensional, and/or functional tests, with the

objective of verifying that quality was being attained for

a typicalpart. Inrecent years, the focus has shifted from

assurance of average quality to assurance of quality of

every part produced, driven by consumer product safety

concerns. Deming [42.18] and others were instrumen-

tal in developing methods for statistical process control,

which focused on the use of quality control data to ad-

just process parameters in a quality feedback loop that

assured consistently high product quality; these tech-

niques were developed and perfected in the 1970s and

1980s. Still more recently, sensors to measure critical

quality variables online have been developed, and the

quality feedback loop is now often automated (algorith-

mic statistical process control). At the same time, the

standards for product qualityhave moved up from about

two sigma (1 defective product in 100) to ﬁve or six

sigma (about 1 defective product in 100000).

Increasing availability consistsof reducing the num-

ber of failures (reliability) and reducing the time to

repair (maintainability) according to the following for-

Part E 42.1

738 Part E Automation Management

mula

A(∞) =

MTBF

MTBF+MTTR

as the asymptotic value of A(t), where MTBF is the

mean time between failures and the MTTR is the mean

time to repair.

Safety is the state of being safe, the condition of the

automated system being protected against catastrophic

consequences to the user(s) and the environment due

to component failure, equipment damage, operator er-

ror, accidents or any other undesirable abnormal event.

Safety hazard mitigationcan take the form of being pro-

tected from the event or from exposure to something

that causes health or economical losses. It can include

protection of people and limitation of environmental

impact.

Industrial automation standards (Fig.42.3), intro-

duce engineering and design requirements that vary

according to the safety integrity levels (SIL). SIL spec-

iﬁes the target level of safety integrity that can be

determined by a risk-based approach to quantify the

desired average probability of failure of a designed

function, probability of a dangerous failure per hour,

and the consequent severity of the failure. Combining

these criteria for a given function leads to four levels

of SILs that can be associated with speciﬁc engineer-

ing guidelines and architecture recommendations; for

example, SIL 4 is the most critical level and the use

of formal methods is strongly recommended to han-

dle the complexity of software-intensive applications

and to prove safety properties. To achieve RMS prop-

erties over the lifecycle of an automated system, two

complementary activities must be undertaken:

•

During the system development and design phase,

the occurrence of faults should be prevented by us-

ing appropriate models and methods: quantitative

approaches based on stochastic models can be used

to perform a predictive RMS analysis, and quali-

tative approaches focusing on engineering process

(e.g., Six Sigma) can be used to improve the quality

of the automated system and its products.

•

During the operational life of the automated system,

personnel should avoid or react to undesired situa-

tions by deploying appropriate safety architectures,

maintenance procedures, and management methods.

Survivability is the quantiﬁed ability of a system to

continue to fulﬁl its mission during and after a natural

or manmade disturbance. In contrast to dependability

studies, which focus on analysis of system dysfunction,

resilience for survivability focuses on the analysis of the

range of conditions over which the system will survive.

42.2 RMS Engineering

42.2.1 Predictive RMS Assessment

To evaluate and measure the various parameters that

characterize system dependability, many methods and

approaches have been developed. Their goal is to

provide a structured framework to represent failures

qualitatively and/or quantitatively. They are mainly of

two types: declarative and probabilistic.

Declarative methods are designed to identify, clas-

sify, and bracket the failures and provide methods

and techniques to avoid them. Most classical mod-

els use graphical classiﬁcation of failure, causes, and

criticality (failure mode, effects and criticality anal-

ysis (FMECA), hazardous operation (Hazop), etc.),

block diagrams, and fault trees to provide a graphical

means of evaluating the relationships between different

parts of the system (Fig.42.4). These models incor-

porate predictions based on parts-count failure rates

taken from historical data. While the predictions are

often not very accurate in an absolute sense, they

are valuable to assess relative differences in design

alternatives.

Probabilistic methods are designed to measure, in

terms of probability, some RMS parameters. Models are

mainly based on the complete enumeration of a sys-

tem’s possible states, including faulty states. These

models usestate-transition notationinvolved inthe clas-

sical stochastic models of discrete event systems such

as Markov chains and Petri nets [42.19]. The beneﬁt

of Markov and stochastic Petri net approaches relies on

their capability to support quantitative analysis of the

models, but these models suffer from the combinatoric

explosion of the states that occurs when modeling com-

plex industrial systems. Moreover, all of these analytic

approaches assume that the stochastic processes can be

modeled using a constant exponential law. For indus-

trial processes that do not ﬁt with this strong Markovian

hypothesis, the deﬁnition of simulation models, such

as Monte Carlo simulation, remains the only way to

evaluate the RMS parameters.

Part E 42.2

Reliability, Maintainability, and Safety 42.2 RMS Engineering 739

Item Actions taken

Sev

Occur

Det

RPN

Class

Process

Function/requirement

Potential

failure mode

Potential effect(s)

of failure

Current

process

controls

prevention

Current process

controls

detection

Potential

cause(s)/mechanism(s)

of failure

Manual application of

wax side indoor

To cover inner door,

lower surfaces at

minimum wax thickness

to retard corrosion

Insufficient wax

coverage over

specified

surface

Deteriorated life of

door leading to:

• Unsatisfactory

appearance due to

rust through paint

over time

• Impaired function

of interior door

hardware

Manually inserted spray

head not inserted far

enough

RPN

Det

Occur

Sev

7280Visual check each

hour-1/shift for

film thickness

(depth meter) and

coverage

Responsability

& target

completion date

Stop added

sprayer

checked on

line

Recommended

actions(s)

Actions

taken

Add positive

depth stop to

sprayer

5Spray head dogged:

• Viscosity too high

• Temperature too low

• Pressure too low

321317105Test spray pattern

at start-up and after

idle periods, and

preventive mainten-

ance program to

clean head

2Spray head deformed

due to impact

22822728Preventive mainten-

ance program to

maintain head

8Spray time insufficient 7 49717392Operators instruc-

tions and lot samp-

ling (10 doors/shift)

to check for cover-

age of critical areas

3. Front door l.h.

Component 1

State: regenerated1

Component 2

State: OK

Component 1

State: OK

Function 1

State: Degraded

Component 1

State: regenerated2

Component 2

State: regenerated1

Component 2

State: regenerated2

Fig. 42.4a,b Example of declarative models. (a) Fault tree. (b) FMECA (RPN – risk priority number, Sev – severity, Occur –

occurence, Det – detectability (high detectability implies lower risk))

Whatever the kind of used approaches, models for

predictive RMS evaluation rely upon system data col-

lection that does not always reﬂect the system reality

due to a gap between real and estimated states. This

limitation reinforces the need to establish reliable gates

between RMS engineering and system deployment to

update the RMS model data with real-time information

provided by the automated system.

42.2.2 Towards a Safe Engineering Process

for RMS

Automation techniques have proven their effective-

ness in controlling the behavior of complex systems,

based on the use of suitable mathematical relationships

involving feedback system dynamics during the de-

sign process. Nevertheless, the process of automating

a system, as addressed by system theory for auto-

matic control, also deals with qualitative phases [42.19]

that require intuitive modeling of real phenomena

(a quantity of material, energy, information, a robot,

a cell, a plant, etc.) to be controlled for achieving

end-user goals. The modeler’s intuition remains impor-

tant [42.20, 21] to build the model as an abstraction

of the real system by identifying the appropriate input,

output, and state variables in order to logically deﬁne

the required system behavior. The main difﬁculty is to

handle the quality of the automation engineering pro-

Part E 42.2

740 Part E Automation Management

Table 42.1 Capability maturity model [42.24]

Level 1:

Initial

The software process is characterized as ad hoc and occasionally even chaotic. Few processes are

deﬁned and success depends on individual effort.

Level 2:

Repeatable

Basic project management processes are established to track cost, schedule, and functionality.

The necessary process discipline is in place to repeat earlier successes on projects with similar

applications.

Level 3:

Deﬁned

The software process for both management and engineering activities is documented, standard-

ized, and integrated into a standard software process for the organization.

Level 4:

Managed

Detailed measures of the software process and product quality are collected. Both the software

process and product are quantitatively understood and controlled.

Level 5:

Optimizing

Continuous process improvement is enabled by quantitative feedback from the process and from

piloting innovative ideas and technologies.

cesses from deﬁnition and development to deployment

and operation of the target system by standardization

and use of best practices that are generic to well-

identiﬁed problem classes and whose quality has been

established by experience. Capability maturity models

(CMM) [42.22], and validation–veriﬁcation methods,

guide engineers to combine prescriptive and descrip-

tive models in order to meet system requirements such

as RMS, but without any formal proof of accuracy of

the resulting system model. Finally, the present trend

to compose automation logic by assembling standard-

ized, conﬁgurable, off-the-shelf components [42.23]

strengthens the need to ﬁrst better relate the modeling

process and the system goals and then to preserve them

through the transformation of models of the automa-

tion engineering chain. The CMM, was developed as

a means of rating the thoroughness of a software de-

velopment process, by the Carnegie Melon University

Software Engineering Institute in the 1990s.

To pave the way toward CMM level 5, there is

a growing demand for formalized methods for assur-

ing dependability in industrial automation engineering,

in order to compensate for the increasing complexity

of software-intensive applications [42.25]. In particular,

high levels of safety integrity, as addressed by the In-

ternational Electrotechnical Commission (IEC) 61508

standard, should be formally checked and proven by

mathematically sound techniques in order to verify the

required completeness, consistency, unambiguity, and

ﬁnally correctness of the system models throughout the

deﬁnition, development, and deployment phases of the

engineering lifecycle [42.26,27].

The conformance measure of system models with

regards to the requirements, and especially RMS fea-

tures, can be obtained using:

•

Assertion methods that include the properties to be

checked in the system models proceed to an a pos-

teriori veriﬁcation using automatic techniques such

as model checking [42.28].

•

Reﬁnement methods that start with the formal-

ization of a requirement model and progressively

enrich this model until a concrete model of the

system that fulﬁls, by construction, the identi-

ﬁed requirements is obtained. They can be based

on:

– Semiformal mechanisms that identify and clas-

sify RMS requirements and then allocate those

requirements to the function, components, and

equipment of the automated system. In this case,

classical models combine computer-science ap-

proaches such as uniﬁed modeling language

(UML) with discrete-event analysis models.

– Formal mechanisms [42.29] that allow a se-

quence of formal models to be systematically

derived while preserving the link between for-

mal models and required properties (goals): an

extension of the spiral method for software en-

gineering.

All of these techniques may be combined to contribute

to RMS issues [42.30, 31], but the emphasis on correct

system deﬁnition is then shifted to earlier requirements

analysis and elicitation phases.

Part E 42.2

Reliability, Maintainability, and Safety 42.3 Operational Organization and Architecture for RMS 741

42.3 Operational Organization and Architecture for RMS

Taking advantage of technological advances in the

ﬁeld of communications (web services embedded in

programmable logic controllers) or in the ﬁeld of

electronics and information technology (radiofrequency

identiﬁcation (RFID), sensor networks, software em-

bedded components, etc.), automated systems now

include an increasing part of information technology

and communication distributed at the very heart of

production processes and products. However, this au-

tomation comes at a price: the complexity of the control

system in terms of both heterogeneous material (ded-

icated computers, communications networks, supply

chain operations and capture, etc.) and software func-

tions (scheduling, control, supervisory control, moni-

toring, diagnosis, reconﬁguration, etc.) that it houses

(Fig.42.5).

This section deals with the operational archi-

tectures and organizations required to enable active

dependability of the automated system by provid-

ing information processing, storage, and communi-

cation capabilities to anticipate undesired situations

or to react as effectively as possible to fault occur-

rences.

today

OPC

data server

OPC

data server

PLC

Remote I/O

Fieldbus

HMI

PLC

Remote I/O

Fieldbus

HMI

MESMES

SCADA

OPC

data server

PLC

Remote I/O

Fieldbus

HMI

SCADA

ERP

CRM SCM

ERPCRM SCM

EAI

CRM

MES

SCM

ERP

EAI

Dynamic synchronization

S95/OAGIS standard

Static

synchronization

(B2MML)

Dynamic synchronization

S95/OAGIS standard

Fig. 42.5 Evolution of automated system architecture (CRM – customer relationship management, ERP – enterprise

resource planning, SCM – system conﬁguration maintenance, MES – manufacturing execution system, OPC – on-

line process control, PLC – programmable logic controller, SCADA – supervisory control and data acquisition, EAI

– enterprise architecture interface, HMI – human machine interface, OAGIS – open applications group integration

speciﬁcation)

42.3.1 Integrated Control

and Monitoring Systems

In orderto maintainan acceptable quality of service, de-

pendability should no longer be considered redundant,

but should be integrated with production systems in

order to be an asset in the business competitive environ-

ment. This leads to integration of additional monitoring

functions with the classical control functions of an au-

tomated system in order to provide the system with the

ability to reconﬁgure itself to continue some or all of

its missions. The main idea is to avoid a complete shut-

down of the system when a failure (with a consequent

reduction in the productive potential of the system) oc-

curs. Considering the system’s intrinsic ﬂexibilities, the

aim is to promote system reconﬁguration using a reﬂex

loop including:

•

Failure detection reports about the normal or abnor-

mal behavior of the system. These are mainly based

on a theoretical model of the functional and dys-

functional behavior of the devices involved in the

automated system.

Part E 42.3

742 Part E Automation Management

Supervision

Fault

processing

Error

recovery

On/Off

Action

Sensors

State of

process

Cr_act

Er_act

Command

filters

Control

command

Decisional

unit

Control

unit

Process

Fig. 42.6 Integrated control and monitoring systems (after [42.32])

•

Diagnosis is mandated to establish a causal connec-

tion between an observed symptom and the failure

that occurred, its causes, and its consequences.

This function involves failure localization to iso-

late the failure to a subarea of the system and/or

devices, failure identiﬁcation to precisely deter-

mine the causes that brought about the default, and

prognosis to determine whether or not there are im-

Business

level

Shop floor

level

Technical

information

system

Business

Management

processing

Technical management

MaintenanceControl

Field-bus

Process

Fig. 42.7 Integrated control, main-

tenance, and technical management:

layers of automation

mediate consequences of the failure on the plant’s

future operation.

•

Reconﬁguration concerns reorganization of hard-

ware and/or software of a control system to ensure

production within a timeframe compatible with

the speciﬁcations. This function involves decision-

making activities to deﬁne the most appropriate

control policy and operational activities to imple-

ment the reconﬁgured control actions.

Integration of monitoring [42.33,34], diagnosis [42.35]

or even prognosis into control for manufacturing sys-

tems have been widely explored for discrete-event

systems (Fig.42.6) and today provide material for iden-

tifying degradation or failure modes where control

reconﬁguration may be required [42.36].

Reconﬁguration exploits the various ﬂexibilities of

the automated system (functional and/ormaterial redun-

dancies). In this way, it aims to satisfy fault-tolerance

properties that characterize the ability of a system (of-

ten computer-based) to continue operating properly in

the event of the failure of some of its components. One

of the most important design techniques is replication –

providing multiple identical instances of the same sys-

tem or subsystem, directing tasks or requests to all of

them in parallel, and choosing the correct result on the

basis of a quorum – and redundancy – providing multi-

ple identicalinstances ofthe same system and switching

to one of the remaining instances in case of a failure.

These techniques signiﬁcantly increase system reliabil-

Part E 42.3

Reliability, Maintainability, and Safety 42.3 Operational Organization and Architecture for RMS 743

ity, and are often the only viable means of doing so.

However, they are difﬁcult to design and expensive to

implement, and are therefore limited to critical parts of

the system.

While automation of these functions is obviously

necessary for ensuring the best reactivity of the in-

dustrial production system to failure occurrence, it is

nevertheless true that system stoppage is often per-

formed by the human operator, who must act manually

to put it back into a admissible state. This justiﬁes

the use of supervision and supervisory control and

data-acquisition (SCADA) systems that help human

operators for plant monitoring and decision-making re-

lated to the various corrective actions to beperformed in

order to get back to a normal functioning situation (re-

conﬁguration, management of operating mode). Given

the ever-increasing complexity of industrial processes,

the burden itself tends to become difﬁcult or even im-

possible. For these reasons, much research is aimed at

developing and proposing solutions aimed at assisting

the human operator in the phases of reconﬁguration.

42.3.2 Integrated Control, Maintenance,

and Technical Management Systems

Further developments of integrated control and moni-

toring systems have lead European projects in intelli-

gent actuation and measurement [42.37–40] to demon-

strate the beneﬁt of integrating control, maintenance,

and technical management (CMTM) activities [42.41]:

•

To optimize control activities by exploiting the plant

as efﬁciently as possible and taking into account

real-time information about process status (device

and function availability) provided by monitoring

and maintenance activities

•

To optimize the scheduling of the maintenance

activities by taking into account production con-

straints and objectives

•

To optimize, by technical management based on

validated information, the operation phase by modi-

fying control or maintenance procedures, tools, and

materials

Applying this principle at the shop-ﬂoor level of the

production system consists of integrating the opera-

tional activities of the CMM agents responsible for

the plant and its lower-level interfaces with the sys-

tem devices. They are also linked with the business

level of the enterprise (enterprise resource planning,

etc.) for business-to-manufacturing integration issues

(manufacturing execution system (MES)). These oper-

ational activities are based on collaboration between

human stakeholders and technical resources that sup-

port schedule management, quality management, etc.,

but also process management and maintenance manage-

ment, which are more dependent on the e-Connectivity

of the supporting devices.

The expected integrated organization for shop-ﬂoor

activities requires that information is made available

for use by all the operational activities (MES or

CMM). In this way, intelligence embedded in ﬁeld de-

vices (e.g., devices such as actuators, sensors, PLCs

(programmable logic controllers), etc.) and digital com-

munication provide a solution to an informational

representation of the production process as efﬁciently

as possible: the system provides the right information

at the right time and at the right place. In other words,

the closer the data representation (e.g., in an object-

oriented system) to the physical and material ﬂows, the

better the semantics of its informational representation

for integration purposes (Fig.42.7).

At the shop-ﬂoor level, local intelligence (software)

allows distribution of information processing, informa-

tion storage, and communication capabilities in ﬁeld

devices and adds to their classical roles new services

related to monitoring, validation, evaluation, decision

making, etc., with regard to their own operations (in-

creased degree of autonomy) but also their application

context (increased degree of component interaction).

42.3.3 Remote and e-Maintenance

Modern production equipment (manufactured by

original equipment manufacturers, OEMs) is highly

specialized; for example, a semiconductor manufactur-

ing plant may have over 200 specialized production

stages and over 100 equipment suppliers. In a serial

process of this type, all 200 steps must operate within

speciﬁcation to produce an operational semiconductor

at the end of the line. This type of process requires

extraordinarily high reliability (and availability) of the

OEM production equipment. When such equipment

must be takenout ofservice, it isnot uncommonto incur

production loss rates of over 100000 $/h, and there-

fore accurate diagnosis and rapid repair of equipment

are essential. Since the year 2000, OEMs have increas-

ingly provided network-capable diagnostic interfaces to

equipment, so that experts do not have to come to the

site to make a diagnosis or repair, but can guide plant

personnel in doing this, and can order and ship parts

overnight. This is often termed e-Diagnostics,andis

crucial to maintaining high availability of production

Part E 42.3

744 Part E Automation Management

equipment. Using e-Diagnostics, a manufacturer may

maintain remote service contracts with dozens of OEM

suppliers to assure reliable operation of an entire pro-

duction process.

In some processes, where production equipment is

subject to wear or usage that is predictably related, for

example, to the number of parts produced, it is possible

to forecast the need for inspection, repair, or periodic

replacement of critical parts, a process called prognos-

tics. Although some statistical methods for prognostics

(such as Weibull analysis) are well known, the ability

to accurately predict the need for service of an individ-

ual part is still not well developed, and is not yet widely

accepted. One goal of this type of analysis is condition-

based maintenance (CBM), the practice of maintaining

equipment based on its condition rather than on the

basis of a ﬁxed schedule [42.43].

Proactive maintenance is a new maintenance pol-

icy [42.44] based on prognostics, and improves on

condition-based maintenance (CBM). CBM acquires

real-time information in order to propose actions and to

repair only when maintenance is necessary. CBM con-

Automation

DCS

Data record

historian

Automation

DCS

Data record

historian

On-demand

Belgium

e-Diagnostic

center

Investigation

center

France

Italy

On-demand

Offline Online

Automation

DCS

Automation

DCS

Data record

historian

Automation

DCS

Data record

historian

Data record

historian

Netherlands

Automation

DCS DCS

Data

concentrator

“data hub”

Fig. 42.8 Distributed e-Maintenance infrastructure in a power energy plant [42.42](DCS – distributed control system)

sists of equipment health monitoring to determine the

equipment state; CBM is a kind of just-in-time main-

tenance. CBM is not able to predict the future state of

equipment. The prognostic capability of the proactive

maintenance is based on the history of the equipment

operation, its current state, and its future operating con-

ditions. The objective of proactive maintenance is to

know if the system is able to accomplish its function

for a given time (for example, until the next plant main-

tenance shutdown).

Information from control systems (distributed or

not), automation, data-acquisition systems, and sensors

makes it possible to measure variables continuously in

order to produce symptoms or indicators of malfunc-

tion, to acquire the number of cycles of production,

the time of production, the energies consumed, etc.,

in order to correlate this information with the diagno-

sis and assess the probabilities of root cause. Based

on these monitoring and diagnosis functions, proac-

tive maintenance, thanks to prognosis, propagates the

drift of system behavior through time, taking into ac-

count the future exploitation conditions. Based on this

Part E 42.3