Nof S.Y. Springer Handbook of Automation

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

Product Lifecycle Management and Embedded Information Devices 43.3 A Development Guide for Your Closed-Loop PLM Solution 755

as computer-aided design/manufacture (CAD/CAM)

but also other back-end software to achieve interop-

erability of all activities that affect a product and

its lifecycle. Figure 43.6 shows the overall archi-

tecture of the PDKM developed in the PROMISE

project.

43.3 A Development Guide for Your Closed-Loop PLM Solution

In this section we describe the main elements of the de-

velopment of a closed-loop PLM solution: modeling,

selection of PEID system, data and data ﬂow deﬁnition,

PDKM, DSS and middleware.

43.3.1 Modeling

PLM has speciﬁc objectives at each phase of the life-

cycle: BOL, MOL or EOL; for example, at BOL,

improving product design and production quality are

main concerns. During MOL, improving reliability,

Updating PEID

PLM system

Dismantler

EOL product expertProduct designerLogistics engineer

Remanu-

facturer

Product

(with PEID)

Analyzing data

Supporting EOL

decision

<<uses>>

Sending feedback

information

Filtering data

Managing information

and knowledge

Gathering, storing,

and transmitting data

RFID application in EOL

Fig. 43.7 Use case for PEID application at EOL

availability, and maintainability of products are the

most interesting issues. In EOL, optimizing EOL prod-

uct recovery operations is one of the most challenging

issues.

It is advisable to begin the development of a closed-

loop PLM solution by modeling the various charac-

teristics of the solutions we want to develop. If, for

example, we consider the EOL phase of a product,

a use-case diagram such as the one shown in Fig.43.7

below will help to identify the main actors and activities

of the solution. This model shows how a PLM system,

Part E 43.3

756 Part E Automation Management

using PEID technology, can gather accurate data re-

lated to product lifecycle history at the collecting and

dismantling phase of EOL products, e.g., which com-

ponents they consist of, what materials they contain,

who manufactured them, and other data that facilitate

reuse of materials, components, and parts. Based on

gathered data, EOL product experts in the PLM system

can predict degradation status and remaining lifetime

of parts or components. With this information, at the

inspection phase, the dismantler can implement EOL

product recovery optimization, in other words, decid-

ing on suitable EOL recovery options such as recycle,

reuse, remanufacturing, and disposal, with the objec-

tive of maximizing values of EOL products considering

product status. This decision also provides useful in-

formation to remanufacturers for making an efﬁcient

remanufacturing plan in advance. Furthermore, logis-

tics engineers can improve logistics at EOL (reverse

logistics) from collecting to remanufacturing, reuse or

disposal. They can obtain supply volume data for re-

cycle, reuse, remanufacturing, and disposal products

in advance from the EOL decision. In addition, EOL

product recovery decision data and product status at

EOL dismantling can give useful information to prod-

uct designers for improving product design with several

purposes, e.g., design for reliability, reuse, recycle, and

so on.

The next step of modeling concerns the process

and events of the solution. This is well achieved with

a swim-lane chart. Figure 43.8 below shows the swim-

lane chart of closed-loop application at EOL,mainly

focusing on EOL product recovery optimization.

In this application, at ﬁrst, the EOL collector gath-

ers products that have lost their values. Then, the EOL

dismantler inspects collected products visually. As a re-

sult, products can be simply classiﬁed into two parts:

disposal, and disassemblyfor moredetailed inspections.

In disassembly, the concerned components or parts will

be inspected in detail and sorted into several EOL op-

tions based on some criteria. During the inspection

and sorting process, if necessary, the dismantler ac-

cesses PEIDs of the parts or components concerned

to gather necessary data for inspecting and sorting the

EOL products. To sort EOL products in a systematic

way, the EOL dismantler asks for EOL decision sup-

port from the PLM system. EOL product experts in

the PLM system estimate the remaining value of the

parts or components concerned, based on accumulated

data, information, andknowledgeat PDKMin the PLM.

Based on the estimated remaining values and other in-

formation such as costs and beneﬁts of recycle, reuse,

remanufacture, disposal, and so on, EOL product ex-

perts decide on an adequate EOL option for each part

or component, i.e., which parts or components should

be recycled, reused, remanufactured or disposed, un-

der some constraints related toenvironmental regulation

and product quality. This information will be stored

in the PDKM and transmitted to dismantlers. If nec-

essary, product designer and logistics engineer receive

this information from the PLM system to improve their

operations.

Based on the proposed EOL decision, dismantlers

sort the parts or components. When the EOL disman-

tler sorts products, depending on the sorting results of

EOL products, operations related to PEIDs may be dif-

ferent. They may be removed and replaced with new

ones; orits datacontents canbe reset or updated without

replacement for the second life of parts or components;

for example, in the recycle case, PEIDs will usually be

detached from products. Then, recyclable products will

be sent to speciﬁc lots that have similar materials fea-

tures. For each lot, a new PEID will be used for its

management. Each lot will be sent to recycling com-

panies. In the reuse case, after quality data of parts

or components are updated to an existing PEID, prod-

ucts will be sent to a remanufacturing site or second

market. In the remanufacturing case, after required in-

formation for remanufacturing such as current quality

data, required quality data, product speciﬁcation, and

production instruction areupdated, productswill besent

to remanufacturing sites. In the case of disposal, af-

ter updating disposal-relevant data to each PEID and

PLM system by disposal engineers, products are sent

to disposal companies.

43.3.2 Selection of PEID System

Table 43.1 shows the basic functions and their corre-

sponding components of a PEID with its speciﬁcations.

Here, PEIDs can be classiﬁed into four types by their

functions and speciﬁcations.

Type A isfor simple applications.It containsonly its

ownidentiﬁcation function. For this, it has a small-sized

read-only microchip that includes its own ID, conﬁg-

uration parameters, and simple logics programmed for

a speciﬁc application. A 1 bit transponder orsimple pas-

sive RFID tag is included in this type. It does not need

any power to transmit data to a PEID controller. It can

be detected by a PEID controller automatically when

it goes into the interrogation zone. Hence, it does not

need any battery. When lifecycleactors justwant toread

a small amount of product identiﬁcation data without

Part E 43.3

Product Lifecycle Management and Embedded Information Devices 43.3 A Development Guide for Your Closed-Loop PLM Solution 757

Dismantler

Reading PEID

with PEID

controller

Filtering out

Unusual

data

Transmitting

product

lifecycle data

Transmitting

product

lifecycle data

RemanufacturerProduct

Data gatheringData analyzingFeedback and taking action

Logistics

engineer

Product

designer

PLM

system

EOL product

expert

- Access authority data

Gathering

EOL product

data

Requesting

EOL data

analysis

- Product usage status

- Product mission profile

- Product specification

-Degradation pattern

- Product status data

- Product EOL data

- Best EOL recovery solution

Estimating

remaining

value

Building up

information

and knowledge

Making

remanufacturing

plan

Sorting

EOL product

Replacing

existing PEID

with new one

Updating

data of PEID

Design

for reliability

Design

for EOL

Making logistic

planning

- Current product status

- Environmental hazard data

- Ease of disassembly

Transmitting

updated

information

- Best EOL recovery solution

Making

decision for best

EOL recovery

- Best EOL recovery solution

- EOL recovery result

- Reuse and recycle rate

RFID application scenario in EOL (EOL product recovery optimization)

Fig. 43.8 EOL swim-lane chart

Part E 43.3

758 Part E Automation Management

Table 43.1 Classiﬁcation of PEIDs(ﬁlled bullet: high capacity, empty bullet: low capacity) (LF – low frequency, HF –high

frequency, UHF – ultra high frequency)

Ourclassiﬁcation

Category

Type A

(1bit transponder)

Type B

(passive or semi-

passive type with

memory)

Type C

(active type with

memory and

sensor)

Type D

(device for smart

product)

Function (corresponding component)

Product identiﬁcation (simple serial number

in built-in chip)

• • • •

Sensing (sensor) – – • •

Data processing (microprocessor) – ◦ ◦ •

Data storage (memory) – • • •

Power management (battery) – ◦ • •

Communication (communication module) – – – •

Speciﬁcation

Memory type (RO

, WORM

, RW

) RO WORM, RW RW RW

Reading distance (L

) L, M M M, H M, H

Data rate (L, M, H) L L, M M, H M, H

Processing ability (L, M, H) – L L, M M, H

Frequency of operation (LF, HF, UHF) LF, HF LF, HF HF, UHF HF, UHF

Application level

Component/

item level

Component/

item or lot level

Assembly level

or lot level

Product level

Read only,

Write once and read many,

Read/write,

up to 1cm,

Up to 1m,

Over 1m (L = low, M = medium, H = high)

storing additional data to a product itself during product

lifecycle, this type of PEID is suitable.

Compared with type A, type B has additionally

storage capability. Hence, it enables storage of nec-

essary data in a product itself during its lifecycle. In

other words, a PEID controller can update new data

or information to this type of PEID, if necessary. This

requires a read/write type of memory. Depending on ap-

plications, some may need processing ability to ﬁlter

gathered data. Furthermore, some may need a bat-

tery because data storage requires a large amount of

power. To keep not only static but also dynamic data

about products (but a small amount, such as product

history data within a product itself) this type is prefer-

able. A semipassive or active tag can be used for this

type of application. This type can be used in produc-

tion lines or warehouses, or in supply chains for item

management applications, e.g., checking item status,

classifying items, tracing item history, and so on.

Type C has sensing and power management func-

tions to gather environmental data of a product, in

addition to the speciﬁcations of type B. Sensors can be

installed into a RFID tag or separately, independent of

a RFID tag. It should have its own battery since sen-

sors require a large amount of power. It may also have

a communication module,depending onthe application.

Through the communication module, it is able to trans-

mit gathered data from sensors to back-end systems by

itself. Its size is larger and its reading distance is longer

than those of the previously described types. Predic-

tive maintenance domain is a major application of this

type of device. Depending on the types of sensors used,

the application areas are huge, from food to machinery

products.

Type D is the most complex PEID, which has ad-

ditionally communication and processing ability. It can

keep some amount of product status data gathered from

sensors in its own memory. Furthermore, it can ana-

lyze gathered data and make some decisional processes

based on them autonomously. This reduces the amount

of data to be handled by the back-end systems. In ad-

dition, it can communicate with a PLM system directly

without the help of PLM agents.

43.3.3 Data and Data Flow Deﬁnition

Table 43.2 describes the main data in several informa-

tion ﬂows in PLM.

Part E 43.3

Product Lifecycle Management and Embedded Information Devices 43.3 A Development Guide for Your Closed-Loop PLM Solution 759

Table 43.2 Main data of information ﬂows in PLM

Information ﬂow Category Main data

BOL to MOL BOM information Product ID, product structure, part ID, component ID prod-

uct/part/component design speciﬁcation, etc.

Information for maintenance/

service

Spare part ID list, price of spare part, maintenance/service

instructions, etc.

Production information Assemble/disassemble instruction,production speciﬁcations

production history data, production routing data, production

plan, inventory status, etc.

BOL to EOL Product information Material information, BOM, part/component cost, disassem-

ble instruction, assembly information for remanufacturing,

etc.

Production information Production date, lot ID, production location, etc.

MOL to EOL Maintenance history information Number of breakdowns, parts/components’ IDsinproblem,

installed date, maintenance engineers’ IDs, list of replaced

parts, aging statistics after substitution, maintenance cost,

etc.

Product status information Degree of quality of each component, performance deﬁni-

tion, etc.

Usage environment information Usage condition (e.g., average humidity, internal/external

temperature), user mission proﬁle, usage time, etc.

Updated BOM Updated BOM by repairing or changing parts and compo-

nents, etc.

MOL to BOL Maintenance and failure informa-

tion for design improvement

Ease of maintenance/service, reliability problems, mainte-

nance date, frequency of maintenance, MTBF

, MTTR

failure rate, critical component list, root causes, etc.

Technical customer support infor-

mation

Customer complaints, customer proﬁles, response, etc.

Usage environment information Usage condition (e.g., average humidity, internal/external

temperature), user mission proﬁle, usage time, etc.

EOL to MOL Recycling/reusing part or compo-

nent information

Reuse part or component, remanufacturing information,

quality of remanufacturing part or component, etc.

EOL to BOL EOL product status information Product/part/component lifetime, recycling/reuse rate of

each component or part, etc.

Dismantling information Ease to disassemble, reuse or recycling value, disassembly

cost, remanufacturing cost, disposal cost, etc.

Environmental effects informa-

tion

Material recycle rate,environmental hazard information, etc.

Mean time between failures,

Mean time to repair

43.3.4 PDKM, DSS and Middleware

PLM has emerged as an enterprise solution. Thus,

all software tools/systems/databases used by vari-

ous departments and suppliers throughout the whole

product lifecycle have to be integrated so that the in-

formation contained in their systems can be shared

promptly and correctly between people and appli-

cations [43.2]. Hence, it is important to understand

how application software in a PLM ﬁts with others

Part E 43.3

760 Part E Automation Management

Table 43.3 Functions and speciﬁcations of main software components

Classiﬁcation Middleware PDKM DSS

Function

•

Request-driven reading

•

Event-driven reading

•

Filter data

•

Data transformation

•

Write

•

PEID management

•

Service management

•

Data transition

•

Document management

•

Field data management

•

User requirement

management

•

Data transformation

•

Communication requirement

management

•

Information requirement

management

•

Making decision

•

Decision support

•

Data analysis

and transformation

Speciﬁcation

•

Location (within product,

outside of product)

•

Reading distance

•

Reading rate

•

Data format

•

Interface protocol with PEID

•

Type of controller

•

Location

•

Main user

•

Types of knowledge

management

•

Data format

•

Amount of data

•

Location

•

Purpose of decision support

•

Decision-maker

•

Data format

•

Expected output type

•

Types of DSS

•

Types of decision model

Information/knowledge

for decision support

Information/

knowledge

New information/

knowledge

Experience

Information

Categorized data

Raw data

Information

Data

Decision support

PLM users

PDKM

PEIDs attached to products

Data

transformer

Decision

support

Database

Middleware

Diagnosis/

analysis tools

Domain experts

Back-end

software

Fig. 43.9 Software architecture for

closed-loop PLM

in order to manage product information and oper-

ations [43.18]. For this, a software architecture is

required. Software architecture is the high-level struc-

ture of a software system concerned with how to

design software components and make them work

together.

Part E 43.3

Product Lifecycle Management and Embedded Information Devices 43.4 Closed-Loop PLM Application 761

Figure 43.9 shows a software architecture for

closed-loop PLM. It takes a vertical approach in the

sense that its structure represents a hierarchy of soft-

ware of closed-loop PLM, from gathering raw data

to business applications. Embedded software (called

ﬁrmware) built into PEIDs plays the role of control-

ling and managing PEID data. The embedded software

can have the ability to ﬁlter raw data gathered by var-

ious sensors, if necessary (this function can also be

done in middleware). This can resolve the problem of

memory size in PEIDs by removing duplicate and un-

necessary data. Furthermore, ﬁrmware can do simple

analyses based on the gathered data, or this function can

also be implemented in other parts such as middleware,

diagnosis, and analysis tools, and PDKM.

Database (DB) software is required to store pro-

cessed data and manage them efﬁciently. A DB can be

distributed or located on a central server. Regarding the

format of the database, relational and object-oriented

databases have been considered in the relevant research

community. The conﬁguration of the DB should be

determined considering a trade-off between cost and ef-

ﬁciency of data management,which is different for each

case.

PDKM, decision support, and middleware software

components mustbe designed and implemented accord-

ing to their description in Sect.43.2.

Finally, back-end software can be deﬁned as the

part of a software system that processes the input

from the front-end system that interacts with the user.

These usually involve legacy systems of an enterprise,

e.g., enterprise resource planning (ERP), supply chain

management (SCM), and customer relationship man-

agement (CRM). The back-end software will support

PLM users in implementing several business processes

(see Chap.90 on Business Process Automation: CRM,

SM and ERP).

Table 43.3 presents the functions and speciﬁcations

of the main software components such as middleware,

PDKM,andDSS.

43.4 Closed-Loop PLM Application

The domain of application presented here is the

end-of-life (EOL) phase of the product lifecycle. It

speciﬁcally deals with the take back of end-of-life

vehicles (ELVs) by dismantlers so that they can be re-

processed: this strategy allows for both the feedback

of vital information (design information, usage statis-

tics on components, etc.),and the materials/components

themselves to the beginning-of-life (BOL) stage of the

product lifecycle; as well as the take back of selected

components into the middle-of-life (MOL) phase of the

product lifecycle as secondhand parts.

This industrial application was developed and im-

plemented by the Research Center of Fiat (CRF)

and its partners in PROMISE, and is reported in de-

tail in [43.19] and in the case study description A1

in [43.20]. It focuses speciﬁcally on the dismantler and

the operations performed to achieve the correct removal

decision [i.e., removal for reuse (BOL or MOL), re-

moval for remanufacturing (BOL), disposal, etc.]; and

the correct categorization and analysis of various en-

vironmental usage statistics associated with speciﬁc

components from the ELV.

The dismantler decides on the ELV’s recy-

cling/recovery path and converts the ELV into com-

ponents for reuse, remanufacturing or recycling. The

dismantler’s role is critical for returning ELV compo-

nents and information from EOL to BOL. He retrieves

from external databases the list of standard components

to be removed from the car and checks if the compo-

nents in the onboard diary are included in the standard

list. At the same time he retrieves models (algorithms

and costs) and thresholds from PDKM in order to com-

pute wear-out level for each component and analyze the

economic value of parts.

02468

List of component to be removed

(in descending order of worth reusing score)

Alternator was replaced 2 weeks

ago. It does not need remanufac-

turing/reworking

Alternator

Suspension

Steering

Starting engine

Inj. pump

Clutch

Battery

Gearbox

Engine

Catalyst silencer

Air cond. compress.

Reuse not convenient

Recycling compulsory due to

legal constraints

Fig. 43.10 List of EOL components of a car

Part E 43.4

762 Part E Automation Management

In particular he decides which parts should be re-

moved from the vehicle, how to recover (reuse or

remanufacture) the removed parts, to which customers

the parts should be delivered, and where to store the

parts.

In the ﬁrst stage, the system generates a bill of ma-

terials (BOM) of the car automatically based on the car

model or identity number inputted in the background

database; this BOM is used as the basis for developing

a list of potentially valuable parts to remove, which also

takes into account the requirements of legislation.

Using the dealer back-end system, the list of com-

ponents to be removed from the car is computed. An

example is shown in Fig.43.10.

43.4.1 ELV Information

andPEIDTechnology

In order to make these decisions properly and accu-

rately, large amounts of information are required by

the ELV dismantlers, which may be classiﬁed into six

categories:

(1) Product-related information

(2) Location-related information

(3) Utilization-related information

(4) Legislative information

(5) Market information

(6) Process information

Generally the information in categories (1), (4), and

(6) above is relatively easy to acquire, because the

product-related information isusually obtainedfrom the

automotive producers and from other relatively static

legislative bodies. However, current information sys-

tems cannot give more detailed speciﬁcations, such as

usage statistics and the environmental conditions un-

der which the ELV was used; this information can only

be obtained from the ELV itself, a situation which, un-

til recently, was only deemed to be resolvable by an

experienced dismantler that could use their subjective

judgement to make decisions about the present ELV

based upon their knowledge of past ELVs. Naturally,

this was seen as an unsatisfactory situation: the relevant

knowledge required was subjective and qualitative, and,

more important, linked to the personality of the disman-

tler. It was difﬁcult to write down or communicate in

numeric terms, and so was deemed difﬁcult to regulate

properly.

PEID technology, used as an enabler of PLM, can

help to remove many of the unsatisfactory elements of

the dismantling problem. By exploiting the capabili-

ties of PEIDs, sensors embedded in particular vehicle

components can collect and record relevant informa-

tion about the vehicle’s lifecycle, including production,

usage, maintenance, and dismantling data. The disman-

tlers only need to read the data from the ELVs’ PEID

system, and can thereby obtain all the required location-

and utilization-related information.

Thus, the solution suggested here removes the qual-

itative, subjective elements of the dismantling problem

by emphasizing the use of a PEID technology infras-

tructure that cumulativelydevelops an informationstore

of usage statistics as the ELV moves through its prod-

uct lifecycle. More importantly, the use of PEIDs allows

developers to remove the decision making at EOL from

the experienced dismantler’s hands,and allows anEOL-

dedicated DSS to be developed based upon numeric

usage statistics from the PEIDsintheELV.

43.4.2 Decision Flow

The decision support for ELVs consists of two web-

based process stages (Fig.43.11). In the ﬁrst stage,

(1) remove decision,the systemautomatically generates

a bill of materials (BOM) of the car based on the car

model or identity number inputted and the background

database; this BOM is used as the basis for developing

a list of potentially valuable parts to remove, which also

takes into account the requirements of legislation [that

is, if there are hazardous parts, such as batteries, that

must be removed by EuropeanUnion (EU)law,whether

valuable or not]. Once this list of parts to be removed

has been generated, the user moves into the second part

of the web interface: (2) recovery path, to determine

what on the projected list of car parts should actually

be removed and what should not be removed owing to

actual damage, abnormal wear and tear or other factors

that reduce the parts’ value.

There are two key removal decisions involvedat this

point for each part in the ELV under consideration:

(1) Remove part from the vehicle for further treatment

(2) Leave part on the vehicle to be shredded

If a part is (1) removed, it is because it is worth it: the

quality of the part, the cost of labor to remove, the mar-

ket conditions,and the present stock levels are assessed;

if the part passes all of these thresholds then it is re-

moved. If a part is (2) left on the ELV, it is because it

is not worth removing: the value of the part does not

cover its quality, the cost to remove, or the market may

Part E 43.4

Product Lifecycle Management and Embedded Information Devices 43.5 Emerging Trends and Open Challenges 763

Make

remove

decision

User login

Input car

model

List of

remove parts

List of BOM

Have decisions

been made for all the

components?

Choosing

decision

module

1. Remove decision

Input car

model

Calculate

recovery decisions

Choose the target

components

Modify recovery

decisions

Enter PEID data for the

chosen components

Calculate

customer's decision

Calculate

location decision

List of

recovery path

Modify

customer's decision

Have data

been entered for

all the chosen

components?

2. Recovery path

Fig. 43.11 A schematic view of DSS for ELVs

be unfavorable or the dismantler overstocked; the part

is left on the ELV to be shredded as base material for

recycling.

In the second stage, (2) recovery path in Fig. 43.11,

the system assumes the recovery of a number of parts

from the ﬁrst stage and focuses on the recovery path

required for these removed components. The two main

recovery paths that any component can now take are:

remanufacturing (i.e., retooling of a part to original

quality levels; normally performed at the BOL phase)

or reuse (i.e., use of the part in the secondary mar-

ket; the part ﬂow path is to the MOL if this is the

case). Using the information derived from the PEIDs

located on the recovered parts, the DSS can direct the

user to the optimal recovery path for each of the re-

moved parts; this is performed by a set of algorithms

that use the usage statistics on the PEIDs of the recov-

ered parts to determine the correct recovery path for

each component (the particular algorithms are not de-

tailed as they are beyond the scope of this paper). Once

the recovery method is issued, the systemwill cooperate

with its back-end system to suggest a potential down-

stream customer and potential storage position for the

component. Again, at each decision-making stage, the

decision-maker has the authority to change the decision

based on their judgement. When all of the decisions re-

lating to the ELV are settled, the system records all the

necessary information to the PDKM system, which is

availableto theBOL designers of thevehicle inquestion

for examination.

43.5 Emerging Trends and Open Challenges

Total management of the product lifecycle is critical to

innovatively meet customer needs throughout its entire

lifecycle without driving up costs, sacriﬁcing quality or

delaying product delivery. For this, it is necessary to

develop a PLM system inwhich informationﬂow is hor-

izontally and vertically closed, i.e., closed-loop PLM.

The closed-loop PLM system provides opportunities to

reduce the inefﬁciency of lifecycle operations and gain

competitiveness.

In this chapter, we have also discussed a system

architecture for product lifecycle management where

information ﬂows are closed due to emerging product

Part E 43.5

764 Part E Automation Management

identiﬁcation technology over the whole product lifecy-

cle (closed-loop PLM). To gather product lifecycle data

during all product lifecycle phases, the concept and ar-

chitecture of PEID has been introduced. Furthermore,

necessary software components and their relations have

been addressed.

The following is a list of issues to be resolved for

implementing the closed-loop PLM concept:

•

In the business model aspect, it is necessary to de-

velop a good business model to apply the concept of

closed-loop PLM for optimizing the proﬁt of a com-

pany. For this, trade-off analysis for cost and effect

are prerequisite. Depending on each case, partial

implementation of closed-loop PLM may be cost-

effective.

•

Regarding the PEID, it is necessary to develop

a generic concept of a PEID that can be used over

the whole product lifecycle. For this, however, ﬁrst,

the lifecycle of the PEID, including reuse, should

be modeled. Based on this design, suitable PEIDs

should be designed, because the great bottleneck to

deployment of PEID into business applications is

their cost.

•

In terms of middleware, it is a prerequisite to

develop a method for managing and controlling

enormous amounts of PEID event data. Methods

for ﬁltering huge amounts of event data and trans-

forming them into meaningful information should

be developed. Furthermore, PEID security and au-

thority problems should be resolved.

•

In terms of PDKM, it is a prerequisite to design

the product lifecycle data schema for integrating

all relevant data objects required in lifecycle oper-

ations.

Finally, the case studies developed so far in the

PROMISE project show that the proposed concept can

yield great beneﬁt to product lifecycle optimization ef-

forts.

References

43.1 F. Ameri, D. Dutta: Product life cycle management:

needs, concepts and components, Technical Re-

port (Product Lifecycle Management Development

Consortium PLMDC-TR3-2004, 2004)

43.2 M. Macchi, M. Garetti, S. Terzi: Using the PLM ap-

proach in the implementation of globally scaled

manufacturing, Proc. Int. IMS Forum 2004: Global

Challenges in Manufacturing (2004)

43.3 H.B. Jun, D. Kiritsis, P. Xirouchakis: Closed-loop

PLM. In: Advanced Manufacturing – An ICT and Sys-

tems Perspective, ed. by M. Taisch, K.-D. Thoben,

M. Montorio (Taylor & Francis, London 2007)

pp. 90–101

43.4 H.B Jun, J.H Shin, D. Kiritsis, P. Xirouchakis: Sys-

tem architecture for closed-loop product lifecycle

management, Int. J. Comput. Integr. Manuf. 20(7),

684–698 (2007)

43.5 H.B. Jun, J.H. Shin, Y.S. Kim, D. Kiritsis,

P. Xirouchakis: A framework for RFID applications in

product lifecycle management, Int. J. Comput. In-

tegr. Manuf. (2007), DOI: 10.1080/09511920701501753

43.6 D.Kiritsis,A.Bufardi,P.Xirouchakis:Research

issues on product life cycle management and infor-

mation tracking using smart embedded systems,

Adv. Eng. Inform. 17, 189–202 (2003)

43.7 D. Kiritsis, A. Rolstadås: PROMISE – a closed-loop

product life cycle management approach, Proc. IFIP

5.7 Adv. Prod. Manag. Syst.: Model. Implement.

Integr. Enterp. (2005)

43.8 A.K. Parlikad, D. McFarlane, E. Fleisch, S. Gross:

The role of product identity in end-of-life decision

making, Technical Report (Auto-ID Center, Institute

of Manufacturing, Cambridge 2003)

43.9 M. Schneider: Radio frequency identiﬁcation (RFID)

technology and its application in the commercial

construction industry, Technical Report (University

of Kentucky, 2003)

43.10 S.S. Chawathe, V. Krishnamurthy, S. Ramachan-

dran, S. Sarma: Managing RFID data, Proc. 30th

VLDB Conf. (2004) pp. 1189–1195

43.11 T. Nieva: Remote data acquisition of embedded

systems using Internet technologies: a role based

generic system speciﬁcation. Ph.D. Thesis (EPFL,

Lausanne 2001)

43.12 Z. Gsottberger, X. Shi, G. Stromberg, T.F. Sturm,

W. Weber: Embedding low-cost wireless sensors

into universal plug and play environments, Proc.

1stEur.WorkshopWirel.Sens.Netw.(EWSN04)

(2004) pp. 291–306

43.13 J. Lee, H. Qiu, J. Ni, D. Djurdjanovic: In-

fotronics technologies and predictive tools for

next-generation maintenance systems, Proc. 11th

Symp. Inf. Control Probl. Manuf. (Elsevier, 2004)

43.14 C.M.Rose,A.Stevels,K.Ishii:Anewapproachto

end-of-life design advisor (ELDA), Proc. 2000 IEEE

Int. Symp. Electr. Environ. (ISEE 2000) (2000)

43.15 PROMISE: PROMISE – integrated project: annex I –

description of work, Project proposal (2004)

43.16 G. Hackenbroich, Z. Nochta: A process ori-

ented software architecture for product life cycle

management, Proc. 18th Int. Conf. Prod. Res.

(2005)

Part E 43