DR3.2 PROMISE Demonstrators & State-of-the-art · DR3.2 PROMISE Demonstrators & State-of-the-art...

Copyright © PROMISE Consortium 2004-2008

DR3.2 PROMISE Demonstrators & State-of-the-art DELIVERABLE NO DR3.2: PROMISE Demonstrators

DATE 13. May 2005

WORK PACKAGE NO WP R3

VERSION NO. 1.0

ELECTRONIC FILE CODE dr3_2 promise demonstrators~1.doc

CONTRACT NO 507100 PROMISE A Project of the 6th Framework Programme Information Society Technologies (IST)

ABSTRACT: This report summarizes the PROMISE work-package R3 deliverable DR3.2 The PROMISE Demonstrators. The purpose of this document is to present state-of-the-art within the following fields:

PEIDs and RFIDs Hardware aspects PEIDs and RFIDs Other aspects Data Management Software Decision support systems PDM/PLM

Further, to present the PROMISE Demonstrators A1 to A11. The PROMISE Demonstrators in this document form the basis for further work in subsequent work-packages of the PROMISE project

STATUS OF DELIVERABLE

ACTION BY DATE (dd.mm.yyyy)

SUBMITTED (author(s)) Carl Christian Røstad and Odd Myklebust 13.05.2005

VU (WP Leader) Odd Myklebust 13.05.2005

APPROVED (QIM) D. Kiritsis 15.05.1005

Edited by: Carl Christian Røstad, SINTEF Technology and society Odd Myklebust, SINTEF Technology and society

Copyright © PROMISE Consortium 2004-2008 Page ii

@

Revision History

Date (dd.mm.yyyy)

Version Author Comments

09.05.2005 0.1 Carl Christian Røstad Draft version for the Final Editorial meeting in Lausanne

13.05.2005 1.0 Carl Christian Røstad & Odd Myklebust Final version submitted

Author(s)’ contact information Name Organisation E-mail Tel Fax Carl Christian Røstad SINTEF Technology &

Society [email protected] +47 73593046 +47 73551326

Odd Myklebust SINTEF Technology & Society

[email protected] +47 73597120 +47 73551326

Copyright © PROMISE Consortium 2004-2008 Page 1

@

Table of Contents 1 PURPOSE OF THIS REPORT ..........................................................................................................................5

PART I: INTRODUCTION ...........................................................................................................................................7

2 OBJECTIVES AND THE PROCESS OF PREPARING THE DELIVERABLE..........................................8 2.1 OBJECTIVES OF WORK-PACKAGE R3..............................................................................................................8 2.2 DERIVED OBJECTIVES OF DELIVERABLE, DR3.2, BASED ON THE TASK DESCRIPTION AND IDENTIFIED CHALLENGES ...............................................................................................................................................................9 2.3 STRUCTURE OF THIS REPORT AND THE PROCESS OF PREPARING THE DELIVERABLE DR3.2 ..........................10

2.3.1 Part I – Introduction ..............................................................................................................................10 2.3.2 Part II – State-of-the-art chapters .........................................................................................................10 2.3.3 Part III – The PROMISE Demonstrators...............................................................................................10 2.3.4 Part IV – Concluding remarks...............................................................................................................10

PART II: STATE-OF-THE-ART ................................................................................................................................11

3 INTRODUCTION TO THE STATE-OF-THE-ART CHAPTERS...............................................................13

4 EMBEDDED DEVICES AND RFIDS, HARDWARE ASPECTS.................................................................14 4.1 STATE OF THE ART, EMBEDDED DEVICES .....................................................................................................14

4.1.1 Power supplies.......................................................................................................................................14 4.1.2 Communication with onboard & outside (near field and distance) .......................................................15

4.2 STATE-OF-THE-ART OF RFID ......................................................................................................................16 4.2.1 Different alternatives .............................................................................................................................16 4.2.2 Standards available and under development .........................................................................................17 4.2.3 Reader technologies...............................................................................................................................18 4.2.4 Technology limitations...........................................................................................................................18

4.3 PARTNER’S PRODUCTS.................................................................................................................................19 4.3.1 Infineon ..................................................................................................................................................19

5 EMBEDDED DEVICES AND RFIDS, OTHER ASPECTS ..........................................................................20 5.1 CURRENT PRACTICES...................................................................................................................................20

5.1.1 RFID systems today ...............................................................................................................................20 5.1.2 Embedded device systems today ............................................................................................................21

5.2 UNIQUE IDENTIFICATION .............................................................................................................................21 5.2.1 Identification of embedded device..........................................................................................................21

5.3 ORGANIZATIONAL ISSUES............................................................................................................................21 5.3.1 Organisational impacts..........................................................................................................................21 5.3.2 New ways of doing business, current important discussions related to the technology.........................22

6 DATA MANAGEMENT ...................................................................................................................................23 6.1 INTRODUCTION............................................................................................................................................23 6.2 CURRENT PRACTICES ..................................................................................................................................24

6.2.1 Process oriented and product (object) oriented approaches .................................................................24 6.2.2 Identification..........................................................................................................................................26

6.3 DATA GENERATION .....................................................................................................................................26 6.3.1 Notifications from the Field ...................................................................................................................26 6.3.2 Commands to the reader........................................................................................................................26 6.3.3 Object Level Events ...............................................................................................................................27 6.3.4 Business Level Events ............................................................................................................................27

6.4 DATA STORAGE...........................................................................................................................................27 6.4.1 RFID Tag ...............................................................................................................................................27 6.4.2 RFID Reader..........................................................................................................................................28 6.4.3 Middleware ............................................................................................................................................28 6.4.4 Backend System......................................................................................................................................29

6.5 DATA PROCESSING ......................................................................................................................................29


@

6.5.1 RFID tag ................................................................................................................................................29 6.5.2 RFID reader...........................................................................................................................................29 6.5.3 Middleware – data processing...............................................................................................................30 6.5.4 Backend System......................................................................................................................................30

7 SOFTWARE.......................................................................................................................................................32 7.1 STATE-OF-THE-ART OF RELEVANT SOFTWARE............................................................................................32

7.1.1 Middleware – vendors and producers ...................................................................................................32 7.1.2 Automatic Identification (Auto-ID) infrastructure software ..................................................................33

7.2 PARTNER’S PRODUCTS.................................................................................................................................36 7.2.1 SAP ........................................................................................................................................................36 7.2.2 Stockway ................................................................................................................................................38 7.2.3 DIALOG project (HUT).........................................................................................................................39

8 DECISION SUPPORT SYSTEMS...................................................................................................................40 8.1 INTRODUCTION............................................................................................................................................40 8.2 CURRENT PRACTICES IN BOL......................................................................................................................42

8.2.1 Production systems ................................................................................................................................42 8.3 CURRENT PRACTICES IN MOL.....................................................................................................................45

8.3.1 Diagnostic and prognostics ...................................................................................................................46 8.3.2 Reliability...............................................................................................................................................48

8.4 CURRENT PRACTICES IN EOL ......................................................................................................................48 8.4.1 Input.......................................................................................................................................................49 8.4.2 Processing..............................................................................................................................................51 8.4.3 Storage...................................................................................................................................................56 8.4.4 Output ....................................................................................................................................................60 8.4.5 Conclusions............................................................................................................................................62

9 PLM TECHNOLOGY.......................................................................................................................................63 9.1 INTRODUCTION............................................................................................................................................63 9.2 PREVIOUS RESEARCH...................................................................................................................................63

9.2.1 General enterprise modeling method.....................................................................................................63 9.2.2 PLM related modeling method...............................................................................................................64

9.3 STATE-OF-THE-ART OF PLM USAGE ...........................................................................................................65 9.3.1 Penetration in Industry ..........................................................................................................................65 9.3.2 System Introduction ...............................................................................................................................65 9.3.3 Functionality..........................................................................................................................................66 9.3.4 Integration and Interfaces......................................................................................................................67 9.3.5 System Architecture ...............................................................................................................................67 9.3.6 Use of PLM Technology.........................................................................................................................68

PART III: THE PROMISE DEMONSTRATORS ....................................................................................................69

10 INTRODUCTION TO THE PRESENTATION OF THE DEMONSTRATORS........................................71 10.1 PARTICIPANTS IN THE WP R3 AND FOCUS AREA OF DEMONSTRATORS........................................................71 10.2 THE STRUCTURE OF THE DEMONSTRATOR DOCUMENTS IN APPENDIX A......................................................72

11 A1 CRF (EOL) – PASSENGER CAR ..............................................................................................................73 11.1 A1 – THE DEMONSTRATOR .........................................................................................................................73 11.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A1 CRF EOL DEMONSTRATOR ............................................74

12 A2 CAT (EOL) – ENGINE IN TRACK TYPE TRACTOR (TTT)...............................................................75 12.1 A2 – THE DEMONSTRATOR .........................................................................................................................75 12.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A2 CAT DEMONSTRATOR ....................................................76

13 A3 BIBA/INDYON (EOL) - INFORMATION MANAGEMENT FOR TRACKING AND TRACING OF MATERIALS IN RECYCLING PLANT..................................................................................................................76

13.1 A3 – THE DEMONSTRATOR .........................................................................................................................76 13.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A3 BIBA/INDYON DEMONSTRATOR..................................77

14 A4 CRF (MOL) - TRUCK.................................................................................................................................78


@

14.1 A4 – THE DEMONSTRATOR .........................................................................................................................78 14.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A4 CRF MOL DEMONSTRATOR ...........................................79

15 A5 CAT (MOL) – LIFT ARM OF THE GRENOBLE TRACK TYPE LOADER (TTL)...........................80 15.1 A5 – THE DEMONSTRATOR .........................................................................................................................80 15.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A5 CAT MOL DEMONSTRATOR...........................................80

16 A6 FIDIA (MOL) - MILLING MACHINE .....................................................................................................81 16.1 A6 – THE DEMONSTRATOR .........................................................................................................................81 16.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A6 FIDIA DEMONSTRATOR .................................................82

17 A7 MTS (MOL) - CONDENSING WALL HUNG GAS BOILERS..............................................................82 17.1 A7 – THE DEMONSTRATOR .........................................................................................................................82 17.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A7 MTS DEMONSTRATOR....................................................83

18 A8 WRAP (MOL) – REFRIGERATOR ..........................................................................................................84 18.1 A8 – THE DEMONSTRATOR .........................................................................................................................84 18.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A8 WRAP DEMONSTRATOR.................................................85

19 A9 INTRACOM (MOL) –TELECOM EQUIPMENT ..................................................................................85 19.1 A9 – THE DEMONSTRATOR .........................................................................................................................85 19.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A9 INTRACOM DEMONSTRATOR.......................................86

20 A10 BOMBARDIER TRANSPORTATION (BOL) – TRACTION CHAIN OF ELECTRICAL LOCOMOTIVE...........................................................................................................................................................86

20.1 A10 – THE DEMONSTRATOR .......................................................................................................................86 20.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A10 BT-LOC DEMONSTRATOR............................................87

21 A11 POLIMI (BOL) – DECISION SUPPORT FOR INTRODUCING CHANGES IN A PRODUCTION SYSTEM.......................................................................................................................................................................88

21.1 A11 – THE DEMONSTRATOR .......................................................................................................................88 21.2 OVERVIEW OF THE FUNCTIONALITIES OF THE A11 POLIMI DEMONSTRATOR ............................................89

PART IV: CONCLUDING REMARKS .....................................................................................................................91

22 CONCLUDING REMARKS TO THE WORK-PACKAGE R3, DELIVERABLE DR3.2 .........................93

REFERENCES AND APPENDIX.............................................................................................................................95

23 REFERENCES...................................................................................................................................................97 APPENDIX A: THE PROMISE DEMONSTRATORS…………………………………………………………..101 APPENDIX B: THE APPLICATION SCENARIOS FROM DELIVERABLE DR3.1………………………...237


@


@

1 Purpose of this report This report summarizes the PROMISE work-package R3 deliverable DR3.2 The PROMISE Demonstrators. In addition to summarizing the developed demonstrators (A1 to A11) the report also presents state-of-the-art knowledge within the following fields:

PEIDs and RFIDs Hardware aspects PEIDs and RFIDs Other aspects Data Management Software Decision support systems PDM/PLM

The state-of-the-art chapters in Part II of this report, cover important aspects identified during the time-span of work-package R3 (month 1 to month 6 of the PROMISE project) were state-of-the-art knowledge was needed. As such, the chapters found in Part II of this report, serves as an introduction to some of the important aspects of the PROMISE project. The PROMISE Demonstrators A1 to A11 in Part III of this report form the basis for further work in the application clusters (AC-1 to AC-3) and are input to various subsequent application work-packages of the PROMISE project. As such, all information related to the demonstrators contained in this report is subject for further development in these work-packages. The application scenarios, which were part of the deliverable DR3.1 and presented in the respective PROMISE deliverable report, have been included in Appendix B of this report in order to facilitate easy access to all results from work-package R3. Appendix B has also been included because some of the application scenarios were modified and updated after the deliverable DR3.1 was delivered and work with DR3.2 showed the need for some updates to be carried out. These specific application scenarios are: A3 BIBA/INDYON, A6 FIDIA, A9 INTRACOM and A11 POLIMI.


@


@

PART I: INTRODUCTION


@

2 Objectives and the process of preparing the deliverable

2.1 Objectives of work-package R3 The basis for this report is found in the Description of work (DoW) of the PROMISE project, and the related description of tasks and objectives for work-package R3, task TR3.2. The DoW states: Work in WP R3 involves, in the context of the activities of the cluster RC-1, the definition of application scenarios to be used in the definition of requirements and specifications and the definition of demonstrators to be used for testing and evaluation of the PROMISE system and its components. Both, application scenarios and demonstrators will be provided by the end user partners. Task TR3.1: Definition of application scenarios Activities of task TR3.1 produced contributions to deliverable DR3.1, delivered on month 3 of the PROMISE project. After the work with task TR3.2 (see below) commenced, some partners adjusted their application scenarios. These were: A3 BIBA/INDYON, A6 FIDIA, A9 INTRACOM and A11 POLIMI. Therefore, it was decided to include all the application scenarios in Appendix B of this report. This also reflects the nature of the all the results of work-package R3, namely that the results form the basis for further work and refinement. The application scenarios were the first steps towards developing the PROMISE demonstrators in task TR3.2. The task TR3.1 is described as follows in the DoW: A number of application scenarios reflecting the needs and wishes of partners representing various application sectors will be defined. The activities to be performed in this task are:

Definition of a method, including use of diagrams, drawings etc. and associated document structure to present application scenarios,

Definition of application scenarios by the PROMISE end-users; consulting of various departments within the company may be necessary,

Documentation of application scenarios in formal document forms. Task TR3.2: Definition of PROMISE demonstrators The activities of task TR3.2 are the basis for this report. The resulting PROMISE demonstrators are defined as the deliverable DR3.2. All the developed demonstrators are presented in Appendix A of this report, and form the basis for further work in the associated application cluster activities starting in month 7 of the PROMISE project. The task TR3.2 is described as follows in the DoW: Based on the defined application scenarios and the PROMISE specifications developed in WP R1 and preliminary versions of PROMISE models developed in WP R21, the definition of a number of PROMISE demonstrators will be produced. These definitions will be used for the detailed design of the demonstrators to be developed in the associated Application Cluster activities. The activities to be performed in this task are:

Identification of appropriate products or components to be used for the demonstrators, Definition of the demonstrator, including a description of the product or component, the

functionality of the demonstrator and the interfaces, Documentation of the demonstrators.

1 As WP R2 starts in month 7 of the PROMISE project, it has been impossible to base the work of R3 on the preliminary models of R2. This is an error in the DoW.


@

2.2 Derived objectives of deliverable, DR3.2, based on the task description and identified challenges

Based on the task TR3.2 description and identified challenges during the time-span of the work-package R3, the following were set as the objectives for deliverable DR3.2:

1. Give an overview of various related technical aspects to PROMISE in relation to the various Demonstrators. Keyword: State-of-the-art within: PEIDs, RFIDs, Software, middleware, Decision support systems, Data management, Product Lifecycle management (PLM), Product Data management (PDM). This state-of-the-art chapters were needed, in order to create a common understanding among the many participants in the PROMISE project.

2. In addition to the necessary input and cooperation with work-package R1, work-package R3 is to refine and utilise the Application Scenario Descriptions from DR3.1 and use these as background for: Identification of appropriate products or components to be used for the demonstrators. Definition of the demonstrator, including a description of the product or component, the functionality of the demonstrator and the interfaces. All this should lead to the documentation of the demonstrators.

3. Include all the application scenarios as some has been modified due to needs identified in task 3.2. The updated application scenarios were: A3 BIBA/INDYON, A6 FIDIA, A9 INTRACOM and A11 POLIMI. This emphasizes the notion that the results from work-package R3 are dynamic and are subject for updates as the PROMISE project progresses.

All three of these objectives were fulfilled. State-of-the-art chapters are presented in Part II of this report, while the PROMISE Demonstrators are presented in Part III and in Appendix A of this report. The application scenarios are presented in Appendix B.


@

2.3 Structure of this report and the process of preparing the deliverable DR3.2 This deliverable consists of four parts, where the PROMISE Demonstrators (found in Part III and Appendix A of this report) are considered to fulfil the objective stated in the PROMISE Description of Work (DoW), task TR3.2.

2.3.1 Part I – Introduction This is the introduction part of the report which states the objectives and contents of the report (this part).

2.3.2 Part II – State-of-the-art chapters Deliverable DR3.1, the application scenarios (found in Appendix B), was the main basis for preparing the PROMISE demonstrators. The application scenarios identified some areas that were needed to be better understood by the partners in the project, therefore it was decided that deliverable DR3.2 should include state-of-the-art chapters related to these areas. These state-of-the-art chapters are found in Part II of this report. The process behind this part was initiated when the PROMISE project realised the need for creating a common understanding of some of the key-aspects related to the technology and systems that are needed in this project. The state-of-the-art chapters were decided upon in a PROMISE meeting, and responsibilities for each part were divided between the relevant partners. Stockway had the overall editorial responsibility of Part II and coordinated the work. Infineon, Stockway, SAP, CRF, Polimi, Inmediasp and EPFL contributed and wrote the various chapters.

2.3.3 Part III – The PROMISE Demonstrators Part III of the report presents the demonstrators developed as the main delivery of DR3.2. The full versions of the demonstrators are found in Appendix A. The PROMISE demonstrators were prepared by the following method.

First, a Demonstrator Draft document was prepared based on the feedback received regarding the application scenarios. The Demonstrator Draft were also based on the feedback from partners stating their needs to be covered by the demonstrator for work in subsequent work-packages.

The draft was then distributed to all partners in work-package R3, and each responsible partner of WP A1 to A11 were asked to complete the draft and give feedback

All drafts were completed, and these were used as background for the Munich PROMISE meeting 11th and 12th of April 2005 were all partners involved in work-package R3 met and discussed their versions of the demonstrators based on the draft.

Based on the Munich meeting and the discussions there, a revised Demonstrator document were prepared and distributed.

All demonstrators were completed and returned SINTEF SINTEF then went through the received demonstrators and requested updates from the

partners were needed The demonstrators were then completed and draft illustrations of the functionalities

identified were prepared The final demonstrators were then included in this report.

2.3.4 Part IV – Concluding remarks Part IV presents the concluding remarks related to this deliverable and the contents found in this report.


@

PART II: STATE-OF-THE-ART


@


@

3 Introduction to the state-of-the-art chapters This part of the deliverable shows the current state-of-the-art of hardware and software systems related to RFID, embedded devices and supply / value chain communication. This part also sheds some light on related application areas of today. In each section, the relevant technologies of PROMISE partners are presented. This part is meant to clarify what is possible to do with the technology of today, how systems today functions and what knowledge and experiences PROMISE partners have. The following partners prepared the State-of-the-art chapters found in Part II of this report.

Table 1: State-of-the-art chapters and responsible partner Focus of State-of-the-art chapter Responsible partner Embedded devices and RFIDs Hardware aspects INFINEON Embedded devices and RFIDs Other aspects STOCKWAY Data Management STOCKWAY and SAP Software SAP Decision support systems CFR/POLIMI PLM Technology INMEDIASP/EPFL The first section goes through different hardware technologies, embedded devices and RFID. The second section briefly brings up some other aspects on embedded devices and RFIDs. The third section goes through data management in RFID systems today, describes the data exchanged, etc. The fourth section handles different software and software architectures related to RFID and unique identification, automatic identification infrastructures, etc. The fifth section goes through decision support systems and their usage today. The last section goes through Product Lifecycle Management systems of today. Some important abbreviations used in Part II are explained in Table 2.

Table 2: Abbreviations used in Part II State-of-the-art Abbreviation Descrtiption BOL Beginning of Life Embedded device

Device embedded to a product. It stores and communicates information such as identity and history to the outside world.

EOL End of Life ERP Enterprise Resource Planning MOL Middle of Life PDM Product Data Management PEID Product Embedded Identification Device. Content similar to that of embedded device. A term introduced in the

Promise project. PLM Product Life-cycle Management PML Physical Mark-up Language RFID Radio Frequency Identification


@

4 Embedded devices and RFIDs, Hardware aspects In the following, the hardware aspects of RFID and embedded devices are discussed. The first section addresses common power consumption and communication issues of embedded devices, while the latter part focuses on state-of-the-art properties of RFID tags. 4.1 State of the art, embedded devices This section brings up the aspects of embedded devices where PROMISE partners have knowledge. It handles power supply issues for embedded devices and discusses embedded device communication.

4.1.1 Power supplies For active or semi-active embedded devices a power supply will be necessary. The highest energy density is achieved by Li-Ion batteries (approx. 180Wh/kg). Also rechargeable batteries have to be considered. These solutions are quite expensive and not service-free. RFID Tags with integrated printable batteries and temperature sensor are already commercially available. They are used for cool chain monitoring. However, these low-cost printable batteries possess a relatively low energy density and a very limited life time compared to standard batteries2. Ambient energy exploitation gives the possibility of service-free and active concepts. Following methods for energy harvesting are feasible:

• Solarcells: Energy conversion with an efficiency of typically 15%, low-cost, need direct light, preferable sun light

• Piezo-electric energy conversion (enOcean): production of electric energy out of process energy (pressure, vibration, temperature) with implemented RF transmission of 10mW at 868MHz, coverage 300m outdoor, 30m in-house. 3

• Thermoelectric generators: Harvesting of electrical energy out of a temperature difference (Seebeck effect), unlimited lifetime, efficiency below 1%, interesting at temperature differences >10°C. 4

2 http://www.rfidjournal.com/article/view/441/1/1 3 http://www.enocean.de 4 http://www.therm-o-tech.de


@

4.1.2 Communication with onboard & outside (near field and distance) Several technologies for wireless communication in Wide Area Networks (WANs), Local Area Networks (LANs) and Personal Area networks (PANs) have been developed. Examples for WANs are cellular networks for mobile telecommunications. The family of IEEE 802.11- standards, also known as WiFi, addresses LANs. Bluetooth is a well-known PAN, originally developed to wirelessly link computers with components like printers, keyboards, etc. A non-exhaustive list of standards see table below. 5 6 7

Table 3: List of wireless standards

Denominator Name Digital 2G Global System for Mobile Communications - GSM Digital 2,5G General Packet Radio Service - GPRS IEEE. 802.11a

(WiFi) transmits at a frequency of 5 GHz with data rates of 54 Mbps using Orthogonal Frequency Division Multiplexing [OFDM]

IEEE. 802.11b

(WiFi) transmits at a frequency of 2.4 GHz with data rates of 11 Mbps using direct sequence spread spectrum modulation.

IEEE. 802.11g

Transmits at a frequency of 2.4 GHz with data rates of 54Mbps. IEEE 802.11b and 802.11g are compatible so devices can coexist in the same network.

IEEE 802.15.1

Bluetooth transceivers operate in the 2.4GHz ISM band. The frequency range is 2400MHz to 2483.5MHz [in most countries]. The channel spacing is 1MHz, with an upper and lower guard band. Output power is also specified. Bluetooth uses GFSK [Gaussian Frequency Shift Keying] as its modulation. The symbol rate is 1Msps

IEEE 802.15.4

Zig-Bee, low-data-rate WPAN technology, with multimonth to multi year battery life and very low complexity. 802.15.4-2003 will operate in an unlicensed, international frequency band. Potential applications are sensor, interactive toys, smart badges, remote controls and home automation.

ISM 868MHz Defines RF link/communication. It is valid for passive tags that receive energy and information from the interrogator. Although tag data are partially specified they are not used in the Sindrion™ technology.

5 http://www.wi-fi.org 6 http://www.bluetooth.com 7 http://www.zigbee.org


@

4.2 State-of-the-art of RFID This chapter goes through the current state of RFID technology, technical options and limitations on RFID technology. Different RFID alternatives and standards are discussed.

4.2.1 Different alternatives

4.2.1.1 Active / passive RFID tags Regarding the power supply RFID tags can be divided in two different classes: Active and passive tags:

• Passive tags don’t have an own power supply. These tags are essentially woken up when they come in the range of a reader system that sends out radio wave queries. Directing these radio signals onto the tag antenna causes it to couple to the electro magnetic field and hence generate a small amount of energy. This energy allows the chip to operate and to transmit its information to the reader. Passive tags can be very small and are comparatively cheap but suffer from a short read range.

• Active tags incorporate a battery so that the tag can continuously interact with the reader system. The battery power significantly increases the transmission distance of the response to the reader. The disadvantages of active tags are the increased size and cost and the fact that battery life (in most cases) determines the life-span of the tag.

• So called semi-active tags also incorporate a battery, but battery power is only used to power the chip, not to enhance communications with the reader. Tags with sensor function to gage physical measures like temperature, pressure and acceleration also belong to this class of tags. Here the battery is used to power the sensors.

4.2.1.2 Read/Write capability The RFID tags’ capability to carry data and have that data amended or updated is defined by the read-write characteristics of the chip:

• Read-only tags contain an identifier such as a serial number that is programmed onto the chip during its manufacture. This identifier remains constant throughout the lifetime of the tag. Neither adding of data nor overwriting the identifier is possible. Read-only tags are generally the least expensive but have the limitation of acting only like a barcode acts.

• A write-once-read-many tag allows users to add data onto the chip beyond the unique identifier, but data can be added only once. There is no limit to how many times the data can be read.

• Read-write tags are open to data manipulation by the users without restrictions. These chips will still contain a unique identifier from the chip manufacturer, but can also carry an updateable memory where data can be added to the chip. Read-write tags are generally more expensive than the other types because of their versatility.


@

4.2.1.3 Frequency areas An important parameter of an RFID system is the radio frequency used for the reader-tag-communication. Some different frequencies are currently in use for RFID applications. Each frequency has advantages and disadvantages relative to its capabilities. Generally a lower frequency means a lower read range, slower data transmission rate, but increased capabilities for reading near or through metal or liquid surfaces that distort radio waves.

• Low frequency (LF): <135kHz

Frequencies in the worldwide ISM (Industrial-Scientific-Medical) frequency range:

• High frequency (HF): 13,56MHz

• Ultra high frequency (UHF): 869MHz (Europe), 915MHz (USA)

• Microwave: 2,45GHz

In addition there are some more frequencies locally accredited for RFID systems and frequencies for very special niche applications.

Today the majority of RFID transponders operate at 13,56Hz. However, the demand for UHF transponder is growing. Especially the retail industry, which is looking for greater reading distance and better anti-collision properties, is promoting this frequency.

4.2.1.4 Memory capacity If RFID transponders are classified according to size of data memory there is also a broad spectrum of variants. The required memory size is directly defined by the designated application. The bottom end is represented by EAS (Electronic Article Surveillance) systems. These are more or less one-bit systems which simply check the presence of a respective transponder in the interrogation zone of a reader device. On the other end of the spectrum there is virtually no limit for memory capacity. Of course, chip size, power consumption and price of RFID tags are increasing with increasing memory. A typical value for high end contactless smart cards is a memory size of 64kB. In most cases the on-chip memory unit is technically realized as EEPROM (Electrically Erasable Programmable Read Only Memory).

4.2.2 Standards available and under development

4.2.2.1 ISO standards Several international standards regularizing design (e.g. size), functioning (e.g. frequency, data transfer protocol), and data format (e.g. numbering system) of RFID transponders are already available or under development. Within the most important are:

• ISO 11784/11785/14223: Radio-frequency identification of animals

• ISO 10536: Contactless smart cards: Close coupling

• ISO 14443: Contactless smart cards: Proximity coupling

• ISO 15693: Contactless smart cards: Vicinity coupling

• ISO 10374: Container identification

• ISO 15961/15962/15963/18000: RFID for item management

A more detailed summary of relevant standards is given in the deliverable DI1.1: PROMISE related standardization activities.


@

4.2.2.2 EPC EPCglobal, a non-profit organization formed by the Uniform Code Council (UCC) and EAN International to commercialize EPC technology from MIT’s Auto-ID Center, is leading to push toward a strong foundation of standards in supply chain based RFID initiatives.

4.2.3 Reader technologies

The RFID reader market is just as large and diverse than the tag market. A huge variety of different reader devices is available differing in basic design (fixed or handheld), operating frequency, antenna configuration and technological complexity. High end readers possessing processors, adequate memory capacity, and dedicated software function as minicomputers. These readers include USB and serial ports and are able to interface with LAN and WLAN environments.

The read range strongly depends on several parameters like frequency, antenna configuration, available RF power and of course the particular tags to be read. For readers operating in the HF region a typical read range is 10-20cm.

A large number of manufacturers are competing in the reader market, e.g.:

• SAMSys Technologies Inc. www.samsys.com

• Symbol Technologies Inc. www.symbol.com

• Nordic ID www.nordicid.com

• Feig Electronic GmbH www.feig.de

• SkyeTek Inc. www.skyetek.com

• OmniTek www.omnitek.com

• BALTECH AG www.baltech.de

4.2.4 Technology limitations

4.2.4.1 Life time - EEPROM: Data retention specification: 10 years,

4.2.4.2 Battery

- Expensive

- In most cases not exchangeable

- Determines the life span of the tag


@

4.2.4.3 Physical environment - Temperature: Typical specification for e.g. smart cards: -25 - +70°C

- Mechanical stress: Depends on packaging

- Metal environment: Metal environment has negative impact on RFID functioning

- Area: Depending on the antenna design the tag size is up to several square centimeter

4.3 Partner’s products

4.3.1 Infineon

4.3.1.1 Sindrion Sindrion™ is a hardware/software architecture for the integration of simple, low-power and low-cost sensors and actuators into Universal Plug and Play (UPnP) environments for Ubiquitous Computing. The architecture defines interfaces for wireless point-to-point connections between so-called Sindrion Transceivers and dedicated computing terminals. The key principle of the Sindrion system is sourcing out complex data processing from the Sindrion Transceivers to the terminals. Thus, the transceivers are kept small, low-power and low-cost.

Sindrion Transceivers consist of a simple microcontroller with limited computing power and memory, and of low cost RF transceivers. Using standard input and output ports, Sindrion Transceivers are connected to arbitrary peripherals ranging from small sensors to home appliances.

Sindrion Transceivers are active smart tags dedicated towards low power consumption of significantly less than 1mW while simultaneously supporting RF wake-up with response times of around 0.5s. This is achieved by a layered power domains hardware architecture and dedicated networking protocols on the MAC layer.

To connect the Sindrion system to a UPnP environment, the Sindrion Transceivers meet the UPnP Basic Device standard for direct UPnP interaction. Resource-hungry UPnP control and eventing is exported by means of a downloaded proxy application to the terminal, which is a computing device with adequate computing power and memory. The proxy application maps the UPnP protocols to a simple, TCP-based, un-semantic control protocol that the Sindrion Transceivers can understand. Thereby, a proxy is established on the terminal which appears as UPnP Device and which uniquely represents the Sindrion Transceiver and its attached peripheral in the UPnP network.


@

5 Embedded devices and RFIDs, Other aspects RFID technology and embedded device systems in general are already used in wide range of applications. Identifying products automatically (RFID) has been found feasible by a number of companies such as Wal-Mart. Nevertheless a few obstacles have been identified which have to be conquered for the technology to truly break through. The way business is done nowadays (a number of companies are involved with a single product) suggests the need for information sharing amongst the companies related to each product. Yet, most of the current embedded device solutions are confined inside one company mostly because of lack of standards, trust and common practises. 5.1 Current practices

5.1.1 RFID systems today On one hand, RFID technology has found its foothold in the same application areas where bar codes and other Auto-ID technologies have been used. Applications include such examples as tagging and tracking luggage in airports, identification in passage control systems and book loaning systems in libraries to name a few. In these fields RFID is increases efficiency and enables new fields of application by introducing the abilities:

- To read multiple product identities simultaneously. - To read identities from distance without having a line-of-sight. - To interact with the product information without a human intervention.

On the other hand, RFID has opened totally new possibilities of which many are yet to be seen. The ability to store and manipulate data on the RFID tag has enabled for example smart packages, which are to ensure the identity and integrity of a product. The same functionality of RFID tags is used to store i.e. historical data about the product in which the tag is attached. Because RFID tags can be read automatically from a distance, the technology can be used to acquire positional information of an object that has a tag attached. For example a train can be located by using tags on the track and a reader attached to the train itself. Furthermore, the variety of transponders has made it possible to tag animals with a “tag” injected under their skin for identifying and tracking purposes. Current adaptors of the technology are dominantly applying RFID in closed environments, meaning that the information is gathered and used within the same company. However, it seems obvious that the true potential of RFID technology will be unleashed in open environments, where information is acquired through the life of the product. In most cases, a single product is due to cross borders of involved companies several times, which strongly implies the need to share product information beyond company borders. A common way to achieve this is needed.


@

5.1.2 Embedded device systems today A vast number of proprietary embedded systems used today can be classified as embedded devices. Loosely put, any product embedded system that holds data about an object and has means to communicate it (with or without RFID) to the outside world is an embedded device. Additionally the system may have sensors or other measurement devices which gather data about the object and on-board computing power with data storage capacity. Incorporating these features allows the embedded device to be conscious of the product it's attached to, to make decisions and to communicate with outside world. Nowadays, applications can be found in almost all types of motorized vehicles as well as in consumer electronics in the form of on-board computing unit. Somewhat depending on where the line is drawn, embedded device systems are currently widely used. Nevertheless they are usually read with a proprietary reader (often wired) and software. The data gathered is strictly confined in a closed environment of the related company, which leaves the product life-cycle loop open in most cases. 5.2 Unique identification

5.2.1 Identification of embedded device Information stored within the embedded device’s on-board memory can be split in to two categories. Firstly, the embedded device might have more or less dynamic data about the product it's attached to. Secondly, almost in every case the embedded device carries identification data that identifies the relating product. To be globally identifiable, the identification code used in embedded device must belong to universally acceptable system. This is also crucial for the fact that the product has to be identifiable throughout the whole life-span. Furthermore, the identification scheme should be backwards compatible to support current identification practises. As some products are assembled from a number of sub-products, it is only logical to links these together. The overall architecture (in respect of technology and identification) of such composite embedded device system should be considered case by case, though some general guidelines would be useful. 5.3 Organizational issues

5.3.1 Organisational impacts The development of information technologies constantly affects the way enterprises operate. Usage of new information technology improves the business and gives competitive advantages to the enterprise. First enterprise systems were typically focused on resolving one problem and were enterprise internal applications. Different applications were used for different tasks inside the company without communicating with each other, which resulted in fragmentation inside the company and complicated the communication between different departments of the company. The Internet and improvements in information communication brought internal Enterprise Resource Planning (ERP) systems, which improved the communication between different departments inside the enterprise. The information could flow more effectively and more naturally between the departments of the enterprise. But, the information flow must not stop at the border of the


@

enterprise. Most products of today are not one company products, totally manufactured, distributed and sold by the same company. More than one company is involved in the supply chain and the life-cycle of a product. Different parts are manufactured by different enterprises and put together by some other enterprise delivered and sold to the customers by other enterprises.

Communicational and structural demands on the organisation have to be taken into account when the use of embedded device systems, automized data collection and knowledge management are introduced to various processes within the organisation. Resulting information is integrated from a number of sources from different parts of a possibly vast organisation, which implies the need for open intra-organisational communication. Considering the fact that communicational issues are constantly found as one of the topmost challenges of organisational development by companies, it couldn't be stressed enough that the organisational culture has to correspond with the new form of information. Information cannot be transformed as knowledge, if the relevance and applicability of the information is not realised by the involved actors. Typically quite a few different parties are involved with a product during its life, thus, it seems imminent that product data will be handled in semi-open way in the future. A company will have to give information to get information. This is true whether the point of view is life-span of a single product or a supply-chain. Nevertheless, on organizational level this boils down to three challenges: trust, control and independence. To whom can we trust which piece of information? How do we control the information we give to others? How do we stay independent but still maintain the information links needed?

5.3.2 New ways of doing business, current important discussions related to the technology Today’s ERP systems are usually not supply chain based and gives the enterprises a hard time managing the information flow between the different parties of the supply chain. Much too often special designed systems are used to connect the ERP systems of two companies, which are both ineffective and money consuming. There is a lack in standards and common practices for exchanging inter organizational information. There is also a suspicion and a lack of trust between enterprises that makes the information sharing harder. Organizations plan their activities internally and do not have the possibility to take into consider the plans of the other participants of the supply chain. Internal planning must be combined with external planning to not shield the enterprise from the other participants in the supply chain. Real-time, accurate and relevant data help improve the performance of the whole supply chain and benefit all the enterprises in the supply chain. The new possibilities with unique ids and other capabilities of RFID tags cannot be fully explored if used only inside one company. Most systems using RFID technology of today are incompatible with each other and cannot be easily connected. There have to be frameworks and protocols to describe the inter-organizational communication, how the information is found in the network, who have access to what information and who needs to be informed about events of the products.


@

6 Data Management 6.1 Introduction The following sections give an overview of the data management in RFID systems. Figure 1 shows the general structure of such systems with RFID readers, middleware and backend systems. Data management also concerns auto-id infrastructure and data from various parties in the supply and value chain. Auto-ID infrastructure is described in the next chapter covering Software. Figure 2 shows the role of auto-id infrastructure in product data communication. First, data gathering in general is to distinguish in process and product oriented. The subsequent section deals with data generation. In the system the data are generated in different stages (field, middleware, backend) and with different content. Usually, on stages closer to the backend system the content is of higher value. Each stage and the corresponding importance of the data are explained in detail. Section 6 relates to the processing of the data. There, the abilities for data processing and therewith value uplifting in each stage of the system are discussed.

RFID Tags RFID Readers Middleware

LocalDatabase

DataWarehouse

Backend Systems

SCEM

ERPBusinessEvents

Notificationsfrom the field

Commandsto the reader

AdditionalDevices

RFID Tags RFID Readers Middleware

LocalDatabase

DataWarehouse

Backend Systems

SCEM

ERPBusinessEvents

Notificationsfrom the field

Commandsto the reader

AdditionalDevices

Figure 1: Structure of a RFID system architecture.


@

Figure 2: Auto-ID infrastructure in supply and value chain communications. Events about unique products can be delivered between involved parties. The Auto-ID infrastructure is used for product and item data communication over organizational boarders. The communication can be triggered by reader activity, backend activity, user applications, etc. 6.2 Current Practices This chapter goes through the current practices in data models and identification used in RFID systems today.

6.2.1 Process oriented and product (object) oriented approaches Pre-industrial revolution: When artisans dominated the production scene, each project was “product centric”. Materials were procured, work was carried out, delivery was made and service was given for each unique and individual product, from beginning to end. Industrial Revolution: Increased demand led to mechanization and automation, invention of “processes”. Post-industrial revolution - today: Development of automated processes continues in order to meet ever greater demands. Increased competition drives need for greater efficiency and streamlining of processes which lead to development and creation of complex process driven ERP systems.


@

Continuing increased competitive environment drives mass produced products to become “tailored” to suit individual client requirements. Processes are “tweaked” to allow various versions of the same product to be delivered. Pursuit of efficiency requires integrated collaborative supply chain management [Datta 2004]. Globalization, acquisitions and mergers place additional burden on processes to meet ever evolving landscape. Products are not the produce of just one company. Many different parties are involved in the supply and value chain of products. Products consist of parts that are products themselves. As customized products become more and more important and complex, the supply and value chain communication must be able to handle this complexity in a controlled and flexible way. There are two different approaches to product data exchange, process oriented and object oriented.

6.2.1.1 Process oriented view The process oriented view onto the data is focused on the activities that are applied to a product. This comprises, for example, the type of operation and the duration of the activities. Processes can consist of several sub processes. The process oriented view onto the data is suited for the planning of available resources and their deployment for production.

6.2.1.2 Object oriented view An object oriented approach to object data means there is a virtual object representing the physical object. The physical object can be linked to the virtual object by identification number. The same identification number used on the physical object (written on the physical object, in a RFID tag, in a barcode, etc.) can be used to find the virtual object in the value chain network. Different parties in the value chain are able to modify, add and remove data related to the object in a controlled way. The different parties providing data about the objects are information providers. Information providers can have their own view of the objects. Not everyone in the value chain sees the objects (products, items, assets, etc.) in the same way. There must be a mechanism for finding the virtual object. This can be a search mechanism that identifies the owner of the virtual object (like in WWAI), a centralized register (like ONS), etc. There should also be a mechanism to find the other information providers (In WWAI the object information includes the information providers, in EPC the Discovery Service will be used for this.). The object information of interest to a party in the supply chain can be requested from the other information providers. Object oriented approaches have been very successful in programming and software design during the last decade. An object orientated approach has also been described to suit the supply and value chain communication [M. Kärkkäinen, T. Ala-risku & K. Främling 2003]. A common way to communicate and find the virtual objects for the physical objects is one step towards a more dynamic supply and value chain where cooperation between organizations would not mean costly, complex and time consuming customized data exchange systems [S. Datta 2004].


@

6.2.2 Identification Global unique identification is one of the main requirements to be able to identify products globally. The unique identification number is not always compatible with the numbers used by the organization internal systems. Typically, links can be created between the company internal codes and the globally unique codes so that existing systems do not have to change immediately. More about coding schemas and automatic identification can be found in the section about RFID & embedded device Hardware aspects. 6.3 Data generation This section describes how and where data are generated within a RFID system. Here, data generation stands for creation of events that contain certain information on different abstraction levels. In the following two subsections two levels of abstraction for data generation are considered: in the field (e. g. warehouse) and on business level (backend). The different data sources and the corresponding output are shown in Figure 1.

6.3.1 Notifications from the Field In RFID systems, the notifications delivered from the field are considered as the lowest level for data generation. RFID readers which are installed in the real world interrogate their environment by means of radio waves. If RFID tags are in communication range a reply, containing the tag ID, is returned to the RFID reader. Different standardized protocols [EPCglobal (3), EPCglobal (4), EPCglobal (5)] are available that specify how the interrogation process and further communication have to be performed. For the communication between the RFID reader and the middleware components standards have been developed or are under development [EPCglobal (1), Auto-ID Center 2003]. They specify interfaces for the configuration of RFID readers (e. g. reader address, event filtering) and for the communication between reader and middleware during runtime (e. g. notification receiver, notification format). Data can be generated for various reasons. First, the interrogation process of the RFID reader and the corresponding communication between RFID tag and reader generates one datum. Thereby, the RFID reader either reads information from a tag (e. g. tag just occurred in range and transmits ID) or writes information onto a tag in communication range (e. g. due to command from middleware). Second, if RFID tags with the ability to sense environmental conditions are deployed the sensor tag is equipped with an energy source (e. g. battery) and samples a certain physical process surrounding the sensor. The corresponding message generation can be performed either time-triggered (after a timer elapsed) or event triggered (after value range was transcended). Third, the data is generated on a request that originates from the middleware. The generation of the required response from the RFID reader triggers the data generation in the reader.

6.3.2 Commands to the reader Beside the communication from the field up to the middleware also downward communication from the middleware to the field is possible. It is required either for configuration purpose or for commands to the RFID reader. Commands for RFID readers can be read commands (e. g. read additional information on tag X which just appeared) or commands that invoke a write operation on the tag. These commands are emitted from the middleware based on certain implemented rules. The corresponding interfaces for the transmission of commands to the RFID reader are specified in standards [EPCglobal (1)].


@

6.3.3 Object Level Events Object level events are events about unique objects and are usually handled on an inter-organizational level. Object events are usually delivered to different information providers involved in the supply or value chain of the object. The information providers are usually found using some auto-id infrastructure. Object events are possible when products are marked with unique ids and can be identified globally. Object events concerns object data or relations between objects and have timestamps. Object level events can, for example, be delivered using web services (e.g., EPC-IS) or by push type of communication (e.g., WWAI). Object events are in a central role in product lifecycle management. Product lifecycle management deals with individual products and various parties involved with that product. Events in product lifecycle management usually concerns one or only a few products, not like, for example, in supply chain management where the events may concern bigger consignments of products (deliveries, etc.). All events about objects do not necessarily trigger business processes, but are informative. Object events give a possibility to “link” data to the physical product and deliver that data to the relevant receivers in the value chain. Object events make it possible to automate and optimize the data exchange between parties in the value chain.

6.3.4 Business Level Events The next stage of events is located on business level in the middleware and above. Middleware serves for mediation of messages between different system components (e. g. applications, devices). Especially in RFID systems the middleware has to perform the mediation of notifications and events between field and business level (see Figure 1). Business events can be generated by different means. First, a notification from the field (e. g. pallet X was in communication range of gate Y) can directly invoke the generation of a business event (e. g. pallet X passed gate Y) without significant delay. The latter notification might also be aggregated with other notifications (e. g. pallet and following goods). Hence, within the middleware a rule determines when a high-level (and higher-value) business event needs to be generated. When additional information is available (e. g. in a local database, Figure 1) and rules describe policies for merging these additional information into a business event, it contains aggregated field notifications and additional (e. g. delivery specific) information. Last, business events can be generated if state changes (defined by rules) occur in the middleware. These state changes can be, for example, timers or input signals (e. g. from human interaction). 6.4 Data Storage In the RFID system several places for data storage exist. The following subsections give a detailed overview of the available storage places, starting from low-level storage (RFID tag and reader) via mid-range components (middleware) up to the backend systems.

6.4.1 RFID Tag Standards [EPCglobal (2)] define different classes of RFID tags with diverse abilities for data storage. Class 0 is the lowest class and defines read-only tags. The information has to be factory-programmed and cannot be changed after initialization. Class 1 additionally implements the capability to write on the tag at an arbitrary time after manufacturing. The identifiers on class 0/1 tags are world-wide unique and can be either 64 or 96 bits long. The data are stored non-volatile on the tag and does not need an additional power source for conservation. With current technologies it is possible to store data on class 0/1 tags for tens of years.


@

Tags corresponding to class 2 and above (class 3 and 4) are able to implement additional memory for storage. The actual amount is tag specific and can range from some bytes to several kilobytes. Additional data can be, for example, handling information (e. g. passed owners in the supply chain) or data supporting security mechanisms (e. g. keys and access rights). Depending on the technology used for the deployed memory an additional power source might be required for assuring the persistence of the stored data. A higher class tag (e. g. class 4) is fully compatible with the specification for lower class tags (e. g. class 3 or below). The data on the tag are available immediately after a read/write operation initiated from a RFID reader.

6.4.2 RFID Reader The purpose of a RFID reader is not to store data; rather it transfers data to/from the RFID tag. Though, short term data storage is required for this data transfer. Configuration information (e. g. reader address, filter configuration) is stored persistent during the entire operation of the RFID reader [EPCglobal (6)]. Data acquired by means of the read process from the tag need to be stored for processing (e. g. simple aggregation of goods to one pallet, elimination of faulty and redundant data) and forwarding to the middleware. Commands provided by the middleware (e. g. invoke write operation on tag) need to be stored short term and translated to internal RFID reader commands. The amount of stored data ranges from some Bytes to several kilobytes. Today, RFID readers can also be integrated in personal digital assistants (PDA). RFID readers are available in the SD card form factor8 and can easily be plugged into a standard PDA. This device type features more memory (up to several megabytes) than a pure RFID reader. Hence, additional information (e. g. delivery data) can be stored locally such that immediate feedback to the user can be provided when a notification is received from the RFID reader. This means that middleware functionality is partially integrated in the PDA.

6.4.3 Middleware High-volume data flows (RFID reader notifications) arrive from the RFID readers at the middleware and are stored short-term for processing purposes. Processing is done for the generation of business events (see Subsection 4.3.4). The required storage space can be up to a few Mbytes for the notifications from the RFID readers. The challenge is to store the possible high-volume notification/event flows for short time. Commands issued from the backend system arrive at the middleware as business events (see Figure 1). They are processed and forwarded as RFID reader commands. The required amount of storage space is up to about one megabyte. Additional information related to the RFID tags (e. g. delivery information) can be stored persistently in the middleware. Therewith, it is possible either to propagate these additional data to devices that are connected to the middleware (e. g. human readable monitoring devices) or to enrich the generated business events for the backend systems. Storing additional data (as a copy of the backend data) in the middleware component is necessary since the response time for acquiring additional data is reduced significantly. Hence, the processing of the notifications and the generation of the business events is accelerated. The storage space required for these data is about tens to thousands of megabytes. The data are stored persistent during runtime of the middleware. Data updates can be initiated either from the middleware or from the backend. The middleware applies rules to the data flows (see Business Level Events) to perform the processing of all incoming data. Rules can be saved in different machine readable formats (e. g.

8 http://www.tradewindtek.com


@

program code, high-level constraints) and require several megabytes for storage. The rules are stored persistently in the middleware during runtime.

6.4.4 Backend System All data delivered from the middleware is transferred to the backend system. Data warehouse systems are the primary place to store mass of data and are one part of the backend systems. The amount of data required in the data warehouse is in the range of petabytes. Within this system the stored data are persistent for decades. To reveal high-value business information (most interdependencies of all data can be unclear) data warehouse business intelligence is deployed. Due to the amounts of data the response time is long compared to the response time for acquiring local data within the middleware. 6.5 Data Processing In the same manner data generation and data processing is distributed on different parts of the RFID system, the data processing can be performed in the RFID tag, the reader, the middleware or the backend system. Data processing issues within the RFID system are discussed in detail in the following subsections.

6.5.1 RFID tag Depending on the class of the RFID tag processing capabilities are available. The lowest classes (class 0/1) do not provide processing capabilities to the outside. Only on-tag processing for realizing the storage and the corresponding data read/write operations is available. Higher class tags (class 2/3/4) can provide additional processing functions. It depends on the resources that are available on the tag. Possible accessories are additional memory, sensors, and security mechanisms. Three different directions for processing are possible. First, a tag equipped with a sensor can sense the environment, process the sample and propagate it (either active with own power source or passive driven by external stimulation) to the RFID readers or similar devices. Second, if a tag contains additional algorithms (e. g. for security) it can receive an external stimulus, process the provided information (e. g. access key) and deliver on-tag data or sensor readings if the interrogator is authorized. Last, a stimulus can be provided by the reader and invoke a certain action with an impact to the environment. Therefore, the data contained in the stimulus need to be transformed by the tag for performing the environmental impact.

6.5.2 RFID reader The data processing in the RFID reader is closely coupled with the capabilities to store data. A reader can either process the data from the field, gathered by interrogation with radio waves, or data from the middleware (e. g. read/write commands). The challenge for this low-level processing is that high-volume data flows can occur due to many tagged artifacts passing by the RFID reader. Depending on the configuration and capabilities of the reader it has to filter the incoming data flow and forward resulting notifications. Filtering is required since the interrogation process performed by the reader might deliver faulty data (e. g. tags appear doubled). Also, preprocessing (e. g. aggregation) is possible to relieve the middleware from processing too many notifications. Commands sent by the middleware need to be processed by the RFID reader in order to correctly translate it to the algorithms that execute the command (e. g. write on tag).


@

6.5.3 Middleware – data processing In the middleware, input data from the RFID readers and backend systems is processed and transformed into appropriate format for the application (e. g. from RFID reader notification to business event). To connect the real world and the corresponding notifications from the RFID readers, the middleware has to perform the transformation between these two representations (real world notifications and business data in backend). Therefore, rules are implemented in the middleware to specify the handling of the real world data. Processing in the middleware is similar to the preprocessing in the RFID reader. Data that are irrelevant for the business process (e. g. time stamp of each good on the pallet) are filtered out such that storage and transmission space as well as processing resources are saved. Also, information that appears to be faulty is eliminated. The filtered data are then further processed to business events, for example with aggregation, piling or compression of RFID reader notifications. Besides the processing of the notifications, also additional information can be merged into the business events. This information can be held locally in the middleware (see Data generation). If extra information is required for the generation of a business process and it is not held locally in the middleware, enquiries to external information servers are possible (e. g. Object Naming Service [GCI IBM] or external WWAI network nodes). These systems can, for example, provide updated product data. This data can be merged with the RFID reader notifications to generate a higher-value business event. External information can also be acquired from devices that are connected to the middleware (e. g. sensors, user interfaces). Data delivered from external devices can also be merged into high-value business events. The middleware has to handle the addressing of the business events so that the appropriate (backend) applications in the correct locations receive the information. Notifications and their appearance (e. g. a certain sequence) can, depending on the rules defined in the middleware, lead to commands being sent from the middleware to the RFID reader. These commands can be combined with information available within the middleware. For example, a RFID tag write command is invoked if a certain tag appears within the readers range. The content to write on the tag is held in the middleware and was acquired in advance to the write action. Business events instructing the middleware to perform certain activities (within the middleware or in connected devices) need to be translated as well. The corresponding command (e. g. write on tag) has to be created and executed by the middleware. The mapping of data types and data structures is done in the middleware in conjunction with notification event transformation. It means that, different physical representations have to be adapted and different data structures are to be handled. Notifications are mapped into data structures complying with the format requirements in the business events.

6.5.4 Backend System The most powerful component for processing within the RFID system is the backend system. Business events are exchanged between different backend systems (e. g. supply chain event management and enterprise resource planning) and data can be saved persistent in high-capacity storage places (see Backend System). Similar to the middleware, the business events received by backend systems are processed according to predefined rules. In contrast to the middleware, only high-value business events (e. g. outcome from RFID system middleware) are processed in the backend system. The business


@

events can directly impact the business processes or other backend systems. Since systems of different types and vendors are involved in the event processing, data types and structures need to be mapped to the appropriate formats (see also the previous section on Middleware). Depending on the application and the backend system, this mapping means a semantic uplifting of the data between different semantic abstraction levels (e. g. observation of a pallet transformed to a delivery). This again possibly corresponds with semantic conversions between different representations (e. g. mapping between different units of measurement). High-capacity storage places (data warehouses / databases) enable to save data that are relevant for mid-term or long-term archiving. Algorithms can be deployed to these data warehouses to perform data mining or analysis. It enables the owner of the information to reveal dependencies that are inherent to the stored data but hidden in their amount. Powerful hardware is required to realize these backend components and to host the algorithms for analysis of the stored data. Due to the huge amounts of data the processing activities can take in the order of hours and days.


@

7 Software The following sections give an overview of the software that is available for development and integration of RFID technology into enterprises. After a description of software for device-to-backend communication, products contributed by PROMISE partners are introduced. 7.1 State-of-the-art of Relevant Software Software for communication between the devices (e. g. RFID readers) and backend systems is divided in to middleware and automatic identification infrastructure specific software. Data generation, storage and processing are described in data management section (see the previous chapter on Data Management). Auto-ID infrastructure software provides special services and operates with interfaces that are particular for RFID systems. The location of most product items changes at least during some phase of their lifecycle. Therefore they tend to have only intermittent network access (typically through Internet). The communication between the embedded part and the backend part of the product agent is performed using so-called middleware software that takes care of transmitting messages over the network. The minimal requirement for establishing this connection is that the embedded part has to store some kind of reference to the backend system. The easiest way to accomplish this is to embed the internet address of the backend product agent in the product item itself. This can be expressed for instance by using an ID@URI notation, where the ID part identifies the product item at the URI (Uniform Resource Identifier). At the minimal level the ID@URI reference can be embedded as a barcode or using a passive RFID tag. Since the URI part uses existing standards and since there exists many possible standards for the ID part, this approach does not need any new identifier standards. Most existing middleware solutions use this approach, i.e. an ID part that serves as an index to a company database at the URI address.

Another approach for connecting embedded devices and backend systems is through the Electronic Product Code (EPC). An EPC makes it possible to access the URI part through the Object Name Service (ONS). A different approach is offered by so-called peer-to-peer (P2P) systems that are mainly known for file sharing of music and movies. The World Wide Article Information (WWAI) protocol is based on P2P principles. The WWAI protocol defines messages that enable nodes to exchange any kind of information and link any kinds of objects to each other by named relations.

7.1.1 Middleware – vendors and producers Middleware in RFID systems serves for mediation of data (e. g. events, commands) from the real world (e. g. warehouse) to their representation in backend systems (e. g. enterprise resource planning). Detailed description of middleware functionality can be found in Section 6. Different vendors (IBM, Oracle, SAP, etc.) provide software components and solutions to perform this integration of real world data into the representation of the backend systems. For such systems several functionalities can be named: - Device management and configuration for setting up and maintaining IT systems that integrate

RFID technology. - Data management for the acquired readings to map the real world data appropriately to the

backend systems. - Process scenarios for RFID specific data and control flows can be built and maintained. - Tracking of tagged items inter- and intra-enterprise wide.


@

- Administration of the RFID tagging process for correct numbering. - Mechanisms to assure compliance of the numbering and data handling with corresponding

standards. - Supply of interfaces to easily exchange readers from different vendors. - Controlling of devices (RFID readers) and their connections by means of different

RFID/wireless protocols. - Management and monitoring of the infrastructure in RFID systems (device configuration and

monitoring, connectivity management to EPC network, etc.). - Data transformation and delivery to supply chain execution systems (also connection to

software from different vendors). Relevant vendors for RFID middleware are: - Globe Ranger - Manhattan Associates - OAT Systems - ConnecTerra - Microsoft - epcSolutions Several middleware producers also provide additional services and products for RFID systems that were not listed above: - RF Code

o Provide active tags (equipped with battery) and appropriate readers. - Savi Technology

o Offer specialized applications for asset management and transportation security. o Mobile manager for synchronized deployment of RFID readers in mobile devices.

- Sun Microsystems o Sun Java System RFID Software

Event manager for communication between readers and upper-layer middleware.

Information server for storing business data around RFID events. - Tibco Software

o Solutions to integrate EPC information in business processes within backend software. - Webmethods

o Integration of RFID technology in business processes. o Tool for business activity monitoring.

- Oracle o Backend applications for seamless integration of RFID technology into enterprises.

- IBM o Solutions for deployment of RFID technology in retail. o Auto-ID technology for supply chain management. o Solutions for asset tracking and inventory management.

7.1.2 Automatic Identification (Auto-ID) infrastructure software Software components for Auto-ID infrastructure can be deployed additional to field hardware (e. g. RFID reader), middleware and backend systems. These components are accommodated to the requirements occurring when RFID technology is deployed. In the following, different concepts available for deployment in RFID systems are explained.


@

7.1.2.1 EPC network This section describes parts of the software used within the EPC network concept.

7.1.2.1.1 ALE – application level events ALE provides an interface for applications to describe filtered and aggregated information. Therewith data from different RFID readers can be used in several applications without the need for coordination between the applications. ALE, as a standard interface for middleware, significantly enhances the interoperability between systems, especially on higher layers. ALE is under development within the software action group of EPC global.

7.1.2.1.2 ONS – object naming service The ONS is a directory for EPCglobal identifiers. Therein, the unique IDs (product group level) are connected to URLs to enable a redirection of requests for further information about a product. An interested party makes a request to the ONS and receives a reference to additional information about the identifier as response. VeriSign and Global eXchange Service maintain a partnership to provide this service. ONS is being built on the existing Domain Name Service (DNS) system in Internet.

7.1.2.1.3 EPCglobal reader protocol The EPCglobal reader protocol standardizes an interface for the communication between the middleware and RFID readers. Currently, the standard is in Working Draft state. With this standard, the commands from the middleware to the reader and the corresponding requests are specified to use a control channel. The communication is standardized for notifications from readers (in the field) to middleware.

7.1.2.1.4 EPC-IS – EPC Information Service EPC-IS is a web service for communication of item and product related data. EPC-IS is used for capturing data about EPCs and for querying data about EPCs. The services can be expanded with industry specific services to fulfill industry specific requirements. With the EPC-IS additional information that are derivable directly from the RFID tag (e. g. type of object is pallet, case) can be gathered. The interested party requests the EPC-IS and subsequently gets a response with the additional information related to that specific tag data structure. Requests for additional information (e. g. dimensions of an item) can be dispatched and forwarded to other information sources.

7.1.2.1.5 PML – physical mark-up language The physical mark-up language is a derivative of XML. It was developed to provide a standard vocabulary to describe information within a RFID system. It was meant to be used for the interfaces (e. g. EPCglobal reader protocol) and for data description (e. g. RFID tag notification). It should be highlighted that PML is out of date and deprecated standard, which is not in active use anymore.


@

7.1.2.1.6 Savant Savant is “middleware” software designed to process the streams of tag or sensor data (event data) coming from of one or more reader devices. Savant performs filtering, aggregation, and counting of tag data, reducing the volume of data prior to sending to enterprise applications. It should be highlighted that Savant is out of date and deprecated standard, which is not in active use anymore. ALE has replaced Savant in the EPC network architecture.

7.1.2.2 WWAI network concept The World Wide Article Information protocol is a protocol specification for managing distributed object-centric information in a networked environment. The WWAI specifies a generic language for systems to communicate about objects and their relations between nodes in the WWAI network. WWAI is an application-level protocol. It is a generic XML-based protocol which is used to deliver information between nodes in a de-centralized WWAI network. WWAI simplifies supply and value chain communication (information delivery). WWAI increases interoperability between non compatible systems and increases the flexibility.

7.1.2.2.1 WWAI vision The vision is to have an open communication language that enables incompatible systems to securely deliver information about identifiable physical and abstract objects and their relations across organization boundaries in an intelligent and focused way. Achieving the vision would mean that the products, containers and shipments can be made to tell us more; to tell us where are they coming from, where are they going, when do they expire, and so on. On top of this the vision is to make it work for distributed incompatible systems and last but not least, make it all securely enough to make it attractive for the industry.

7.1.2.2.2 Code is the key All communication in the WWAI network is related to a unique object code. Each code in the WWAI network is globally unique regardless of the standards used for coding. This enables systems to understand what they are talking about and make sure the systems are talking about the same thing/object. Every code in the WWAI network is unique, and one thing means one code in the network. Two different things can not have the same code. In order to make sure the uniqueness of the codes, each node has its own certificate for each code prefix. Certificates are delivered by a globally accepted certification authority / authorities. Trusted certification authorities validate each player in the network and release the code prefixes to the network.

7.1.2.2.3 Networking infrastructure The WWAI network consists of WWAI compatible systems connected together via internet. These are called WWAI nodes. There is no centralized storage for any of the information in the WWAI network. Each of the nodes is responsible for their own data and systems. They may prevent or grant access to their information to other players as they wish.


@

7.1.2.2.4 Putting it together

WWAI in supply chains The WWAI is a standard that enables different parties to communicate about products/objects in a common way. The WWAI is for keeping track of information providers of objects in a distributed network and sharing meaningful information about objects and their relationships between other objects. This means that one is able to find out the players involved with a specific product/object in the chain as the product/object moves towards the end-user. The end-user is also able to find specific information for a unique product/object from all the information providers within the network. WWAI also specifies a way to deliver real-time events between known players, which can be used to increase visibility in a supply chain. The relationships between objects make it attractive in logistical chains because of the possibility to attach and detach objects together like in real life logistics where products are collected to containers and then again separated and tracked individually. Meaningful relationships also enable smart and focused routing of information giving the possibility to efficiently reduce unnecessary flow of information. 7.2 Partner’s products

7.2.1 SAP In this subsection the software relevant for the integration of RFID technology is described.

7.2.1.1 Auto-ID Infrastructure (AII) The Auto-ID Infrastructure is a middleware, specially suited for deployment of RFID technology. In enables the backend connection to the field devices (RFID readers, Bluetooth devices, embedded systems, barcode scanners, etc.). The AII processes the RFID notifications and transforms them to business events according to predefined rules. The rules can be defined specific for each application scenario. The AII provides capabilities to store additional data that further can be merged or correlated to RFID notifications. Business events that instruct the middleware to take action on RFID tags can be dispatched with the AII and forwarded to appropriate devices (RFID readers). As a result of the standardized interfaces the AII can be deployed in conjunction with arbitrary RFID readers. The XI (described in the following) realizes the interoperability to upper layers (e. g. different backend systems). Currently, the AII is deployed for the integration of RFID technology into supply chain processes. The out-of-the-box functionality of the AII fulfils the requirements for RFID compliance in several large-scale application scenarios (e. g. U.S. Food and Drug Administration, Wal-Mart, Metro Future Store).

7.2.1.2 Exchange Infrastructure The Exchange Infrastructure provides open integration technologies that support process-centric collaboration among SAP and non-SAP components, both within and beyond enterprise boundaries. When the components that support business processes are spread across heterogeneous systems, changes to those components can get expensive. The Exchange Infrastructure reduces the costs of, and removes the barriers to, true integration. It consolidates the knowledge necessary to access functionality, integrate systems, and drive business processes in a shared knowledge base. With the XI the business events arriving from the AII can be forwarded to any backend system with an open interface. In the internal Integration Repository (IR) and the Integration Directory (ID) the information about the transformation rules are contained. The downstream Integration


@

Server (IS) then performs the transformation and routing of the business events according to the predefined rules in IR and ID. An interface provides access to functions for monitoring the system health. Not only data are manageable with the XI, also dispatching of control information is possible. Altogether, the XI enables the interoperability between different SAP and non-SAP systems (e. g. with different protocols, formats, etc.) for intra- and inter-enterprise communication and data exchange.

7.2.1.3 Supply Chain Event Management Business events that are generated by the AII and forwarded through the XI can arrive at the SCEM. It enables the operator to visualize the ongoing processes, for example in a supply chain in real time. Events from the real world and from the communication with supply chain partners can be merged and integrated to the business processes. Predefined rules determine the handling of the business events and the connections to the business processes. With the Supply Chain Event Management the relevant milestones of a process can be modeled, such as the preparation of a pallet of goods or the departure of a truck. With the SCEM the proceeding events are monitored and alerts are provided when delays occur, events take out of sequence, or events fail to take place at all. For example it alerts the user to the fact that a delivery is overdue or lets you know when a vendor has not started production in time to meet planned delivery dates. The SCEM can automatically assess the impact of a delay through its links with other planning and execution systems.

7.2.1.4 Enterprise Resource Planning With ERP software the resources available in an enterprise can be planned. These resources comprise for example human capital, material, production capacity finance. Therefore, IT support is provided for different business processes (billing, invoicing, production planning, human resources planning, distribution etc.). In order not to overload the ERP system with redundant information the amount of business events from the real world has to be reduced significantly. This information filtering is performed in the middleware (see Data Management). The SAP ERP solution consists of integrated modules instead of separated and isolated software programs. Between the modules the data exchange is realized via the SAP NetWeaver platform. For example, the procurement of materials is recorded in the financial module and both modules are connected to the SAP NetWeaver platform.


@

7.2.2 Stockway Stockway’s product family includes Trackway Engine, Trackway Now! and a Development platform. Trackway Engine is the core information delivery server. Trackway Now! is Stockway’s end user application developed on the Trackway Engine. The Development platform is a SDK for developing solutions based on Trackway Engine. [www.stockway.fi]

7.2.2.1 Trackway Engine Trackway Engine is Stockway’s WWAI implementation. Trackway Engine handles the WWAI communication, handles the events and requests between WWAI network nodes. Trackway Engine takes care of storing WWAI data. Trackway Engine is compatible with the most used SQL databases. Trackway Engine includes: Feature Description Data persistence Buffers unsent events in case of network failure. Access rights Manages what information can be given to which nodes. Device connectivity Easily integrated with new devices and readers. Easy connection of nodes Trackway Engine provides a flexible way to extend the

network of company internal nodes and company external nodes when needed.

Support for processors Trackway Engine includes interfaces for easy connection of different types of data processors. Data processors can be customized to process WWAI data as required in the application

Support for converters (data to backend systems, etc.)

Trackway Engine includes interfaces for easy connection of different types of data converters. Data converters convert WWAI data to any require format and the output can go to external databases, files, binary streams, etc. Data converters can be customized to suite the needs of data in the application.

Support for GUI components Trackway Engine can easily be used with customized GUIs and web applications.

7.2.2.2 Development platform Trackway development platform is based on the Trackway Engine. The platform provides an API for development of WWAI application. The development platform is a fast and cost effective way to benefit from all WWAI features. The development platform includes documentation and guides for software development utilizing the open WWAI protocol. The development platform is available freely for developers and can be downloaded from Stockway’s web page (http://www.stockway.fi/).

7.2.2.3 Trackway Now Trackway Now! is an end user application. Trackway Now! is build on Trackway Engine and includes tools for track and trace, product information exchange, product event exchange.


@

7.2.3 DIALOG project (HUT) At Helsinki University of Technology a pilot middleware system called “Dialog” has been developed for accessing and updating product-related information using the ID@URI notation. The software is available at “http://dialog.hut.fi” and is distributed under the terms of the GNU Lesser General Public License. This software is usable “as-is” because HUT is not a technology provider in the sense that no resources are allocated for software development However, the Dialog system is used for testing and verifying concepts and models produced by the research work so it evolves depending on the needs of the research work. The software has also been used in two industrial pilots in a multi-enterprise setting (in 2002 and in 2004). It could be possible to develop and use the Dialog system for the needs of PROMISE demonstrators.

7.2.3.1 Identification technology Product identifiers can be read using barcode readers, passive RFID tags and readers and by manual entry from keyboard. Most existing barcode readers are supported. A general-purpose interface was defined for RFID tag readers. Implementations of the RFID tag readers exist for two reader types, i.e. the Piccolink RF600 handheld reader from NordicID Oy (Finland) and the Omron VT720 reader with external antenna. RFID tags operating at 13.56 MHz and using Philips iCode communication standard have been used in practical tests but the reader interface does not limit the used frequency or communication standard in any way.

7.2.3.2 Messaging protocols The current Dialog implementation uses three different communication protocols and data formats for message passing: · SOAP messaging [W3C, 2000]. Programming language-independent protocol. Data is transferred as text using the XML notation. · HTML form [W3C, 1999]. Programming language-independent protocol. Data is transferred as text using the HTML form format. · Java RMI messaging [Sun Microsystems, 2002b]: Mainly used in development and in intra-company installations. RMI is flexible and easy to use, but it may be problematic for firewalls and version management when service interfaces change. In order to make the system as open as possible, a major challenge is to standardise the messaging interfaces, i.e. possible messages and their contents, so that any software producer could implement them and have their applications communicate with others successfully.

7.2.3.3 Connection to backend systems Databases are used for providing a connection to backend systems because they can be used in a non-proprietary way (or almost) through the SQL (Structured Query Language). The Dialog software components are programmed in Java, so communication with databases is performed using the JDBC (Java Database Connectivity) protocol [Sun Microsystems, 2002a]. Database tables used by the middleware component are created as/when needed. For now, databases seem to be the only universal way to communicate with most existing enterprise applications such as ERP (Enterprise Resource Planning) systems because ERP systems tend to have proprietary Application Programming Interfaces. A more direct integration with ERP systems could be


@

necessary for some real-time applications with short reaction times, but for most product lifecycle management applications it should not be necessary.

7.2.3.4 Industrial references Two pilot installations have been performed in a multi-company environment. The first pilot consisted in tracking project shipments in a global environment [ISI Industry Software, 2003]. Shipments were identified with RFID technology and tracked in several checkpoints. Location update messages were sent using the RMI protocol, which in this case worked despite multiple firewalls. The second pilot consisted in tracking incoming and outgoing goods at warehouses of several third-party contractors. Goods were identified with barcodes, while location update messages were initially sent using SOAP. Due to firewall problems that occurred with some contractors, messaging was later modified to use HTML forms.

8 Decision Support Systems

8.1 Introduction In this document an overview about main existing Decision Making Tools / Strategies along PLC is given. Broadly speaking a DSS uses as input some information and uses this information for taking some decision. Typically information used as input for DSS are structured data about the product. Since these data can potentially be collected and organised all along the PLC, characteristics of a lifecycle information system are therefore essential in determining capabilities and potentiality Decision Making Tool along PLC. A product-oriented approach is often used to model lifecycle information management systems. This will enable decision support that handles the unique requirements of every single product. One of the factors that forces such an approach is that manufacturers today are increasingly embracing the concept of mass customisation, where each product is manufactured uniquely to suit the requirements of individual customers. Hence, it is unlikely for instance, that a product sold to customer A be exactly similar to another product, sold under the same label, to customer B. Moreover, the fact that each product is subjected to a different set of conditions throughout their lifecycle makes it evident that product information will be unique to every single product. This flexibility required by the recovery processes can be enabled by a lifecycle information system that has the following possible characteristics:

• Ability to uniquely identify and track products at the item level throughout the supply chain.

• Ability to provide relevant identity information associated with the product as well as external information as required by EOL processes.

• Ability to provide information to determine the “current state” of the product. • Ability to update product information as it changes throughout the product’s lifecycle. • Ability to communicate all related information across all partners of the supply chain as

required. • Ability to provide instructions that enable the system to automatically route products

through the product recovery processes. • Ability to provide decision support at various stages of the product recovery process.

Generally speaking, a “product-oriented” information system is well suited to meet these needs. In the following, a brief overview of some of these systems will be presented.


@

Lifecycle information monitoring systems are designed to monitor and record performance parameters during the usage phase and make this information available for DSS operating in MOL and EOL phase. In general, these systems display the following characteristics which are relevant to lifecycle data monitoring systems:

– Enable unique identification of products at item level. – Provide design and disassembly information as set down at the design stage of the

lifecycle. – Monitor and records important performance parameters of components throughout the

lifecycle and stores this information within the product. – Recyclers are provided access to the dynamic information stored with the product and also

linked to the ‘static information’ stored by the manufacturers through the Internet. Table 4 provides a brief summary of the characteristics of some existing lifecycle information systems. It is clear that at the present none are capable of providing accurate information about the state and structure of the product at its end-of-life because they fail to incorporate changes brought throughout the product’s lifecycle and associated external information required for making decisions at the end-of-life. The lifecycle data monitoring systems classify information into (a) static classes, which includes design and disassembly information, and (b) dynamic classes, which includes performance parameters that affect EOL decisions. The major drawback of such an approach is that it fails to capture the dynamic nature of the so-called ‘static’ information. For example, it is unable to incorporate changes inflicted by the production process on the design of the product. In addition, they fail to integrate necessary external information (legislation, corporate policies, etc.) that is required for making effective product recovery decisions. This results in the inability of these systems to provide accurate information regarding the status of the product at end-of-life, thereby failing to provide sufficient support for EOL decision making.

Table 4: Characteristics of existing lifecycle information systems. Source [D.C. MacFarlane 2003] Existing Solutions

Unique product ID

Product Identity Info

External Info

‘Current State’ Info

Lifecycle history

Comm with supply chain partners

Process instructions

Decision support

IMPRIS X X X Recycling Passport

X X X

PLMS X X X X X X ReDaMa X X X X X ISPR X X X X X X X X LCDA X X X X X Green Port X X X X X


@

8.2 Current practices in BOL

8.2.1 Production systems Decision making here is inherent to the production of products (second step in the BOL phase), i.e. the transformation of materials and/or components in order to obtain the finished product. Distribution of products all along the supply chain will not be considered here. RFID technologies, and embedded device technologies in general, promise to become a very important component of modern production systems, and a large number of applications in the executive phase are running worldwide. The traceability of products inside the system, provided by such technologies, enables in theory the decision maker to have a complete vision on the payload of the system, knowing exactly where each product really is. Other potential uses are enabled by the possibility of reading/writing the chip on the tag with information useful for production execution in its different phases. The state of the art concerning the existing applications in decision making activities on production systems comprises cases in the manufacturing sector, typically the automotive and the white goods sector, in which RFID tags and readers are mainly used to manage the progress of products along the assembly lines and to govern the functional control activities of the same lines. RFID tags are positioned on materials handling devices, e.g. pallets and trays, or directly on products in the assembly phase, e.g. on the basement of a refrigerator, and are in general usable more than one time.

8.2.1.1 Hierarchical decision making within modern production systems. To better comprehend which decision making activities are carried out in modern production systems, a reference framework will now be given. These activities concern the planning and control of production inside a firm. A first general reference schema considers different levels of detail for different kinds of decisions, following the typical hierarchical approach used in practice. Such an approach allows the decision makers operating at different levels to decompose a very complex problem into a series of sub-problems, which are easier to solve. The impact, on the enterprise performance, of decisions taken at each level on the enterprise performance, the level of detail of the information available to take the decision, the time horizon of reference and the number of constraints for the decision is shown schematically in Figure 3.

Figure 3: Impact on performance, detail of information, length of time and number of constraints.


@

Now a brief explanation of decisions taken at the different levels is reported.

1. Long term production planning. The budget for the production is created for every factory/plant/line of the enterprise, following some turnover target. The overall capacity of the production system is determined here, by considering a reference period of a year ore more.

2. Medium term production planning. The objective here is to formulate the MPS (Master Production Schedule) in terms of how much of each product has to be produced, in each sub-period of the considered time horizon, for example for each month of a semester or of a year.

3. Short term production planning. The allocation of the different resources of the production system is here decided, as well as the sequence of orders the same system must process. The input to the decision is the MPS and the output is an operative plan, decided after having stated the requirements in terms of materials and components, the single machines to be used, the sequence of orders on each machine, etc. The time horizon here is typically a month, divided into a certain number of periods, e.g. four weeks.

4. Production control. The execution of the operative plan is monitored and its status is reported. The time interval to be considered in this phase is mainly influenced by the IT technologies used in monitoring activities. The control can be made every shift or, in the opposite extreme case, in real time, depending from the actual needs of the firm and from the available technologies.

RFID technology is used for production control, as well as some other embedded device solution. These technologies can theoretically tighten the time interval of monitoring, thus enabling decision makers to solve problems with an increasing frequency. The technical feasibility of such a solution has been shown in many industrial cases, in pilot projects and in the current practice too.

8.2.1.2 Manufacturing control and the needs for product identity information. As reported by Chokshi et al. [N. Chokshi, A. Thorne, D.C. MacFarlane 2002], a number of functions within real-time control can directly benefit from the fact that information concerning product identity is made available on the shop-floor. A sample overview of these functions is now shown:

1 Product Tracking and Genealogy. This function provides visibility to where products and WIPs are at all times. This information, e.g. which machine is currently working on which product, components or raw materials, made available on the upper levels of decision making, could be then analysed.

2 Automated Storage and Retrieval. AS/RS (Automated Storage and Retrieval Systems) involve important issues concerning products identification, e.g. the sorting of incoming parts, allocation of storage space for prioritised orders or products, exact routing of parts during storing and retrieving procedures, and certainly maintaining account of inventory levels at all times and at the deepest level of detail.

3 Product Routing, Dispatching and Flow Control. Material handling is often quite difficult to manage. In discrete manufacturing, for example, dispatching of products between one machine and another becomes crucial when machines are process bottlenecks. Moreover, some products could become at a certain time more important than others, e.g. because they have tight deadlines, and thus they have to be routed with higher


@

priority. Automatic product identification and related information could enhance many of these control functionalities. Currently RFID technology can be used to control production in hierarchical control systems; however the breakthrough would be a distributed control system to manage products, machines and equipments in an open and easy way.

4 Process Recipe Management. Products may have different “recipe” requirements in terms of sequence of machining operations, assembly/disassembly instructions, palletising, intermediate storage, etc. This issue involves automobile industry, semiconductor and electronic industries, mixed packaging operations in many sectors, etc.

Other potential applications of product identity information in manufacturing control include forecasting of raw material consumption, statistical process control, alarms and triggers management, etc. Further information can be found in reference [D.C. MacFarlane 2002].

8.2.1.3 Review of Automatic Product Identification for control purpose The three principal forms [N. Chokshi, A. Thorne, D.C. MacFarlane 2002] in which Automatic Product Identification has been previously used are: 1 Discrete sensing. It concerns the detection of the presence of products on specific locations. Examples range from mechanical switches to laser sensors, etc.

2 Bar-codes. Bar-codes have been used as well as discrete sensing for applications such as sorting of products on conveyors, assessing work-in- process inventory, etc. Details concerning standards and their utilization can be found in [J.A. Tompkins, J.A. White, Y.A. Bozer, E.H. Frazelle, J.M.A. Tanchoco, Jaime Trevino 1996].

3 RFID. RFID is used in industrial control, in most cases as a counterpart of bar-codes [N. Chokshi, A. Thorne, D.C. MacFarlane 2002]. Other key applications apart from those of bar-codes are:

o Storing machining instructions on RFID tags to ensure consistency between different machining stations (in the automotive industry);

o Tracking and tracing of aggregates such as pallets or unit loads; o Etc.

Other techniques have also received little attention in some specific application, such as acoustic sensing or optical vision. Again in [N. Chokshi, A. Thorne, D.C. MacFarlane 2002] one can find the requirements for integrating auto-id infrastructure within manufacturing control, both on the hardware/software side and on the data management side.


@

8.3 Current practices in MOL The schema in Table 5 below illustrates logical steps, and related delays in the fault injection – bug fixing loop. This is a “general schema”, but for automotive industries the length of this loop is one of the most crucial issues for the definition of the quality of the product and one of the causes of expensive recall campaign. Some attempt to speed-up has been done in some crucial phases of this long information loop. In this paragraph we’ll see some DSS that have been developed in this context.

Table 5: The steps and indicative times in the fault injection – bug fixing process

The first issue that will be described in detail in this document is positioned in the phase of Use, and deal with Diagnostics and Prognostics. The introduction of wireless communications capability into vehicles provides indeed a means to offer new services centred on remote monitoring, diagnostics and prognostics for vehicle systems linked to the communications channel. A DSS capable to identify incoming failure is an efficient method to shorten the fault injection – bug fixing process. DSS focused on prognostics typically rely on “on-line” data; a second relevant aspect is linked to the phase of diagnosis and anomalies identification. DSS in this domain uses a large amount of “off-line” field data in order to promptly identify pattern linked to possible anomalies, increase in defectivity and so on. Several company specific initiatives are active in this context.


@

8.3.1 Diagnostic and prognostics The state of the art today indicates that, in mass produced complex systems, a combination of on-board diagnostics and service bay diagnostics must be utilized to identify a problem and isolate its cause to guide repair procedures economically. However, for automotive OEM's on-board diagnostic systems are limited in scope and capability by cost and hardware constraints from legacy designs in vehicles, and accurate diagnostics in the service bay can only be accomplished after the vehicle is brought to the facility for examination to verify the concern is present or attempt to re-create it, perform fault isolation and initiate action to acquire replacement parts. Both the development system and the planned production system have on-board computational ability to perform simple analysis for the sake of long-term diagnostic analysis (such as histograms, parameter averaging etc.). The system microprocessor has the capability of performing dozens of common numerical computations in real-time on the parameters being observed to consolidate and analyse the data on-board. This feature and other aspects of the system discussed below are intended to take advantage of the distributed computing environment intrinsic to the system design. The primary motivations for the on-board analysis are:

• Permit consolidation of information on-board the vehicle in production systems to avoid the need for constant surveillance and reduce the amount of data that must be transmitted.

• Reduce the computational load on the central decision centre by transmitting pertinent information rather than just monitored data for analysis.

• Transmission Costs The Decision Centre requires a computational resource to receive the information, analyse the data, render a diagnosis (whether by automated analysis or expert technician), store and archive the data, and make the data available for a variety of engineering analysis. The diagnostic analysis of "fault concern data" is completed using real-time data exchange with the vehicle and executing diagnostic routines as necessary to accomplish the diagnostic task. The primary goal of the off-board system with respect to diagnosis and prognosis is, to the greatest extent possible, to automatically process the incoming information and reach a decision on what action to take. We will assume that the package of information arriving at the decision centre constitutes a "session". The sequence of events in such a session can be simplified to acquisition, validation, diagnosis, information storage, repair scheduling and repair verification

8.3.1.1 Intellibus Initiative Demand for mobility is constantly increasing both in terms of quantity and quality. Public administrations and transport companies have to deploy management policies realising at the same time technological innovation and efficient utilisation of existing resources aiming to improve competitivity in view of the on-going liberalisation of the market. Maintaining vehicles in full efficiency are a significant operating cost but also an essential condition in order to pursue the objective of public service quality. Vehicle breakdowns causing interruptions of normal service operation involve not only remarkable expenses but also service discontinuities, discomfort for passengers and damages for the image of the transit company. In order to improve vehicle maintenance operations and to reduce road failures IRISBUS-IVECO and Centro Ricerche FIAT have developed a new project, called INTELLIBUS, introducing a major change in the vehicle maintenance concepts.


@

By combining advanced automotive electronics, wire-less communication technologies and innovative concepts for predictive diagnosis, traditional methods for periodic maintenance shall be substituted by new strategies based upon generation of early warnings of components degradation calling for preventive maintenance actions be undertaken at the proper time before actual failure occurs, but at the same time reducing unnecessary maintenance costs and vehicle down-time. INTELLIBUS operation is based on two main features: first of all any error and warning message issued by the sophisticated on board control units during vehicle operation is recorded and associated with extended auxiliary information on vehicle operating conditions pre and post event. The recordings are transferred by means of wire-less communication links to the work-shop at vehicle return to the depot. In this way vehicles needing urgent upkeeping are immediately routed to the proper service point in the shop and the repair team may prepare the tools in advance for fixing the failure with highest efficiency. Perhaps even more important, Intellibus keeps under continuous observation the time histories of most parameters of the vehicle (fluids temperatures and pressures, shafts speeds, battery voltage, and so on) during normal operations, and automatically analysed by sophisticated diagnostic algorithms in order to detect significant deviations from normal operating values, giving early warnings of possible degradations in critical mechanical equipment of the vehicle (such as the engine cooling circuit, the electric power system or the auxiliary pneumatic circuit, and so forth). Where required, additional sensors may have to be fitted, for increasing the predictive diagnostic capabilities of the system. During the daily mission vehicle signals and error codes are collected, pre-processed and stored on board. At the end of the mission the data are transferred to the depot ground station via a short range radio communication. The DSS in the ground station, the recorded alarms are processed to decide if the vehicle needs immediate repairing action or could be parked. Afterwards all operating data are transmitted to the main control centre and stored into a general data base where data from all the missions of the whole fleet over a given period of time is collected. The data-base is daily analysed in order to identify possible deviations of diagnostic parameters which may be correlated to early degrading of vehicle components. In this event Intellibus timely informs the service centre of the arising problem. Critical events may also be communicated in real-time to the fleet control room via GSM network, and a preliminary remote diagnosis of the failure may be carried out in order to decide upon the most convenient repair strategy (continuing operation, on road fitting or tow away). Intellibus is designed for interfacing and share information with other fleet management equipment related to service exploitation (such as ticketing, driver and passengers messaging, etc), in a way to exploit the inherent synergies. Starting from positive results obtained in experimental prototypes with diesel and natural gas propulsion, Iveco-Irisbus in accordance with the Public Transit Company of the city of Milano has launched the industrialisation of the product by equipping with Intellibus system a batch of 238 new CityClass vehicles purchased by the company. The application for the city of Milano also provides for the installation of short range communication equipment based on the Telepass toll collection technology for 6 parking yards. Each depot is also provided with a ground processing station connected through the Company network to the main database server. Intellibus stands as a new tool for managing public transport fleet, combining the impressive evolution of vehicle technologies with info-telematics and innovative diagnostic concepts, to improve service quality and competitivity.


@

8.3.2 Reliability In order to implement the concept “Design for Reliability”, one of the key tasks is the analysis of the field data flow regarding product failures and anomalies. This analysis is aimed at identify pattern linked to possible anomalies, increase in defectivity and so on. Company specific DSS are active in this context. The result of this analysis Typically these tools are data mining solutions, used to integrate raw “off-line” field data about maintenance, intervention for cleansing and analysis. Typically they include:

- Warranty claims - Product Quality surveys - Other field reports

Analysis capabilities of these tools in general include:

• Specific model failure (Trends) • Prediction of cost increases (on specific parts) • Single integrated view of “Failure Incidents” through integration of multiple data for early

alert detection and management. • Correlation of critical symptom, cause, failure and cost information across multiple data

sources to help in faster root cause detection and response (specially low volume products) • Identification and correlation of Leading and Lagging Indicators on specific parts and

vehicle failures on field reports, warranty and consumer discussion boards in order to predict future incidents and costs

• Identifying anomalies and inconsistencies between Field reports symptoms and causes • Sharing of crucial alert information, failure criticalities, and concerns in order to improve

the escalation process to quality experts and design engineers for faster response. Classical data mining techniques are usually adopted for the identification of “statistical models” used for the failure identification. Models can be based on mileage or days in service, and can be used to estimate costs, failure frequencies or safety related aspects. 8.4 Current practices in EOL This section is focused on the DSS used within the ELV (End of Life Vehicle) dismantler, which is a long established business. At the moment, there are very few computer systems in place that are EOL-focused; existing ones focus mainly upon the various stages to be found in EOL (End of Life). Currently, EOL is focused around the practices of the dismantler, and the way they work with the products received from end-users. The current state of practice at the EOL stage may be described as in Figure 4: inputs is concerned with sourcing their raw material, for example by getting the end-user to deliver the ELV to the dismantler; processing concerns the removal decisions involved once the dismantler has the ELV; storage assesses the inventory requirements and tracking and tracing procedures involved with the removed parts and recyclable materials; and, finally, outputs examines how parts are moved from the dismantler to customers / disposal units / recyclers etc. The following sections provide further details on each of these headings.


@

End Of Life

Input Processing Storage Output

WebsitesAdvertisements

DSSRemoval

InventoryManagement

SalesHubs

Figure 4: EOL current state of practice.

8.4.1 Input In order to perform the EOL (End of Life) operations upon ELVs (End of Life Vehicles), dismantlers must first obtain the end-of-life products from consumers who wish to dispose of finished ELVs. Current practice in EOL to solve this problem follows the same routines as other market sectors; dismantlers must draw attention to their services via advertisement. There are a number of options available to the EOL dismantler who wishes to advertise; this can be performed via:

• Local media; • Trade magazines and other industry-related literature; • Websites; • Dealerships.

Local media At a municipal level, buying column inches in local newspapers, and advertisement via local radio, television etc. are all a means of improving the image and name of individual dismantlers among the local population of an area; a dismantler is dependant—for a large part of their business—to the support and enterprise of the local community to survive in the EOL arena; the dismantler offers a much-needed service on a local level, allowing ELVs to be removed from service, thereby freeing up local scrapyards / dumps etc. from the necessity of taking on this added waste, and allowing components of the ELVs to be reused or materials to be recycled.

Trade magazines and industry-related literature There is a multitude of trade magazines and other industry-related literature available to the EOL sector to take advantage of; some examples of such literature include: Materials Recycling Week (UK) 9; Recycling Today10; New York Automotive Recycler magazine11; Automotive Recycling (the magazine of the Automotive Recyclers Association)12; United Recyclers Group Newsletter13;

9 http://www.environmental-expert.com/magazine/emap/ 10 http://www.recyclingtoday.com 11 http://www.arany.com/recyclermagazine.htm 12 http://www.a-r-a.org/publications/index.html 13 http://www.u-r-g.com/newsletters.htm http://www.u-r-g.com/pinnacle.htm


@

AutoWeek14; Automotive Body Repair News15 etc. In fact most recycling associations use the magazine-format as a vehicle to spread their ideas to others who are working in the same sector. The trade-magazine type of advertisement reaches a far narrower audience than the general purpose local-media advertisement; however, for those dismantlers interested in connecting and extending their businesses within the EOL realm, advertisement in these magazines is essential—they provide a mouthpiece for those sharing common concerns and purposes in EOL to exchange ideas and information, and by advertising in these magazines, the dismantler may be able to obtain better quality business from a wider field of interested parties.

Websites There are currently a plethora of localised dismantler’s websites available on the Internet (for a representative sample of these see16); similar to other websites, these offer basic information concerning the dismantler, the type of dismantling work carried out (for example, what models are serviced, costs etc.), and optional inventory searches. They serve a localised market, whereby the local community may access the website to discover relevant information concerning their local dismantler; they also serve external parties, who can quickly assess if dismantlers are available in an area.

Dealerships E-hubs consist of recycling associations, dealers, manufacturers, and dismantlers working together to organise an extranet-type network, whereby customers can enter to locate information concerning servicing, repair and recycling/dismantling facilities. Ford, for example, operate a “blue-oval dealership policy”17, whereby selected dismantlers become registered dealers that must conform to Ford’s customer-service policies. Similar examples of dealerships being outsourced to EOL teams are located with all the major auto manufacturers: see for example18 —Fiat, Toyota, Nissan, Mazda, General Motors, VW. The dealership connection creates a relationship between the auto manufacturer and individual dismantlers; by linking themselves closely to a specific auto manufacturer, the dismantler can insure a certain level of business from the servicing, and recycling of that firm’s vehicles. End-users are recommended to return ELVs to specific dismantle dealers only, thus creating a tighter integration between MOL and EOL.

14 http://www.autoweek.com/ 15 http://www.cahners.com/ 16 Dismantler’s websites—examples: See http://911pcar.com/ ; http://www.301autoparts.com/ ; http://www.431autoparts.com/ ; http://www.6440autoparts.com/ ; http://www.a-b-auto.com/ ; http://www.valleyautowrecking.com/ ; http://www.voauto.com/ ; http://www.lavictoriaparts.com/ ; http://www.aaceautoparts.com/; http://www.68motorsandsalvage.com/ ; http://www.overtongarage.co.uk/ . 17 http://www.fordvehicles.com/dealerships/index.asp 18 See http://www.fiat.ie/cgi-bin/pbrand.dll/FIAT_IRELAND/home.jsp?BV_UseBVCookie=no

http://www.toyota.com/toyotaApp/dealers/index1.jsp http://www.nissanusa.com/form/1,,action-NDealerSearch,00.html http://www.mazda.ie/ http://www.gm.com/automotive/vehicle_shopping/dealer_locator/ http://www.vw.com/dealerLocator/locateEntry 18 See http://www.fiat.ie/cgi-bin/pbrand.dll/FIAT_IRELAND/home.jsp?BV_UseBVCookie=no

http://www.toyota.com/toyotaApp/dealers/index1.jsp http://www.nissanusa.com/form/1,,action-NDealerSearch,00.html http://www.mazda.ie/ http://www.gm.com/automotive/vehicle_shopping/dealer_locator/ http://www.vw.com/dealerLocator/locateEntry


@

8.4.2 Processing As soon as the dismantler has taken possession of the ELV, they can start to process it. The essential set of decisions that the EOL dismantler is faced with at this juncture can be stipulated into three categories:

• Dismantling and removal of parts that HAVE to be removed (under legislation);

• Dismantling and removal of parts for reuse/remanufacturing;

• Decision not to remove part.

Parts that HAVE to removed (for example, batteries and oil in automobiles) are driven by national and international legislative requirements; irrespective of the cost to dismantle, these parts must be removed from the ELV before further processing may take place. “Reuse” refers to the regeneration of parts that are suitable for the secondary market; reuse parts are harvested from the ELV according to a quality inspection, the cost of removal, and the current market demand for the product. “Remanufactured” parts are those that can be regenerated after they have been reworked so that their quality has been brought back to former levels; decisions of quality, cost of removal, and market demand all impact here; however, additional issues—such as the cost to regenerate the part to former levels—also impact here. The decision not to remove reuse/remanufactured parts and for other parts not considered to be worth harvesting, results in the ELV “hulk” (i.e. what is left of the ELV after all the reuse/remanufacturered and legislative-driven parts are removed) being processed by the shredder, whereby different separation techniques are used to recycle basic metals and plastics (see Figure 5).

Figure 5: Current separation techniques used in the recycling of materials from ELVs [Ferguson, N. 2002]

Parts that HAVE to be removed—Legislative requirements On the 18th of September 2000 the European Parliament passed a Directive on End of Life Vehicles. This Directive lays down measures, which aim at the prevention of waste from vehicles. In addition, this directive aims at the reuse, recycling and other forms of recovery of end-of life vehicles and their components so as to reduce the disposal of waste. Also this directive focuses on the improvement in the environmental performance of all of the economic operators involved in the life cycle of vehicles and especially the operators directly involved in the treatment of end-of


@

life vehicles (Commission 2000). Table 6 summarises the recycler’s responsibilities under the ELV Directive. The essential result of the directive is a list of parts that the dismantler is compelled to remove, regardless of the make, model or type of ELV.

Table 6: Recycler’s Responsibilities under the End of Life Vehicle Directive Player Responsibility

Article No.

Activity Affected

Responsibilities

Recycler 5(3) Treatment Certified Recyclers have to issue a Certificate of Destruction to the holder of the ELV.

Recycler 6(2) Treatment Recyclers are required to obtain a permit from the local authorities in order to process ELVs.

Recycler 6(3) Treatment Recyclers are required to remove all hazardous materials from the ELV before any further dismantling occurs.

Recycler 6(5) Treatment Recyclers are also encouraged to introduce a Certified Environmental Management System.

Recycler 7(2) Treatment Reuse/Recovery/Recycling Targets. By the 1st January 2006 Reuse/Recovery – 85% by average weight /vehicle Reuse/Recycling - 80% by average weight /vehicle By the 1st January 2015 Reuse/Recovery – 95% by average weight /vehicle Reuse/Recycling - 85% by average weight /vehicle

Parts for Reuse The “reuse” decision forces the dismantler to try and balance a number of issues that affect whether the part should be harvested for reuse or not. Issues that affect the decision include:

• Quality of the component—usually performed via a visual inspection;

• Cost of removing the part—in terms of the time required to remove the parts, and the cost of labour to perform this; and

• Market demand—i.e. how many have been sold recently; is it worth removing this part; is it a common or rare part; what sales price may be obtained etc.

Parts for Remanufacture The “remanufacture” decision forces the dismantler to account for the decisions reached in Parts for Reuse above, plus other decisions such as:

• Cost of regenerating the part to former levels—i.e. a determination of the costs involved in bringing the part back up to former levels; for example, cost of rework, transport cost to place of rework, additional labour cost etc.

Decision not to remove part There are two types of parts in this category:

• Those that have failed the reuse / remanufactured test, and do not HAVE to be removed by law; and

• Those that are not considered worth reusing / remanufactured, and are only considered for recycling.


@

Recycling, therefore, is only considered when everything of value has been previously removed from the ELV, leaving the ELV hulk. As has been stated before, the hulk is then passed on to the shredder to be processed.

Decision Support Systems for the removal decision Currently, the dismantler has very few options available to them to allow the removal decision to be supported by a software decision module. Many dismantlers continue to make this important decision using their existing databases (such as sales history, inventory data etc.), and their own discretion, experience and intuition. The PinnacleTM Auto Recyclers Trading System (PARTS) System19, however, offers the most comprehensive decision support system available for the removal of parts; while the UCars20 system is a more financially-oriented inventory-based system that allows for some limited decision-support. The relevant capabilities of these systems are outlined below.

Pinnacle The PinnacleTM Auto Recyclers Trading System (PARTS) System has a vast number of functionalities, which makes it one of the most comprehensive EOL DSS currently available to the dismantler; other parts of the system will be explained in their proper places — here, however, Pinnacle’s decision module is analysed. The Pinnacle system offers decision support at each stage of the collection and processing of the ELV (see Figure 6): when the tow driver is sent out to collect an ELV, they provide instant feedback (1.) to the Pinnacle system, via a handheld device called a Pinnacle Pad21— the feedback involved includes information about the model, year, distance travelled, and significant defects of the ELV; this information is used by Pinnacle to generate a dismantling check sheet (1(a).) based upon the tow driver’s information, current stock levels, legislation etc; the check sheet takes into account the defects that the tow driver reports in the formulation of the check sheet. Thus, even before the ELV arrives, the parts to be dismantled—based upon a pre-assumed idea of what the quality of the ELV will be like—are outlined. The check sheet breaks parts into:

• Parts to be pulled and warehoused; • Parts to be pulled and left in the vehicle (for example, fragile components such as glass; or

as additional storage); • Parts to be pulled for surplus; • Parts that need more information to be identified; • Parts to be left on the vehicle; • Tag print for parts to be pulled.

Once the ELV is towed to the dismantler for processing, it is scheduled (2.), and given a position in the queue. When it is its turn to be dismantled, the component parts of the ELV are dismantled according to the idealised check sheet formulated previously; it is during this operation that changes to the idealised check sheet may be detected—for example, parts may not actually be up to the idealised quality suggested in the check sheet. In these cases, the changes are reported to the Pinnacle system (3.). Subsequently, the removed parts are dispersed to their new locations, and enter the inventory of the dismantler.

19 http://www.actual-systems.com/page.php?stylesheet =stylesheet/main.css&content = pinnacle&login =#1A 20 http://www.ucars.com.au/prodinfo.htm 21 http://www.u-r-g.com/newsletters.htm http://www.u-r-g.com/pinnacle.htm]


@

3. Changes to check sheet registered inPinnacle

2. ELV’s dismantling is scheduled

1. Feedback of relevant ELV information from towdriver: e.g. model, year, miles travelled, significant

defects / components missing Tow driverconfirms ELV in

the field

Towed todismantlers for

processing

ELV is dismantledas per checksheet

Removedcomponents

distributed to theirnew locations in

storage

PINNACLE SYSTEM

1 (a). Generation of idealisedcheck sheet based upon towdriver’s information, and in-house specifications: stock

levels, sales history, legislationetc. Check sheet outlines thefuture destinations of parts

ELV

Information Flow

Material Flow

Legend

Figure 6: Removal decision as per Pinnacle system

Parts are graded by an A, B, C classification22:

• A grade: highest quality part; an A grade part contains a minimum amount of damage; • B grade: second level quality part: a B grade part contains a moderate amount of damage; • C grade: third level quality part: although still usable, a C grade part does not represent

insurance quality. A unit of damage is defined as damage not exceeding the standard size of a credit card. Damage is measured in hours—a common description of damage where hours represents the time needed to repair a part. The measure is subjective however, as recyclers and collision repairers seldom agree on the hours needed for repair. In terms of Pinnacle, A parts are graded as taking 1 hour or less; B parts 1.1 hours to 2.0 hours; and C parts more than 2.1 hours.

22 http://www.aarda.com/pdf/RevisedARAParts.pdf


@

Other Pinnacle modules that aid the removal decision are outlined in Table 7.

Table 7: Pinnacle Overview notes23 Feature Remark Pricing • Automatic Pricing System - A user definable option that will automatically price parts

based on stock levels, sales history and request activity, at your option. This is an easy way to maintain prices on parts.

• Easy to use price maintenance system for parts that are not automatically priced. Pinnacle provides you with all the needed information to make an informed pricing decision on those parts you do not want the computer to automatically price, ranked by order of importance.

• The user can choose to see only those parts that have not received price updates within a user defined number of days. This minimizes reviewing the same pricing issues again.

Detailed Dismantling Sheet

• Clearly spells out what is to be done with each part.

• Lists parts that could not be correctly identified during the inventory process, so the item can be correctly resolved by the dismantler.

• Provides an area for special notes, specific to dismantling of this vehicle.

• Provides record-keeping areas for items such as time it took to dismantle, quantities of fluids removed, compression data for engines, batteries, tires, etc.

• The computer chooses the next vehicle to be dismantled by picking vehicles with a sold part first, then the vehicles with the highest likelihood of parts selling. This can be modified, if management prefers another vehicle to be dismantled first.

UCars The Ucars24 system is not as comprehensive as Pinnacle, coming, as it does, at the removal decision problem from a financially-oriented standpoint that is focused upon the car-level, rather than the part level. It is based upon vehicle inventory and expense tracking software that is focused upon used car lots or for vehicle brokers who buy and sell used cars25. UCars allows the dismantler to find vehicles by make-model-year and to manage its stock levels; providing records of vehicle purchase and vehicle sales and has room for notes on special vehicle equipment or selling features which should be emphasised. UCars will display vehicle expenses below each vehicle record and calculates total investment on any or all vehicles. The benefits of the UCar system, as outlined by the owners26, are in Table 8.

23 http://www.actual-systems.com/page.php?stylesheet =stylesheet/main.css&content = pinnacle&login =#1A 24 http://www.ucars.com.au/prodinfo.htm 25 http://www.rossknecht.com 26 http://www.ucars.com.au/prodinfo.htm


@

Table 8: UCars Overview Benefit Remark Stock monitoring • Effective control of Stock and Costs

• Management information for competitive advantage • Elimination of paperwork and duplication • Optional transfer of Stock Control information into selected Accounting Systems

Data Entry • Complete details about each vehicle

• Immediate calculation of profit (potential or real) for each vehicle • Instant summary of Stock on Hand • Complete details of costs and creditors • Lot charges, warranty • Instant recall of costs, invoices and creditor business

The chief problem with UCars, however, is its financial focus; this mandates that ELVs are analysed as whole units, so UCars does not provide indepth analysis of individual parts—unlike Pinnacle—rather its focus is upon a car-by-car basis.

8.4.3 Storage Once the dismantler has taken the necessary removal decisions with regard to the ELV, they are left to track and trace the parts that they have removed; which involves efficient inventory management. From the previous section, it is clear that there are four alternative destinations for parts in EOL:

• Reuse market—i.e. the secondary market; the market for spare parts etc. • Remanufacture market—whereby parts are returned to the O.E.M. or other

remanufacturers for regeneration to former levels; • Recycle market—from parts not worthy of reuse/remanufacture, and for other materials,

the recycle market develops new products; • Disposal—the remainder is disposed.

Each of these destinations have different requirements with regard to inventory control. For the dismantler, the most profitable market is likely to be that of reuse / remanufacture, so greater emphasis is place upon the efficient tracking and tracing of these parts; the recycle market is effected after the reuse / remanufacture decision upon each ELV has been decided, thus recycling inventory decisions occur upon parts and basic materials that are not deemed worthy of being reused / remanufactured; while final disposal is only considered for those parts that are left after these processes. Each of these destination streams are tracked via inventory applications; a number of inventory management packages—specifically designed for the EOL arena—are available. Most of these are operated upon a barcode identification system, which allows for the efficient tracking and tracing of parts in the inventory system. The best known of these packages are outlined below. CheckMate CheckMate27 is a generalised family of bar code programs that allow for document tracking, fixed asset tracking, inventory tracking, tool tracking, and job data tracking, which has helped hundreds

27 http://www.abarcode.com/Inventry.htm


@

of large and small organisations take advantage of the speed and accuracy of bar code data collection. CheckMate inventory tracking software can be used to track anything, from office supplies to electronic spare parts. Data collection is via Palm OS, Intermec, or Opticon, which allows dismantlers to create and print bar codes corresponding to part numbers or to use the manufacturer's UPC codes already on many items. Location bar codes can represent freezers, shelves, rooms, bins, containers, or a particular container on a particular shelf in a particular room. Data collection can take place at a PC, or at many stations on a LAN, or everywhere using a battery powered portable bar code reader. Table 9 outlines the common features.

Table 9: CheckMate Features Features Multiple key cross reference Discrepancy reporting Key word search All common data collection processes FIFO tracking Complete audit trail Fast Parts The Fast Parts28 inventory system has many features available on the system to help dismantlers run their businesses. Fast Parts allows dismantlers to enter inventory in many ways, such as by choosing to enter complete vehicles first, or loose parts that are stored warehouses separately. With the Fast Part system, the dismantler can perform a complete car inventory by printing a worksheet that is designed for that car model and has all of the options printed on the sheet; the dismantler fills out the top of the worksheet and then circle the parts that are worth removing in the car. Once at the computer, the same form is on the screen; the dismantler then places an A next to the parts that were circled on the worksheet. In this way, the parts are placed into the inventory system as soon as the removal decision has been made; this allows for more efficient tracking and tracing. Loose part inventory is also very simple: a tag is placed upon the loose part and then the tag number is recorded in the computer. The dismantler can use hand written tags or computer generated tags to mark the part. Computer tags are just one of many options available with the system—Fast Parts uses Vin. Decoding as a standard. Vin. Decoding allows dismantlers to find the exact year, engine size, and other pertinent information; all that is needed is the Vehicle Identification Number to access the information (see Table 10for an example of an 1999 Ford Truck).

Table 10: Vin. Decoding in Fast Parts Code I.D. 1 United States F Ford Division T Truck (Complete Division) N 8501-90000 lbs. X20 F250SD 4x2 Super Cab (styleside) S 10-415 (6.8L) SOHC (Windsor) X Check digit was verified X 1999 E Kentucky Truck xxxxxx [SEQUENTIAL NUMBER]

Fast Parts has number of other services29, including: FASTNNET (access to other inventories of Fast Parts customers); HOTLINES (uses satellite communications to allow real time searches of

28 http://www.fastpartsinc.com/index.htm 29 http://www.fastpartsinc.com/index.htm


@

inventories across the country); Car-Part.com30 (lets Fast Parts customers easily and automatically sell parts on the internet; this widens the customer base and makes individual dismantlers’ parts visible to people they would not reach otherwise; trading partners and other specialized tools can be included with this service); and EDEN (a popular parts locator network). Hollander Yard Management System The ADP Hollander Yard Management System31 is a complete inventory management system suitable for the needs of dismantlers. In a similar fashion to the Fast Parts concept, Hollander automatically generates dismantling worksheets, making it easy to inventory parts quickly. Worksheets are printed out, checked against the vehicle under review, and typed straight into the Hollander system; inventory input is piecemeal—that is, inventory is entered as the dismantler acquires ELVs, or start with the most profitable part types. The Hollander system creates a record for each customer and tracks the activity on their account, including accounts receivable, invoices, statements and monthly sales reports. Additionally, financial data can be exported from the Hollander Yard Management System to a Windows-based accounting package like Peachtree Accounting to handle accounts payable and general ledger. The Hollander Yard Management System is seamlessly integrated with EDEN (see Fast Parts above), enabling dismantlers to perform ”locates” directly from your Find and Sell screen and cut invoices directly from EDEN. EDEN users display their inventory records with those of 3,000 other recyclers in the U.S. and Canada. It's the biggest parts locating network available with a trading circle of over 80 million parts. Hollander use Vin. Decoding. ADP also operates the Hollander Interchange32. An interchange allows recyclers / reusers and remanufacturers identify reuse/remanufactured parts that are not model specific, and can be used across a range of vehicle types. The Hollander Interchange produce manuals and allows for simplified part searches among among many dismantlers, scrapyards, recyclers etc. Pinnacle The PinnacleTM Auto Recyclers Trading System (PARTS) System33 has a vast number of functionalities, which makes it the most comprehensive EOL DSS currently available to the dismantler; other parts of the system will be explained in their proper places—here, however, Pinnacle’s inventory module is analysed. The notes in Table 11 are taken from the PinnacleTM Auto Recyclers Trading System (PARTS) System Overview.

30 http://www.car-part.com/index.htm 31 http://www.adpclaims.com/autorecycling/products/Business/HYMS/HYMSFAQs.html 32 http://www.hollander-auto-parts.com/ 33 http://www.actual-systems.com/page.php?stylesheet =stylesheet/main.css&content = pinnacle&login =#1A


@

Table 11: Pinnacle inventory module features Feature Remark Enhanced Stocking Level Recommendation

• Advises you of the quantity needed to help eliminate "over stock" situations. • Pinnacle excludes high mileage and excessive damage parts from the stock level

calculation to make the figures more accurate. • The close rate for a "part type" is considered along with the close rate for this

"particular part", resulting in a more accurate recommended stock and price level. • The user can define the number of days of inventory they want in stock.

Barcodes • System will have barcode and wireless, real time (RF) capabilities.

• Just scan and sell the part at the counter. • Quick inventory reconciliation - scan the part, scan the location, and the computer

confirms or prints a report of missing parts and parts in the wrong location. • RF guns are wireless and communicate full time with the computer, constantly

updating inventory. • When warehousing parts, scan the part, scan the location, then load into computer

saving hours on inventory input.

Main Vehicle Record (MVR)

• The stock number for new vehicles will be computer generated and consist of 5 digits. Due to the vast information available, there is no need to "code" important information into the stock number. However, a yard will be able to use their own numbering system if desired.

Streamlined Inventory Process

• VIN decoding will aid in providing a more accurate list of usable parts without having to wade through pages of unrelated parts.

• Inventory person will have a detailed sheet that provides a wealth of accurate information that will aid in their decision process.

• Shows a recommended stock level for each part that is figured by how many of this part is needed, based upon sales, requests, and how many days of stock you want on hand.

• Inventory persons will have at their fingertips the quantity, condition, locations, prices and pricing recommendations, stocking recommendations, and sales history providing them with all the information they need to make an educated decision.

• Customizable inventory sheet providing you with the list of parts you want to inventory on a specific type of vehicle.

• Computer calculated recommendations as to what to do with that part.

Table 12 offers a brief comparison of the previous number of EOL inventory management systems based upon available information.

Table 12: Comparison of Inventory packages

CODING FORMAT OF PARTS

INTERCHANGE PRICING ADD-ONS

CheckMate Barcode No Manual Minor Fast Parts VIN Dec. / Barcode Yes Via Interchange Considerable Hollander VIN Dec. / Barcode Yes Via Interchange Considerable Pinnacle VIN Dec. / Barcode Yes Calculated Complete


@

8.4.4 Output Having efficiently decided upon what parts to remove from the ELV, dismantled them, and put them into inventory, the dismantler must try to obtain a profit from these, in order to remain in business. The key output of the dismantler’s business is the four streams of material outlined earlier:

• Reuse parts—the output is to the secondary market; • Remanufactured parts—the output is to OEMs that are interested, or other buyers, such as

consolidators; • Recycled materials—the output is usually to various raw material industries; • Disposal—the output is usually to landfill, incineration etc.

Reuse The secondary parts market is a huge market, and provides the most profitable returns on investment for dismantlers. Two types of dismantler-customer relationship may be identified here: the development of long-term buyer-supplier partnerships in reuse parts; or a once-off sale of reuse parts to a customer. Groups such as the United Recyclers Group (URG)34 focus upon providing a state of the art, Recycler Information Management System (RIMS); providing products and services to partners to allow growth in sales through cooperative buying, advertising, and the internet; and providing communications between partners, vendors, and insurance agencies. URG establishes fixed consortium-based relationships between dismantlers and secondary buyers, so that the dismantler’s sale of certain reuse parts is assured. Car-Part.com enables dismantlers to offer a cheap and flexible option to once-off customers. Car-Part.com35 functions as a huge used auto parts market, enabling extensive searching facilities throughout its recycling and dismantler’s database; sales through Car-Part.com are more once-off, and rarely lead to a buyer-supplier relationship between the dismantler and the customer. The customer selects the model of vehicle (including year) they are interested in, the specific part, and the geographic location from which they are interested in purchasing the part from: the search returns specific results outlining the dismantlers that have the part in that location, their address, and the price they charge for the part. The customer is then free to choose whether to buy the part or search again. The Car-Part.com system enables dismantlers to place online their inventory catalogue that often contains parts for which there is no ready-made market such as the URG option above offers. Remanufacture There is also a considerable market for parts that are not quite suitable for reuse, but with regeneration may be remanufactured to ”as-new” standards. Initiatives in this group are very often led by the O.E.M., who may be interested in buying back old, worn parts for renewal: it is often a cheaper option than making a new part from scratch. For example, the Ford Motor Company has put in place a set of remanufacturers who are QS1 and QS 9001 registered and undergo routine quality audits36; Ford has negotiated with these remanufacturers to regenerate specific parts, and then to sell them on to their own dealerships37. In this way, Ford can ensure a steady stream of

34 http://www.u-r-g.com/newsletters.htm http://www.u-r-g.com/pinnacle.htm 35 http://www.car-part.com/index.htm 36 http://www.genuineflmservice.com/default.asp?page=G3 37 http://www.integratedsolutionsmag.com/Articles/2000_10/001002.htm


@

remanufactured parts that may be used for repairs, maintenance, or as input as new parts into BOL. Note that the concept of remanufactured parts is not suitable, like the reuse concept outlined above, for the once-off decision to sell. Remanufacturing requires the development of consortium-based partnerships that enable dismantlers to off-load their remanufactured parts upon O.E.M.-sponsored remanufactures, which in turn sell the regenerated parts to the O.E.Ms dealerships. It is unlikely that a dismantler will be able to sell components that need to be remanufactured if these relationships are not already in place; hence the changes of a once-off sale are low. However, intermediaries, such as consolidators — businesses who buy parts needing to be remanufactured from dismantlers at low prices, and subsequently sell these on to remanufacturers when they have sufficient volumes — may be an option, but can hardly be relied upon. Recycle Recycling concerns the dismantler’s ELV hulk, when all the reuse/remanufactured parts have been removed. To date the material recycler has been a very strong player in ELV recycling. All ELVs will eventually be recycled for their metallic content, which typically makes up 75 per cent (by weight) of the vehicle38. This recycling rate makes the automobile the most complex product in the world. The infrastructure for the disposal of ELVs is essentially concerned with the salvage of the metal content, especially the ferrous (steels) and non-ferrous (copper, aluminium, zinc, and lead) materials; the infrastructure recycling plastic composite, rubbers and glass is less well developed [Wright, C.; Lewis, A.; Hunston, H.; Bursa, M. 1997]. Other recycling that has emerged with the EOL sector includes the hazardous material recycler; many of the parts the dismantler has by law been forced to remove from the ELV may be recycled (for example, batteries etc.). The hazardous material recycler operates upon a ”maximum re-supply” basis, whereby the recycler arranges for the removal of the goods once a given quantity has been amassed. Disposal The remainder of the ELV, i.e. those parts and materials that do not fit into the reuse / remanufacture / recycle typology are disposed of. Currently, the drive for a more fuel-efficient car has led to a dramatic increase in the use of plastics and other lightweight composites [H. Hock 1993]. These plastics together with rubbers and glass (called the dirt fraction) make up the remaining 25 percent of the vehicles weight, which ends up in landfill often contaminating the soil and groundwater. In the EU this represents 1.9 million tonnes of hazardous waste each year [Commission 1997].

38 http;//www.rco.on.ca/research/proceedings/elv.html


@

8.4.5 Conclusions This section has focused on the DSS elements used within the ELV (End of Life Vehicle) dismantler’s practice, which is a long established business. At the moment, there is very little information available, with the exception of the automotive EOL industry; the main focus of this is upon decision support for ELVs at the input, processing, storage and output stages. Key decisions, at all of these stages, are influenced by the information made available to the EOL practitioner: legislative requirements which aim at the prevention of waste from ELVs, for example; or, the inventory management data and past sales history that the dismantler has from previous ELVs. These information flows are being used to determine the best way to deal with individual ELV components, from reuse and remanufacturing initiatives, to the recycling of materials or disposal of waste products. The removal decision, for example, is influenced by legislative requirements, the quality of the components or material involved, the cost of removal, and the market demand for the component/material. Current practices for the removal decision, i.e. as in Pinnacle, suggest the use of pre-existing information to build an idealised check sheet, based upon which the ELV is dismantled, with changes to the check sheet being reported back to the system. Thus, there are clearly opportunities for improvement to this process that can be achieved by the addition of an automatic quality input of data (via RFID for example), which would enable real-time development of a check sheet of components to be removed based upon actual, not idealised, component data. This type of data input from individual components would close the information loop, and provide a complete system by removing the idealised segments of the system.


@

9 PLM Technology

9.1 Introduction The term “Product Lifecycle Management” (PLM) emerged after nearly twenty years of market and technological evolution. In the mid 1980’s to early 1990’s, there was confusion as to what to call product-related information, particularly engineering information. As the data came to be referred to generically as product data, the term “Product Data Management” (PDM) emerged. Both users and solution providers embraced PDM and used the term for many years. The PDM technology continuously has become a management approach for data, applications and processes throughout the entire lifecycle. PDM vendors and integrators have found a multitude of acronyms, e.g. Collaborative Product Development (cPDM), Collaborative Product Commerce (CPC), 3D Product Lifecycle Management (3D-PLM), Product Knowledge Management (PKM) or Virtual Product Development (VPDM) for their software products. In fact, today all used acronyms and descriptions are converging to Product Lifecycle Management. PLM is the extension of PDM towards a comprehensive approach for product-related information and knowledge management within an enterprise. This includes planning and controlling of processes that are required for managing data, documents and enterprise resources throughout the entire product lifecycle. PLM systems are distributed technological information systems for archiving, administering and providing all product or facility related information in required quality and at the right time and place. 9.2 Previous research There have been many modeling works that can be classified into two categories: enterprise modeling methods and PLM related modeling, as shown in Table 13.

9.2.1 General enterprise modeling method Integrated Enterprise Modeling (IEM) approach is being developed by the Fraunhofer Institute in Berlin. It is based on SADT/IDEF0 from which it borrows the activity box concept. It strongly promotes an object-oriented approach for the definition of the input, control, output, and mechanism (ICOM), and interface of the activity box. It can be applied to system requirements definition and design specification but does not provide an implementation description model (Vernadat 2002). CIMOSA, European Open Systems Architecture for CIM, has been developed by the AMICE Consortium as a series of ESPRIT Projects jointly financed by the European Commission and project partners grouping CIM suppliers, larger users, and academia from 1986 until 1994. The CIMOSA provides a framework based on the system life cycle concept together with a modeling language and definitions of a methodology and supporting technology. The CIMOSA provides a rich set of constructs to model functional aspects of an enterprise at different abstraction levels using a terminology close to the language of business users (Vernadat 2002). Purdue Enterprise Reference Architecture (PERA) was developed by Purdue University. It is first of all a complete methodology. It is supported by very simple graphical formalisms and easy-to-understand textual manuals. It has been created to cover the full enterprise life cycle from inception and mission definition down to its operational level and final plant obsolescence (Vernadat 1996). ARIS stands for Architecture for integrated Information Systems, which was developed by Prof. Scheer. Its overall structure is very similar to CIMOSA, but instead of focusing on


@

computer-integrated manufacturing systems, it deals with more traditional business-oriented issues of enterprises. It focuses on software engineering and organizational aspects of integrated enterprise system design. It has four views and three modelling levels. The three modelling levels are those of CIMOSA. The four views are as follows: function view, data view, organization view, and control view (Vernadat 1996). GERAM stands for Generalized Enterprise Reference Architecture and Methodology, which was developed by IFAC/IFIP. GERAM essentially builds on results from CIMOSA, GIM, and PERA. The purpose of GERAM is to serve as a reference for the whole community concerned with the area of enterprise integration providing definitions of the terminology, a consistent modelling environment, a detailed methodology, promoting good engineering practice for building reusable, tested, and standard models, and providing a unifying perspective for products, processes, management, enterprise development, and strategic management (Vernadat 1996).

9.2.2 PLM related modeling method CIMdata (2002) addressed a high-level PLM definition, describing its core components, and clarifying what is and is not included in a PLM business approach. CIMdata mentioned three core concepts of PLM: 1) Universal, secure, managed access and use of product definition information; 2) Maintaining the integrity of that product definition and related information throughout the life of the product or plant; 3) Managing and maintaining business processes used to create, manage, disseminate, share and use the information. Ming and Lu (2003) proposed the new business model in virtual enterprise in order to tackle issues of product development in the scope of PLM. The architecture of this new model is developed based on the framework and the application of web service and process management for collaboration product service in virtual enterprise. They proposed the framework of product lifecycle process management for collaborative product services. The framework consists of industry specific product lifecycle process template, product lifecycle process application, abstract process lifecycle management, supporting process technology, supporting standards, and enabling infrastructure. Morris et al. (2004) described, in detail, a case study and solution of an IBM research project (called Hedwig) to investigate creating robust solutions for PLM. They focused on several research issues, including information federation, data mapping, synchronization, and web services connections. They described a working system that allows access to several heterogeneous PDM systems that are used in the automotive and aerospace industries.

Table 13: Modeling methods Classification Previous research

Enterprise modeling

IDEF (Integrated computer aided manufacturing DEFinitions methodology) (Mayer 1994) IEM (Integrated Enterprise Modeling) (Vernadat 1996), PERA (Purdue Enterprise Reference Architecture) (Vernadat 1996), CIMOSA (Open System Architecture for CIM) (Bruno and Agarwal 1997), ARIS (Architecture for integrated Information System) (Scheer 1998a, 1998b), GERAM (Generalized Enterprise Reference Architecture and Methodology) (Vernadat 1996) UEML (Unified Enterprise Modeling Language) (Vernadat 2002)

PLM Related modeling

High-level PLM definition (CIMdata 2002) New business model in virtual enterprise (PLM) (Ming and Lu 2003) Conceptual lifecycle modeling framework with IDEF (Tipnis 1995) Conceptual architecture and the key components for total product lifecycle design supporting system (Kimura and Suzuki 1995) Conceptual product lifecycle model which consists of a product model and a process network for lifecycle simulation (Nonomura et al. 1999) IPPD (Integrated Product and Process Development) methodology: conceptual math model for describing product lifecycle with a simple graph description technique (Yan et al. 1999)


@

Although there have been many previous works about enterprise or PLM related modeling, but few addressed the requirements and basic system architecture for PLM, in particular, closed-loop PLM using embedded device. Although CIMOSA and PERA considered the lifecycle concept, however, their lifecycle concepts are focused on the development of manufacturing systems or enterprise business. Moreover, the previous product lifecycle modeling methods lacked integrated views throughout enterprise lifecycle (Tipnis 1995, Kimura and Suzuki 1995). For example, Ming and Lu (2003) addressed the architecture for PLM but they only focused on the process viewpoint. In summary, enterprise modeling frameworks are too broad and conceptual to describe PLM system architecture. On the other hand, the previous PLM modeling works are too conceptual and implicit to do it. 9.3 State-of-the-art of PLM Usage

9.3.1 Penetration in Industry PLM technology is primarily used in automotive and aerospace industries followed by machinery industry. The minority of productive applications are in high tech/electronic and heavy construction industries. The different degree of penetration in industry is founded on different requirements of business. Aerospace industries’ products have long lifecycles, high complexity and nearly no possibility of physical prototyping. In contrast to that electronic goods have very short lifecycles and minor product complexity, e.g., mobile phones. The number of parts that must be handled and variant management capabilities are important criteria for system selection in aerospace industry. On the other side an OEM of electronic equipment has strong requirements for configuration management and flexibility in reacting on dynamic constraints at the component suppliers’ side. High tech manufacturers do not have intensive construction phases in product lifecycle like automotive manufactures have, but design and sales-oriented Business-to-Business (B2B) processes are essential for that industry. This means, the kind of PLM solution and drivers for system introduction are totally different for each industry because of the individual business processes.

9.3.2 System Introduction For more than twenty years PDM systems have been developed and applied, but mostly large companies gained experiences in that field. More than 50% of all large companies have productive PLM applications and only 10% of them are without activities for introduction (Figure 7). But most companies with productive PLM applications are planning to replace parts of their current system environment by the next system generation. Because of this, users have started setting up project pilots for benchmarking, testing and evaluating. In some cases management strategies have led to a complete replacement of current productive PLM systems. Nearly 30% of mid-sized companies are using PLM systems, but these implementations are not as complex as in large companies. There is a high potential for software vendors and integrators to start first initiatives for SME because 25% of midsized and 53% of small companies are still showing no activities in this field. 14% of small companies have implemented turnkey-solutions, which are offering core functionality and high usability.


@

Figure 7: Status of PLM introduction

9.3.3 Functionality Today most of the PLM systems include basic features like:

• Data vault management • Document and object management • Release and change management • Product structure management • Viewing, mark-up and image services • Classification of retrieval • Configuration management • Tools for system administration, configuration and customizing • Management of assets (e.g. plant machinery and facilities, production line equipment • Management of in-service information supporting service after sales • Notification services using mail servers

Typically, PLM is used to work with digital files and database records. These may include product configurations, part definitions and design data, specifications, CAD drawings, engineering analysis models, manufacturing process plans and NC part programs. Modern systems are providing additional groupware functions for enterprise-wide collaboration.


@

9.3.4 Integration and Interfaces PLM is an initiative that encompasses all of what is within design and development, added program management and is expanding out into maintenance and support. This is why integration of applications across the product lifecycle and non-redundant and consistent management of information becomes very important. More than 40% of all CAD systems are well integrated in PLM systems. 26% of CAD systems can exchange product information automatically with PDM systems in both directions. ERP systems have traditionally dealt with the product production lifecycle. New solution providers are beginning to deliver products that combine some ERP and some PLM capabilities into one offering. Other business functions, such as the logistics of supply chain management, logistics itself, marketing and sales, distribution, HR and finance are not part of the basic PLM capabilities, but they all interact at multiple points along the product lifecycle or with components of a comprehensive PLM solution. Most of the ERP systems (84%) can exchange data in one direction, but there is no sufficient integration at all. Normally, information is moved by interfaces to the ERP system where Bills of Materials (BOM) are built and processed. Only 11% of project management tools are integrated in PLM systems. 67% of them have just an unidirectional possibility for data transaction. Most PLM systems are offering interfaces to CAD systems, MCAD and ECAD systems, office applications, DTP systems, and ERP/MRP systems. Specific APIs can be programmed. Data exchange is supported by using standardized data formats, e.g., STEP (AP 203, AP 214) or XML. While interfaces for engineering applications reached an advanced level the integration level of business partners today is still insufficient. End customers are not integrated in PLM based processing. 30% of suppliers can only reach the needed product information by viewing them on the client side, while 70% still have no PLM based access. Development partners are currently best integrated into business processes of all business partners. 45% of them have full access to their partners’ PLM database and 30% of them can use bi-directional data transactions.

9.3.5 System Architecture PLM systems include a distributed electronic vault as file server or data repository, a set of user functions, a set of utility functions, and a distributed data management system for meta-data. An electronic vault is used as a repository to control all kinds of product information. Distribution and file replication is up the data management system or the PLM system itself. Although meta-data models in PLM systems are object-oriented, relational data management systems are the de facto standard for PLM systems. PLM systems can be divided into two categories: Web-enabled systems use system modules which have a procedural software kernel without the ability of using internet technologies. Web-centric systems use modules which are based on an object-oriented software kernel. These modules have the ability to communicate by directly using internet technologies. Web-enabled PLM systems are still providing limited functionality and accessibility over the internet. Full access to web-enabled PLM systems is only provided via platform-specific clients, which communicate using standard network protocols. The boundaries between a completely web-centric and a web-enabled system architecture are difficult to determine. Ideal web-centric solutions can be characterized by the consequent usage of internet-based technologies in all modules.


@

9.3.6 Use of PLM Technology Instead of covering applications and processes along the product lifecycle, PLM solutions are still focused on product design and prototyping (Figure 8).

Figure 8: Current use of PLM along the product lifecycle today Today productive PLM applications are more than five years behind state-of-the-art solutions. Technological potentials have not been utilized consequently and have led to a poor integration level of business applications and processes. Implementation problems have been underestimated and project goals have not been fully achieved. Achieved benefits of PLM are the standardization and automation of workflows, even if they are not completely supported by the system. Using PLM it is easier to access, to extract and to handle product information in global environments. Although quantification of certain benefits is difficult for users, the reducing of product development times and time-to-market are facts. PLM technology provides high data consistency and transparency, which have tremendously increased process and product quality.


@

PART III: THE PROMISE DEMONSTRATORS


@


@

10 Introduction to the presentation of the Demonstrators

10.1 Participants in the WP R3 and focus area of Demonstrators Table 14 shows the involved partners in WP R3 that are responsible for the subsequent application work-packages A1 to A11. The table also illustrates the main focus lifecycle phase of each demonstrator, the related application work-package and application cluster the partner is involved in. Demonstrator relates to the following application work-package

Main focus lifecycle phase

Partner Application cluster activity

WP A1: PROMISE EOL information management for monitoring End of Life Vehicles

EOL CRF AC-1

WP A2: PROMISE EOL information management for heavy load vehicle decommissioning

EOL CATERPILLAR AC-1

WP A3: PROMISE EOL information management for tracking and tracing of products for recycling

EOL BIBA/INDYON AC-1

WP A4:PROMISE MOL information management for predictive maintenance for trucks

MOL CRF AC-2

WP A5: PROMISE MOL information management for heavy vehicle lifespan estimation

MOL CATERPILLAR AC-2

WP A6: PROMISE MOL information management for predictive maintenance for machine tools

MOL FIDIA AC-2

WP A7: PROMISE MOL information management for EEE (1)

MOL MTS AC-2

WP A8: PROMISE MOL information management for EEE (2)

MOL WRAP AC-2

WP A9:PROMISE MOL information management for Telecom equipment

MOL INTRACOM AC-2

WP A10: PROMISE BOL information management for Design for X

BOL BT-LOC AC-3

WP A11: PROMISE BOL information management for Adaptive Production

BOL POLIMI AC-3

Table 14: Involved partners in WP R3 and main focus in their demonstrators In this Part III of the report, a brief description of the each demonstrator can be found. Both objectives and an overview of the related functionalities needed to fulfil the objectives are also added. The complete demonstrators can be found in Appendix A.


@

10.2 The structure of the demonstrator documents in Appendix A In order to document the demonstrators, the following structure was chosen for the demonstrator documents, which are presented in Appendix A. The following chapters 11 to 21 in this report are excerpts of the documents found in Appendix A, but do not cover all aspects found in the appendix. A total number of 7 parts can be found for each demonstrator in the appendix. Part 1 covers what the demonstrator is, its overall functionality and the rationale why this is the focus for the demonstrator. This overall description is an introduction and provides the overview of the demonstrator. This description is also found in the following chapters. Part 2 of the demonstrator states the objectives that are sought achieved by the PROMISE demonstrator. The rationale why the objective is important for the demonstrator is also stated. The objectives with rationale are also presented in the following chapters. Part 3 describes the lifecycle actors, whether they are external or internal actors, and how they are/will be involved in the demonstrator. Further, the importance of the actor related to the demonstrator and its place in the lifecycle are indicated. Part 4 focuses on the physical components that are to be part of the demonstrator. The physical components functionality and necessary interfaces to other components, software/support-systems are presented. Included for each component, a description of the availability of the component in-house of the company responsible for the demonstrator is discussed. Further, the relation to the demonstrator objectives in part 2 and the functionalities of the demonstrator (part 6) are covered. Part 5 concerns the demonstrator software/support-systems and the needed functionality. The same way as interfaces, availability, relation to objectives and functionalities were described for the physical components, this is also done for the systems in Part 5. Part 6 is the description of the functionalities of the demonstrator. In this part, both the outputs and required inputs of each functionality are described together with any necessary controls and technologies/systems/actors involved. Further, the rationale why the functionality is needed, its priority and which objective the functionality is related to are stated. The functionalities themselves with brief comments are presented in the following chapters. Part 7 is a draft visualisation of the functionalities and forms the basis for discussion and further refinements of the functionalities found in part 6 in subsequent work-packages of the PROMISE project. The visualisation consists of believed needed inputs and outputs for the functionalities, what sort of systems/actors etc are needed, and also comments on when or what governs the functionality. The draft visualisations are based on IDEF0 as IDEF0 is commonly known by all partners that has developed, and will further develop, their demonstrators. However, many aspects of the functionalities, inputs etc are yet to be developed in subsequent work-packages. The draft visualizations will therefore be used conceptually in the subsequent work-packages of PROMISE. All parts of the demonstrator documents are living parts. This implicates that the parts will be used as basis for further work and will be subject for several upgrades as the PROMISE project progress after this deliverable DR3.2 has been submitted.


@

11 A1 CRF (EOL) – Passenger car

11.1 A1 – The Demonstrator The main focus of the A1 CRF EOL demonstrator is the passenger car and its EOL phase. The reason for this focus is that the lifecycle of a passenger car is quite long. Closing the information loop of a product with a long life is of paramount importance for CRF. Especially considering that the residual value of the product at EOL is still high, both in reusability potential and in terms of environmental impact. The lifecycle actors involved in this demonstrator are: the users of the car, the design department of the car manufacturer, the authorised garage, the authorised dismantlers, the after sales department and the re-manufacturer.

Figure 9: The A1 demonstrator illustrated CRF lists a total number of 7 objectives that are sought achieved through this PROMISE demonstrator. These are listed here with a short description why the objective is important.

O1: Identify what components are worth re-using when deregistering the vehicle. Increasing the percentage of reused components and increasing the viability of the initiative (also introducing automation procedures) is one of the key drivers for reducing OEM Deregistering costs.

O1.1: Tracking relevant components information from B.o.M. / Production phase. Some information about component origin (composition, production date, design nr, etc) are necessary for the decision that will be taken at the moment of deregistration.

O1.2: Tracking relevant component information about its usage / mission. The wear-out level of a component can differ considerably depending on the mission experienced by the component itself. It is therefore necessary to define some effective “summary”, capable to synthesise mission profile. Once a suitable summary has been chosen, it is necessary to continuously update it during usage.

O1.3: Updating / resetting information about component mission in case of component substitution. If a component is replaced, the summary about the mission profile must be reset.

LAST OWNER CRUSHER

Iron Lightmetal

DISMANTLING

Glass Seat foams

BottlesUndercarpetsCar

air ducts

Catalyticconverters

5% Ash to landfill

ENERGY RECOVERY

Used sparepartsOils, batteries

Inertization/reuse

Fluids,other dangerous

material

National Obligatory Consortia

Precious metals

FLUFF INCINERATION

DISMANTLERMETALLURGICAL

INDUSTRY

METALS RECOVERY

Bumpers

DEPOLLUTION

SHREDDER


@

O1.4: Identify economical information about component re-use. Another fundamental aspect to be taken into account is the commercial viability of the component. This evaluation depends also on potential II hand market sale price, market acceptability capacity and so on.

O1.5: Decide whether to re-use a component or not, using all the information from O1.1 to O1.4. This is the important objective to fulfil, as this fulfils the O1 objective.

O2: Transfer on the component “some” relevant info about its post –deregistering life. The availability of a Tag on the component can be used to record relevant info about the treatment after separation from the vehicle. Depending on the decision taken in O1.5 it is necessary to record what reworking is necessary (if any), other info about wear out level and so on.

11.2 Overview of the functionalities of the A1 CRF EOL Demonstrator CRF has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

• FU1 - Update Component mission profiles Clock = 1 second

• FU2 - Reset Component mission profile, update age of component This operation should be fully automatic

• FU3 - Transfer Ident. Nr, substitution date from TAG to DSS On-board computer could be used to do this transfer

• FU4 - Transfer Comp. Mission profile and mileage from on board computer to DSS • FU5 - Get off-line info from OEM back-end system and decide • FU18 - Transfer Info from DSS to Component TAG • FU21 - Transfer Info from DSS to OEM back end system


@

12 A2 CAT (EOL) – Engine in Track Type Tractor (TTT)

12.1 A2 – The Demonstrator Caterpillar has chosen the Engine of Track Type Tractor (TTT) for this demonstrator. The A2 demonstrator will aggregate all kind of field data, product specific information, and additional information and transform it – supported by decision support systems – into knowledge that can be used to take productive and effective actions. The data must be accessible by the supply chain in a PDKM system. This demonstrator covers the closure of the information loop between product operation (MOL) and product recycle, reuse, remanufacture or disposal (EOL). However, to effectively impact these focus areas the demonstrator will also have to close the loop with manufacturing and design (BOL). The lifecycle actors involved in this demonstrator are: product design, manufacturing, logistics and remanufacturing.

Figure 10: The A2 CAT EOL Demonstrator Track Type Tractor (TTT) A total number of three objectives is sought achieved by this demonstrator.

OB1: Prove the closure of the information loop between knowledge required to manage the field population as well as make the appropriate EOL decisions. This demonstrator covers the closure of information loop knowledge-based actions at the end of life (EOL).

OB2: The demonstrator shall aggregate available engineering data, field data, and ancillary information. All required information and data will be used to manage the field population as well as making decisions and selecting procedures for product recycle, reuse, remanufacture or disposal (EOL).

OB3: Use product embedded devices such as RFID to track components and automatically maintain related data linkages such that it can be transformed into the required knowledge. This provides a decision making process for EOL that is based on knowledge of the entire field population.


@

12.2 Overview of the functionalities of the A2 CAT Demonstrator CAT has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

FU1 - Initial data storage and reading system from RFID Flexible and user configurable. Intuitive user interface that is automated where possible.

FU2 - PDKM functionality for the logistics management system for EOL remanufacturing Flexible and user configurable. Intuitive user interface that is automated where possible.

FU3 - PDKM functionality for field application data collection and remanufacturing system Flexible and user configurable Intuitive user interface that is automated where possible.

13 A3 BIBA/INDYON (EOL) - information management for tracking and tracing of materials in recycling plant

13.1 A3 – The Demonstrator The main focus of this demonstrator is the EOL information management for tracking and tracing of products for recycling in a recycling plant. The focus will be on material flow and information flow, and the main actors are: customers selling used parts, logistic operators, machinery workers recyclers, customers who use recycled plastics, automotive design departments. For the material flow of car bumpers, Figure 11 illustrates the application field for the RFID technology in the life cycle of car bumpers with an attached or embedded tag (or PEID) from the producer side.

PPCollectingSorting

MillingFilling

Loading

TransportMeasuring ofheaviness

Loading (in)ControllingQuality checkMeasuring of heavinessStorageLoading (out)

Data transfer:

PROMISE PEID System

PROMISE PDKM System

Data transfer:

PROMISE PEID System

PROMISE PDKM System

MixExtrusionGranulatingFilling

Waste

Production / use

Loading (in)Storage Loading (out)

TransportMeasuring of heaviness

2

4

P

P

P

P

PP

P

P

P P P

P

P

PP

P

PP

P

P

P P

Figure 11: Use of RFID technology in the recycling of bumpers


@

The objective of this demonstrator is to develop an application which supports the tracking and tracing of products estimated for recycling by using the PROMISE PEID technology and PDKM system in combination with the using of indoor and outdoor navigation systems. The application scenario including specifications for the required equipment, the sensors, the smart tags, the receivers i.e. all the communication infrastructure will be provided by INDYON and BIBA by taking into account results of a national funded research project (OPAK). The above objective has been broken down into four objectives:

OB1: Develop an application which increases the recycling rate. Less waste, legislative pressure, financial aspects, independency from raw materials.

OB2: Tracking and tracing of relevant product data together with the materials during all recycling processes and supply of these data for recycling process. During the processes where the materials are being milled, etc. it is important to keep the right data to the materials, even when there is a mixture of different batches. The parameters of the recycling processes depend on these data.

OB3: Tracking and tracing of relevant product data together with the materials during all recycling processes and supply of these data for product design. During the processes where the materials are being milled, etc. it is important to keep the right data to the materials, even when there is a mixture of different batches. The design of new products depends on these data.

OB4: Support of decision making systems with relevant data. Control systems adapted to the processes depending on the incoming data from the materials.

13.2 Overview of the functionalities of the A3 BIBA/INDYON Demonstrator BIBA/INDYON has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

FU1 - Data transfer from RFID transponder tagged to the bumper to packing material after cutting and milling Access to the PROMISE PDKM system

FU2 - Data transfer from RFID transponder tagged to the packing material to on-board computer fork lift The data transfer must be in real time by having an W-LAN access from the fork lift to the PROMISE PDKM system

FU3 - Transport of packing material The data transfer must be in real time by having an W-LAN access from the fork lift to the PROMISE PDKM system (for the navigation of the fork lift).

FU4 - Storing of packing material The data transfer must be in real time by having an W-LAN access from the fork lift to the PROMISE PDKM system (for the navigation of the fork lift).


@

14 A4 CRF (MOL) - Truck

14.1 A4 – The Demonstrator The A4 CRF MOL focus is the Truck. The main reason for focusing on trucks in this demonstrator is that monitoring information during MOL will allow the improvement of maintenance plans and to acquire info about the vehicle mission profile. The lifecycle actors involved in this demonstrator are: the users of the trucks, the design department of the truck manufacturer, the authorised garages that perform service on the trucks, the after sales department and fleet managers.

MAINTENANCEON DEMAND

MISSION PROFILE ID.

MISSION ANALYSIS

REMOTE DIAGNOSTIC LINK (WIRELESS)

GROUND STATION

Information and clustering of data

E C U

GPS GSM/GPRS

Signals

COMUNICATION WITH CAN(ECU Engine, ECU, Transmission, …)

IDENTIFICATION OF INCOMING ANOMALIES IDENTIFICATION OF MISSION PROFILES AND CORRELATION WEAR / DRIVING STYLE

MAINTENANCE

REMOTE DIAGNOSTIC

LINK

Engine usage profile

Consumption analsys


MISSION PROFILE ID.

MISSION ANALYSIS


GROUND STATION


E C U

GPS GSM/GPRS

Signals



MAINTENANCE

REMOTE DIAGNOSTIC

LINK


Consumption analsys

Figure 12: Illustration of the A4 CRF MOL demonstrator CRF has identified four objectives that are to be achieved by this demonstrator:

O1: Develop a predictive maintenance algorithms able to predict engine oil wear out for the specific vehicle depending on ad-hoc mission profile indicators. From a business point of view: Optimisation of maintenance policy will improve vehicle availability and safe of material. From a research point of view: Oil Life Management Strategy is an active R&D filed where most important OEM are playing.

O2: Collect prediction values as defined in OB1 on a ground station in order to remotely manage a fleet of vehicles. This is a first step for the fleet management. The results of the predictive maintenance algorithms are transmitted to the ground station. Some first statistics about the fleet behaviour and component wear out are possible.

O3: Collect ad-hoc mission profile indicators as defined in OB1 on a ground station in order to remotely monitor a fleet of vehicles, with the application of the predictive maintenance algorithms on the ground station. Monitor and analysis capabilities on the ground station will improve if it would be possible to send to the ground station mission profiles indicators used to define the predictive maintenance algorithm.


@

O4: Collect ad-hoc mission profile indicator on a ground station in order to remotely monitor a fleet of vehicles, with the objective to have information about the mission profile of each vehicle belonging to the fleet. The data elaboration should be able to: give residual autonomy for each vehicle, provide feedback about the vehicle “correct” usage, provide feedback about fleet mission profile, and provide feedback about typical component usage maintenance management (policy, day by day maintenance). Further, to optimally monitor and analysis capabilities on the ground station by using all the useful mission profiles indicators.

14.2 Overview of the functionalities of the A4 CRF MOL Demonstrator CRF has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

FU1 - Real time measure component physical values (for ex. Engine rpm, engine load etc) FU2 - Updating of mission profile indicators, relative to vehicle, components or engine oil. FU3 - Reset mission profile indicators, relative to vehicle, components or engine oil FU4 - Calculate component residual autonomy FU5 - Send message to the driver FU6 - Send message to the ground station FU7 - Send mission profile indicators to the ground station FU8 - Send mission profile indicators to the ground station FU10 - Fleet management


@

15 A5 CAT (MOL) – Lift arm of the Grenoble Track Type Loader (TTL)

15.1 A5 – The Demonstrator The A5 CAT MOL demonstrator will use the lift arm of Grenoble Track Type Loader (TTL) as the basis for the demonstrator. The demonstrator will aggregate all kinds of field data, product specific information, and additional information and transform it – supported by decision support systems – into knowledge that can be used to take productive and effective actions – i.e. to increase uptime through better service. The data must be accessible by the supply chain in a PDKM system. This demonstrator covers the closure of the information loop between product operation (MOL) and product recycle, reuse, remanufacture or disposal (EOL). However, to effectively impact these focus areas the demonstrator will also have to close the loop with manufacturing and design (BOL). The lifecycle actors in this demonstrator are: product design, manufacturing, dealers, owners/operators, suppliers and logistics.

Figure 13: The Grenoble Track Type Loader (TTL) of A5 CAT MOL 15.2 Overview of the functionalities of the A5 CAT MOL Demonstrator CAT has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

FU1 - Initial data acquisition and management system from sensor Flexible and user configurable. Intuitive user interface that is automated where possible.

FU2 - PDKM functionality for the logistics management system Flexible and user configurable. Intuitive user interface that is automated where possible.

FU3 - PDKM functionality for field application data collection and management system Flexible and user configurable. Intuitive user interface that is automated where possible.

FU4 - PDKM functionality that provides Df(x) information to designers


@

16 A6 FIDIA (MOL) - Milling machine

16.1 A6 – The Demonstrator The A6 FIDIA demonstrator focuses on milling machines. Milling is the process of cutting away material by a rotating cutter. FIDIA Milling Machines are integrated systems for the machining of complex forms for the moulds and dies industry. Milling systems are made up of multiple mechanical axes moved by electric drives that are able to translate and rotate the milling head in the workspace. The milling head is made up of a rotating spindle equipped by a set of many different machining tools that allow the realization of various and complex forms. The milling systems are controlled by a numerical control. This demonstrator is related to the improvement of technical aspects of the product functionalities after exploiting field knowledge gathered through the product lifecycle. The lifecycle actors in this demonstrator is the customers of FIDIA, FIDIAs design department and FIDIAs technical assistance service.

Figure 14: Illustration of the A6 FIDIA demonstrator FIDIA has developed three objectives that are to be met by this demonstrator:

OB1: Traceability of components The components do not reside on the same machine throughout their lifecycle. Often after a repair intervention a fixed component is re-installed on a different machine. It would be highly desirable to keep track of the ‘history’ and the characteristics of the components installed on each machine because knowing their exact features makes easier the technical interventions.

OB2: Predictive Maintenance FIDIA can get useful information about the components state performing periodic checks on the machine. Storing this data enables statistical analysis of the components lifecycle, such as finding the relation between the wear and the failure rate. This can help to single out the machines failure causes, allowing the optimization of the technical interventions and thus minimizing machine unavailability.

OB3: Design improvement The constant improvement of the machine design is essential to offer the customers products more fitting to their requirements. Also a better components design can allow easier technical interventions.


@

16.2 Overview of the functionalities of the A6 FIDIA Demonstrator FIDIA has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

FU1 - Data transfer (read/write operation) between RFIDs installed on critical components of a milling machine and receiver. The data transfer should be periodical (e.g. every three months).

FU2 - To allow traceability of components. RFIDs should store technical data (e.g. from data sheets) about the installed components. Moreover the RFIDs should collect data of all the technical assistance interventions performed on each component.

FU3 - To execute Predictive Maintenance evaluations. The decision support software gathering data from RFIDs should run locally on the PC of the Numerical Control. This SW should:

o perform suitable tests on the machine o elaborate data and extract relevant parameters o make decisions based on these parameters.

17 A7 MTS (MOL) - Condensing wall hung gas boilers

17.1 A7 – The Demonstrator This demonstrator focuses on MTS’ condensing wall hung gas boilers and improving maintenance and service operations related to boilers and as a result increase performance and up-time of said items, and thus achieve customer satisfaction. The lifecycle actors involved in this demonstrator are MTS after sale service, the related service companies of MTS’ products, and the boiler owners.

Figure 15: Illustration of the A7 MTS demonstrator

MTS Brown-goods demonstrator for MOL

Serial protocol already implemented on boiler control board

PEID (developed in RC2 and provided by involved partners)

Sensor: developed in RC2 and provided by involved partners

RF short distance

Internet communication (long distance)

PLM Preventive maintenance algorithms Developed in RC4

Boiler provided by MTS


@

A total number of three objectives have been defined by MTS as important to achieve with this demonstrator:

OB1: To systematically collect and store the data relevant to the application and to apply evolutionary diagnostic and prognostic algorithms over the product lifespan (MOL), which will make it possible to do Predictive Maintenance on gas boilers. Prognostic algorithms will enable Service Companies to do Predictive Maintenance on gas boilers. Prognostic algorithms, by analyzing continuously data acquired from PEID (developed for MTS’s specific demonstrator by RC2, in WP R4 and R5) from demonstrator (gas boiler), must be able to recognize that a specific component or system is going to have a failure in a certain time span and with a certain probability percentage. The Service Companies will then have the time to plan a visit to the boiler’s owner bringing with them the right spare part, before the component breaks down, and so the owner will have 100% boiler availability, not suffering from a cold house.

OB2 Test the PEID, developed under MTS specifications by RC2, in WP R4 and R5, on the gas boilers, in order to assess its capability to collect data from boiler serial protocol and from additional sensors, store and transmit data with long distance communication capability. The bigger obstacle to the introduction in each boiler of a data logging/analysis/shipment system (PEID) to a remote collecting point (PLM/PDKM/decision making support system) is mainly the cost of the PEID. The target price for PEID will be reached when every house will have and IP connection already available. In Promise project the goal is to prove the concept.

OB3: Test the back-end, PDKM, PLM, DSS, developed in RC-3 and RC-4 according to the MTS demonstrator needs, to prove that it is able to handle all data coming from PEID, analyze it through predictive algorithms, send e-mail to Service Companies to advise of a predicted failure, with a WEB interface accessible by Service Company/MTS who can see list of all errors, make graphs of data, set parameters like e-mail, dial the PEID and see real time values of all data/sensor logged from the boiler, and download to a local PC in xls format from the PDKM through a web interface all data received from PEID and all info generated by data analysis (e.g. trends of Predictive maintenance indicators). It must also be accessible to boiler manufacturer for changing parameters needed to tune predictive algorithms. The goal is to handle info on MOL from the source of data (PEID connected to the boiler and to additional sensors), to analyze it (predictive algorithm) and to let the users (Service Companies and MTS) to access this info, for predictive maintenance.

17.2 Overview of the functionalities of the A7 MTS Demonstrator MTS has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

FU1 - Collect, store, analyze and transmit data with long distance communication capability from boiler control board serial protocol and from additional sensors, to the PLM/PDKM/DSS (this work is done by specifi PEID with long distance communication developed in RC2). How many data, type of data, type of sensors, samples time of each single data, memory space necessary, MIPS required must be defined with the partners involved in designing predictive algorithms.

FU2 - PDKM, Decision making support system, predictive algorithms Store data coming from PEID; analyze them with predictive algorithm and generate failure prediction.


@

FU3 - WEB interface for the back-end Promise Users, which are Service Companies and MTS, must have a WEB interface to be able to have functions as described in SS1, and OB3

18 A8 WRAP (MOL) – Refrigerator

18.1 A8 – The Demonstrator The focus of the WRAP demonstrator is the refrigerator (i.e. the cooling system in residential use). The reason for this focus lies on the fact that a regular lifecycle for a refrigerator is about 10 years and for that period of time the manufacturer isn't aware of what really is going on with the appliance since there are no pre-scheduled checks/inspections (like in the automotive industry for example). When a refrigerator stops working all its perishable load (food) is lost and that causes a lot of trouble and complication for the owner. In addition, for a multitude of reasons, the condition in which the appliance operates may vary and sometimes inefficiencies of the compressor level might develop and thus lowering its electric efficiency (sometimes also downgrading to different class: i.e.: A --> B). The result is larger electric bills for the owner and a relative large environmental impact. Ideally, white goods appliance manufacturers (like WRAP) are looking to deliver SERVICE and not just the product, to either increase customer fidelization level as well as the quality of the product. The lifecycle actors involved in this PROMISE demonstrator are the WRAP service companies, WRAP’s production and electronic design departments.

Figure 16: Illustration of the A8 WRAP demonstrator WRAP has defined a total number of four objectives to be achieved by this demonstrator:

OB1: Faster End-of-line testing Reduces in-line time of the good

OB2: Compressor efficiency Longer life for the goods and environmental impact reduced

OB3: Cooling circuit pressure Longer life for the goods and environmental impact reduced

OB4: Internal/External Temperature Better food conservation and parameter for compressor efficiency

Refrigerator Under Test

Proxy Device

Ultra Low Cost Power-line

Diagnosis by Performance

Wireless Link

Knowledge Repository


@

18.2 Overview of the functionalities of the A8 WRAP Demonstrator WRAP has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

FU1 - Data transfer from Refrigerator Main Board to Proxy device At least one resistive load in the WG appliance (i.e.: lamp)

FU2 - Transmission of data to a local / remote Server (for data reconfiguration/analysis) Communication node (for both tx and rx) to enable communication

FU3 - Electric quantity measurement Power Meter within the proxy device

FU4 - Refrigerator parameter set updating File setting parameter knowledge (which parameter needs to be updated)

FU5 - Refrigerator Control Board data acquisition from sensors and electric load Refrigerator Digital control board

19 A9 INTRACOM (MOL) –Telecom equipment

19.1 A9 – The Demonstrator In the A9 demonstrator, INTRACOM focuses on its INTRACOM Broadband Access System, IBAS. The IBAS system contains a set of components for delivery of narrowband voice services across an Access Network. It is a Next Generation Multi-Service Access Node (MSAN) featuring broadband and narrowband subscriber interfaces. IBAS is one of the DSLAM family products, which is the last element in the access network before the subscriber’s home, and is thus the vehicle for delivering broadband services. The IBAS product includes software and hardware components (line cards). This broadband access system is one of INTRACOMs key products under development, and will be used as the corner stone of Next Generation Access Network. The lifecycle actors of this demonstrator are technicians (service, maintenance teams), engineers (designers, product managers), and INTRACOM’s customers.

Figure 17: Part of the INTRACOM Broadband Access System (IBAS) Based on the importance of this demonstrator for INTRACOM, the company has set a total number of four objectives that are to be met:


@

OB1: To efficiently collect, integrate and manage information about the product. The collected information will be appropriately managed providing to the evolved actors the tools to correspond efficiently and effectively when a problem occurs and support decisions about product improvements.

OB2: To receive information about product operation. This raw data will provide valuable input to obtain knowledge about the product.

OB3: To transform operational data to valuable knowledge. The transformed data are going to be used for the decision support system.

OB4: To support decision making. The engineers and technicians will be able to be supported about product improvements and problems solving/preventive maintenance.

19.2 Overview of the functionalities of the A9 INTRACOM Demonstrator INTRACOM has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

• FU1 - Identify performance • FU2 - Identify repetitive problems • FU3 - Decision about product improvement • FU4 - Request for best practices • FU5 - Request for trouble shooting information • FU6 - Update the PDKM with the incidents • FU7 - Operational data transferred into PDKM • FU8 - Maintenance data transferred into PDKM • FU9 - Call tracking data transferred into PDKM • FU10 - Update product data

20 A10 BOMBARDIER TRANSPORTATION (BOL) – Traction chain of electrical locomotive

20.1 A10 – The Demonstrator The main focus of this demonstrator is on the traction chain of an electrical locomotive. The traction chain of an electric locomotive transforms electrical energy into the wheel movement, transferring traction force to the rail or transforms brake forces into electrical energy. The traction chain is a central function of an electric locomotive, where BT gathers various field data which can be used to validate the DfX Demonstrator. The DfX Demonstrator will aggregate all kind of field data and additional information, and transform it – supported by decision support systems – into DfX knowledge, accessible by the engineers in a PDKM system. This demonstrator covers the closure of information loop between product operation (MOL) and design (BOL). The lifecycle actors involved in this demonstrator are the following: service organisation (inclusive commissioning), DfX specialist engineers, engineers / designers, operator, IS specialist, and maintainers.


@

Scop

e of

Sce

nario ‘DfX’ Transformer

• Aggregation of field information

• Transformation into appropriate DfX knowledge

• Management of baseline-oriented configurations (as offered, as designed, as built, as maintained

Decision Support System

• Supporting the transformation of field information into knowledge

• Deriving of actions

Engineering ServiceManufacturing

PDKM Environment

• Management of DfX knowledge

• Application-specific presentation of DfX knowledge

Field Data

Field Info Database(Captured by CM / CBM, FRACAS,

Service and/orProduct-Embedded Devices)

Other Info Sources(PDM, Databases,

Standards & Regulations, etc)

Supply Mgt / Supplier

Figure 18: The A10 BT-LOC demonstrator BT-LOC has developed five objectives, where the first objective (OB1) is the overall objective of the demonstrator.

OB1: Prove the closure of information loop between experience embedded in field data and knowledge (concentrated on Design for X aspects). This demonstrator covers the closure of information loop between product operation (MOL) and design (BOL).

OB2: Demonstrator shall aggregate available field data and additionally needed other information. For the transformation process all necessary data shall be considered from various sources.

OB3: Semi-automatic transformation of field data into appropriate DfX knowledge governed by specialist engineer. The specialist shall finally decide on the transformed DfX knowledge.

OB4: Transformation process shall be adequately supported by a decision support system. The decision support system shall aggregate necessary data & information into deciding basis & decision proposals and provide them to the specialist engineer.

OB5: Knowledge Management functionality as part of PDKM environment shall manage DfX knowledge structured according to a predefined work breakdown structure (WBS). PDKM environment is the main engineering system to manage information. WBS is the main form how to structure information.

20.2 Overview of the functionalities of the A10 BT-LOC Demonstrator BOMBARDIER has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

• FU1 - Field info database to manage all kind of field data Database shall manage all kind of field data captured by CM, FRACAS (VIPSCARSIS,


@

MAXIMO), Service and/or PEID’s and shall standardize this electronic data for transfer to the demonstrator (see Use Case Diagram).

• FU2 - Read in different kind of field data from different sources Demonstrator shall accept all kind of field data captured and processed by field data base and from other sources as: CM/CBM, FRACAS (VIPSCARSIS, MAXIMO), Service and/or PEIDs and shall aggregate this electronic data into appropriate information.

• FU3 - Read in additional necessary information on product, lessons-learnt, standards, etc. Allow the access of the DfX Transformer to electronic information in PDM, Lotus Notes databases, EboK’s (Intranet), Internet (see Use Case Diagram).

• FU4 - Transformation of data into DfX knowledge Transformer processes, semi-automatically DfX knowledge following defined transformation methods under governance of specialist engineer. Transformer provides the DfX knowledge to PDKM system. DfX knowledge shall be periodically updated if additional field data or other information is available. For the aggregation and transformation process the different configuration (as-designed, as-built, as-maintained) of the input data shall be considered appropriately. The tool supporting the transformation process shall be easy to use and preferably integrated with the other tools in a portal.

• FU5 - Decision Support to support transformation The Decision Support System shall aggregate necessary data & information and provide appropriate deciding basis & decision proposals to the DfX transformation process.

• FU6 - PDKM functionalities to manage DfX knowledge PDKM functionalities shall manage the knowledge provided by the DfX transformer, structured according to a predefined work breakdown structure (WBS) with various vehicle, system and location elements.

21 A11 POLIMI (BOL) – Decision support for introducing changes in a production system

21.1 A11 – The Demonstrator The demonstrator is a software for the support of the decision on the selection of the best change action to introduce in the production system related to the cylinder head of the FIAT multi jet diesel engine. The demonstrator provides robust support to the decision maker in deciding how to modify the production system layout, technology and equipment to satisfy the new product and/or process requirements. In more detail, the possible adaptation actions are:

Introduction of new machines in the production line. Introduction of new part transporters in the production line. Introduction of additional WIP buffers in the production line. Introduction of new work operators in the production line. Modification of process parameters. Modification of the number of fixtures flowing in the production line.

This Demonstrator closes the loop between MOL/EOL and BOL. Indeed the information collected from the field during the MOL and EOL phases is transformed into knowledge which, in turn, generates new ideas for improving the product. The improvement of the product may cause changes of the related production systems often costly or sometimes infeasible. The demonstrator creates the conditions for closing this loop. The lifecycle actors involved by this demonstrator are production system designers, product designers, process designers, and production planners.


@

Figure 19: The production system in focus of the demonstrator A11 Two objectives have been defined by POLIMI for this demonstrator:

OB1: Production system reconfiguration The optimal adaptation of the production system is important because it allows the continuous improvement of the product.

OB2: What if analysis The What If analysis is important to quantify the impact of a potential modification of the product and/or the process. Indeed the product/process designer often considers a large variety of alternative modifications that are difficult to assess in terms of performances obtained at the factory shop floor level. For example it is not possible, without such an analysis, to properly assess the impact of all these alternatives in terms of system throughput, production cost, etc.

21.2 Overview of the functionalities of the A11 POLIMI Demonstrator POLIMI has identified the following functionalities needed to be fulfilled in order to achieve the objectives of stated in the previous section:

• FU1 - To receive data concerning the product, with or without modification with respect to the present product.

• FU2 - To receive data concerning the process, with or without modification with respect to the present process.

• FU3 - To receive data concerning the production system, with or without modification with respect to the present system.

• FU4 - To optimize the configuration of the production system, adapting it to product and process modifications..

• FU5 - To evaluate the performance of the production system.

Buffer #1

Station 1

Station 3

Station 2

Buffer


@


@

PART IV: Concluding remarks


@


@

22 Concluding remarks to the work-package R3, deliverable DR3.2 This report has presented the work carried out in task TR3.2 of the PROMISE work-package R3. One of the underlying objectives of this work-package has been to start the involvement of all the industrial partners of PROMISE as soon as the project started. This has been achieved, and is reflected both in the Application Scenarios, Appendix B, and the Demonstrators, Appendix A. The industrial partners were involved both by interviews carried out in visits to their respective sites, and by the responsibility of developing application scenarios and demonstrators. As a result of the involvement of the industrial partners in preparing both the application scenarios and the demonstrators, the ownership of their own processes related to their respective application work-packages A1 to A11 have been created. This has been an important part of the work related to this deliverable as the respective industrial partner has the responsibility for further developing the results found in this deliverable in their subsequent application work-package. This has been one of the aims of work-package R3, i.e. to have initiated the process and developed the foundation for further work in PROMISE. WP R3 has in this regard contributed to keeping track of the industrial focus in the project, both for the research clusters activities RC1- to RC-4 and the application clusters activities AC-1 to AC-3 where research and development and further development of the results from this deliverable will be carried out. Deliverable DR3.2 has also contributed to creating a common understanding of state-of-the-art issues within essential areas of knowledge needed for the PROMISE project through Part II of this report.


@


@

References and Appendix


@


@

23 References Auto-ID Center (2003). PML Core Specification 1.0. M. Abramovici, Sieg and C. Olaf(2002). STATUS AND DEVELOPMENT TRENDS OF PRODUCT LIFECYCLE MANAGEMENT SYSTEMS. A. Nonomura, T. Tomiyama, and Y. Umeda (1999). "Life cycle simulation for inverse manufacturing," presented at 6th International seminar on life cycle engineering. A.-W. Scheer (1998a) ARIS Business process framework: Springer. A.-W. Scheer (1998b). ARIS-Business process modeling: Springer. Clemons, J. and Unger, K. (2004). PLM – The link between the internal external Supply Chain. CIMdata (2002). Product lifecycle management-empowering the future of business. CIMdata (2004). A CIMdata Report, Product Lifecycle Management. C. Bornhövd, T. Lin, S. Haller and J. Shaper (2005). Integrating Smart Items with Business Processes – An Experience Report. In Proc. of the 38th Hawaii International Conference on System Sciences (HICSS’05). January 2005, Big Island, Hawaii. Commission (1997), “Proposal for a Council Directive on End of Life Vehicles”, Brussels, 09-07-1997, COM (97)385 final 97/0194 (SYN). Datamation Limited (2002). Understanding Product Lifecycle Management. D.C. MacFarlane (Feb. 2002). “Auto-ID based control: An overview”, White Paper CAMAUTOID-WH0oo4, Auto-ID Center, http://www.autoidcenter.org. D.C. MacFarlane (Sep. 2003). The Role of Product Identity in End-of-Life Decision Making. White Paper, Auto-ID Center, http://www.autoidcenter.org. E. Wolfe, P. Alling, Harry Schwefel and S. Brown (2003). Supply-Chain Technology. Bear Sterns Equity Research. EPCglobal(1), Inc. EPCglobal Reader Protocol 1.0. Working Draft. EPCglobal(2), Inc. EPCglobal Tag Data Specification Version 1.1. International Standard. EPCglobal(3), Inc. EPCglobal HF Class 1. International Standard. EPCglobal(4), Inc. EPCglobal UHF Class 0. International Standard. EPCglobal(5), Inc. EPCglobal UHF Class 1. International Standard. EPCglobal(6), Inc. EPCglobal Reader Management 1.0. Working Draft.


@

F. B. Vernadat (2002). UEML: Toward a Unified Enterprise Modelling Language. International Journal of Production Research, vol. 40, pp. 4309-4321. F. B. Vernadat (1996). Enterprise modeling and integration: principles and applications. Chapman and Hall. F. Kimura and H. Suzuki (1995). Product life cycle modelling for inverse manufacturing. presented at IFIP WG5.3 International Conference on Life-cycle Modelling for Innovative Products and Processes, Berlin, Germany. G. Bruno and R. Agarwal (1997). Modeling the enterprise engineering environment. IEEE Transactions on Engineering Management, vol. 44, pp. 20-30. GCI, IBM (Nov. 2003). Global Commerce Initiative – EPC Roadmap. Köln. H. Hock (1993). A Preliminary Study of the Recovery and Recycling of Automotive Plastics. Society of Automotive Engineers, Inc Publication No. 930557. H. Morris, S. Lee, E. Shan, and S. Zeng (2004). Information integration framework for product lifecycle management of diverse data. Journal of computing and information science in engineering, vol. 4, pp. 352-358. http://www.aimuk.org/pdfs/RFID_compendium.pdf http://www.aimglobal.org/technologies/rfid/ http://www.rfidjournal.com/ http://www.tradewindtek.com/ J.A. Tompkins, J.A. White, Y.A. Bozer, E.H. Frazelle, J.M.A. Tanchoco and J. Trevino (1996). Facilities Planning. John Wiley & Sons, New York, USA. P.J. Jakovljevic and J. Brown (2003). Selecting a PLM Vendor. M. Barrat (2004). Understanding the meaning of collaboration in the supply chain. Emerald Group Publishing Ltd. M. Kärkkäinen, T. Ala-risku and K. Främling (2003). The product centric approach: a solution to supply network information management problems. Science Direct. Mikko Kärkkäinen, Timo Ala-risku and Kary Främling (2003). The product centric approach: a solution to supply network information management problems. Science Direct. N. Chokshi, A. Thorne and D.C. MacFarlane (Feb. 2002). Routes for Integrating Auto-ID Systems into Manufacturing Control Middleware Environments. White Paper CAMAUTOID-WH0oo4, Auto-ID Center, http://www.autoidcenter.org.


@

P. Yan, M. Zhou, and D. Sebastian (1999). An integrated product and process development methodology: concept formulation. Robotics and Computer Integrated Manufacturing, vol. 15, pp. 201-210. R. J. Mayer (1997). IDEF0 function modelling: Knowledge based systems, Inc. S. Datta (2004). Adapting Decisions, Optimizing Facts and Predicting Figures- Can Confluence of Concepts, Tools, Technologies and Standards Catalyze Innovation? Working Paper Draft (version 6.0). Forum for Supply Chain Innovation, Massachusetts Institute of Technology. T. Davenport and J. Brooks (2004). Enterprise systems and the supply chain. Emerald Group Publishing Ltd. V. A. Tipnis (1995). Toward a comprehensive life cycle modeling for innovative strategy, systems, processes and products/services. presented at IFIP WG5.3 International Conference on Lifecycle Modelling for Innovative Products and Processes. C. Wright, A. Lewis, H. Hunston and M. Bursa (1997), “Automotive recycling: opportunity or cost?” London, Financial Times Automotive X. G. Ming and W. F. Lu (2003). A framework of implementation of collaborative product service in virtual enterprise. Innovation in Manufacturing Systems and Technology (IMST).


@


Appendix A: The Demonstrators


@


@

Appendix A: The Demonstrators In this appendix, all the demonstrators developed by the partners for the second deliverable DR3.2 of work-package R3 are presented. Where there are discrepancies between the Demonstrator and the Application Scenario (found in Appendix B), the demonstrator-document overrides all aspects of the application scenario.

1 A1 CRF (EOL) – DEFINITION OF THE DEMONSTRATOR ..................................................................107 1.1 A1 – THE DEMONSTRATOR........................................................................................................................107 1.2 A1 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ....................................................................................107 1.3 A1 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ................................108 1.4 A1 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .......................................................................109 1.5 A1 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ..............................................................110 1.6 A1 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR .............................................111 1.7 A1 – DRAFT ILLUSTRATION OF DEMONSTRATOR’S FUNCTIONALITIES .......................................................112

2 A2 CATERPILLAR (EOL) – DEFINITION OF THE DEMONSTRATOR..............................................115 2.1 A2 – THE DEMONSTRATOR........................................................................................................................115 2.2 A2 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ....................................................................................115 2.3 A2 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ................................116 2.4 A2 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .......................................................................117 2.5 A2 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ..............................................................118 2.6 A2 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR .............................................119 2.7 A2 – DRAFT ILLUSTRATION OF THE DEMONSTRATOR’S FUNCTIONALITIES ................................................120

3 A3 BIBA/INDYON (EOL) – DEFINITION OF THE DEMONSTRATOR................................................123 3.1 A3 – THE DEMONSTRATOR........................................................................................................................123 3.2 A3 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ....................................................................................124 3.3 A3 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ................................124 3.4 A3 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .......................................................................125 3.5 A3 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ..............................................................127 3.6 A3 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR .............................................128 3.7 A3 – DRAFT ILLUSTRATION OF THE DEMONSTRATOR’S FUNCTIONALITIES ................................................130 3.8 A3 – ADDITIONAL INFORMATION RELATED TO THE BIBA/INDYON DEMONSTRATOR.............................131

4 A4 CRF (MOL) – DEFINITION OF THE DEMONSTRATOR .................................................................141 4.1 A4 – THE DEMONSTRATOR........................................................................................................................141 4.2 A4 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ....................................................................................141 4.3 A4 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ................................142 4.4 A4 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .......................................................................143 4.5 A4 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ..............................................................144 4.6 A4 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR .............................................145 4.7 A4 – DRAFT ILLUSTRATION OF THE DEMONSTRATOR’S FUNCTIONALITIES ................................................147

5 A5 CATERPILLAR (MOL) – DEFINITION OF THE DEMONSTRATOR.............................................151 5.1 A5 – THE DEMONSTRATOR........................................................................................................................151 5.2 A5 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ....................................................................................151 5.3 A5 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ................................152 5.4 A5 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .......................................................................153 5.5 A5 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ..............................................................154 5.6 A5 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR .............................................155 5.7 A5 – DRAFT ILLUSTRATION OF THE DEMONSTRATOR’S FUNCTIONALITIES ................................................156

6 A6 FIDIA (MOL) – DEFINITION OF THE DEMONSTRATOR ..............................................................159 6.1 A6 – THE DEMONSTRATOR........................................................................................................................159 6.2 A6 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ....................................................................................159 6.3 A6 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ................................160


@

6.4 A6 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .......................................................................161 6.5 A6 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ..............................................................164 6.6 A6 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR .............................................165 6.7 A6 – DRAFT ILLUSTRATION OF THE DEMONSTRATOR’S FUNCTIONALITIES ................................................166 6.8 A6 – ADDITIONAL INFORMATION RELATED TO THE BUSINESS, HARDWARE, SOFTWARE AND NETWORK ARCHITECTURE OF THE FIDIA DEMONSTRATOR ......................................................................................................167

7 A7 MTS (MOL) – DEFINITION OF THE DEMONSTRATOR.................................................................173 7.1 A7 – THE DEMONSTRATOR........................................................................................................................173 7.2 A7 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ....................................................................................173 7.3 A7 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ................................175 7.4 A7 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .......................................................................176 7.5 A7 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ..............................................................180 7.6 A7 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR .............................................182 7.7 A7 – DRAFT ILLUSTRATION OF THE DEMONSTRATOR’S FUNCTIONALITIES ................................................183

8 A8 WRAP (MOL) – DEFINITION OF THE DEMONSTRATOR .............................................................187 8.1 A8 – THE DEMONSTRATOR........................................................................................................................187 8.2 A8 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ....................................................................................187 8.3 A8 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ................................187 8.4 A8 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .......................................................................188 8.5 A8 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ..............................................................188 8.6 A8 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR .............................................189 8.7 A8 – DRAFT ILLUSTRATION OF THE DEMONSTRATOR’S FUNCTIONALITIES ................................................190

9 A9 INTRACOM (MOL) – DEFINITION OF THE DEMONSTRATOR...................................................193 9.1 A9 – THE DEMONSTRATOR........................................................................................................................193 9.2 A9 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ....................................................................................193 9.3 A9 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ................................194 9.4 A9 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .......................................................................195 9.5 A9 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ..............................................................196 9.6 A9 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR .............................................198 9.7 A9 – DRAFT ILLUSTRATION OF THE DEMONSTRATOR’S FUNCTIONALITIES ................................................200

10 A10 BOMBARDIER TRANSPORTATION (BOL) – DEFINITION OF THE DEMONSTRATOR ......203 10.1 A10 - ABBREVIATIONS USED IN THE A10 DEMONSTRATOR .......................................................................203 10.2 A10 – THE DEMONSTRATOR......................................................................................................................203 10.3 A10 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ..................................................................................204 10.4 A10 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ..............................204 10.5 A10 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .....................................................................205 10.6 A10 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ............................................................216 10.7 A10 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR ...........................................219 10.8 A10 – DRAFT ILLUSTRATION OF THE DEMONSTRATOR’S FUNCTIONALITIES ..............................................223 10.9 A10 – ADDITIONAL INFORMATION AND ILLUSTRATIONS RELATED TO THE BT-LOC DEMONSTRATOR......225

11 A11 POLIMI (BOL) – DEFINITION OF THE DEMONSTRATOR..........................................................229 11.1 A11 – THE DEMONSTRATOR......................................................................................................................229 11.2 A11 – OBJECTIVES (OBS) OF THE DEMONSTRATOR ..................................................................................229 11.3 A11 – INVOLVED ACTORS (ACS) IN THE WHOLE LIFECYCLE OF THE DEMONSTRATOR ..............................230 11.4 A11 – THE DEMONSTRATOR PHYSICAL COMPONENTS (PCS) .....................................................................231 11.5 A11 – THE DEMONSTRATOR SOFTWARE/SUPPORT-SYSTEMS (SSS) ............................................................232 11.6 A11 – DESCRIPTION OF THE FUNCTIONALITY (FUS) OF THE DEMONSTRATOR ...........................................234 11.7 A11 – DRAFT ILLUSTRATION OF THE DEMONSTRATOR’S FUNCTIONALITIES ..............................................235


@

DELIVERABLE NO Relates to DR3.2: PROMISE Demonstrator WP A1

DATE 09. May 2005


VERSION NO. 1.2

ELECTRONIC FILE CODE dr3_2 appendix a demonstrators~2.doc


ABSTRACT: This is the final version of the document and will form the basis for the deliverable DR3.2.



SUBMITTED (author(s)) Mario Gambera 09.05.2005

VU (WP Leader) CRF

APPROVED (QIM) To be approved in deliverable DR 3.2

Written by: Mario Gambera, CRF

PROMISE Demonstrator A1 CRF (EOL)


@

Revision History

Date (dd.mm.yyyy)


01.04.2005 0.1 Carl Christian Røstad This is the first draft version of the document. This document will be the basis for the discussions in the meeting in Munich 11.-12. April

11.04.2005 0.2 Carl Christian Røstad

Updated structure based on input from the Munich meeting on the 11.-12. April 2004. The version was sent SAP, EPFL, BIBA, STOCKWAY and INFENEON for comments before distribution.

20.04.05 1.0 Mario Gambera First draft covering all parts of the documents

05.05.2005 1.1 Carl Christian Røstad Updated structure of the document

09.05.2005 1.2 Mario Gambera Updated functionalities table

Author(s)’ contact information Name Organisation E-mail Tel Fax Mario Gambera CRF [email protected] 011-9083047


@

1 A1 CRF (EOL) – Definition of the demonstrator

1.1 A1 – The Demonstrator Demonstrator Describe functionality Describe why this Demonstrator is focused in

PROMISE Passenger Car Transport people Lifecycle of a Passenger Car is quite long. Closing

the information loop of a Product with a long life is of paramount importance. Residual value of the product at EOL is still high, both in reusability potential and in terms of environmental impact.

Table 1: The A1 PROMISE demonstrator

• This document was written using one generic Component as example. • The Component used in the demonstrator must still be identified • There will most likely be more than one component

1.2 A1 – Objectives (OBs) of the Demonstrator ID Objective (one per ID) Describe why O1 Identify what components worth re-use when

deregistering the vehicle Increase the percentage of reused component and increase the viability of the initiative (also introducing automation procedures) is one of the key driver for reducing OEM Deregistering costs

O1.1 Tracking relevant components info from B.o.M. / Production phase

Some information about component origin (composition, production date, design nr, etc) are necessary for the decision that will be taken at the moment of deregistration.

O1.2 Tracking relevant component info about its usage / mission

The wear-out level of a component can differ considerably depending on the mission experienced by the component itself. It is therefore necessary to define some effective “summary”, capable to synthesise mission profile. Once a suitable summary has been chosen, it is necessary to continuously update it during usage.

O1.3 Updating / resetting info about component mission in case of component substitution

If a component is replaced, summary about mission profile must be reset.

O1.4 Identify economical information about component re-use

Another fundamental aspect to be taken into account is the commercial viability of the component. This evaluation depends also on potential II hand market sale price, market acceptability capacity and so on.

O1.5 Decide whether re-use a component or not, using all the info above

See O1. This goal is achieved by using” all the information collected from O1.1 to O1.4

O2 Transfer on the component “some” relevant info about its post –deregistering life

The availability of a Tag on the component can be used to record relevant info about the treatment after separation from the vehicle. Depending on the decision taken in O1.5 it is necessary to record what reworking is necessary (if any), other info about wear out level and so on.

Table 2: Objectives (OBs) of the A1 PROMISE demonstrator


@

1.3 A1 – Involved actors (ACs) in the whole lifecycle of the Demonstrator ID Actor External

/ Internal

Describe how they will be involved, their role and impact of the PROMISE technology

Importance / Relevance High, Medium, Low

BOL

MOL

EOL

AC1 The users E The innovation doesn’t affect the user L X AC2 The Design

dept I Design and management of info about

component on the backend system M X

AC3 Authorised Garage

I/E Minimum change in the mol maintenance. Wireless comm. System automatically update on-board computer when a component is replaced.

M X


I/E Use DSS. Starts the deregistration process. Collects dynamic info from the car. With the help of the DSS integrates all the static and dynamic info and decide what to reuse. Writes some info on Tag component before detachment.

H X

AC5 Authorised dismantlers

E Same for Authorised Garage H X

AC6 After Sales Department

I Manages Cost model, Magages policy for II hand parts, manages backend systems

H X X X

AC7 Re- manufacturer

I/E Reworking operation of the II hand component. He rely on more information than on the As- is process

M X

Table 3: Involved lifecycle actors (ACs) of the A1 PROMISE demonstrator


@

1.4 A1 – The demonstrator physical components (PCs) ID Physical

component Describe its functionality Describe the necessary

interfaces of this physical component to other PC IDs, SS IDs etc

Is this physical component already available at your company today or not? Please describe how and in what form it is available, or what is needed in order to get it available

What is the relation to Demonstrator objectives

Relate this to all relevant functionalities (FU IDs)

PC1 TAG on relevant Component X

Uniquely identify component X, record some info about component X history.

Wireless communication with SS1. Physical, solid and stable link with component X

No. Easily available on the market. Promise Partner will provide the best solution.

Essential FU1, FU2, FU3, FU11, FU12, FU13

PC2 Normal Production Sensor of X measurement (for ex. temperature)

Continuously measure some vehicle parameter (for ex. Outside temperature)

Link with PC4 Yes Can be simulated with data organised in time series

FU7

PC3 Component X Depending on X Supports TAG Yes It is the “subject” of the evaluation

PC4 ECU Manages in real – time vehicle electronics.

Wireless link with PC1, link with PC2, hosts SS1, link with SS2

Yes The on board diary SS1 will probably be hosted by ECU

Table 4: Physical components (PCs) of the A1 PROMISE demonstrator


@

1.5 A1 – The demonstrator software/support-systems (SSs) ID Software /

support system Describe its functionality Describe the necessary

interfaces of this software/support system to other PC IDs, SS IDs etc

Is this software / support system already available at your company today or not? Please describe how and in what form it is available, or what is needed in order to get it available

What is the relation to the Demonstrator objectives


SS1 On board Diary Store summary about component mission. Perform some basic calculation from sensor measurements. Update component specific summaries. Reset Component specific summaries. Communicate with PC1 (r/w), PC2 (r), SS2.

Communication with PC1 when a Component is mounted or replaced, with PC2 continuously, with SS2 during the deregistration phase.

No. According to actual knowledge, on-board computer could be hosted on Vehicle ECU. SW is all to be developed

Essential FU4, FU5, FU6, FU8, FU9, FU10, FU20

SS2 Back-end DSS Download info from On-Board diary, get component age and mileage from On – board computer, get info from other back end systems SS3 and SS$, take decision about what reuse

No FU14 FU15 FU16 FU17 FU18 FU19

SS3 OEM Back end IMDS

Manages info about component. Allow the identification of component characteristics from its ID number on TAG, etc.

Yes / No

SS4 Component cost model

Manages economic info about Component. No

Table 5: Software / support systems (SSs) of the A1 PROMISE demonstrator


@

1.6 A1 – Description of the functionality (FUs) of the demonstrator ID Functionality Comments to

functionality Define the inputs needed to achieve this functionality and relate the input to other FU IDs (e.g. output data from FU3)

Define the outputs from this functionality

What are the controls? ID the controls by using C1, C2 etc

Technologies/Physical components/Systems/Actors involved Describe the technologies involved, or assumed technology/systems needed

Rationale Describe why this functionality is needed

Priority High, Medium, Low

Related to objective ID (Sec 1.2)

FU1 Update Component mission profiles

clock = 1 second Sensor values Map / statistics sinthetising component mission profile, Component mileage

During vehicle use (engine on)

PC2, SS1 Accurate knowledge of the component mission profile is essential for assessing the "worth for reusability"

High OB1.2

FU2 Reset Component mission profile, update age of component

This operation should be fully automatic

Component Id Date / time

Component mission profile (resetted to 0), updated age of the component (substitution date)

When component is replaced OR with a new vehicle

PC1, PC3, SS1 When a component is replaced his history must be resetted

High OB1.3

FU3 Transfer Ident. Nr, substitution date from TAG to DSS

On-board computer could be used to do this transfer

Component Id age of the component (substitution date)

Component Id age of the component (substitution date) on DSS

At the deregistration phase

PC1, SS1, SS2 High OB1.5

FU4 Transfer Comp. Mission profile and mileage from on board computer to DSS

Component mission profile, Component mileage

Component mission profile, Component mileage on DSS


SS1, SS2 High OB1.5

FU5 Get off-line info from OEM back-end system and decide

Component ID, mission profile, mileage and age on DSS

Reuse component (yes / no) Residual quality level, list of reworking operations


SS1, SS3, SS4 High OB1.5

FU18 Transfer Info from DSS to Component TAG


Reuse component (yes / no) Residual quality level, list of reworking operations ON TAG


PC1, SS1, SS2 Medium OB2

FU21 Transfer Info from DSS to OEM back end system


Info on SS3 At the deregistration phase

SS2, SS3 Low

Table 6: Functionalities (FUs) of the A1 Demonstrator


@

1.7 A1 – Draft illustration of demonstrator’s functionalities

Component missionprofile on DSS

FU1

Update Component mission profilesSensor

values

Map / statistics sinthetising component

mission profile, Component mileage

During vehicle use (engine on)

PC2 Sensor SS1 On board Diary

FU2

Reset Component mission profile, update age of

component

Component Id

Date / time

Component mission profile (resetted to 0),

updated age of the component (substitution

date)

When component is replaced OR with a new

vehicle

PC1 TAG on relevant

Component X

PC3 Comp-onent X

SS1 Onboard Diary

FU3

Transfer Ident. Nr, substitution date from

TAG to DSS

Component Id

Age of the component (substitution

date)

Component Idon DSS

Age of the component (substitution date) on DSS

At the de-registration

phase

SS1 Onboard Diary

PC1 TAG on relevant

Component X

SS2 Back-end DSS

FU4

Transfer Comp. Mission profile and mileage from

on board computer to DSS

Component mission profile

Component mileage


SS1 Onboard Diary

SS2 Back-end DSS

FU5

Get off-line info from OEM back-end system and

decide

Component mileageon DSS

Reuse component (yes / no), List of

reworking operations, and Residual quality

level


phase

SS1 Onboard Diary

SS4 Component cost model

SS3 OEM Back end

IMDS

FU18

Transfer Info from DSS to Component TAG

Reuse component (yes / no)

Residual quality level, list of reworking

operationsON TAG


phase

SS1 Onboard Diary

PC1 TAG on relevant

Component X

SS2 Back-end DSS

FU21

Transfer Info from DSS to OEM back end system Info on SS3 OEM Back

end IMDS


phase

SS2 Back-end DSS

SS3 OEM Back end

IMDS


@

DELIVERABLE NO Relates to DR3.2: PROMISE Demonstrator A2

DATE 05. May 2005


VERSION NO. 1.0






SUBMITTED (author(s)) Tonya A.T. Garrett 28.04.2005

VU (WP Leader) CATERPILLAR


Written by: Howard W. Ludewig Caterpillar Inc. Updated by: Tonya A.T. Garrett Caterpillar Inc

PROMISE Demonstrator A2 Caterpillar (EOL)


@

Revision History

Date (dd.mm.yyyy)





08.04.2005 0.2 Howard W. Ludewig Draft write up

26.04.2005 0.3 Tonya A.T. Garrett Updated

28.04.2005 0.4 Tonya A.T. Garrett Split into 2 documents: MOL & EOL

05.05.2005 1.0 Carl Christian Røstad Updated structure of the document and added draft illustration of functionalities

Author(s)’ contact information Name Organisation E-mail Tel Fax Howard Ludewig Caterpillar Inc. [email protected] 3095784469 Tonya Garrett Caterpillar Inc [email protected] 3095786734 3095786734 Keith Herman Caterpillar [email protected] +3271259662 +3271252531 Jean Jacques Janosch Caterpillar [email protected]


@

2 A2 CATERPILLAR (EOL) – Definition of the demonstrator


PROMISE Engine of Track Type Tractor (TTT

The demonstrator aggregates all kind of field data, product specific information, and additional information and transforms it – supported by decision support system – into knowledge that can be used to take productive and effective actions. The data must be accessible by the supply chain in a PDKM system.

This demonstrator covers the closure of information loop between product operation (MOL) and product recycle, reuse, remanufacture or disposal (EOL). However, to effectively impact these focus areas the demonstrator will also have to close the loop with manufacturing and design (BOL).

Table 7: The PROMISE EOL demonstrator

2.2 A2 – Objectives (OBs) of the Demonstrator ID Objective (one per ID) Describe why OB1 Primary objective:

Prove the closure of information loop between knowledge required to manage the field population as well as make the appropriate EOL decisions.

This demonstrator covers the closure of information loop knowledge-based actions at the end of life (EOL).

OB2 Demonstrator shall aggregate available engineering data, field data, and ancillary information.

All required information and data will be used to manage the field population as well as making decisions and selecting procedures for product recycle, reuse, remanufacture or disposal (EOL).

OB3 Use product embedded devices such as RFID to track components and automatically maintain related data linkages such that it can be transformed into the required knowledge.

This provides a decision making process for EOL that is based on knowledge of the entire field population.



@

2.3 A2 – Involved actors (ACs) in the whole lifecycle of the Demonstrator ID Actor External /

Internal Describe how they will be involved, their role and impact of the PROMISE technology


BOL MOL EOL

AC1 Product Design Internal Optimize designs and support Dfx

H X

AC2 Manufacturing Internal Optimize manufacturing processes and forecasting build

M

AC3 Logistics Internal/External Forecasting and tracking H AC4 Remanufacturing Internal Decision making and process

optimization H X



@







OS1 Engine of TTT product

Vehicle motion and power RFID will be attached on the on the engine.This RFID will provide information of the component during PLM Information from the RFID could be tracked and updated during each maintenance period or other major envent (renting, selling products,…) . Data could be store periodically by using RFID reader. Critical PLM information could provide user of major information on failure mode and maintenance reporting (repair, replace component) for EOL actions

The engine already exists on CAT TTL. No sensor is providing feedback information during PLM for EOL RFID has to be hire and need to be placed on the engine and data transfer system, data management system should be develop for PLM EOL application. Data reader system should be physically implement at dealers for data transfer and updated

Develop component data information PLM fro EOL acion, reduce risk of productt failure, increase user safety working conditions,

FU 1 Data storage FU 2 Data reader, FU 3Data udtae FU 4 EOL actions



@







SS1 Data storage on RFID (ID, manufactured location,….

store manufacturing, logistics data

software reader (wireless system)

Software is not available. It should be hire to be used Capture data from engine during PLM for EOL action

FU1

SS2 Data management ssytem

Update data on on RFID for any major issue occur on engine during PLM

Update information on RFID by using software and RFID reader

Software will be used to store information on RFID for SS3 Software is not available. It should be developed to be used

Update component data information during PLM for EOL product

FU2

SS3 Data management system

Transform information into decision for EOL

Provide BOL and PLM major event for EOL decision (reuse, reman, recycle

Software should transform information into action for EOL treatment Software is not available. It should be developped

Transform information into knowledge for EOL product

FU3



@

2.6 A2 – Description of the functionality (FUs) of the demonstrator

ID Functionality Comments to the functionalities Define the inputs needed to achieve this functionality and relate the input to other FU IDs (e.g. output data from FU3)







FU1 Initial data storage and reading system from RFID

Flexible and user configurable Intuitive user interface that is automated where possible.

RFID information (ID, Manufac location, logistic) from component

Data storage from major events during PLM (failure, replacement,service condition, hours…)

Engine of TTT product, RFID, data transfer information system into reader Antenna, controller connected to the PDKM interface hardware

This function provides the data needed for EOL remanufacturing Reliable in harsh environments

H OB3

FU2 PDKM functionality for the logistics management system for EOL remanufacturing


Information output from F1 Define decision for logistic management system for EOL remanufacturing

Software and data wireless transfer system from RFID to dealers

This function provides for a logistic system that can forecast need based on field population and remanufacturing

H OB2, OB3

FU3 PDKM functionality for field application data collection and remanufacturing system


Information output from F1, F2 Define decision for remanufacturing and for design corrective actions (BOL)

Intelligent system to make deterministic decisions relative to reuse, recycle, remanufacture, or dispose including:

• Materials • Recyclables • Functional

specifications • Sourcing • Cost

Processes & Procedures

System the is capable of reading the RFID information and then making the required connections to the information in the PDKM system Provides the linkage between BOL, MOL, and EOL for intelligent management of the EOL functions

H OB1, OB2



@

2.7 A2 – Draft illustration of the demonstrator’s functionalities

FU1 (A2)

Initial data storage and reading system from

RFID

RFID information (ID, Manufac location, logistic)

from component

Engine of TTT product, RFID, data transfer information system into reader

Antenna, controller connected to the PDKM interface

hardware

FU2 (A2)

PDKM functionality for the logistics management

system for EOL remanufacturing

Software and data wireless transfer

system from RFID to dealers

FU3 (A2)

PDKM functionality for field application data

collection and remanufacturing system

Data storage from majorevents during PLM (failure,

replacement,service condition, hours…)

Data storage from majorevents during PLM (failure,

replacement,service condition, hours…)

Define decision for remanufacturing and for design corrective actions

(BOL)

Define decision for logistic management

system for EOL remanufacturing

Processes & Procedures

Intelligent system to make deterministic decisions relative

to reuse, recycle, remanufacture, or dispose

including:Materials, Recyclables,

Functional specifications, Sourcing, Cost


@


DATE 05. May 2005


VERSION NO. 1.0






SUBMITTED (author(s)) Andreas Plettner 28.04.2005

VU (WP Leader) INDYON


Written by: Dr. Andreas Plettner, INDYON Martin Schnatmeyer, BIBA

PROMISE Demonstrator A3 BIBA / INDYON (EOL)


@

Revision History

Date (dd.mm.yyyy)





27/04/2005 0.3 Martin Schnatmeyer Updated structure based on input from the Munich meeting on the 11.-12. April 2004

28/04/2005 0.4 Andreas Plettner Updated structure based on input from the Munich meeting on the 11.-12. April 2004

05/05/2005 0.5 Martin Schnatmeyer Update A3 Functionalities


Author(s)’ contact information Name Organisation E-mail Tel Fax Dr. Andreas Plettner INDYON [email protected] +49 89 54759128 Martin Schnatmeyer BIBA [email protected] +49 421 218

5532 +49 421 218 5610


@

3 A3 BIBA/INDYON (EOL) – Definition of the demonstrator


PROMISE EOL information management for tracking and tracing of products for recycling

Material flow Figure 3 (see section 5) describes the application field for the RFID technology in the life cycle of car bumpers with an attached or embedded tag (or PEID) from the producer side: After use and dismantling the single bumper or bumper fraction goes to the collection point (e.g. an open container) by passing a reader gate. This reader gets all data from the single bumper tag. The milling starts when a sufficient amount of bumpers is available. Before milling, a manual or automated sorting system sorts the bumpers for recycling from the container fractions. After milling and filling the material goes via a truck to another recycling facility. There the material is put into a warehouse. On customer demand this facility produces new plastic granulate, which is basis for new plastic products. Information flow The external information flow in the recycling industry is normally text based via paper documents, fax and e-mails in combination with verbal agreements. The text based information is combined with additional information. Agreements will be not recorded. The internal information is also text based but instead of using fax and e-mail the information handling is supported by an internal ERP system, WMS (Warehouse Management System) or PPS (Production Planning and Control System). There is no data collection in place regarding PLM relevant data.

The objective of this demonstrator is to develop an application which supports the tracking and tracing of products estimated for recycling by using the PROMISE PEID technology and PDKM system in combination with the using of indoor and outdoor navigation systems. The application scenario including specifications for the required equipment, the sensors, the smart tags, the receivers i.e. all the communication infrastructure will be provided by INDYON and BIBA by taking into account results of a national funded research project (OPAK).



@

3.2 A3 – Objectives (OBs) of the Demonstrator ID Objective (one per ID) Describe why OB1 Develop an application which increases the

recycling rate. Less waste, legislative pressure, financial aspects, independency from raw materials.

OB2 Tracking and tracing of relevant product data together with the materials during all recycling processes and supply of these data for recycling process.

During the processes where the materials are being milled, etc. it is important to keep the right data to the materials, even when there is a mixture of different batches. The parameters of the recycling processes depend on these data.

OB3 Tracking and tracing of relevant product data together with the materials during all recycling processes and supply of these data for product design.

During the processes where the materials are being milled, etc. it is important to keep the right data to the materials, even when there is a mixture of different batches. The design of new products depends on these data.

OB4 Support of decision making systems with relevant data.

Control systems adapted to the processes depending on the incoming data from the materials.





BOL MOL EOL

AC1 Customer selling used parts

External Supplier of relevant product data H X X

AC2 Logistic operator

Internal Moving of the materials; Data exchange for process support.

H X X

AC3 Machinery workers recycler

Internal Production of high quality recycling products

H X

AC4 Customer which uses recycled plastics

External He gets precise data about his product H X

AC5 Automotive design department

External Feedback from recycled product quality and data

H X



@







PC1 RFID tag 868 MHz (optional, only if PC9 is not in use)

ID #/pallet # PC3 Yes RFID tagged to the packing material for item identification

FU1 / FU2

PC2 RFID transponder 125 kHz

Storage of geographic position

PC4 Planned for OPAK RFID embedded into the warehouse floor for position identification

FU1 / FU2

PC3 UHF RFID reader system

Reading of PC1 PC1, PC6, PC7, PC8, SS4 Yes See PC1 FU1 / FU2

PC4 125 kHz RFID reader system

Reading of PC2 PC2, (PC5), PC6, PC7, PC8, SS4, SS5

Planned for OPAK See PC2 FU1 / FU2

PC5 Ultrasonic sensor (optional, not necessary if PC3 is in use)

storing position identification (x-, y-position)

PC4 Planned for OPAK See PC2 FU1 / FU2

PC6 Ultrasonic sensor Storage level identification (z-position)

PC4 Planned for OPAK See PC2 FU1 / FU2

PC7 Fork lift Mobile reader system PC3, PC4 Yes See PC1 and PC2 FU1 / FU2 PC8 Fork lift terminal Worker order support PC3, PC4 Planned for OPAK See PC1 and PC2 FU1 / FU2 PC9 RFID 868

MHz/13,56 MHz (PEID) tagged to packing material (octabin or bags) with recycled material (PP of PA granulate)

For testing PC3 No Demonstration of tracking and tracing of material coming from EOL plastic material

FU1 / FU2


@

ID Physical component

Describe its functionality Describe the necessary interfaces of this physical component to other PC IDs, SS IDs etc




PC10 RFID 868 MHz/13,56 MHz (PEID) tagged to EOL plastic part (e. g. ELV bumper)

RFID carrying use data, parts ID

SS4, SS5 No Demonstration of tracking and tracing of EOL plastic material going to recycling

FU3

PC11 Truck loading platform

For testing SS4, SS5 Planned for OPAK See PC1 and PC2 FU1 / FU2

PC12 Warehouse storing rack

For testing SS4, SS5 Yes See PC1 and PC2 FU1 / FU2

PC13 Packing material For testing PC1, SS4, SS5 Yes See PC1 and PC2 FU1 / FU2 PC14 Car bumper For testing PC10, SS4, SS5 No See PC10 FU3



@







SS1 Production machines

Recycling processes like milling, granulating, mixing, cutting

SS4, SS5, PC3, PC4 No User of product data. FU1 / FU2, FU3

SS2 Logistic systems Transport of the materials SS4, SS5, PC3, PC4 Yes Continuous data flow, just in time processes

FU1 / FU2, FU3

SS3 Control systems Weight, temperature SS4, SS5, PC3, PC4 No Support of decision support systems

FU1 / FU2

SS4 Warehouse management system

Software support for warehouse management

PC3, PC4, PC11, PC12 Planned for OPAK Warehouse management support system

FU1 / FU2, FU3

SS5 Indoor / outdoor navigation system

For testing PC4, PC11, PC12 Planned for OPAK See PC1 and PC2 FU1 / FU2, FU3



@









FU1 Data transfer from RFID transponder tagged to the bumper to packing material after cutting and milling

Access to the PROMISE PDKM system

Data from RFID transponder embedded into the bumper (PEID)

Data from RFID transponder after milling Communication in a radio field between RFID reader and tags.

Technologies / Systems Bumper PEID RFID reader PDKM

Actors ELV Recycler

administration ELV Recycler worker Truck driver

See OB2, OB3, OB4 H H H

OB2 OB3 OB4

FU2 Data transfer from RFID transponder tagged to the packing material to on-board computer fork lift

The data transfer must be in real time by having an W-LAN access from the fork lift to the PROMISE PDKM system

Packing material ID (output data from FU1) combined with position a.

Packing material ID combined with position b.

Communication in a radio field between RFID reader and tags.

Technologies / Systems 868 MHz Tags and

Reader System 125 kHz Transponder

and Reader System Fork lift Lab Storage system

demonstrator W-LAN access points Server Fork lift terminal Warehouse

management system Fork lift software

Actors Truck driver Warehouse worker Worker from quality

assurance / control Worker from production

See OB2 H M M

OB2 OB3 OB4


@








FU3 Transport of packing material

The data transfer must be in real time by having an W-LAN access from the fork lift to the PROMISE PDKM system (for the navigation of the fork lift).

Data transfer of ID number from RFID transponder embedded in the warehouse floor

Transported packing material Communication in a radio field between RFID reader and tags.

Technologies / Systems 125 kHz Transponder

and Reader System Fork lift Lab W-LAN access points Server Fork lift terminal Warehouse


Actors Warehouse worker

See OB2 H M

OB2 OB4

FU4 Storing of packing material

The data transfer must be in real time by having an W-LAN access from the fork lift to the PROMISE PDKM system (for the navigation of the fork lift).

Data transfer of ID number from RFID transponder embedded in the warehouse floor

Stored packing material Communication in a radio field between RFID reader and tags.

Technologies / Systems 868 MHz Tags and

Reader System 125 kHz Transponder

and Reader System Fork lift Lab Storage system

demonstrator W-LAN access points Server Fork lift terminal Warehouse


Actors Truck driver Warehouse worker Worker from quality

assurance / control Worker from production

See OB2 H M

OB2 OB4



@


FU2 (A3)

Data transfer from RFID transponder tagged to the

packing material to on-board computer fork lift

FU1 (A3)

Data transfer from RFID transponder tagged to the

bumper to packing material after cutting and

milling

Packing material ID combined with position a. Packing material ID combined with position b.Data from RFID

transponder embedded into the bumper (PEID)

Data from RFID transponder after milling

"868 MHZ Tags and Reader System"125 kHz Transponder and Reader System"Fork lift"Lab"Storage system demonstrator"W-LAN access points"Server"Fork lift terminal"Warehouse management system"Fork lift software

"Truck driver"Warehouse worker"Worker from quality assurance / control"Worker from production

Communication in a radio field

between RFID reader and tags.



"Bumper"PEID"RFID reader"PDKM

"ELV Recycler administration"ELV Recycler worker"Truck driver

FU3 (A3)

Tranpor of packing material

"125 kHz Transponder andReader System"Fork lift"Lab"W-LAN access points"Server"Fork lift terminal"Warehouse management system"Fork lift software

Warehouse workers



FU4 (A3)

Storing of packing material

"125 kHz Transponder andReader System"Fork lift"Lab"W-LAN access points"Server"Fork lift terminal"Warehouse management system"Fork lift software

Communication in a radio field between RFID

reader and tags.

Stored packing material

"Truck driver"Warehouse worker"Worker from quality assurance / control"Worker from production

Data transfer of ID number from RFID

transponder embedded in the warehouse floor

Transported packing material


@

3.8 A3 – Additional information related to the BIBA/INDYON Demonstrator In this section, the demonstrators added other relevant information related to the Demonstrator not already covered. Each Demonstrator was free to form this section as needed and this section can e.g. serve as a reminder for the WP Ax (and other WPs) when these start. Recycling of Car Bumpers with RFID Technology as an Example for A3 For a better understanding of the opportunities of the RFID technology in the product life cycle management, this chapter describes a possible recycling scenario for car bumpers. Figure 1 describes possible application fields for the RFID technology in the life cycle of car bumpers with an attached or embedded tag from the producer side: After use and dismantling the single bumper or bumper fraction goes to the collection point (e. g. an open container) by passing a reader gate. This reader gate reads all data from the single bumper tag and writes data on the tag (see Table 19).

CollectingSorting

MillingFilling

Loading



Data transfer:Type of MaterialConsistence of MaterialFilling MaterialsAdditivesColourDay of FillingWeightPacking MaterialQualityPlaceTruckPersonal dataPlace of Storage (in)Day of StoragePlace of Storage (out)Quality status





Waste

Production / use



Information Break

Information Break

Information Break

Figure 1: Use of RFID technology in the life cycle of bumpers The milling starts after a sufficient amount of bumpers is available. Before the milling, a manual or automated sorting system sorts the bumpers for recycling from the container fractions. After milling and filling the material goes via a truck to another recycling facility. There the material goes into a storage


@

system. On customer demand this facility produces new plastic granulate, which is basis for new plastic products. The different process steps have different requirements of data exchange. Table 19 describes examples for an information exchange between the transponder and the collecting / sorting production, transport, loading and storing systems. The transponder technology enables in this example the data acquisition of the collected material types and -mix at the collecting point, i. e. at the place of waste collecting, in temporary storage facilities systems or in storage systems of external logistic services. Advantages are the ubiquitous availability of data about the material during the whole recycling process. Breaks in the information chain (cf. Figure 1) are buffered via the transponder chips. The fast information exchange by passing reading systems is more efficient than the manual scanning of barcodes. As an additional functionally it is possible to control the temperature of the packed material (granulated plastic is self inflammable).

Process step Data exchange (examples)

Collecting / Sorting

Bumper transponder to production system: Additives, brand, colour, consistence of material, bumper identification number (external), type of material, weight Recycler production system to bumper transponder: Day of storage, personal data, place of storage (in), bumper identification number (internal), quality

Production Production system to packing transponder: Additives, consistence of material, day of filling, personal data, place of filling, packing unit identification number, status, type of material, weight, machine number Packing transponder to production system: Packing identification number, temperature

Transport Packing transponder to truck: Packing unit identification number, material, place of storage on truck, weight, temperature Truck to packing transponder Personal data, truck number plate

Loading Packing transponder to fork lift: Packing unit identification number, material, place of storage on truck, weight Fork lift to packing transponder: Day and time of loading, fork lift identification number, personal data

Storing Packing transponder to storage system: All collected data on the transponder (e. g. additives, consistence of material, material, packing material, personal data, packing unit identification number, temperature, weight) Storage system to packing transponder: Storage place, date and time, quality status

Table 19: Date exchange during the recycling process of bumpers (examples)


@

Real Time Decision Support The ubiquitous availability of information accompanying the material flow can be further used in order to realise innovative decision support tools, which can be adopted for various issues within enterprise networks and the process chains in the field waste and recycling management. Tools on top of data acquisition solutions as mentioned above can conduct further processing of the data coming along with individual entities (like bumpers) or batches. During this process data becomes information, which can be used to make better decisions on the operational, tactical and even strategic level. Examples for potential improvements on each of these levels are as follows: Operational level

• Reaction on interference during the collection process (e. g. due to road construction) of waste or recycling material

• Reaction on unavailability of vendor parts or material in production and recycling • Allocation for required resources for inbound and outbound flow of material / products for

warehousing (loading unloading, packing, unpacking etc.) • Control and better utilisation of transportation networks, as well as production and warehousing

resources because of better information and forecasts based on real time data Tactical level

• Clustering of areas, route planning for collection of recycling material or waste considering seasonal variability

• Production or recycling planning based on reliable information and forecasts for demand and availability

• Specification and adaptation of suitable warehousing policies (e. g. for reordering or delivery) • Short-term adaptations of existing (recycling) networks as a result of a breakdown of a partner (e.g.

selection of a new supplier) Strategic level

• Composition and decomposition and of recycling networks (design and global optimisation) • Long-term decisions as the location of new facilities for production, warehousing etc. • Assessment of new technologies systems for collection, production, transport, warehousing,

loading, unloading etc. Thus real-time information concerning the various decision problems along the composition, operation and decomposition recycling networks or process chains offers huge optimisation potentials. In addition real-time information allows better forecasts and estimations regarding uncertainties and variability, which are inherent everywhere in production or recycling. In combination with tools following a holistic approach decisions and solutions can be developed which fulfils all requirements regarding efficiency, robustness and sustainability at the same time. Today there are quite a number of approaches available in order to support the planning, control and optimisation problems related to the operation of production or recycling networks. The range covers pure mathematical methods (systems of equations), methods from Operations Research (mathematical programming), Soft Computing (evolutionary algorithms, neural networks, fuzzy methods), System Dynamics, Benchmarking or Simulation. While thinking about suitable approach for the realisation of a decision support system all of these approaches come along with specific disadvantages. Most of them are caused by the complexity of the underlying system. In this context it is questionable whether mathematical models, Operations Research or system dynamics can build adequate representations of reality. Although Soft Computing can solve even NP (Non-deterministic Polynomial-time) -hard problems and therefore


@

fulfils the requirements regarding complexity it must be considered as a black box as the way to come to the solution, which was delivered, cannot be comprehended by the user. Another approach, which is widely used in practice, is Benchmarking. But this method requires reference cases (which are not necessarily available) in order to allow estimations about the quality of a certain decision or system configuration. Furthermore all of the methods mentioned so far do not support a holistic view for the decision support as they are either focussed one certain aspects of networks or the underlying processes. In contrast to the other methods simulation (nearly) don’t have any limitations regarding the complexity and supports a holistic view on the system to be considered. In addition simulation allows the integration of variability and uncertainty, which are always inherent in existing production and recycling systems. Thus it appears as a good candidate for an innovative decision support system. Unfortunately there are also disadvantages coming along with simulation. First of all each simulation study requires a model of the reality which will be executed within the simulator in order to get insights into the dynamics of the model which allows to draw conclusions on the behaviour of the real system. Usually the modelling process requires significant effort in terms of time and money. Therefore the application of simulation for complex but short-term scenarios is difficult due to the time, which is required for model building.

Communication Infrastructure

Interface

Information BaseInteractive InformationRetrieval

SimulationOptimisationOptimisation

OptimisationOptimisation


Common

VisualisationVisualisation



Data AcquisitionData Acquisition

Figure 2: Architecture of a simulation-based decision support tool Another problem covers the development of optimal or at least good solutions for a given decision problem. Due to its characteristic an environment for the emulation of systems simulation cannot propose such solutions on it’s own. In fact they are developed by conducting various experiments with slightly different parameter sets in order get insights regarding the sensitivity of certain parameters concerning the overall model behaviour. Afterwards the model can be adapted considering this knowledge. However in order to find a good solution some expertise and experience in modelling and analysis of simulation data is required which domain experts as decision makers and thus the users of a decision support tool usually do not have. However the obstacles depicted so far can be overcome with the availability of real-time information whereas the modelling effort can significantly decrease by utilising the available information in an (semi-) automatic way. Such an integrated simulation environment can be further interconnected with an optimisation module (whereas the feasibility of such an approach was already realised within the EU-funded project ONE – Optimisation methods for Networked Enterprises (Project No. GRD1-2000-25710), which in turn can support domain experts in order to identify good system configurations and make the right decisions. Figure 2 shows the architecture of such a simulation-based decision support tool.


@

The tool comprises several functional components addressing the acquisition of data, which are delivered by external entities (e. g. transponders while passing reader gates). After data processing the resulting information is stored within a global information base. This component provides all of the information, which is required by the other components and can be interactively accessed by the component for information retrieval. Further modules are the integrated simulator, which allows the execution of models by integrating real time information delivered from the information base. The optimisation of specific models or scenarios is furthermore supported by the communication with optimisation components whereas as different versions can be integrated into the environment each of which addressing different objectives. Finally different components for animation and visualisation allow the representation of dynamic aspects related to the underlying system or functional modules as the simulator. All of these different components are integrated by using the same communication infrastructure which is accessed by a common interface whereas the approach depicted here follows the architecture proposed by the High Level Architecture (HLA) which was developed by the American Department of Defence for distributed simulation (Originally the idea for the HLA was derived based from the problem of reutilisation of existing simulation environment in order to save development time and costs). At the end such enhanced environments will support the decision maker in order to identify system configuration or concepts covering the whole life-cycle of products which are flexible, efficient, robust and sustainable at the same time by using an holistic approach while considering system inherent variability and uncertainties at the same time. Further application fields of the solution proposed here covers training and education of decision makers based on a “virtual reality” which can be provided by the tool. A3 Demonstrator Options Configuration According to figure 4 there are different configuration possibilities for the data processing: 1. The first one is based on the central data management, means that the whole PDKM system is

running via a central server system. Mobile units, like packing material, only need an identification number for tracking and tracing them in the supply chain (passive PEID).

2. The second possibility is also based on a central server concept but more autonomous based on decentralised data storage on the PEID (passive or active PEID with a higher storage capacity). Data (like in table 2) can be stored directly on the PEID, an access to a central server is not mandatory for each process step.

3. The third possibility is a PDKM system running directly on the PEID (active PEID). The controlling of such activities is still based on a central server.

4. The fourth possibility is a combination of the central and decentralised running PDKM system. Data processing Before, during and after changing the status of products or material (by filling, milling, mixing or extruding it) as well as changing the logistic position of the product, the information has to be processed (see figure 4). This is related to all types of data. In addition to table 2 these are e.g.:

• Temperature during processing, during storing or during transport (plastic granulate is self-inflammable),

• Quality data, • Material composition, • Logistic data like packing material, weight, orign, storage place, destiny or • Previous product life data


@

PPCollectingSorting

MillingFilling

Loading



Data transfer:

PROMISE PEID System

PROMISE PDKM System

Data transfer:

PROMISE PEID System

PROMISE PDKM System


Waste

Production / use



2

4

P

P

P

P

PP

P

P

P P P

P

P

PP

P

PP

P

P

P P

Figure 3: PROMISE EOL application scenario


@

A3 Demonstrator design Demonstrator infrastructure basis The demonstrator infrastructure is based on packing material for plastic scraps or granulates, labelled with RFID chips. The RFID technology enables the data acquisition of the collected material types and -mix at the collecting point, i.e. at the place of waste collecting, in temporary storage facilities systems or in storage systems of external logistic services. Parallel to this data acquisition, interfaces to a central material database assure an optimised production planning and controlling. Beside the RFID identification a RFID positioning system will be tested in combination (see figure 5).

W-LAN

Display

RFID-Antenna

Sensor

RFID-Antenna

RFID-Transponder Figure 4: PROMISE EOL application scenario

The forklift in this demonstrator will be used as a mobile material / product identification and positioning system. For identification one RFID antenna is placed above the fork. This will be used for reading the information from the packing material. The second RFID antenna is placed under the bottom of the fork lift. This antenna reads the geographic data coming from the RFID transponder embedded into the warehouse ground. Combined with a W-LAN access data collected from the packing material and the warehouse ground can be transmitted to a central WMS which traces the material movements and placement in the warehouse (or production plant) and provides the driver of the forklift with new transport orders after finishing her or his job. This semi automated system is optimised for this special recycling industry type. A high investment in full automated systems does make no sense for this industry type because the logistic process can not be standardised due to the mixed material fractions and material consistencies. Especially the specific customer situation (customer on the input and output side which has to be served, see section 2.1) causes all types of transport systems. Demonstrator enhancements The described demonstrator is only working in a closed environment depended on the installed infrastructure which is based on passive RFID tags. Additionally the back end system is working on a traditional basis. Based on this and like described in section 5 it’s planned to improve the system availability by using the PEID in combination with the PDKM system for closing the whole information and material loop.


@


@


DATE 05. May 2005


VERSION NO. 1.1






SUBMITTED (author(s)) Mario Gambera 20.04.2005

VU (WP Leader) CRF



PROMISE Demonstrator A4 CRF (MOL)


@

Revision History

Date (dd.mm.yyyy)





20.04.05 1.0 Mario Gambera First draft covering all parts of the document


Author(s)’ contact information Name Organisation E-mail Tel Fax Mario Gambera CRF [email protected] 011-9083047


@

4 A4 CRF (MOL) – Definition of the demonstrator


PROMISE Truck Transport goods Monitoring info during MOL will allow to improve

maintenance plan and to acquire info about vehicle mission profile


4.2 A4 – Objectives (OBs) of the Demonstrator

ID Objective (one per ID) Describe why OB1 Develop a predictive maintenance algorithms able to

predict engine oil wear out for the specific vehicle depending on ad-hoc mission profile indicators

Business point of view: Optimisation of maintenance policy will improve vehicle availability and safe of material. Research point of view: Oil Life Management Strategy is an active R&D filed where most important OEM are playing.

OB2 Collect prediction values as defined in OB1 on a ground station in order to remotely manage a fleet of vehicles

This is a first step for the fleet management. The results of the pred. Maint alg. Are transmitted to the ground station. Some first statistics about the fleet behaviour and component wear out are possible.

OB3 Collect ad-hoc mission profile indicator as defined in OB1 on a ground station in order to remotely monitor a fleet of vehicles, with the application of the predictive maintenance algorithms on the ground station

Monitor and analysis capabilities on the ground station will improve if it would be possible to send to the ground station mission profiles indicator used to define the predictive maintenance algorithm.

OB4 Collect ad-hoc mission profile indicator on a ground station in order to remotely monitor a fleet of vehicles, with the objective to have information about the mission profile of each vehicle belonging to the fleet Data elaboration should be able to:

give residual autonomy for each vehicle feedback about vehicle “correct” usage feedback about fleet mission profile feedback about typical component usage maintenance management (policy, day by day maintenance).

Optimal monitor and analysis capabilities on the ground station by using all the useful mission profiles indicators.

Table 21: Objectives (OBs) of the A4 PROMISE demonstrator Note: the objective from OB1 to OB4 are considered to be “incremental”. The starting point is OB1, i.e. the development of an algorithm of predictive maintenance applied on a single truck. The capability to send to a ground station some amount of information with a certain frequency will allow to cover objective from OB2 to OB4.


@


/ Internal

Describe how they will be involved, their role and impact of the PROMISE technology


BOL

MOL

EOL

AC1 The users E Get the message of “residual autonomy” from the on board computer or other message from the ground station

L X

AC2 The Design dept

I Gives specification for the Predictive maintenance algorithms Gives specification for the mission profile indicators Receives feedback about vehicle usage from the ground station

H X


I/E Possible use of Authorised garage for the download of mission profiles indicators

M X

AC5 After Sales Department

I Ideal Host of the “company wide “ground station. Maintenance management (policy, day by day maintenance). Send feedback to design department about vehicle mission profiles

H X

AC6 Fleet manager

E Possible host for a ground station for the management of owned fleet. Management of day by day maintenance Control of use of the vehicles

M X



@


component Describe its functionality Describe the necessary interfaces

of this physical component to other PC IDs, SS IDs etc

Is this physical component already available at your company today or not?


Relate this to all relevant functionalities

PC1 Sensors Measure specific vehicle values (for ex. Oil temperature, engine rpm, engine load, etc)

Already existing interfaces with the On board computer

Yes Primary source of information about vehicle behaviour

FU1

PC2 On board computer

Hosts predictive maintenance strategies (SS1 + SS2)

Yes

PC3 Vehicle to ground communicator

Communicate with ground station Yes / No What can be transmitted, at what distance, what is the updating frequency

FU6 FU7 FU8 FU9

PC4 Ground station PC

Hosts Ground station DSS (SS3 + SS4)

No



@




Is this software / DSS already available at your company today or not?


Relate this to all relevant functionalities

SS1 Strategies for Mission profiles indicator management

Define, update, reset specific indicators for the description of vehicle mission profile, engine mission profile, engine oil mission profile. These indicators are updated based on sensor values.

No FU2 FU3

SS2 Predictive maintenance algorithms

Starting from indicator for the description of the mission profile (vehicle, engine and engine oil), define a “residual autonomy” in terms of mileage for a specific component (for ex. Engine oil replacement)

No FU4 FU5

SS3 Ground Station DB

Collects data (vehicle mission profile indicators, engine mission profile indicators, engine oil mission profile indicators, component residual autonomy) for each vehicle of the fleet

No FU10

SS4 Ground station Data miner

Elaborate data from the ground station DB and derive messages / info for:

residual autonomy for each vehicle feedback about vehicle “correct” usage feedback about fleet mission profile feedback about typical component usage maintenance management (policy, day by day maintenance).

No FU10

Table 24: Software / support systems (SSs) of the A4 PROMISE demonstrator Note: Predictive maintenance strategies = Strategies for Mission profiles indicator management (SS1) + Predictive maintenance algorithms (SS2) Ground Station DSS = Ground Station DB (SS3) + Ground station Data miner (SS4)


@









FU1 Real time measure component phisical values (for ex. Engine rpm, engine load etc)

? Component physical values

Real time, when engine is on

PC1 High OB1

FU2 Updating of mission profile indicators, relative to vehicle, components or engine oil.

Physical values from sensors

Mission profile indicators updated Every second SS1 High OB1

FU3 Reset mission profile indicators, relative to vehicle, components or engine oil

Oil change flag Mission profile indicators updated When oil is changed/ component replaced or fixed

SS1 Medium OB1

FU4 Calculate component residual autonomy

Mission profile indicators Residual mileage / user message / warning SS2 High OB1

FU5 Send message to the driver

Residual mileage

User message / warning

Comparison with a threshold

PC2 High OB1

FU6 Send message to the ground station

See R1 Residual mileage User message / warning Comparison with a threshold

PC3, PC4 Medium OB2

FU7 Send mission profile indicators to the ground station

See R2 Mission profile indicators Population of DB of Ground Station DSS See Ex. 1 PC3, PC4 Medium OB3

FU8 Send mission profile indicators to the ground station

See R3 Mission profile indicators Population of DB of Ground Station DSS See Ex. 2 PC3, PC4 Medium OB4


@








FU10 Fleet management DB of DSS populated Provide information about: residual autonomy for each vehicle feedback about vehicle "correct" usage feedback about fleet mission profile feedback about typical component usage maintenance management (policy, day by day maintenance).

SS3, SS4 Medium OB4



@


FU1 (A4)

Real time measure component phisical values

(for ex. Engine rpm, engine load etc)

?component

phisical values

real time, when engine is on

PC1 Sensors

FU2 (A4)

Updating of mission profile indicators, relative to vehicle, components or

engine oil.

every second

SS1 Strategies for Mission

profiles indicator management

FU3 (A4)

Reset mission profile indicators, relative to

vehicle, components or engine oil

oil change flag

when oil is changed/

component replaced or

fixed

SS1 Strategies for Mission

profiles indicator management

FU4 (A4)

Calculate component residual autonomy

mission profile indicators updated

mission profile indicators updated

user messagewarning

SS2 Predictive maintenance algorithms

FU5 (A4)

Send message to the driver

residual mileage user message

warning

comparison with a

threshold

PC2 On board

computer

FU6 (A4)

Send message to the ground station

user message

warning

comparison with a

threshold,

PC 3 Vehicle to ground

communicator


FU7 (A4)

Send mission profile indicators to the ground

station related to O3

B

BPopulation of DB of Ground Station DSS


communicator


FU8 (A4)

Send mission profile indicators to the ground

station related to O4B Population of DB of Ground Station DSS


communicator


FU10 (A4)

Fleet managementDB of DSS populated

Provide information about:residual autonomy for each

vehiclefeedback about vehicle "correct"

usage feedback about fleet mission

profilefeedback about typical

component usage maintenance management (policy, day by day

maintenance).SS3

Ground Station DB

SS4 Ground station

Data miner


@

DR3_2 Appendix A Demonstrators~2.doc


@

DELIVERABLE NO Relates to DR3.2: PROMISE Demonstrator A5

DATE 05. May 2005


VERSION NO. 1.0






SUBMITTED (author(s)) Tonya A.T. Garrett 28.04.2005

VU (WP Leader) Caterpillar Inc


Written by: Howard W. Ludewig Caterpillar Inc. Updated by: Tonya A.T. Garrett Caterpillar Inc

PROMISE Demonstrator A5 Caterpillar (MOL)



@

Revision History

Date (dd.mm.yyyy)





08.04.2005 0.2 Howard W. Ludewig Draft write up

26.04.2005 0.3 Tonya A.T. Garrett Updated

28.04.2005 0.4 Tonya A.T. Garrett Split into 2 documents: MOL & EOL


Author(s)’ contact information Name Organisation E-mail Tel Fax Howard Ludewig Caterpillar Inc. [email protected] 3095784469 Tonya Garrett Caterpillar Inc [email protected] 3095786734 3095786734



@

5 A5 CATERPILLAR (MOL) – Definition of the demonstrator


PROMISE Grenoble Track Type Loader (TTL) The demonstrator will be applied to the lift arm.

The demonstrator aggregates all kind of field data, product specific information, and additional information and transforms it – supported by decision support system – into knowledge that can be used to take productive and effective actions. The data must be accessible by the supply chain in a PDKM system.

This demonstrator covers the closure of information loop between product operation (MOL) and product recycle, reuse, remanufacture or disposal (EOL). However, to effectively impact these focus areas the demonstrator will also have to close the loop with manufacturing and design (BOL).

Table 26: The PROMISE MOL demonstrator

5.2 A5 – Objectives (OBs) of the Demonstrator ID Objective (one per ID) Describe why OB1 Primary objective:

Prove the closure of information loop between information related to field application embedded in field data and knowledge required to manage the field population.

This demonstrator covers the closure of information loop between product operation (MOL) and knowledge-based actions.

OB2 Demonstrator shall aggregate available engineering data, field data, and ancillary information.

All required information and data will be used to manage the field population, including maintenance and logistics, (MOL) as well as making decisions.

OB3 Use product embedded devices such as RFID to track components and automatically maintain related data linkages such that it can be transformed into the required knowledge.

This provides a decision making process for MOL that is based on knowledge of the entire field population.




@




BOL MOL EOL

AC1 Product Design

Internal Optimize designs and support Dfx

M X

AC2 Manufacturing Internal Optimize manufacturing processes and forecasting build

H x

AC3 Dealers External Field support and maintenance H AC4 Owner

Operators External Work site management H

AC5 Suppliers External Forecasting product needs H AC6 Logistics Internal/External Forecasting and tracking H




@







OS1 Structural Component - Lift Arm of TTL product

Working component lifting loads ( MOL)

Sensor will be physically attached in the lift arm.

The physical component (lift arm) already exists on a TTL, but no sensors are used today. .

Maximize use of lift arm (remaining life measured, not estimated) , develop preventive maintenance MOL, reduce risk of component failure, increase user safety working conditions,

FU 1 Data acquisition FU 2 Data transfer, FU 3Data management FU 4 preventive actions

OS2 Sensor Sense the remaining life of OS1

A method to communicate sensor data in the PDKM system needs to be determined.

The mentioned sensor is under development at another company and must be obtained.




@


support system

Describe its functionality Describe the necessary interfaces of this software/support system to other PC IDs, SS IDs etc




SS1 Data acquisition system for sensors

Capture data from sensor and store it

Sensor software reader (wireless system)

Software is not available at CAT. It should be provided by another company to be used

Capture data from field application during MOL product

FU1


To transform data on information Transform data on stress range application

Software will be used to transform information into decision SS3 Software is not available. It should be hire to be used

Transform data into information during MOL product

FU2


Transform information into decision

Transform stresses ranges into fatigue life calculation

Software should transform information into fatigue life prediction in order to evaluate residual life of the component during MOL Software is not available at CAT. It should be provided by external company to be used

Transform information into knowledge in order to develop preventive maintenance

FU3

SS4 PDKM Transform decision into action Transform result of calculation into action to applied preventive maintenance

Software should transfer decision in order to define action for preventive maintenance through MOL actors (dealers, users,… Software should be developed

Application of preventive maintenance on Ids product.

FU4




@


ID Functionality Comments to the functionalities

Define the inputs needed to achieve this functionality and relate the input to other FU IDs (e.g. output data from FU3)







FU1 initial data acquisition and management system from sensor


Sensor information from component Data storage during filed application Lift arm TTL product, sensor, data transfer information system into on board PC or sensor reader

This function provides the data needed for field replacement and remanufacturing

H 0B3 ; 0B2

FU2 PDKM functionality for the logistics management system


Information output from FU1 Define decision for logistic management system

Software and data wireless transfer system from product to dealers

This function provides for a logistic system that can forecast need based on field population and failure data

H 0B2; 0B1

FU3 PDKM functionality for field application data collection and management system


Information output from FU1, FU2 Define decision for preventive maintenance and design corrective actions

Field data collection and management for maintenance, application related data, and field population. Provides feedback knowledge to design and manufacturing relative to field applications.

This provides the functionality to track components through the life of a product. This capability includes: Component life Repair Maintenance Application severity Field population

H 0B1

FU4 PDKM functionality that provides Df(x) information to designers

? Information from FU1 Information that designers can use to improve design

0B1




@




@


DATE 05. May 2005


VERSION NO. 1.0






SUBMITTED (author(s)) Daniele Panarese 26.04.2005

VU (WP Leader) FIDIA


Written by: Daniele PANARESE, FIDIA Michele SURICO, FIDIA

PROMISE Demonstrator A6 FIDIA (MOL)


@

Revision History

Date (dd.mm.yyyy)




Updated structure based on input from the Munich meeting on the 11.-12. April 2004. The version was sent SAP, EPFL, BIBA, STOCKWAY and INFINEON for comments before distribution.

27.04.2005 0.3 Fabrizio MEO


Author(s)’ contact information Name Organisation E-mail Tel Fax Daniele PANARESE FIDIA [email protected] +39 0805856270 Michele SURICO FIDIA [email protected] +39 0805856270


@

6 A6 FIDIA (MOL) – Definition of the demonstrator


PROMISE Milling machine Milling is the process of cutting away

material by a rotating cutter. Fidia Milling Machines are integrated systems for the machining of complex forms for the moulds and dies industry. Milling systems are made up of multiple mechanical axes moved by electric drives that are able to translate and rotate the milling head in the workspace. The milling head is made up of a rotating spindle equipped by a set of many different machining tools that allow the realization of various and complex forms. The milling systems are controlled by a numerical control.

This demonstrator is related to the improvement of technical aspects of the product functionalities after exploiting field knowledge gathered through the product lifecycle.


6.2 A6 – Objectives (OBs) of the Demonstrator ID Objective (one per ID) Describe why OB1 Traceability of components The components do not reside on the same machine

throughout their lifecycle. Often after a repair intervention a fixed component is re-installed on a different machine. It would be highly desirable to keep track of the ‘history’ and the characteristics of the components installed on each machine because knowing their exact features makes easier the technical interventions.

OB2 Predictive Maintenance We can get useful information about the components state performing periodic checks on the machine. Storing this data enables statistical analysis of the components lifecycle, such as finding the relation between the wear and the failure rate. This can help to single out the machines failure causes, allowing the optimization of the technical interventions and thus minimizing machine unavailability.

OB3 Design improvement The constant improvement of the machine design is essential to offer the customers products more fitting to their requirements. Also a better components design can allow easier technical interventions.



@


/ Internal Describe how they will be involved, their role and impact of the PROMISE technology


BOL MOL EOL

AC1 Design department

Internal OB1 and OB2 allow to gather data on the state of each machine critical component. The design department will receive the feedback, perform statistical analysis on this data and keep track of the overall components performance. This knowledge will be exploited to manufacture better machines (OB3).

High X X

AC2 Technical assistance service

Internal OB1, OB2 and OB3 allow to increase the quality of technical assistance. The Promise technology could help to: 1) restrict the field of failure causes (thus making easier the assistance interventions) 2) suggest the best replacements parts for each technical intervention

High X

AC3 Customer External For the time being a failure on a milling machine implies the sudden interruption of the manufacturing process (with the consequent loss of production) and the intervention of a technician to fix the machine The development of each and every objective would greatly: 1) reduce the customer’s related costs 2) extend the milling machine lifecycle

High X



@







PC1 Computerized Numerical Control (CNC)

CNC is the interface between the mechanical machine and the human user. The CNC controls the motion of the mechanical axes.

CNC is installed on the milling machine. It runs a Windows or Linux operative system (SS2). It reads data from sensors (PC4). It will read data from RFIDs (PC3).

This component is already available The Predictive Maintenance Tool (SS4) that will be developed in order to gather, elaborate and manage data coming from the A/P RFIDs installed on the machine will run on the CNC. This is essential for OB2 and OB3.

FU1

PC2 Mechanical axis A milling machine is made up of multiple mechanical axes moved by electric drives that translate and rotate the milling head in the workspace to allow the machining of complex moulds.

Mechanical axis is made up by servodrive, electrical drive, encoder, screw (PC7), nut (PC6), bearings (PC5). Its motion is controlled by CNC (PC1). Position sensors (PC4) are installed on mechanical axis.

Components available. OB1 and OB2 reserve particular attention to the critical components of the mechanical axis (e.g. nuts, bearings, screws).

FU3

PC3 RFIDs RFIDs will store the configuration of the electronic boards (firmware version, updating, etc.) and data about the machine installed critical components (type, batch number, fixing interventions, etc.).

Wireless communication up to 5 meters of distance with the CNC (PC1) Read/write operations with the CNC (PC1) to upload or download data about components.

Component not available. It will be available in PROMISE project.

It would be highly desirable that RFIDs could follow the components during their life (OB1), thus allowing the Predictive Maintenance Software Tool (SS4) to work correctly (OB2).

FU1, FU2, FU3


@






PC4 Sensors Position sensors on milling machine retrieve the position of the milling head in the workspace. Temperature sensors monitor temperature inside the working area of the machine.

Wire communication with CNC (PC3). Data from sensors will be elaborated by Predictive Maintenance Software Tool (SS4).

Position transducers and temperature sensors are already in use. Accelerometers are possible future sensors if needed by Predictive Maintenance Tool (SS4) development.

Sensors as well as RFIDs (see above) represent the product embedded devices from which field data is gathered in order to develop a life cycle management (OB2).

FU3

PC5 Bearings Components designed to reduce friction between moving parts.

Critical components for OB1 and OB2

FU2, FU3

PC6 Nut Component designed to convert rotative motion in linear motion


FU2, FU3

PC7 Screw Component designed to transmit motion between electrical motor and mechanical axis


FU2, FU3

PC8 Electronic boards Electronic boards elaborate signals and data

Are installed in slots on CNC (PC1) but also on the rack of the milling machine. It is needed to install RFIDs (PC3) on these components. Information regarding these components will be managed in Backend software (SS1)

The objective OB1 will allow the traceability of the Numerical Control electronic boards.

FU2, FU3

PC9 Central PC Central PC (located at Technical Assistance Service Department in the Builder Site) will host the Backend software (SS1). It will provide product lifecycle management.

Remote connection is possible between Central PC and local CNC (PC1).

Point to point remote connection is available at the Technical Assistance Service. It will be evaluated the opportunity (e.g. security issues) to develop Internet communication.

All the data required for OB1 will be stored in the Central PC.

FU2, FU3


@






PC10 RFIDs receivers Receive data for the CNC (PC1) from RFIDs (PC3).

Wireless communication up to 5 meters of distance with RFIDs (PC3). Standard connection (PCI bus, Serial, USB, etc…) to CNC (PC1).

Component not available. It will be available in PROMISE project.

It is needed to allow communication between the RFIDs and the CNC.

FU1, FU2, FU3



@







SS1 Backend software

This will be the PLM system. Backend SW must be able to perform statistical analysis on components data collected from several monitored machines. This will improve the knowledge about the product.

Backend software will run on central PC (PC9). Backend software will be remotely connected to local CNC (PC1) by a point to point modem connection or the internet.

When available, this SW will run on the central PC at technical assistance department. It will be based mainly on database application.

It provides feedback to the design department useful to understand the components lifecycle and to identify defective series (OB3). It also keeps track of all the components history (OB1).

FU2

SS2 Operative system The demonstrator is equiped with a computer running Windows or Linux operative system.

It is the interface for all the SW modules.

It is already available. It is the background for the Predictive Maintenance Software Tool

FU2, FU3

SS3 RFIDs-CNC Interface

It will allow the receiver antenna (PC10) to communicate with the CNC.

Driver interface (e.g. ActiveX, dll).

It must be provided with the RFIDs. It should be a SW application allowing communication between RFIDs and CNC.

Needed for all objectives.

FU1

SS4 Predictive Maintenance Software Tool

It must collect data periodically (e.g. every 3 months) from sensors and transform them into information and knowledge. Decision support will be required at this step.

This module will run on local CNC (PC1), take data from sensors (PC4), elaborate incoming data (SS4).

To be developed (e.g. Visual C++ application). Periodically it will execute standard test (already available) and gather data to transform into knowledge (this will be developed in PROMISE project) about installed components state from (already known) relevant parameters.

It allows OB2 (predictive maintenance) and OB3 (design improvement).

FU3



@










FU1 Data transfer (read/write operation) between RFIDs installed on critical components of a milling machine and receiver.

The data transfer should be periodical (e.g. every three months).

Input from RFIDs (PC3) Data collected from this functionality is used for traceability (FU2) and predictive maintenance (FU3)

Periodical requests from CNC (C1).

Components involved: RFIDs (PC3), receivers (PC10), CNC (PC1). Actors involved: technical assistence (AC2). Technology: RFIDs-CNC interface (SS3).

This functionality is needed to exchange data between transmitter antenna and receiver antenna. CNC should be able to read data from and write data on RFIDs.

High OB1 and OB2

FU2 To allow traceability of components.

RFIDs should store technical data (e.g. from data sheets) about the installed components. Moreover the RFIDs should collect data of all the technical assistence interventions performed on each component.

Input from (FU1) Output to backend sw (SS1) Manual input by technical service (C1).

Components involved: RFIDs (PC3), critical components (PC5÷8). Actors involved: technical assistence (AC2). Technology: backend system (SS1).

This functionality is needed to gain traceability of the machine parts.

High OB1

FU3 To execute Predictive Maintenance evaluations.

The decision support software gathering data from RFIDs should run locally on the PC of the Numerical Control. This SW should: 1) perform suitable tests on the machine 2) elaborate data and extract relevant parameters 3) make decisions based on these parameters.

Input from (FU1), sensors (PC4) Output to Predictive Maintenance Software Tool (SS4)

Periodical requests from CNC (C1).

Components involved: RFIDs (PC3), critical mechanical components (PC5÷7), CNC(PC1). Actors involved: technical assistence (AC2), design department (AC1). Technology: Predictive Maintenance Software Tool (SS4).

System must be able to handle data and information from RFIDs in order to allow predictive maintenance operations.

High OB2, OB3



@



@

6.8 A6 – Additional information related to the business, hardware, software and network architecture of the FIDIA demonstrator

In this section, the demonstrators added other relevant information related to the Demonstrator not already covered. Each Demonstrator was free to form this section as needed and this section can e.g. serve as a reminder for the WP Ax (and other WPs) when these start.


@


@


DATE 05. May 2005


VERSION NO. 1.0






SUBMITTED (author(s)) Lorenzo Marra 27.04.2005

VU (WP Leader) MTS


Written by: Lorenzo Marra, MTS

PROMISE Demonstrator A7 MTS (MOL)


@

Revision History

Date (dd.mm.yyyy)





27.04.2005 V 00 Marra Lorenzo Previous document as been rewritten in order to adapt to this new template.


Author(s)’ contact information Name Organisation E-mail Tel Fax Lorenzo Marra MTS [email protected] +39-071-

7200568 +39-071-7100275


@

7 A7 MTS (MOL) – Definition of the demonstrator


PROMISE Condensing wall hung gas boilers

max power output 27KW for domestic application, with both Central Heating and Domestic hot water production.

Improving maintenance and service operations related to boilers and as a result increase performance and up-time of boilers, and thus achieve customer satisfaction. MTS is focusing on gas boilers, and especially the condensing ones, as these are the products that will have the biggest market-share in the future, as they have the highest efficiency and lowest emission. MTS is therefore interested in studying predictive maintenance on these boilers, in order to improve MOL operation on products that will be amongst the most imporant MTS products in the future.


7.2 A7 – Objectives (OBs) of the Demonstrator ID Objective (one per ID) Describe why OB1 To systematically collect and store the data

relevant to the application and to apply evolutionary diagnostic and prognostic algorithms over the product lifespan (MOL), which will let be possible to do “Predictive Maintenance” on gas boilers.

Prognostic algorithms will enable Service Companies to do “Predictive Maintenance” on gas boilers. Prognostic algorithms, by analyzing continuously data acquired from PEID (developed for MTS’s specific demonstrator by RC2, in WP R4 and R5) from demonstrator (gas boiler), must be able to recognize that a specific component or system is going to have a failure in a certain time span and with a certain probability percentage. The Service Companies will then have the time to plan a visit to the boiler’s owner bringing with them the right spare part, before the component breaks down, and so the owner will have 100% boiler availability, not suffering from a cold house.

OB2 Test the PEID, developed under MTS specifications by RC2, in WP R4 and R5, on the gas boilers, in order to assess its capability to collect data from boiler serial protocol and from additional sensors, store and transmit data with long distance communication capability

The bigger obstacle to the introduction in each boiler of a data logging/analysis/shipment system (PEID) to a remote collecting point (PLM/PDKM/decision making support system) is mainly the cost of the PEID. The target price for PEID will be reached when every house will have and IP connection already available. In Promise project the goal is to prove the concept.

OB3 Test the back-end, PDKM, PLM, DSS, developed in RC-3 and RC-4 according MTS demonstrator needs, to prove that it is able to handle all data coming from PEID, analyze it through predictive algorithms, send e-mail to Service Companies to advise of a predicted failure, with a WEB interface accessible by Service Company/MTS who can see list of all errors, make graphs of data, set parameters like e-mail, dial the PEID and see real time values of all data/sensor logged from the boiler, and download to a local PC in xls format from the PDKM through a web interface all data

The goal is to handle info on MOL from the source of data (PEID connected to the boiler and to additional sensors), to analyze it (predictive algorithm) and to let the users (Service Companies and MTS) to access this info, for predictive maintenance.


@

ID Objective (one per ID) Describe why received from PEID and all info generated by data analysis (e.g. trends of Predictive maintenance indicators). It must also be accessible to boiler manufacturer for changing parameters needed to tune predictive algorithms.



@




BOL MOL EOL

AC1 Service Companies

External Service Companies have Service Contracts with boiler’s owners. If they can be advised in advance that a specific component is going to have a failure (thanks to predictive algorithms) they can visit the boiler’s owner and replace the component which is going to break down. So they can do Predictive Maintenance. Their work will also be more efficient, as they now in advanced what to do on a certain boiler, not making anymore repairing error, in other words, avoiding to replace a component which is perfectly working because the Service Engineers was not able to identify the problem occurred.

High X

AC2 Boiler’s owners

External Thanks to Predictive Maintenance, the boiler’s owner can receive from Service Companies an higher service level, having the gas boiler always available, never suffering from cold house and cold Domestic Hot Water

High X

AC3 MTS After sale service

Internal MTS could provide to Service Companies an “advanced service tool”, which is the Predictive Maintenance information, under the payment of a certain e.g. “yearly fee”, and can decrease the amount of component replaced by error during warranty period

High X



@







PC1 Gas boiler Produce heat for central heating and domestic hot water

The gas boiler has control board in which a serial protocol is available. This serial protocol is a source of data related to all sensors/actuators present in the boiler and of data related to boiler status. This serial protocol must be implemented in the PEID so it can log the data contained in it. So PC1 is connected to PC6 (PEID)

Yes, it is available. It is a standard MTS product, available in warehouse. No modification on the MTS standard boiler must be done, not to affect boiler safety. PEID and additional sensors will be plugged outside the boiler.

OB1, OB2 and OB3 FU1

PC2 Heating circuit To distribute hot water generated from gas boiler to heating system (radiators, floor-heating system,…)

-PC1, as the boiler is connected to heating circit; -PC7 (additional sensors) as some sensors will surely connected to the heating circuit (e.g. pressure sensor, flow sensor, temperature sensors,…)

Yes, it is available as the boiler needs it to be installed.

If the water pressure in the Heating circuit is below a threshold (e.g. 0.7 bar) the boiler will go in lock-out. Now the boiler is equipped with a pressure stat, whose switch status (open/closed) is read by boiler control board. If the water pressure is lower than 0.7 bar the contact will open and the control board will generate a lock out. In PROMISE we want the PEID to collect/analyze/ship to PLM the pressure measured from an additional pressure sensor in order to understand if the pressure is decreasing (e.g. owing to a leakage) and before it reaches the

FU1


@






threshold generates a Predictive alarm. The relation to the objective is OB O1 (PREDICTIVE MAINTENANCE)

PC3 Flame detection system

It is build of electrode rod placed in the flame, connection cable to boiler control board, in which a circuit compares the flame signal to a threshold. Its function is to determine if, after the ignition sequence took place, the burner is really lit and so the flame is present, avoiding unburned gas to come out. If the flame signal is over the threshold the gas valve is kept open otherwise it is closed and a lock-out is generated.

The signal form flame detection system is available from MTS serial protocol already present in MTS boiler control board. The interface is to the PEID which must implement MTS serial protocol from which it can log, store and transmit data related to flame signal The PC3 is interfaced to PC6 (PEID) through MTS serial protocol

This physical component is built in the boiler (PC1)

At the moment we use the flame signal in an ON/OFF way, to determine if the flame is present/not present, but we know that the flame detection system has a degradation that lowers very slowly the flame signal down until it is under the threshold and the boiler goes into lock-out. The goal is to identify which are indicators able to detect the degradation and make a prediction of when the signal will go under the threshold. If a Service company will be advised by e.g. e-mail of this prediction he can plan in advance a visit to the customer in order to replace the degraded component in the chain (to be assessed which one it is) with a new one. The relation to the objective is OB O1 (PREDICTIVE MAINTENANCE)

FU1

PC4 Pump To let water circulate through heating circuit (primary circuit)

Status of the pump can be retrieved from MTS serial protocol already present in MTS boiler control board. The interface is to the PEID which must implement MTS serial protocol from which it can log, store and transmit data related to the pump. The PC4 is interfaced to: -PC6 (PEID) through MTS


The pump component can degrade in different way and, at the end, it can happen that the pump is completely stuck, or rotates too slow or the motor and the impeller and linked anymore by the axis. It can also happen that, owing to air bubbles the impeller rotates in air and doesn’t generate water circulation. The goal is to identify which are indicators (current, Voltage, cos Φ, pressure increase after pump start, flow rate generated,…) able to

FU1


@






serial protocol -PC7 (additional sensors) as some additional sensors will have to measure info related to pump (e.g. current, voltage and cos Φ)

detect the degradation , and via predictive algorithms, predict the failure letting Service Company to do Predictive maintenance. The relation to the objective is OB O1 (PREDICTIVE MAINTENANCE)

PC5 Domestic Hot water heat exchanger

To exchange heat from primary circuit water to secondary circuit water (Domestic Hot Water, DHW)

Information related to DHW temperature, and Flow and Return temp of primary circuit can be retrieved from the serial protocol already present in MTS boiler control board. The interface is to the PEID (PC6) which must implement MTS serial protocol from which it can log, store and transmit data related to DHW exchanger. The interface is also to PC7 (additional sensors) as some additional sensors will have to measure info related to DHW function (e.g. temperature of cold inlet water, water flow,….)


It is a plated heat exchanger, and so it performances is degraded by limestone which will depot on the plates surfaces, thus decreasing the heat exchange factor. When the limestone layer on the plate gets too high, the boiler will work in DHW with very frequent cycling (ON/OFF) and the user will notice the DHW temperature also cycling from too hot to too cold. Then the user has to call Service Company which will replace the DHW exchanger with a new one. The goal is to identify which are indicators to detect the degradation process and predict when the limestone will get so big to let boiler cycling ON/OFF. .If a Service company will be advised by e.g. e-mail of this prediction he can plan in advance a visit to the customer in order to replace the DHW heat exchanger. The relation to the objective is OB O1 (PREDICTIVE MAINTENANCE)

FU1


@






PC6 PEID Read data from MTS serial protocol and from additional sensors, log them and transmit to PLM/PDKM/DSS. Additional sensors and what data to be logged will be defined together with partners involved in predictive maintenance algorithm

PC6 (PEID) has interface to: -PC1 boiler (in particular to boiler control board serial protocol, already present in MTS boiler and that must be implemented by PEID); -PC7 additional sensors, as they are needed to collect data relevant to predictive maintenance on PC1, PC2, PC3, PC4 and PC5 -SS2, as data collected must be sent to PLM/PDKM/DSS for predictive maintenance purpose

No, it is not available. PEID, both its hardware and its software (e.g. protocol for exchange data to PDKM/PLM/DSS, software to log and store data,…) will be developed in RC2

OB1, OB2 and OB3 FU1 and FU2

PC7 Additional sensors

Additional sensors to be logged by the PEID and installed externally to the boiler will be defined together with partners involved in predictive maintenance algorithm

PC6: additional sensors output are collected by PEID; PC1 PC2, PC3, PC4, PC5: additional sensors will be connected to physical component for measuring data relevant for predictive maintenance on them.

Some sensors can be found in standard market other should be developed inside the PEID (e.g. circuit to measure Voltage, current and Cos Φ of the boiler)

The relation to the objective is OB O1 (PREDICTIVE MAINTENANCE)

FU1



@







SS1 WEB site It is the way for Service Companies and MTS to access to all data received from the PEID through long-distance communication capability (e.g. list of all diagnostic event predicted on a certain boiler, see in a graphic way the trend of variables, indicators, sensors logged by the PEID and transmitted to the PLM/PDKM) set parameters like e-mail to which the predictive diagnostic event info is sent to, set parameters needed to tune predictive algorithms, dial the PEID attached to the boiler and see real time value of all data/sensors acquired. They can also download to a local PC in xls format from the PDKM through a web interface all data received from PEID and all info generated by data analysis (e.g. trends of Predictive maintenance indicators).

The WEB site must have an interface to SS2, as it will show on a web page data stored in PDKM database and predictive maintenance request generated by predictive algorithm and Decision Support System.

No, it is not available as it will be the Promise WEB site.

OB-03 FU3 and FU2


@

ID Software / support system





SS2 PDKM/Decision making support system/predictive algorithms

Store data coming from PEID; analyze them with predictive algorithm and generate failure prediction.

This must have an interface to PC6 PEID because the PDKM/Decision Support System/predictive algorithms must elaborate data coming from PEID.

No, it is not available as it will be result of the Promise project.

The related objective is ID OB 01 (PREDICTIVE MAINTENANCE) and OB3

FU3 and FU2



@










FU1 Collect, store, analyze and transmit data with long distance communication capability from boiler control board serial protocol and from additional sensors, to the PLM/PDKM/DSS (this work is done by specifi PEID with long distance communication developed in RC2).

How many data, type of data, type of sensors, samples time of each single data, memory space necessary, MIPS required must be defined with the partners involved in designing predictive algorithms.

- data received from serial protocol of MTS control board - data received from additional sensors connected outside the boiler

- data flow from PEID to the PLM/PDKM/DSS (FU2). When/how often data must be send out will be decided with partners involved in predictive algorithms

- C1 MTS specifications

-long distance communication (MTS prefers GPRS communication) to be implemented in PEID

This function is needed because data collected, stored, analyzed and transmitted will be the base on which predictive algorithms will work to extract a failure prediction.

High ID OB1 and ID OB2.

FU2 PDKM, Decision making support system, predictive algorithms

Store data coming from PEID; analyze them with predictive algorithm and generate failure prediction.

-data received from PEID (FU1) -data coming from PEID are handled and stored in the Database -decision support system/predictive algorithms analyse data and generate a predictive maintenance event


-predictive algorithm: MTS has not know in this field, and so will cooperate with Partners involved in predictive maintenance, providing its knowledge on the boiler and its capability to realize experiments to generate data on which predictive algorithm can be developed and tuned

This function is needed to extract a failure prediction on a specific component from data received from PEID (FU1)

High ID OB1 and ID OB2.

FU3 WEB interface for the back-end

Promise Users, which are Service Companies and MTS, must have a WEB interface to be able to have functions as described in SS1, and OB3

-data available from FU2 -web pages on which data are displayed (see SS1) -e-mail to Service Company and MTS to advice of a predictive maintenance request


-MTS has no specific requirement

This function is to give to the Promise Users (MTS and Service companies, AC1 and AC3) info on MOL (predictive maintenance e-mail) from the source of data (PEID connected to the boiler and to additional sensors), to analyze it and to let the users (Service

High ID OB1, OB2 and ID OB3.


@









Companies and MTS) to access this info.



FU1 (A7)

Collect, store, analyze and transmit data with

long distance communication capability from boiler control board serial protocol and from

additional sensors, to the PLM/PDKM/DSS (this work is done by specifi PEID with long distance

communication developed in RC2)

Data from serial protocol of MTS control board

Data from additional sensors connected outside the boiler

Data flow from PEID to the PLM/PDKM/DSS

(FU2)

C1 MTS specification

s

long distance communication (MTS

prefers GPRS communication) to be implemented in PEID

FU2 (A7)

PDKM, Decision making support system, predictive

algorithms Generated predictive maintenance event


s

Predictive algorithms

FU3 (A7)

WEB interface for the back-end

Data Web pages on which data are displayed (see SS1)

E-mail to Service Company and MTS to advice of a predictive maintenance request


s


@


@


DATE 05. May 2005


VERSION NO. 1.0






SUBMITTED (author(s)) Pier Andrea Pracchi 30.04.2005

VU (WP Leader) WRAP


Written by: Pier Andrea Pracchi, Wrap Emanuela Antognoli, Wrap

PROMISE Demonstrator A8 Wrap (MOL)


@

Revision History

Date (dd.mm.yyyy)





28.04.2005 0.3 Pier Andrea Pracchi Updated structure based on input from Carl Rostad


Author(s)’ contact information Name Organisation E-mail Tel Fax Piero Pracchi Wrap [email protected] +3907326362222 +3907326362001


@

8 A8 WRAP (MOL) – Definition of the demonstrator


PROMISE Refrigerator Cooling system in residential use The reason for this focus lies on the fact that a

regular lifecycle for a refrigerator is about 10 years and for that period of time the manufacturer isn't aware of what really is going on with the appliance since there are no pre-scheduled checks/inspections (like in the automotive industry for example). When a refrigerator stops working all its perishable load (food) is lost and that causes a lot of trouble and complication for the owner. In addition, for a multitude of reasons, the condition in which the appliance operates may vary and sometimes inefficiencies of the compressor level might develop and thus lowering its electric efficiency (sometimes also downgrading to different class: i.e.: A --> B). The result is larger electric bills for the owner and a relative large environmental impact. Ideally, white goods appliance manufacturers (like WRAP) are looking to deliver SERVICE and not just the product, to either increase customer fidelization level as well as the quality of the product


8.2 A8 – Objectives (OBs) of the Demonstrator ID Objective (one per ID) Describe why OB1 Faster End-of-line testing Reduces in-line time of the good OB2 Compressor efficiency Longer life for the goods and environmental impact reduced OB3 Cooling circuit pressure Longer life for the goods and environmental impact reduced OB4 Internal/External Temperature Better food conservation and parameter for compressor

efficiency





BOL MOL EOL

AC1 Service company

Internal Data collection, User service delivery High x

AC2 Production Internal In-line testing procedures Medium x AC3 Electronic

Design Internal Design of the Control Board Medium x



@







PC1 NTC Determines Temperature Refrigerator Digital Control Board

Yes, its is part of the actual BOM Vital Information on appliance behaviour

FU5

PC2 Compressor Proper functioning of the Fridge

Refrigerator Digital Control Board


FU5

PC3 No Frost Resistor Quantify the building up of the Frost

Refrigerator Digital Control Board


FU5

PC4 Proxy Device Data acquisition from refrigerator; electric quantity measurement

Refrigerator Power Cable It’s under development and will be completed for the purpose of this project

Acts as a PEID FU1,2,3,4








SS1 Predictive maintenance software

To acquire data from the refrigerator and to extract knowledge on its behaviour by the use of proper algorithm (any malfunctioning, possible inefficiency)

PC4 No it has to be developed through the cooperation with the partner involved. We need to determine which are the needed components component that have to be monitored in order to predict a possible failure.

The output of the SW is vital in order to deliver predictive maintenance to the appliance

FU2,3



@



Define the outputs from this functionality What are the controls? ID the controls by using C1, C2 etc





FU1 Data transfer from Refrigerator Main Board to Proxy device

At least one resistive load in the WG appliance (i.e.: lamp)

Output from FU5,3 Download/upload data from/to Control Board memory to the proxy device. The format of the data will be defined at a second time.

C1 – Wrap Spec Ultra Low Cost Powerline communication (the outcome of TEAHA – IST FP6 Funded Proj.)

To download statistical and operational – functional - information from the appliance

High OB-ALL

FU2 Transmission of data to a local / remote Server (for data reconfiguration/analysis)

Communication node (for both tx and rx) to enable communication

Output from FU1 Download/upload data from/to remote/local server (SS1)

C1 – Wrap Spec Wireless link is preferable (WiFi could be an option as well Zwave, Zigbee, BTooth …..)

To download data from the proxy to a remote / local server

High OB-ALL

FU3 Electric quantity measurement

Power Meter within the proxy device

The output is to generate internal load digital signature in order to analize any possible deviance from it so that to determine whether any malfunctioning are occurring

C1 – Wrap Spec Electric Quantity analysis and measurement for determining the digital signature of fridge’s internal loads

Interfaces with the Micro controller on board the Proxy device

High OB-ALL

FU4 Refrigerator parameter set updating

File setting parameter knowledge (which parameter needs to be updated)

Output from remote server FU2 To update the Refrigerator Testing File in case of specific request from the plant (it is possible to shorten the time of the testing or to run a through one)

C1 – Wrap Spec Proxy device, ad-hoc Sw reprogramming tool

defrosting cycle length can be varied when needed and specifically to production there is the need to make it the most flexible as possible

High OB1

FU5 Refrigerator Control Board data acquisition from sensors and electric load

Refrigerator Digital control board Acquisition from internal sensor and power meter

C1 – Wrap Spec Wrap designed control board and sensors system

To acquire and generate information from the whole refrigerator

High OB-ALL



@


FU1 (A8)

Data transfer from Refrigerator Main Board

to Proxy device

Download/upload data from/to Control Board memory to the proxy

device.

C1 – Wrap Spec

Ultra Low Cost Powerline

communication

FU2 (A8)

Transmission of data to a local / remote Server (for

data reconfiguration/analysis)

Download/upload data from/to remote/local server

(SS1)

C1 – Wrap Spec

Wireless link is preferable (WiFi

could be an option as well Zwave, Zigbee, BTooth

FU3 (A8)

Electric quantity measurement

C1 – Wrap Spec

Electric Quantity analysis and

measurement for determining the digital signature of fridge’s

internal loads

FU4 (A8)

Refrigerator parameter set updating

Update the Refrigerator Testing File in case of

specific request from the plant

Proxy device, ad-hoc Sw

reprogramming tool

FU5 (A8)

Refrigerator Control Board data acquisition from

sensors and electric load

Wrap designed control board and sensors system

C1 – Wrap Spec

Generated internal load digitalsignature in order to analyze any

possible deviance from it so that todetermine whether any

malfunctioning are occurring

Acquisition from internal sensor

and power meter


@


DATE 05. May 2005


VERSION NO. 1.0






SUBMITTED (author(s)) Dimitra Pli 29.04.2005

VU (WP Leader) INTRACOM


Written by: Dimitra Pli, INTRACOM Maria Anastasiou, INTRACOM

PROMISE Demonstrator A9 INTRACOM (MOL)


@

Revision History

Date (dd.mm.yyyy)





28.04.2005 0.3 Dimitra Pli, INTRACOM

Maria Anastasiou, INTRACOM


Author(s)’ contact information Name Organisation E-mail Tel Fax Dimitra Pli INTRACOM S.A. [email protected] +30 210 6674370 +030 210 6671312 Maria Anastasiou INTRACOM S.A. [email protected] +30 210 6674205 +030 210 6671312


@

9 A9 INTRACOM (MOL) – Definition of the demonstrator

9.1 A9 – The Demonstrator Demonstrator Describe functionality Describe why this Demonstrator is

focused in PROMISE INTRACOM Broadband Access System, IBAS. The IBAS system contains a set of components for delivery of narrowband voice services across an Access Network.

It is a Next Generation Multi-Service Access Node (MSAN) featuring broadband and narrowband subscriber interfaces. It is one of the DSLAM family products, which is the last element in the access network before the subscriber’s home, and is thus the vehicle for delivering broadband services. IBAS product includes software and hardware components (line cards).

It is for INTRACOM one of the key products under development, and it will be used as the corner stone of Next Generation Access Network.


9.2 A9 – Objectives (OBs) of the Demonstrator ID Objective (one per ID) Describe why OB1 To efficiently collect, integrate and manage

information about the product The collected information will be appropriately managed providing to the evolved actors the tools to correspond efficiently and effectively when a problem occurs and support decisions about product improvements.

OB2 To receive information about product operation

This raw data will provide valuable input to obtain knowledge about the product.

OB3 To transform operational data to valuable knowledge

The transformed data are going to be used for the decision support system.

OB4 To support decision making The engineers and technicians will be able to be supported about product improvements and problems solving/preventive maintenance.



@




BOL MOL EOL

AC1 Technicians (service, maintenance team)

Internal Technicians will be facilitated in their everyday work by being able to exploit knowledge gained through previous similar situations. The technician will be able to find in the knowledge base special characteristic of the customer site, as well as to the history of the related IBAS, cases with similar symptoms, the diagnosis made, as well as the solution given. At the customer site, the technician will have access to PROMISE system. Additional effort will be required by technicians to register in the appropriate way information related to the diagnosis made, solution given, as well as to customer site specific information. Customer support will have filtered access to the information coming from the EMS systems in order to perform preventive maintenance.

High X

AC2 Engineers (designers, product manager)

Internal Established processes will facilitate engineers to be informed about repetitive faults that occur and could lead to decision-making about improvements to the product.

High X

AC3 Customers External Simple troubleshooting information shall be available on line for customers. In addition, their collaboration is required to provide INTRACOM with product operation information.

High X



@







PC1 RFID tag The RFID tag would be used in order IBAS location to be identified.

PC2 No, it is going to be developed in the framework of PROMISE

Although initially INTRACOM did not intend to use RFID in its application, the analysis indicated that RFID could be used for identifying the location of the specific IBAS.

PC2 RFID reader The RFID reader would be used to read the information coming from the RFID tag.

PC1 No, it is going to be developed in the framework of PROMISE

As described above the need to use an RFID tag was identified during the analysis, consequently an RFID reader will be used.

Table 53: Physical components (PCs) of the A9 PROMISE demonstrator Regarding the use of an RFID tag and RFID reader that was identified during this analysis, it will be specified in detail.


@


support system





SS1 SIS Contains problems, solutions and card history. The lab personnel uses SIS system to register the problems and solutions, as well as to keep the cards’ history. It only contains information about cards manipulated by the lab.

SS4, SS5 This system is available in our company today, but some adjustments and integrations will be needed in order to interoperate with the other relevant systems.

The database SIS should interoperate with the PROMISE PDKM.

FU2, FU3, FU6, FU8

SS2 EMS Efficient operation management and supports the following functional areas: - Fault Management - Configuration Management - Performance Management - Security Management

SS4, SS5 This system exists at NOC (Network Operation Centre) of the operator. In cases that INTRACOM is the operator of the system EMS is available, otherwise depends on the Service Level Agreement.

Customer support will have filtered access to the information coming from the EMS system in order to perform preventive maintenance.

FU1, FU7

SS3 Call tracking system

Tracks the calls made by customers, the problem described, the technician allocated and the solution

SS4, SS5 This system is available in our company today, but some adjustments and integrations will be needed in order to interoperate with other relevant systems.

Information of the call tracking system to be integrated in the PDKM.

FU4, FU5, FU6, FU9

SS4 Decision Support System

Support the work of technicians (best practices, symptom problem, solution), preventive maintenance and identify repetitive problems (product improvements)

SS1, SS2, SS3 This system is going to be developed in the framework of PROMISE.

Information coming from the EMS, SIS, Call tracking system will be integrated in the Decision Support System.

FU3, FU4, FU5, FU10


@






SS5 PDKM Contains all the information about the product, the users and the customers. Support the work of technicians, engineers, and customers by providing all the necessary information.

SS1, SS2, SS3, SS4

This system is going to be developed in the framework of PROMISE

PDKM should interoperate with all relevant systems providing support to all involved actors.

FU1-FU10



@









FU1 Identify performance

INTRACOM-002 INTRACOM-007

Operational data Indications of performance, Identify preventive maintenance

C1: Customer agreement

PDKM, Technicians-Maintenance support

The technicians will be able to be supported about the performance of the product

High OB2

FU2 Identify repetitive problems

INTRACOM-007

Historical data, Data about product Parameters

List of repetitive problems C2: Amount of available data

PDKM, Engineers

The engineers will be supported to identify preventive maintenance

High OB2

FU3 Decision about product improvement

INTRACOM-001 INTRACOM-002 INTRACOM-010

FU2 output Product improvement C3: Cost C4: Lifecycle

PDKM, Engineers, Product manager

The engineers will be supported to decision making about product improvements

High OB4 OB3

FU4 Request for best practices

INTRACOM-010 Symptoms, Product ID, Keywords

List of related incidents* C5: Cases available PDKM, Technical support Customer support

Technicians will be facilitated by the knowledge gained through previous similar situations.

High OB4

FU5 Request for trouble shooting information

INTRACOM-010 Keywords Product

Trouble shooting information C6: Web access C7: Existence of relevant agreement

PDKM, Customers

Simple troubleshooting information shall be available on line for customers

High OB4

FU6 Update the PDKM with the incidents


Symptoms, Product instance, Diagnosis, Solution

New incident registered with PDKM C8: Template available

PDKM, Technical support Customer support

Updating the PDKM with incidents the technicians will be supported when a problem occurs by the knowledge gained through previous similar situations.

High OB1 OB2

FU7 Operational data transferred into PDKM


Operational data Registered operational data into PDKM C9: customer agreement

PDKM, EMS

All the information relevant to operational data will be processed to PDKM to support all involved actors.

High OB2

FU8 Maintenance data transferred into PDKM


Related product information Registered maintenance data into PDKM C10: Integration between the systems

PDKM, SIS

All the information relevant to maintenance data will be processed to PDKM to support all involved actors.

High OB1


@








FU9 Call tracking data transferred into PDKM


Related product information Registered call tracking data into PDKM C11: Integration between the systems

PDKM, Call tracking system

All the information relevant to call tracking data will be processed to PDKM to support all involved actors.

High OB1

FU10 Update product data

INTRACOM-001 INTRACOM-003 INTRACOM-004 INTRACOM-007 INTRACOM-009

Output from FU7, FU8, FU9 Updated product data, KM C12: Integration with relevant systems

PDKM, Engineers, Product manager Technicians-Maintenance support Customer support

The information gathered will facilitate all actors to perform their every day work efficiently and effectively.

High OB1, OB3, OB4


* Incident: product instance, symptoms, problems, solution


@



@


DATE 05. May 2005


VERSION NO. 1.0






SUBMITTED (author(s)) Markus Frey 29.04.2005

VU (WP Leader) Bombardier Transportation


Written by: Markus Frey, et al., Bombardier Transportation

PROMISE Demonstrator A10 BOMBARDIER TRANSPORTATION (BOL)


@

Revision History

Date (dd.mm.yyyy)





19.04.2005 0.3 Markus Frey, et al. Inclusion of BT Draft

25.04.2005 0.4 Martin Vögeli, Markus Frey First update of BT Draft

29.04.2005 0.5 Martin Vögeli, Anders Hynen, Martin Frank, Daniel Küffer, Markus Frey

Final update of BT Draft


Author(s)’ contact information Name Organisation E-mail Tel Fax Markus Frey BT LOC [email protected] +41 44 318

3817 +41 44 318 1000

Martin Frank BT LOC [email protected] +41 44 318 2610

+41 44 318 2450

Daniel Küffer BT PPC [email protected] +41 56 299 3802

+41 56 299 40 90

Martin Vögeli BT BOG [email protected] +41 52 264 1419

+41 52 264 1101

Anders Hynen BT PPC [email protected] +46 21 317322

+46 21 145318


@

10 A10 BOMBARDIER TRANSPORTATION (BOL) – Definition of the demonstrator

10.1 A10 - Abbreviations used in the A10 demonstrator BOL Beginning of Life BT Bombardier Transportation CM Condition Monitoring CBM Condition Based Maintenance DfX Design for X (where X can stand for: RAM/LCC, Product Safety, Environment, etc.) EboK Engineering book of Knowledge FRACAS Failure Reporting Analysis and Corrective Action System IS Information System LCC Life Cycle Cost MOL Middle of Life P & O People & Organisation PDKM Product Data & Knowledge Management PDM Product Data Management PEID Product Embedded Information Device RAM Reliability, Availability & Maintainability TCMS Train Control and Management System WBS Work Breakdown Structure (with various vehicle, system & location elements)


PROMISE DfX Demonstrator Product: traction chain of el. locomotive

The demonstrator aggregates all kind of field data and additional information and transforms it – supported by decision support system – into DfX knowledge, accessible by the engineers in a PDKM system. The traction chain of an electric locomotive transforms electrical energy into the wheel movement, transferring traction force to the rail or transforms brake forces into electrical energy.

This demonstrator covers the closure of information loop between product operation (MOL) and design (BOL). The traction chain is a central function of an electric locomotive, where BT gathers various field data which can be used to validate the demonstrator.



@

10.3 A10 – Objectives (OBs) of the Demonstrator ID Objective (one per ID) Describe why OB1 Overall objective:

Prove the closure of information loop between experience embedded in field data and knowledge (concentrated on Design for X aspects).

This demonstrator covers the closure of information loop between product operation (MOL) and design (BOL).

OB2 Demonstrator shall aggregate available field data and additionally needed other information.

For the transformation process all necessary data shall be considered from various sources.

OB3 Semi-automatic transformation of field data into appropriate DfX knowledge governed by specialist engineer.

The specialist shall finally decide on the transformed DfX knowledge.

OB4 Transformation process shall be adequately supported by a decision support system

The decision support system shall aggregate necessary data & information into deciding basis & decision proposals and provide them to the specialist engineer.

OB5 Knowledge Management functionality as part of PDKM environment shall manage DfX knowledge structured according to a predefined work breakdown structure (WBS).

PDKM environment is the main engineering system to manage information. WBS is the main form how to structure information.





BOL MOL EOL

AC1 Service organisation (incl. commissioning)

Internal Provision and input of field data into system

High X

AC2 DfX Specialist engineer

Internal Trigger and govern the transformation of field data into DfX knowledge

High X X

AC3 Engineer / designer

Internal a) Provision and input of field data into system in form of reports of failure analyses, solved problems, etc.

b) Appropriate usage of provided DfX knowledge

High X

AC4 Operator External Disclosure on usage of locomotive Medium X X AC5 IS specialist Internal Administration and support of tools Low X X X AC6 Maintainer External Provision and input of field data into

system High X



@







PC1 Converter (incl. power electronics)

A traction converter is a converter that is resistant to shock and vibration. The traction converter comprises all those components vibration. The traction converter comprises all those components between the line side and the output of the motor converter.

Converters are mounted inside the machine room of the locomotive. Interface to the: o electrical- or optical bus

system to the vehicle control unit

o traction motor (sensor) o temperature sensors of

the traction motor o speed sensor of the

traction motor o cooling tower o transformer o auxiliary converter o main circuit breaker o line side (sensor) o other converters (fibre

optic)

PC1 is available. Data are available from the Control Electronic PC1.3 which sent the information to the superior diagnosis system on vehicle level. Inspection of traction converter during preventive-/corrective maintenance. Measuring and recording of electrical characteristic during preventive or corrective maintenance or repair according to the operation manual. o Vibration monitoring not available on

locomotive o Standby time monitoring (DC-link charged) is

not available on locomotive o Switching On/Off time monitoring is not

available for converter

OB1 - example of most important electrical systems in traction chain

FU1 – provides field data

PC1.1 Gate drive unit Control unit for the IGBT in an Integrated Power Module.

Gate Drive Unit is linked to o Control electronic PC1.3 o Power modules PC1.2 o power supply

PC1.1 is available. Data are available from the Control Electronic PC1.3 which sent the information to the superior diagnosis system on vehicle level. o Vibration monitoring not available on Gate Drive o Switching On/Off power supply monitoring not

available Inspection of power gate drive unit during preventive maintenance => normally only records if module is damaged or failed.

Considered as example of important component in traction chain

ditto


@






Measuring and recording of electrical characteristic during preventive maintenance or repair.

PC1.2 Power modules Mechanical entity comprising the semi-conductors and associated components for one complete switching unit in a traction converter.

Power modules is linked to o Control electronic PC1.3 o Gate Drive Unit PC1.1 o Cooling system PC1.5

PC1.2 is available. o Vibration monitoring not available o Switching On/Off time monitoring is not

available for power modules Inspection of power modules during preventive maintenance => normally only records if module is damaged or failed. Measuring and recording of electrical characteristic during preventive maintenance or repair.

Considered as example of important electrical component in traction chain

ditto

PC1.3 Control electronics

The control electronics forms part of the vehicle control electronics and comprises those parts interacting with the traction converter.

Control electronics is linked to o Traction converter PC1.0 o Gate Drive Unit PC1.1 o Power modules PC1.2 o Sensors PC1.4 o Cooling system (sensor)

PC1.5 o Contactors PC1.6

PC1.3 is available. Data are available from the Control Electronic PC1.3 which sent the information to the superior diagnosis system on vehicle level. Inspection of control electronics during preventive maintenance => normally only records if module is damaged or failed. Measuring and recording of electrical characteristic during preventive maintenance or repair.


ditto

PC1.4 Sensors The sensor measuring voltage, current, temperature, pressure, speed of a certain circuit

Sensor is linked to o Traction converter PC1.0 o Sensors PC1.4 o Cooling system (sensor)

PC1.5 o Contactors PC1.6 o Others PC1.7

PC1.4 is available. Data are available from the Control Electronic PC1.3 which sent the information to the superior diagnosis system on vehicle level.


ditto


@






PC1.5 Cooling system The cooling circuit is a self-enclosed system and includes all those components required to force-cool the electrical components of the traction converter.

Cooling system is linked to o Traction converter PC1.0 o Sensors PC1.4 o Contactors PC1.6 o Indirect Control

electronic PC1.3

PC1.5 is available. o Vibration monitoring not available No permanent monitoring of leakages in the cooling system. Data are available from the Control Electronic PC1.3 which sent the information to the superior diagnosis system on vehicle level. Inspection of cooling system during preventive-/corrective maintenance. Measuring and recording of hydraulic and electrical characteristic during preventive or corrective maintenance or repair according to the operation manual.

Considered as example of most important mechanical interface in traction chain

ditto

PC1.6 Contactors The contactor closes and opens a circuit

Contactor is linked to o Traction converter PC1.0 o Gate Drive Unit PC1.1 o Power modules PC1.2 o Control electronics PC1.3 o Sensors PC1.4

PC1.6 is available. o Switching On/Off cycle monitoring not available

on contactors Data are available from the Control Electronic PC1.3 which sent the information to the superior diagnosis system on vehicle level. Inspection of contactors during preventive-/corrective maintenance. Measuring and recording of mechanical and electrical characteristic during preventive or corrective maintenance or repair .

ditto

PC2 Rail – wheel contact

Transmission of weight force between running surfaces of wheel and rail and guiding forces between wheel flange and rail by means of form fit. Transmission of different forces between the running wheel and the fixed rail by means of friction:

Traction force Brake force

Running surface is integral part of the wheel PC2.1

Speed is measured and recorded by speedometer system SS1

Wheel slip and slide is measured and controlled by wheel slip / slide protection system PC2.7

PC2 is available Data are available from wheel slip / slide

protection system PC2.7 Data are available from speedometer system SS1

o Data currently not available for DfX demonstrator

OB1 - example of most important mechanical interface in traction chain

ditto


@






Friction forces due to relative movements (lateral, rotation round the z-axis) between wheel and rail

PC2.1 Wheel (profile) Carries and guides the wheel set in the track and transmits traction forces, brake forces and guiding forces to the rail.

Wheel contains running surface PC2

Wheel profile combined with the rail profile defines substantially the running behaviour

Wheel is (mostly) fitted onto the axle PC2.2 by means of press fit

o PC2.1 is available o Derailment detection not available on locomotive o Stability monitoring not available on locomotive o Wear monitoring not available on locomotive

Wear is currently monitored during preventive maintenance by means of measuring key measures of the profile or recording the wheel profile electronically and measuring wheel diameter, out of round, etc.. Data available in depots / workshops in form of attachments to protocols (in paper or electronically)

Considered as example of a component of the most important mechanical interface in traction chain

ditto

PC2.2 Axle Torque and force transmission between wheels, gearbox and journal bearings. In case of the axle hung gearbox of the locomotive, carries and guides the gearbox. In connection with the traction chain the axle is a “solid” link between the wheels..

Wheels PC2.1 are press fitted on the axle

Journal bearings PC2.3 sit on the axle

Interface to gearbox PC3.x by means of bearings and / or press fitted gearwheel

N/A Considered as a “solid” linking component in the traction chain, with a service life >= service life of the vehicle.

ditto

PC2.3 Journal bearing

Bearing the axle Journal bearing is fitted on the axle PC2.2 and sits in the axle box PC2.4,

o Hot box detection not available on locomotive o Vibration monitoring not available on

locomotive PC2.3 is available

Condition of bearing is currently monitored during preventive maintenance by means of inspections on the whole bearing and inspections of bearing parts while overhauling the bearing. Data available in depots / workshops in form of reports.

Considered as example of a component of the traction chain

ditto


@






PC2.4 Axle box Houses the journal bearing PC2.3 and transmits forces.

The axle box is connected to the bogie frame PC 2.11 by: Primary spring PC 2.8 Primary damper PC2.10 Primary traction rod

PC2.9


ditto

PC2.5 Wheel flange lubricating system

Lubricates wheel flange to reduce flange wear

Spray nozzle normally fitted to a support on the bogie frame PC2.11.

Position has to be such, that lubricant gets applied to the wheel flange only, PC2.1.

Lubricant on running surface PC2 reduces friction coefficient thus reducing transmission of traction forces

PC2.5 is available Functional checks during operation and

preventive maintenance => normally no records Check of application zone during preventive

maintenance => normally no records

Considered as example of a component that has influence to the traction chain

ditto

PC2.6 Sanding system Distributes sand to the running surface of the rail to improve the adhesion coefficient.

Sand tube normally fitted to a support on the bogie frame PC2.11.

Position has to be such, that sand reaches contact zone between wheel and rail PC2

PC2.6 is available Functional checks during operation and

preventive maintenance => normally no records Check amount of sand and application zone

during preventive maintenance => normally no records


ditto

PC2.7 Wheel slip/slide protection system

Controls slip between wheel and rail to maximise friction coefficient and to minimise wheel wear and prevents wheel from blocking in case of braking

Sensors measuring the number of resolution are fitted on the axle box PC2.4 or in traction motor PC3.x

Sensors transmit signal to WSP electronics by means of cables.

PC2.7 is available Data currently not available for DfX

demonstrator


ditto


@






PC2.8 Primary spring Suspension between axle box and bogie frame

Primary spring rests on the axle box

PC2.4 supports bogie frame

PC2.11 transmits also forces in

lateral & longitudinal direction

o No permanent monitoring of springs available PC2.8 is available Inspection of springs during preventive

maintenance => normally only records if spring is damaged or failed

Measuring and recording of spring characteristic during preventive maintenance. Data (diagrams) available in depots / workshops in form of attachments to protocols (in paper or electronically)


ditto

PC2.9 Primary traction rod with rubber bearings

Longitudinal (and some times lateral)guidance of axle box / wheel set

Primary traction rod is linked by means of rubber bearings to: the axle box PC2.4 the bogie frame PC2.11

o No permanent monitoring of traction rod available

PC 2.9 is available Inspection of traction rods during preventive

maintenance => normally only records if rubber bearing or rod (body) is damaged or failed


ditto

PC2.10 Primary damper Damping of vertical movements between bogie frame and axle box.

Primary damper is linked by means of “rubber” bearings to: the axle box PC2.4 the bogie frame PC2.11

o No permanent monitoring of dampers available on the locomotives

PC2.10 is available Inspection of dampers during preventive

maintenance => normally only records if damper is leaking, is damaged or failed

Measuring and recording of damper characteristic during preventive maintenance. Data (diagrams) available in depots / workshops in form of attachments to protocols (in paper or electronically)


ditto


@






PC2.11 Bogie frame In connection with the traction chain the bogie frame is a “solid” link to form a bogie

The bogie frame is linked to:. Wheel flange lubricating

system, PC2.5 Sanding system, PC2.6 Primary springs, PC2.8 Primary traction rod,

PC2.9 Primary damper, PC2.10 Secondary springs,

PC2.12 Secondary vertical

dampers, PC2.13 Secondary lateral

dampers, PC2.14 Secondary yaw dampers,

PC 2.15 Secondary traction rod,

PC 2.16 Torque reaction link to

traction motor, PC3.1


ditto

PC2.12 Secondary spring Suspension between bogie and car body

Secondary spring rests on the bogie frame,

PC2.11 supports locomotive (car)

body, PC2.17 transmits also forces in

lateral & longitudinal direction

o No permanent monitoring of springs available PC2.12 is available Inspection of springs during preventive

maintenance => normally only records if spring is damaged or failed



ditto


@






PC2.13 Secondary vertical damper

Damping of vertical movements between car body and bogie

Secondary vertical damper is linked by means of “rubber” bearings to: the bogie frame, PC2.11 the locomotive (car)

body, PC2.17






ditto

PC2.15 Secondary yaw damper

Damping of yaw movements between car body and bogie

Secondary yaw damper is linked by means of “rubber” bearings to: the bogie frame, PC2.11

the locomotive (car) body, PC2.17






ditto

PC2.16 Secondary traction rod with rubber bearings

Flexible traction and brake force transmission between bogie and car body

Secondary traction rod is linked by means of rubber bearings to: the bogie frame, PC2.11 the locomotive (car)

body, PC2.17

o No permanent monitoring of traction rod available

PC2.16 is available Inspection of traction rods during preventive

maintenance => normally only records if rubber bearing or rod (body) is damaged or failed

Measuring and recording of bearing characteristic during preventive maintenance. Data (diagrams) available in depots / workshops in form of attachments to protocols (in paper or electronically)


ditto


@






PC2.18 Coupling device: Pair of buffers and sprung screw coupling or (semi) automatic coupler

Flexible traction and brake force transmission between two railway vehicles.

Coupling device is: built on to the

locomotive (car) body, PC2.17

linked to the coupling device of the next vehicle

o No permanent monitoring of coupling devices available on the locomotives

PC2.18 is available Inspection of coupling devices during preventive

maintenance => normally only records if coupling device is damaged or failed


Considered as example of a component that is part of the traction chain

ditto

PC3 Traction motor & gearbox (incl. bogie integration)

The traction motor used to rotate the axle of an electric or diesel electric locomotive. It is mounted close to the axle and transmits power through a gearbox. The 3-phase traction motor is compact, robust and shall has a high reliability.

Traction motors are integral part of the traction chain Interface to the: o Bogie frame o traction converter (PC1,

PC1.1, PC1.2) o Sensor (PC1.4)

motor temperature sensors speed sensors

o Control Electronics (PC1.3)

PC3 is available. Data are available from the Control Electronic PC1.3 (indirect from PC1.4) which sent the information to the superior diagnosis system on vehicle level. Inspection of traction motor during preventive-/corrective maintenance. Measuring and recording of electrical characteristic during preventive or corrective maintenance or repair according to the operation manual. o Vibration monitoring not available on

locomotive o Standby time monitoring (DC-link charged and

pulsing) is not available on locomotive o Switching On/Off time monitoring is not

available for motor

OB1 - example of important electro-mechanical system in traction chain

ditto

PC3.1 Torque reaction link of traction motor

Flexible torque reaction link between traction motor and bogie frame

Torque reaction link interface to: o Bogie frame o Traction motor o Gear box

PC3.1 is available. Inspection of traction motor during preventive-/corrective maintenance. Measuring and recording of characteristic during preventive or corrective maintenance or repair. o no resonance/oscillation measurements are

available o no measurements on locomotive for stress due


ditto


@






vibration and shock PC3.2 Traction motor

monitoring and sensors

Traction motors are equipped with sensors for monitoring the rotor speed and the stator temperature. The motor speed sensor provides the input signal for the speed and traction effort control to the drive control unit.

Traction motors monitoring and sensors are part of the traction chain Interface to the: o Bogie frame PC2.11 o traction converter (PC1,

PC1.1, PC1.2) o Control Electronics

(PC1.3)

PC3 is available. Data are available from the Control Electronic PC1.3 (indirect from PC1.4) which sent the information to the superior diagnosis system on vehicle level. Inspection of traction motor during preventive-/corrective maintenance. Measuring and recording of electrical characteristic during preventive or corrective maintenance or repair according to the operation manual. o Vibration monitoring not available on

locomotive o Standby time monitoring (DC-link charged and

pulsing) is not available on locomotive o Switching On/Off time monitoring is not

available for motor


ditto

PC4 Line voltage system

Voltage source from which the vehicle takes its traction energy and, in braking mode, uses for energy recovery.

Excluded from demonstrator to reduce complexity, all other subsystems of the traction chain will not be considered

n/a

PC5 Transformer The main transformer is used for converting the line voltage into a voltage level that can be conveniently handled by modern power electronic devices without connecting semi-conductors in series, and be supplied to the traction motors without further transformation.

ditto n/a


@






PC6 Auxiliary converter

Auxiliary converter converts either direct or alternating voltage from the contact line, main transformer, heating train line or DC-link into a direct or alternating voltage. The output signal may have either a variable or fixed voltage and frequency. AUX are used to charge vehicle batteries, to supply electronics, to drive ventilators and compressors.

ditto n/a

PC7 Other subsystems (Brake resistors, filters etc)

ditto n/a

PC8 PEID’s PEID’s shall gather and provide various data about the behaviour of the loc and its main components in operation

PEID’s are interfaced with the TCMS via a bus system

Various kinds of PEID’s (e.g. sensors) are already installed and are considered within the demonstrator. Most probably no additional or newly designed PEID’s will be necessary.

OB1 – only already installed PEID’s are included (see left)

FU2



@







SS1 Train Control and Management System (TCMS)

The vehicle control and communication system of the locomotive

Powerful serial bus systems are used for information transfer between traction vehicles (train control level) and between the components of the vehicle itself (vehicle control level).

The MITRAC® vehicle and train control system consists of a multi-computer architecture for the functions on train and vehicle control level as well as controllers for the drive control level. The latter are designed for specific traction converter requirements such as high processing speed. The processing of train and vehicle functions is realised in the vehicle and train control software, which is a control application running on the Display and Control Processing Unit (DCPU) hardware.

Excluded from demonstrator TCMS manages some of the needed field data, which will be gathered within the Field Info Database

FU2

SS2 Diagnostic System

The diagnostic system serves both for visualising the main locomotive operating values and for diagnostic purposes.

Diagnostic facilities are spread over all train and vehicle functions and are hierarchically structured to train, vehicle and subsystem levels.

On the subsystem level, diagnostic messages are generated if disturbances, faults or failures occur in the monitored processes. They are transferred to the next hierarchic level, the vehicle diagnostic system, to be stored in a non-volatile memory. The stored data are represented on displays in the driver’s cab (or in the coaches) for two target groups: operational personnel like locomotive drivers (operational diagnostics) and maintenance personnel (maintenance diagnostics).

Excluded from demonstrator Diagnostic system holds some of the needed field data, which will be gathered within the Field Info Database

FU2

SS3 Maintenance management system

The program BTRAM (based on MAXIMO resp. VIPSCARSIS) is used within BT as Configuration and Maintenance Management

Interfacing can be developed to PDM, MRP/ERP systems

Configuration Management is used to described the process of tracking the maintenance and repair history of vehicles and their registered component parts throughout the lifecycle

Excluded from demonstrator Maintenance Mgt system manages some of the needed field data, which will be gathered within the Field Info Database

FU2


@






SS4 Field info database

Database manages all kind of field data captured by CM/CBM, FRACAS, Service and/or PEID’s and their aggregation into information

Provides necessary input data / information to DfX Transformer SS6

A single system for all kind of field data is not available. Currently the field data is mainly managed contract specific.

• Condition Monitoring / Condition Based Maintenance

• Diagnosis System • Event Recorder • Maintenance Management Systems • Inspection Information • Failure Reporting Analysis and Corrective

Action System (FRACAS)

OB2 – Field info database makes first aggregation of field data

FU1

SS5 Other information sources

Provision of additional necessary information on product, lessons-learnt, standards, etc.

Provides necessary input data / information to DfX Transformer SS6

Available are • PDM system • Lotus Notes databases • eBoK’s (Intranet) • Internet • and other similar data & information sources

(DfX basic data, standards, etc.)

OB2 – sources are providing needed data & information

FU3

SS6 DfX Transformer The DfX Transformer accesses all specified input data and information sources, processes this data & information into DfX knowledge according the defined transformation methods, provides the specified DfX knowledge to PDKM system

Transforms data from Field Info Database SS4 & Other Info Sources SS5 into knowledge managed by PDKM SS8, and is supported by Decision Support System SS7

Not available It has to be considered that the input data is based on different types of configurations, e.g. field data on ‘as-maintained’ and design data on ‘as-designed’.

OB2 – further aggregation of data & information OB3 – supports transformation process

FU4


@






SS7 Decision support system

The Decision Support System supports specialist engineer in the transformation process by aggregating necessary data & information into deciding basis & decision proposals

Support transformation process interfacing to DfX Transformer SS6

Not available OB4 – supports decision making process

FU5

SS8 PDKM environment

PDKM environment shall incorporate KM functionalities to manage the knowledge provided by the DfX transformer, structured according to a predefined work breakdown structure (WBS) with various vehicle, system and location elements.

Manages the output of transformation process from DfX Transformer SS6

PDM System (UGS Teamcenter 2.0) is available, but a specific KM functionality / system is not available.

OB5 – supports management of DfX knowledge

FU6



@





Technologies/Physical components/Systems/Actors involved



Related to objective ID

FU1 Field info database to manage all kind of field data

Database shall manage all kind of field data captured by CM, FRACAS (VIPSCARSIS, MAXIMO), Service and/or PEID’s and shall standardize this electronic data for transfer to the demonstrator (see Use Case Diagram).

Collection of field data related to functions, systems and / or components, which are relevant for a function, as: • date, time and location when / where

failure occurred • operating circumstances • environmental conditions • symptoms • effect on train service • operator's actions after failure • primary / secondary fault assignment • circumstances under which fault was

first become apparent • operating distance, time, cycles, since

it was put into service

Provide standardized field data related to function, systems and / or components, which are relevant for the design of a function, covering detailed information about: • date, time and location when / where

failure occurred • operating circumstances • environmental conditions • circumstances under which fault was

first become apparent • symptoms • effect on train service • operator's actions after failure • operating distance, time, cycles, since it

was put into service • primary / secondary fault assignment

Input data to FU4 and FU5

C1 Actors are governing the field info database according P&O definition

C2 Data input is activated by the communication unit of TCMS

C3 Data output is activated by requests of the DfX Transformer

A great number of event data is recorded in Diagnosis Systems (e.g. GSM-R, MITRAC Remote), but those data are not linked to failure occurrences which are stored in the MAXIMO data base Involved actors are • Operator • Maintainer • Service organisation /

commissioning engineers

• DfX specialist engineer

Development of proven design, standardized assessment of recorded field data to identify repeat defects, systematic problems and the root causes such that corrective actions can be established. Detailed information of functions, systems and / or components which did not cause problems aren't available. Field experiences about functions are totally missing. Field data are only gathered during warranty period and in case problems / failures have been detected which are relevant for validation of the vehicle.

Medium OB2

FU2 Read in different kind of field data from different sources

Demonstrator shall accept all kind of field data captured and processed by field data base and from other sources as: CM/CBM, FRACAS (VIPSCARSIS, MAXIMO), Service and/or PEIDs and shall aggregate this electronic data into appropriate information (see Use Case Diagram).

Field data from FU1 and other sources related to function, systems and / or components, which are relevant for a function

Process input data for further steps. Check data for plausibility as far as

possible.

C4 Activation by DfX Demonstrator requiring information

Data exchange technologies between different kind of systems & tools

All kind of field data shall be accessible for transformation process

High OB2

FU3 Read in additional necessary information on product, lessons-learnt, standards, etc.

Allow the access of the DfX Transformer to electronic information in PDM, Lotus Notes databases, EboK’s (Intranet), Internet (see Use Case Diagram).

a) Lessons learned – structured according WBS – from their different engineering phases of existing platform projects, related to functions, systems and / or components

b) Requirements related to functions - customer specific requirements - standards and / or guidelines - safety specific requirements

Process input data for further steps. Check data for plausibility as far as

possible.

C4 Activation by DfX Demonstrator requiring information

Data exchange technologies between different kind of systems & tools

a) Enhancement of explicit Know-how, "lessons learnt" information is incorporated in functions of new vehicles, reduce or eliminate possible failure mechanisms early in the design phase where they may be easier

Medium OB2


@








- homologation requirements (defined by notified bodies) - internal requirements

to locate and correct; share of experience among different projects

b) All different requirements are taken into account during the design phase

FU4 Transformation of data into DfX knowledge

Transformer processes, semi-automatically DfX knowledge following defined transformation methods under governance of specialist engineer. Transformer provides the DfX knowledge to PDKM system (see Use Case Diagram). DfX knowledge shall be periodically updated if additional field data or other information is available. For the aggregation and transformation process the different configuration (as-designed, as-built, as-maintained) of the input data shall be considered appropriately. The tool supporting the transformation process shall be easy to use and preferably integrated with the other tools in a portal.

Selection off all relevant data for each function, system or component Output data from FU2 and FU3

Provision of DfX knowledge to PDKM system Input to FU6

C5 DfX Specialist Engineers are governing the DfX Transformer according P&O definition

C6 Decision support system requires information and/or provides necessary deciding basis & decision proposals

Involved actors: • DfX Specialist Engineers DfRAM/LCC Provide reliability value of functions, systems and / or components and dependency on / influence to (e.g. min / max values) due to: - operation distance - operating time (driving-

and stand by mode) - operating cycles - minimal, nominal and

maximum load - ambient temperature - preventive maintenance DfSafety Provide information

about system conditions – same as for RAM/LCC – that are relevant for the BT safety hazards:

- Asphyxiation - Burns - Biological hazards - Chemicals - Collision - Crush - Cut - Derailment - Fall - Electrocution - Impact - Medical equipment

incompatibility - EMC (e.g. interference

Central functionality of DfX demonstrator The pure calculated or measured reliability figures are often not very meaningful without knowing on which information the values are based e.g. field data and / or calculation model. Knowing the impact of different factors on the reliability supports the selection of systems / components in the design process

High OB3


@








with signalling system) DfEnvironment:

Provide information of products, systems and components regarding - Material choice (BT list

of prohibited & restricted material) considering the categories ‘prohibited material’, ‘restricted material’, ‘recycled material’ and ‘renewable material’

- End-of-use aspects (recycling, marking, take back obligations, disposal cost)

- Energy related issues (total energy use, energy solutions)

- Emissions (e.g. noise) - Energy consumption - EMC behaviour

FU5 Decision Support to support transformation

The Decision Support System shall aggregate necessary data & information and provide appropriate deciding basis & decision proposals to the DfX transformation process.

The necessary input shall be provided by the DfX Transformer FU4

Provision of appropriate deciding basis & decision proposal to DfX Transformer FU4

C5 DfX Specialist Engineers are governing the Decision Support Ssystem according P&O definition

C7 DfX Transformer provides information and/or requires necessary deciding basis & decision proposals

Involved actors: • DfX Specialist Engineers

The tool supporting the decision making process shall be easy to use and preferably integrated with the other tools in a portal.

The transformation process requires various kind of decisions. Therefore a support is needed to provide the DfX Specialist with needed deciding basis and / or decision proposals.

Low OB4


@








FU6 PDKM functionalities to manage DfX knowledge

PDKM functionalities shall manage the knowledge provided by the DfX transformer, structured according to a predefined work breakdown structure (WBS) with various vehicle, system and location elements.

All kind of DfX knowledge Output of FU4

Accessibility of DfX knowledge for all interested parties

C8 Actors are accessing and governing according P&O definition

C9 WBS for structuring of DfX knowledge

Involved actors: • DfX Specialist Engineers • Engineer / Designer

The KM functionality shall be integratable into commercially available PDKM systems (like SAP PLM, UGS TC). The KM functionality shall be easy to use with easy & quick access and search functionalities on the needed DfX knowledge.

The transformed DfX knowledge must be accessible to all interested parties (mainly engineers/designers) Integrity of DfX knowledge must be managed.

Medium OB5



@



@

The KM functionality shall be integratable

into commercially available PDKM

systems (like SAP PLM, UGS TC).

The KM functionality shall be easy to use

with easy & quick access and search

functionalities on the needed DfX knowledgeFU5 (A10)

Decision Support to support transformation

FU4 (A10)

Transformation of data into DfX knowledge

B

C

D

E

Provision of DfX knowledge to PDKM system

C5 DfXSpecialist

Engineers are governing the

DfX Transformer according P&O definition

C6 Decision support system requires info-

rmation and/or provides necessary

deciding basis& decision proposals

DfX Specialist Engineers* DfRAM/LCC* DfSafety* DfEnvironment

Provision of appropriatedeciding basis & decisionproposal to DfX Transformer FU4

C5 DfX Specialist

Engineers are governingThe Decision Support

Ssystem according P&O definition

C7 DfX Transformer provides information

and/or requires necessary deciding

basis & decision proposals

DfX Specialist Engineers

The tool supporting the decision making

process shall be easy to use and preferably integrated with the other

tools in a portal.

FU6 (A10)

PDKM functionalities to manage DfX knowledgeAll kind of DfX

knowledge DfX knowledge

Accessibility of DfX knowledge for all interested

parties

C8 Actorsare accessing and governing according P&O

definition

C9 WBS for structuring of

DfX knowledge

* DfX Specialist Engineers* Engineer / Designer


@

10.9 A10 – Additional information and illustrations related to the BT-LOC demonstrator A) Traction chain of el. locomotive:

B) Train Control and Management System

TCMS includes • Sensors • Vehicle bus • Diagnosis system • External communication via GSM


@

C) Work Breakdown Structure (WBS)

WBS is the main form how to structure information in BT LOC

Activities

Sub-Activities

Workpackages

Deliverables

Vehicle

System

Location

Group

LOC/E

Site

Site and Project

03.00 Vehicle

03.00.01 Vehicle Administration & Lead

03.00.02 Vehicle Concepts

03.00.02/03.01 Reliability, Availability03.00.02/03.02 Product Safety03.00.02/03.07 Environment03.00.02/03.10 Maintainability, Life Cycle Cost

03.00.03 Vehicle Integration

03.00.04 Vehicle Support

03.00.05 Vehicle Training & Documentation

03.02 System Carbody Fittings

03.04 System Power Supply

03.05 System Propulsion

03.05.01 Drive Systems

03.05.02 Traction Converter

03.05.04 Propulsion Cooling Systems

03.05.06 Propulsion Controls

03.06 System Auxiliaries

03.08 System Interiors

03.09 System On-Board Controls

03.13 System HVAC

03.20 Loco complete, Cabling & Piping

03.21 Location Bogie

03.22 Location Cab

03.23 Location Carbody

03.24 Location Machineroom

03.24.01 Machineroom Arangement

03.24.02 Machineroom Cubicles

03.24.03 Compressed Air Cubicle

03.25 Location Underframe

03.26 Location Roof


@


DATE 05. May 2005


VERSION NO. 1.3






SUBMITTED (author(s)) Andrea Matta 26.04.2005

VU (WP Leader) POLIMI


Written by: Andrea Matta, POLIMI Maurizio Tomasella, POLIMI

PROMISE Demonstrator A11 POLIMI (BOL)


@

Revision History

Date (dd.mm.yyyy)





26.04.05 1.2 Maurizio Tomasella, Andrea Matta New version of the document, based on version 0.2 received from Carl Christian. To be submitted SINTEF.


Author(s)’ contact information Name Organisation E-mail Tel Fax Maurizio Tomasella POLIMI [email protected] +39.02.2399.4892 Andrea Matta POLIMI [email protected] +39.02.2399.4891


@

11 A11 POLIMI (BOL) – Definition of the demonstrator


PROMISE WPA11/BOL/Adaptive Production. The demonstrator is a software for the support of the decision on the selection of the best change action to introduce in the production system related to the cylinder head of the FIAT multi jet diesel engine.

The demonstrator provides robust support to the decision maker in deciding how to modify the production system layout, technology and equipment to satisfy the new product and/or process requirements. In more detail,. the possible adaptation actions are:

• Introduction of new machines in the production line.

• Introduction of new part transporters in the production line.

• Introduction of additional WIP buffers in the production line.

• Introduction of new work operators in the production line.

• Modification of process parameters.

• Modification of the number of fixtures flowing in the production line.

This Demonstrator closes the loop between MOL/EOL and BOL. Indeed the information collected from the field during the MOL and EOL phases is transformed into knowledge which, in turn, generates new ideas for improving the product. The improvement of the product may cause changes of the related production systems often costly or sometimes infeasible. The demonstrator creates the conditions for closing this loop.


11.2 A11 – Objectives (OBs) of the Demonstrator ID Objective (one per ID) Describe why OB1 Production system reconfiguration

The optimal adaptation of the production system is important because it allows the continuous improvement of the product.

OB2 What if analysis The What If analysis is important to quantify the impact of a potential modification of the product and/or the process. Indeed the product/process designer often considers a large variety of alternative modifications that are difficult to assess in terms of performances obtained at the factory shop floor level. For example it is not possible, without such an analysis, to properly assess the impact of all these alternatives in terms of system throughput, production cost, etc.



@




BOL MOL EOL

AC1 Production system designer

Internal He is responsible for the design of the production system and directly uses the decision support software, i.e. the demonstrator. He proofs the feasibility of new systems configurations by using the demonstrator, and chooses the adaptations to be implemented into the present production system, i.e. the new system configuration.

HIGH X

AC2 Product designer

Internal He designs the product, e.g. he modifies the product following what has been gathered from the field. He evaluates the impact of the design modifications on the production system performance, both in terms of technical and economic performance, directly before the implementation of such modifications.

MEDIUM X

AC3 Process designer

Internal He designs the production process, e.g. he modifies the production process following what has been gathered from the field. Then he can make the same evaluations as the product designer, but concerning process modifications instead of product ones.

MEDIUM X

AC4 Production planner

Internal He manages the production system, e.g. plans how to produce the products. He is involved in the adaptation of the production system to the new requirements because he is the one who can directly measure the implications of different potential system configurations on the production capacity offered by each configuration to the firm, thus allowing the production planner to evaluate different plans and modes of use directly comparing the system performance to the market demand. This is also enabled by the possibility of having this demonstrator and of using it in everyday practice.

LOW X



@







No physical component needed for A11 Demonstrator, which is simply a software. This software will be able to simulate different configurations for the production system of anyone of the products considered in PROMISE (though the demonstrator will be developed basically considering the case of the cylinder head of the FIAT

multijet diesel engine). The same software will provide support for decision making to actors described in section 2.3.



@







SS1 PROMISE DSS The full functionality of the PROMISE Decision Support System, as to be still defined inside task TR9.1 from WPR9.

See Table 6 and section 2.7 for details.

It shall be the PROMISE official Decision Support System.

OB1, OB2

SS2 A11 Demonstrator

The demonstrator provides robust support to the decision maker in deciding how to modify the production system layout, technology and equipment to satisfy the new product and/or process requirements. In more detail,. the possible adaptation actions are:

• Introduction of new machines in the production line.

• Introduction of new part transporters in the production line.

• Introduction of additional WIP buffers in the production line.

• Introduction of new work operators in the production line.

• Modification of process parameters.


Software tools for the configuration of production systems have already been developed by POLIMI. The software for A11 demonstrator will be developed.

OB1, OB2 FU4


@






• Modification of the number of fixtures flowing in the production line.

In particular, with regard to Table 6, its functionality is mainly FU4.

SS3 PROMISE PDKM- Data Base

With regard to Table 6, its functionalities are mainly FU1 and FU2.


It shall be the PROMISE official PDKM system. OB1, OB2 FU1, FU2

SS4 SDKM- Data Base

With regard to Table 6, its functionality is mainly FU3.


Some kind of Data Base for production systems is now under construction inside POLIMI for other purposes.

OB1, OB2 FU3



@









FU1 To receive data concerning the product, with or without modification with respect to the present product.

Information request, from FU4. O1-product data, to FU4. C1- Internal Capacity. C2- Budget constraint.

M1-SS3. HIGH OB1, OB2

FU2 To receive data concerning the process, with or without modification with respect to the present process.

Information request, from FU4. O1-process data, to FU4. C1- Internal Capacity. C2- Budget constraint.


FU3 To receive data concerning the production system, with or without modification with respect to the present system.

Information request, from FU4. O1-production system data, to FU4. C1- Internal Capacity. C2- Budget constraint.


FU4 To optimize the configuration of the production system, adapting it to product and process modifications..

I1-product data, from FU1. I2-process data, from FU2. I3-production system data, from FU3. I4-Performance for the configuration evaluated, from FU5.

O1-A feasible configuration for the production system.

C1- Internal Capacity. C2- Budget constraint.

M1-AC1,AC2,AC3,AC4. M2- Configuration rules.

HIGH OB1

FU5 To evaluate the performance of the production system.

I1- production system configuration, from FU4.

O1- Performance for the configuration evaluated, to FU4.

C3- Maximum computational time.

M1- Evaluation tools (e.g. analytical Methods, simulation).

HIGH OB2



@


FU1 (A11)

To receive data concerning the product,

with or without modification with respect

to the present product

FU2 (A11)

To receive data concerning the process,

with or without modification with respect to the present process

Process data

C1Internal Capacity

C2Budget

constraint

SS3PROMISE

PDKM – Data base

FU3 (A11)

To receive data concerning the production

system, with or without modification with respect

to the present system

SS4 SDKM –

Data base

FU4 (A11)

To optimize the configuration of the production system,

adapting it to product and process modifications

C1Internal

Capacity

C1Internal

Capacity

C2Budget

constraint

C2 Budget constraint

SS3PROMISE PDKM –

Data base

Production system data

Product data

A feasible configuration for the production system.

C1 Internal Capacity

C2 Budget constraint

Configurationrules

AC1 Production system designerAC2 Product designerAC3 Prosess designerAC4 Production planner

FU5 (A11)

To evaluate the performance of the production system

Performance for the configuration

evaluated

C3 Maximum computational

time

Evaluation tools (e.g. analytical Methods,

simulation).

Information request


@


Appendix B: Application Scenarios

Copyright © PROMISE Consortium 2005 Page 238

@


@

Appendix B: Application scenarios In this appendix, all the application scenarios developed by the partners for the first deliverable DR3.1 of work-package R3 are presented. Where there are discrepancies between the Demonstrator and the Application Scenario, the demonstrator-document overrides all aspects of the scenario. 1 APPLICATION SCENARIO DESCRIPTION A1 CRF EOL.....................................................................243

1.1 TECHNICAL ISSUES A1...............................................................................................................................247 1.2 BUSINESS/ECONOMICAL ISSUES A1 ...........................................................................................................250 1.3 VALUE-CHAIN ISSUES A1 ..........................................................................................................................252 1.4 ENVIRONMENTAL ISSUES A1 .....................................................................................................................253 1.5 SOCIAL ISSUES A1 .....................................................................................................................................254

2 APPLICATION SCENARIO DESCRIPTION A2 CATERPILLAR EOL ................................................257 2.1 TECHNICAL ISSUES A2...............................................................................................................................263 2.2 BUSINESS/ECONOMICAL ISSUES A2 ...........................................................................................................266 2.3 VALUE-CHAIN ISSUES A2 ..........................................................................................................................268 2.4 ENVIRONMENTAL ISSUES A2 .....................................................................................................................269 2.5 SOCIAL ISSUES A2 .....................................................................................................................................270

3 APPLICATION SCENARIO DESCRIPTION A3 BIBA/INDYON EOL ..................................................273 3.1 TECHNICAL ISSUES A3...............................................................................................................................278 3.2 BUSINESS/ECONOMICAL ISSUES A3 ...........................................................................................................281 3.3 VALUE-CHAIN ISSUES A3 ..........................................................................................................................283 3.4 ENVIRONMENTAL ISSUES A3 .....................................................................................................................285 3.5 SOCIAL ISSUES A3 .....................................................................................................................................286 3.6 ANNEX A3.................................................................................................................................................286

3.6.1 Recycling of Car Bumpers with RFID Technology as an Example for A3...........................................286 3.6.2 Real Time Decision Support ................................................................................................................288 3.6.3 Conclusion and Outlook.......................................................................................................................291

4 APPLICATION SCENARIO DESCRIPTION A4 CRF MOL....................................................................295 4.1 TECHNICAL ISSUES A4...............................................................................................................................299 4.2 BUSINESS/ECONOMICAL ISSUES A4 ...........................................................................................................303 4.3 VALUE-CHAIN ISSUES A4 ..........................................................................................................................306 4.4 ENVIRONMENTAL ISSUES A4 .....................................................................................................................307 4.5 SOCIAL ISSUES A4 .....................................................................................................................................308

5 APPLICATION SCENARIO DESCRIPTION A5 CATERPILLAR MOL ...............................................311 5.1 TECHNICAL ISSUES A5...............................................................................................................................316 5.2 BUSINESS/ECONOMICAL ISSUES A5 ...........................................................................................................319 5.3 VALUE-CHAIN ISSUES A5 ..........................................................................................................................321 5.4 ENVIRONMENTAL ISSUES A5 .....................................................................................................................322 5.5 SOCIAL ISSUES A5 .....................................................................................................................................323

6 APPLICATION SCENARIO DESCRIPTION A6 FIDIA ...........................................................................327 6.1 TECHNICAL ISSUES A6...............................................................................................................................330 6.2 BUSINESS/ECONOMICAL ISSUES A6 ...........................................................................................................333 6.3 VALUE-CHAIN ISSUES A6 ..........................................................................................................................334 6.4 ENVIRONMENTAL ISSUES A6 .....................................................................................................................335 6.5 SOCIAL ISSUES A6 .....................................................................................................................................336

7 APPLICATION SCENARIO DESCRIPTION A7 MTS MOL ...................................................................339 7.1 TECHNICAL ISSUES A7...............................................................................................................................343 7.2 BUSINESS/ECONOMICAL ISSUES A7 ...........................................................................................................346 7.3 VALUE-CHAIN ISSUES A7 ..........................................................................................................................348 7.4 ENVIRONMENTAL ISSUES A7 .....................................................................................................................349


@

7.5 SOCIAL ISSUES A7 .....................................................................................................................................350 8 APPLICATION SCENARIO DESCRIPTION A8 WRAP MOL................................................................353

8.1 TECHNICAL ISSUES A8...............................................................................................................................357 8.2 BUSINESS/ECONOMICAL ISSUES A8 ...........................................................................................................359 8.3 VALUE-CHAIN ISSUES A8 ..........................................................................................................................360 8.4 ENVIRONMENTAL ISSUES A8 .....................................................................................................................362 8.5 SOCIAL ISSUES A8 .....................................................................................................................................363

9 APPLICATION SCENARIO DESCRIPTION A9 INTRACOM MOL.............................................................................367 9.1 TECHNICAL ISSUES A9...............................................................................................................................372 9.2 BUSINESS/ECONOMICAL ISSUES A9 ...........................................................................................................374 9.3 VALUE-CHAIN ISSUES A9 ..........................................................................................................................377 9.4 ENVIRONMENTAL ISSUES A9 .....................................................................................................................378 9.5 SOCIAL ISSUES A9 .....................................................................................................................................379

10 APPLICATION SCENARIO DESCRIPTION A10 BOMBARDIER BOL ...............................................384 10.1 TECHNICAL ISSUES A10.............................................................................................................................390 10.2 BUSINESS/ECONOMICAL ISSUES A10 .........................................................................................................395 10.3 VALUE-CHAIN ISSUES A10 ........................................................................................................................397 10.4 ENVIRONMENTAL ISSUES A10 ...................................................................................................................399 10.5 SOCIAL ISSUES A10 ...................................................................................................................................400

11 APPLICATION SCENARIO DESCRIPTION A11 POLIMI BOL ............................................................403 11.1 TECHNICAL ISSUES A11.............................................................................................................................408 11.2 BUSINESS/ECONOMICAL ISSUES A11 .........................................................................................................411 11.3 VALUE-CHAIN ISSUES A11 ........................................................................................................................413 11.4 ENVIRONMENTAL ISSUES A11 ...................................................................................................................414 11.5 SOCIAL ISSUES A11 ...................................................................................................................................415


@

DELIVERABLE NO Input to DR 3.1, Relates to WP A1

WORK PACKAGE NO WP R3, TR 3.1

VERSION NO. 1.3

ELECTRONIC FILE CODE dr3_2 appendix b application scenarios~1.doc


Application Scenario Description CRF EOL

Written by: G. M. Secco Suardo, CRF


@

Revision History

Date (dd.mm.yyyy)


13.12.2004 1.0 G. M. Secco Suardo The draft version submitted SINTEF

05.01.2005 1.1 Carl Christian Røstad, SINTEF Updated v1.0 document – Chapter references below refers to the old chapter structure in v1.0

3.14 Technical interfaces - DELETED (transferred to WP R1)

3.15 Facility and quality technical requirements – DELETED (transferred to WP R1)

3.16 Hardware and software platforms in use – DELETED (transferred to WP R1)

4.2 To-be, Future scenario concept - REMOVED ERRONUS DESCRIPTION TEXT

4.3 GAP analysis of As-is and To-be - REMOVED

4.6 Cost models - DESCRIPTION CHANGED

5.2 Describe possible downsides/upsides … - DESCRIPTION UPDATED

6.4 Improved LCA indications - REMOVED

6.5 Improved MOL/BOL/EOL options - REMOVED

7.1 Changed labour/work conditions - DESCRIPTION UPDATED

7.2 Social Impact on society - DESCRIPTION UPDATED

7.3 Ethical issues - DESCRIPTION CHANGED

12.01.2005 1.2 M. Gambera Modification on 2.2, 3.7, 5.* on.

05.05.2005 1.3 Carl Christian Røstad Prepared for inclusion in DR3.2

Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisation E-mail Tel Fax G.M. Secco Suardo CRF [email protected] +39 011 9083030 M. Gambera CRF [email protected] +39 011 9083047 J. Mascolo CRF [email protected] +39 011 9083911 A. Leverano CRF [email protected]


1 Application scenario description A1 CRF EOL Where discrepancies, the Demonstrator-document overrides all aspects of this scenario. Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario The envisaged scenario refers to the use of PEIDs for managing the passengers vehicles End of Life, the decision making and process management. The overall scenario includes:

− The delivery of the ELV to a dismantler; − The deregistration of the ELV; − The depollution of the ELV; − The separation of parts for reuse or remanufacturing; − The separation of parts suitable for recycling; − The delivery of the hulk to a presser; − The delivery of the pressed hulk to a shredder; − The transport of parts for reuse/remanufacturing, of the hulk to be pressed, of the hulk to

be shredded, of the materials to be recycled to their destination. The objective of the scenario is to assess the use of PEID (most probably RFID) for improved decision making (based on information concerning parts status and history stored on the RFID), materials tracking and for testing the achievement of recycling and reuse targets as stated by the European directives. Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil The ELV (End of Life Vehicle) directive (EU/2000/53) introduced by the EU in 2000 addresses pollution arising from vehicles that have reached the end of their useful life. The directive specifies thresholds for the reuse, recycling and recovery of materials from ELVs. By 2006 the ratio of materials in an ELV which should be reused, recycled or recovered will reach 85% of the total vehicle weight and 95% by 2015. Moreover, End of Life is an area where PEID seem to provide major benefits:

− ID/use/environmental historical information to support decision making and add value to the EoL processing.

− effective and efficient tracking capability, similarly to logistics area. − support to operating/routing instructions;

Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work The proposed scenario relates to all four objectives of PROMISE inasmuch:

− It develops a new closed loop life cycle information model; − It contributes to the definition of a PLM and IT infrastructure; − It will contribute to new standards concerning EoL treatments; − It develops new business models appropriate to the EoL phase.

Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL


@

The scenario covers most of EoL processing and decision making. It uses data which derive from MoL (maintenenance data) and from BoL (BOM and dismantling/processing work instructions). Marketing and Engineering can derive useful information from EoL, identifying among other overdesigned components/subsystems. Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues. The products being considered in the scenario are the ELV and its components. Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL BoL: Engineering is supposed to provide detailed data concerning BoM, materials, dismantling and processing information. At the moment we have no information on data Engineering may wish to collect from the ELV. Data concerning the rate of recycling and reuse may be of some use, for design purposes and for detecting potentially over-designed parts. MoL:

− data will be collected concerning component use/ environment/ maintenance. This information may be collected at vehicle level (global information), and/or subsystem level (local information); this information will be used for EoL management as well;

− detached parts may be reused directly or after some remanufacturing/repair as a used spare part.


@

Illustration of the application scenario Provide an illustration of the application scenario that can be used for communication purposes (e.g. in trade magazines, on the front of reports, slide shows etc). Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file.

Illustration of the information flow (flowchart) In order to identify informational requirements, illustrate the flow of information and clearly identify information/data flows by denoting this in the figure. Use rectangles, arrows, circles etc with text. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here.

LAST OWNER CRUSHER

Iron Lightmetal

DISMANTLING

Glass Seat foams

BottlesUndercarpetsCar

air ducts

Catalyticconverters

5% Ash to landfill

ENERGY RECOVERY

Used sparepartsOils, batteries

Inertization/reuse

Fluids,other dangerous

material

National Obligatory Consortia

Precious metals

FLUFF INCINERATION

DISMANTLERMETALLURGICAL

INDUSTRY

METALS RECOVERY

Bumpers

DEPOLLUTION

SHREDDER


@

Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) One should identify what parts/subsystems are potentially worth reusing/remanufacturing/recycling, which implies detaching in the first place. Then one should identify what information is needed to improve decision making (e.g. some material may have no use if the average humidity is higher than a give threshold). This specifies the information to be captured. Then one should study how to capture this information and where to store it. A good solution might be on the on-board computer. After dismantling the the information should be attached to the component PEID and follow the part. This read and write facility is an issue to be tackled by the project. Other aspects related to the Application Scenario If some aspects are not are covered above, please use this field.


@

1.1 Technical issues A1 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA 1. The incoming vehicle will be identified by a top-level PEID, which will indicate the type of vehicle, its ID, the owner, the assembly date, to mention the main information. I am assuming that a number of global information will be collected and stored on the vehicle on-board computer:

− mission profiles statistics about the use of the vehicle and components (e.g. kilometres travelled);

− mission profiles statistics about other environmental conditions (e.g average humidity, external temperature, temperature in the engine area);

− history of all maintenance activity, and specifically the list of replaced parts and corresponding date.

Local information might be stored either on the on-board computer or on some local chip. 2. The components and subsystems worth reusing/remanufacturing will be identified (decision making!) and detached based on this information and following the work instructions downloaded from IDIS backend system. These information could be shown on a display to be used by the worker. 3. Detached parts will be identifiable thanks to the information stored on a local PEID (which may be attached at the moment). Besides the ID, the essential information which should travel with the component will be:

− the manufacturing date, − installed date, − material code − summaries concerning the use (e.g. kilometres travelled); − environmental conditions (e.g average humidity, external temperature, temperature in the

engine area); − history of all maintenance activity, and specifically the list of replaced parts and

corresponding date. − routing instructions (destination recycler/remanufacturer) − processing instruction (mainly for recycling).

4. At its arrival at the dismantler the vehicle will be deregistered and its ownership will be transferred to the dismantler. 5. The vehicle will be tracked until the shredder. After reaching the shredder the vehicle will be cancelled, and statistics will be updated.


@

Data&Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc). Data going into the PEID – apart the identifier, material code and work instructions – is the same collected for MoL applications. It will depend on the part type and material. An analysis is needed. My hunch is that fewer than 5-6 data are enough to characterize the use/environmental history. Some data (global) will apply to all vehicle components. Other (local) will apply to specific components (e.g. wipers work hours). The former can be stored on the on-board computer, the latter on local devices. Data&Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc). Same data as in input, as far as downstream processing is concerned. I am not excluding that summaries (information) may be useful to Engineering, but I still have to make sure. Data&Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs) One has to distinguish part for reuse and parts for recycle. Engines, gearbox, steering wheels, brakes, etc. which qualify for manufacturing, are more demanding than parts for recycle. In the former case a history of use, service interventions, environment may easily add value to the part to be reused. This information requires quite a few data. In the latter case material code and possibly a class code (depending on environmental condition) would be enough. As far as processing instruction, in the former case a routing instruction is all is needed. In the latter, processing instruction could be useful. Information such as processing or detailed engineering drawings could be downloaded from internet as needed. Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed.

1. For recording part information, work instructions and routing after dismantling RFID are warranted in a sufficiently automated environment – otherwise a paper slip and bar code could be enough. Assuming the use of RFIDs, then it must be investigated if RFIDs are attached at dismantling time or at vehicle assembly time (the latter solution would be needed to keep track if the vehicle configuration). In all cases a read/write capability is required, at least for recording work instructions.

2. The use of local devices to record local data may be warranted if the value of the reused component is adequate.

3. Read/write capability assumes a fairly short range. Information to be downloaded from backend via web does not require special channels.

Hardware: Life span of devices What is the needed minimum life span of the devices? The average vehicle life is 15 years, maximum 20. Devices mounted on the vehicles and to be read at EoL should last 20 years at least.


@

Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc) In the vehicle there are mainly 2 working environment: motor compartment: temp: -20 + 100 high vibrations elsewhere: temp –2 + 40 low vibrations Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Existing sw technology is adequate Software: Middleware (software that allows different software applications to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Existing sw technology is adequate Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. The only application I can this is if data collected by the on-board computer are written on the components RFIDs. Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Read and write facilities shall be available. Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. A PLKM is assumed where BoM, material, work instructions, decision rules will be stored. This information will be downloaded at dismantling time. An application sw will provide the deregistration of the vehicle. Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. I am assuming that the operator will decide with the support of a PDA which will collect data from the RFID, and based on a program downloaded from the back end system will decide if the part is worth detaching and what sorting/processing has to undergo (write on RFID). Other aspects related to the Technical issues


@

1.2 Business/economical issues A1 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Italy has implemented the EC directive only partially. Fiat has implemented the provisions which require the producers to “use components and material coding standards, in particular to facilitate the identification of those components and materials which are suitable for reuse and recovery”. To that end Fiat has implemented norm ISO 22628, and supported IDIS systems with the proper dismantling and processing information. Fiat is by no means involved at the moment in any recycling activity. Remanufacturing and reuse of parts is limited to major assemblies collected in the warranty period. To-be, Future scenario concept Describe in more detail the To-be solution/implementation. Describe it in such a way that it is related to the As-is description above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. We still have to talk to Fiat Auto and therefore we cannot specify what the future business model will be. All we know is that the automakers operating in Italy (Fiat, Peugeot, DC, etc.) are defining a network of dismantlers, which will deal with the ELVs. In other words, the scenario makes technical assumptions, but at this moment we do not know what are the business interests of the stakeholders. Business effects (own business) – negative aspects Describe the negative business effects the application scenario (described in section 1) will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.) The implementation of the European directive will probably load the automakers with extracosts, especially if the target of 95% of recovery must be implemented. The use of valuable however could streamline and optimise the decision making and open some opportunities in the area of used parts. A detailed analysis is lacking. Business effects (own business) – positive aspects Describe the business effects the application scenario will/could have on your business. (e.g. Improved business situation Business improvements opportunities (productivity, quality, environment, social issues) etc. As said before, the minimum one can say is that the MoL information so gathered will reduce the costs of implementing the European directives.


@

Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per PEID, support systems etc? It’s important to identify the maximum price range that can be added to a product/vehicle etc as a consequence of the aspects described in this application scenario. Describe therefore aspects that will have a consequence for costs, and in what range the “hurting” price for the customer (or users etc) will be. Again, a detailed analysis is still to be done. Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field. A fundamental issue is to identify the business interests of the different stakeholders. There are clearly components/assemblies which may have a substantial value at EoL. What are they? What is the profit that one can make after remanufacturing, repairing and distribution? Who will take care of them? The manufacturers or special or remanufacturing enterprises? What is the worth of the information which can be attached to the part? To identify the sustainable cost of the device one has to address these key issues. Then there are parts which have no value except contributing to the 85% recovery target (95% by 2015). In this case the use of an RFID is to streamline the operations, to track the material, and nothing else. The advantage concerns more the efficiency than the potential profits.


@

1.3 Value-chain issues A1 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The actors involved are:

− The users − The producers − The state motor register − The dismantlers − The recyclers − The shredders − The workshops − The remanufacturers − The manufacturers − The transporters − The distributors (of new/used parts)

The users deliver the vehicles to the dismantlers; the dismantlers will detach and sort the parts: the remanufacturers will refurbish the parts using new/used components; the distributors supply new/used parts to the workshops and remanufacturing plants; the recyclers transform the material into useable materials (plastics, rubber, etc.) and sell the material to the manufacturers; the shredder receives the compacted shell, it shreds the shell and sell the output to the steel mills and dump the residual. The transporters provide the transport and container facilities. Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) What kind of consequences will the application scenario have for the partners/business associates/customers etc in the value-chain (identified in 5.1). E.g. Dismantler: Dismantler must invest in new systems for reading/handling discarded products etc, but will have an upside regarding their operations of reuse/remfg etc as they more readily can… E.g. Customer: Customer will experience changes in their maintenance program this can be perceived as a positive or negative aspect (briefly describe why/how) Legislative prescription, as well as the intensive use of smart tag in the EOL of the vehicle will will impact on the whole value chain described in 5.1. The principal changes will regard:

The dismantlers, in terms of adoption of new technologies, partnership with the automotive industry, information sharing with the car maker.

The reverse logistic process, i.e. from the dismantler back to the manufacturer via te recyclers

Other aspects related to the Value-chain issues If some aspects are not are covered above, please use this field.


@

1.4 Environmental issues A1 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate. This and the following questions assume a detailed analysis which is still to be done. Energy savings will derive from recovering part of the fluff and from the extended use of recovered parts. State of the art ELV recycling starts with the shredding of the entire vehicle and proceeds to separate different kinds of material (i.e. ferrous from non-ferrous metals). The residual material, up to 30% of the weight of the vehicle, is termed Auto Shredder Residue (ASR) or simply “Fluff”. Fluff is composed of 50% polymers as well as rubber, glass and electronic components. The multi-material nature of ASR makes it economically impossible to segregate, recycle and reuse. Fluff is thus usually disposed of by means of incineration (thermal recycling). This practice has a considerable environmental impact in terms of CO2 emissions and at the same time poses a serious health hazard resulting form toxic incineration residue disposed of in landfills. Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. Recycled plastics will replace at least a share of virgin material. hile ferrous materials are already efficiently recycled, the challenge for the next future is to improve the recycling of polymer materials. In a modern vehicle a polymer percentage sums up up to 25%. Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. The business or reused parts is murky, at least in Italy. One can say that subject to an official warranty and lower price they will find a more widespread use in the workshops. Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field.


@

1.5 Social issues A1 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions Social Impact on society Describe, if any, implications of the application scenario regarding Social Impact on society n.a. Ethical issues Is there ethical issues related to the application scenario? IF Yes explain n.a. Other aspects related to the Social issues If some aspects are not are covered above, please use this field.


@



VERSION NO. 1.3

ELECTRONIC FILE CODE

dr3_2 appendix b application scenarios~1.doc


Application Scenario Description Caterpillar EOL

Written by: Howard Ludewig: Caterpillar Anthony Grichnik: Caterpillar Jean-Jacques Janosch: Caterpillar Keith Herman: Caterpillar Pat Ludewig: Caterpillar


@

Revision History

Date (dd.mm.yyyy)


1.0 See front page The draft version submitted SINTEF














1.2 Keith Herman, Howard Ludewig, Jean Jacques Janosch, Pat Ludewig


Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisation E-mail Tel Fax Keith Herman Caterpillar [email protected] Howard Ludewig Caterpillar [email protected] Jean Jacques Janosch Caterpillar [email protected] Pat Ludewig Caterpillar [email protected]


2 Application scenario description A2 CATERPILLAR EOL Where discrepancies, the Demonstrator-document overrides all aspects of this scenario. Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario The purpose of this scenario is to identify the basic framework for implementing the PROMISE End of Life (EOL) methodology on construction and mining equipment. The application scenario focuses on information that is gained during EOL events and how rigorous management of the information can improve EOL responsive to the event as well as provide feedback to BOL and MOL functions and tracking of total life cycle information. The demo case for this scenario will be based on the Track Type Loader (TTL) or Track Type Tractor (TTT) as shown in Figures1 and 2, respectively.

Figure 1: Caterpillar Track Type Loader.

Figure 2: Caterpillar Track Type Tractor. The primary objective of the proposed scenario is to manage the waste stream for MOL activities. In addition this information can provide feedback to the design and manufacturing sources as well as management to make the PLM processes more robust. Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil The scenario will be used to identify, test, and document the information requirements, component requirements, information flow, and business case relative to life cycle management. The focus of the scenario is EOL responsiveness to customers needs and commercial drivers. However, there is a requirement for a systematic approach for identifying the opportunities to convert the data that is gathered during the defined MOL process into useful knowledge to better manage the design, production, and waste management processes. In this context the waste management processes includes recycling, remanufacturing, and disposal. Standard systems must be developed where possible to facilitate data flow, material flow and data management with a end goal to maximize reuse and minimize disposal within a viable economic model.


@

Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work PROMISE main objective #1: To develop new closed-loop life cycle information flow models for BOL, MOL and EOL. This scenario will use information relative to component life and failure modes gained during MOL to enhance the design process in BOL. It will use field population data and implied demand to enhance the logistics information for the component providers in the remanufacturing phase of BOL. It will also provide for the study of waste stream data to optimise EOL processes. PROMISE main objective #2: To develop new PLM system and IT infrastructure exploiting the capabilities of smart product embedded information devices. Embedded devices will form the bases of the data and information tracking during the MOL event that triggers the process generating the waste stream for EOL management. These devices will continue to be used during EOL to track and document data relative to the logistics and validation through the supply chain. PROMISE main objective #3: To develop new standards to allow the technologies and associated tools to be developed by the PROMISE project to be accepted by the market and allow it to expand quickly by creating an appropriate environment for the development of new innovative applications. Standards will be required to convert the event data into a actionable information package. In addition the scenario will support the need for standards in device and information protocols. New standards must address the need for recycle and reuse parameters within an acceptable economic model. PROMISE main objective #4: To develop new working and business models appropriate for the use and exploitation of the new technologies and tools to be developed by all actors involved in a product lifecycle. The scenario will be used to identify, test, and document the information requirements, component requirements, information flow, and business case relative to life cycle management. This will include processes and information management that will facilitate EOL activities including quantification of recyclable content and processes to validate proper levels of recyclable content as well as socially acceptable disposal processes. Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL This scenario is primarily related to EOL activities. However, it impacts both BOL and MOL process as previously stated. Information will be collected from the machine during use. When onboard data processing determines that there is an “event”, this event data will be transmitted to the appropriate source. For example, a major failure should transmit information directly to the service people (MOL). Logistics information would also be sent out so the replacement part(s) (BOL) could be put in route to the destination of the failure. Manufactures would also be contacted in the case that no parts are available or if the supply of the needed part(s) falls below a designated quantity (MOL). Other importance performance data could be transmitted to the service people and/or designers to help understand how to determine the source of the problem or improve the design. (BOL). As components , assemblies, and machines are replaced in the MOL phase a waste stream is generated that will transfer the focus to EOL processes. Information into EOL will be tagged by a RFID linked data base. This information will establish the bases for EOL decisions relative to reuse, recycle, and disposal. The first objective would be to reuse as much of the components , assemblies, or machines as possible. Often this will require some remanufacturing so information flow back to BOL will be critical to optimizing the process.


@

Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues. The product to be used in this scenario will be either a track type tractor or a track type loader, depending on which fits better with the PROMISE scenario. (see Figure 1 and 2) These products are commonly used in construction and mining application with a large distribution of application requirements that significantly impact the life and performance of the product. Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL An overall PLM concept drawing related to the scenario is shown in Figure 2 in ILLUSTRATION OF THE APPLICATION SCENARIO. The interfaces between the lifecycle phases are shown in Figure 4 in ILLUSTRATION OF THE INFORMATION FLOW 8. The primary interface point is between the MOL and EOL processes are illustrated. The interface includes recyclable content data as well as validation data for waste stream management. Application data will provide the basics for EOL decisions relative to reuse, recycle, or dispose. This information is both application specific and product specific. Therefore, it is very important that the interface information format and content is user configurable. There is also an interface point between the EOL and BOL for any parts that are reused. This interface involves both logistics relative to the supply chain and manufacturing relative to remanufacturing processing.


@


Figure 3: Life Cycle Management concept drawing.

Service

Manufacturing

Recycle

Remanufacture

Dispose

Sensors/ RFID

Technology

Wireless Communication

PDKM

Production Needs

Logistics Information

Logistics

Automatic Service Call

Performance Information

Design Engineering

Critical Machine Information

EOL

Information on Machines put out of service


@

Illustration of the information flow (flowchart) In order to identify informational requirements, illustrate the flow of information and clearly identify information/data flows by denoting this in the figure. Use rectangles, arrows, circles etc with text. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Product Life Cycle Management EOL Application Scenario

End Of LifeMiddle Of LifeBeginning Of Life

Product Operatingin a Field

Application

Event Trigger

Diagnostics & Logistics ActionPrognostics Extension

CommonTransmission

Device

Action to be taken

RFID info ofaffected components

Service Provider Logistics PullTriger

New ComponentsUpdated RFID

Information Recyclable contenthow to measure

how to verifyComponent RFID

yes

no

Dispose

no

LogisticsInformation forPart Provider

DesignInformation

What is failingWhy it fails

usage data (RFID)Length of life

Field PopulationImplied Demand

ForecastingPrognostics

Trigger Table

Reuse

RFID LinkedComponent

Information DataBase

Waste StreamCharacterization

Part identificationmaterials

contaminationeconomic value

Remanufacture

ManufacturingProduct Identification

Remanufacturing ProcessesQuality Requirments

no

Raw MaterialProcessing

yes

Recycle

Disassembly

ComponentCharacterization

Figure 4: Flow chart of the EOL Application Scenario.


@

Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here. Collection and documentation of User Requirements is not a straightforward process relative to a broad based implementation of this scenario. The best way to get this information is through a combination of interviews and brainstorming sessions. If the right people can be pulled together, a series of “focus group” brainstorming sessions may be the best tool to fully understand the process requirements. Some of the general requirements are:

• Component information linked to a RFID. • User configurable data base structures for component information. • User configurable management systems for proprietary diagnostics and prognostics

systems. • High level of system reliability in harsh remote environments. • Commercially available hardware interfaces.

Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) The single most important challenge will be getting consensus of standardization issues in both hardware and software protocol, communications, and data structures. Application requirements are going to vary significant within a industry segment as well between industry segments. Generic identification of information classifications will facilitate the development of a system that is user configurable. Other aspects related to the Application Scenario If some aspects are not are covered above, please use this field. There are several requirements for this scenario that must be fulfilled for it to be successful. The real challenge is to develop standard methods and protocols that can be used for a number of different applications. The process start point is defined as a TTL or TTT operating in the field as illustrated in the top of the MOL box in Figure 4. In fact this can be characterised as any machine with some diagnostic and prognostic capability operating in its designed application. There are a number of decision point in the EOL processes of reuse, recycle, and dispose depicted in Figure 4. The information requirements and processes definitions related to these decision points have to be identified. However, each application will be different and must be identified by the end user of the system. The final challenge will be to fully define the information flow between the MOL process and the BOL and EOL processes. Some high level concepts are included in Figure 4. However, these will have to be further defined and specified by the PROMISE team.


@

2.1 Technical issues A2 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA Data will be collected from PEID sensors through out the life of the product, component, and piece part. Most of the data will be stored in data bases that are associatively connected to the PEID via an identification number. In some cases the data may be stored on the PEID itself. This will have to be determined on each individual product. This data or information will be used in EOL to characterize the components and/or piece parts. The data will be used to retrieve the most up to date processes and procedures for disassembly, remanufacturing, recycling, and disposal. The database will contain information such as part identification, material, contamination, duration of life, and service conditions.

Data&Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc).

• Sensor data from a range of sensors. • Manually entered data from servicemen. • RFID information identifying machine components

Data&Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc).

• Time/Date stamp • Event type • Relevant Event data • Action Required • Product serial number (TTT or TTL) • Component serial number (Specific component in question) • Machine hours • Component hours • Relevant sensor information (condensed or raw data) • Maintenance information • Misc. user input - . . If there are large amounts of sensor data that cannot be transmitted, an event could be triggered which informs a service man to come and manually collected the needed data from the machine and clear the storage device.


@

Data&Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs) At this point, it is not clear where or what data will be stored. The application scenario needs a bit further refinement to come to that stage. Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed. Unknown Hardware: Life span of devices What is the needed minimum life span of the devices? Since Caterpillar machines live for decades (50+ years) in the field, the life should be quite long. This should, at a minimum, match the time to the first major overhaul of the machine where devices could possibly be replaced. Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc) Caterpillar machines work in very rugged conditions. Both extreme heat (55 °C) and extreme cold (-30 °C) conditions are encountered. Vibration, impact, large amounts of dust, oil, rain, mud, etc are also part of the normal operating conditions. These machines work in all weather conditions. Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Software should be user configurable and relatively open so that the user (Caterpillar or a dealer) can customise it to fit a specific customer’s needs. It could then also be customised monitor multiple components on a machine (engine, critical structures, etc) Software: Middleware (software that allows different software applications to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. See SOFTWARE: FIRMWARE (EMBEDDED SOFTWARE Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. See SOFTWARE: FIRMWARE (EMBEDDED SOFTWARE Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. See SOFTWARE: FIRMWARE (EMBEDDED SOFTWARE


@

Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. In a final product, all decisions would be made by proprietary Caterpillar software, however we will need a solution for the PROMISE demonstration. Possibly a portable PC could be placed on board the product to perform data analysis and storage for the demo. The need for storage would most likely be needed only in the case that the volume is too great to transfer with the chosen communication device. Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. See SOFTWARE: BACKEND SOFTWARE (SOFTWARE FOR DATA MANAGEMENT, DECISION MAKING ETC) Other aspects related to the Technical issues If some aspects are not are covered above, please use this field. N/A


@

2.2 Business/economical issues A2 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The as-is situation is that all information from the machines must be manually collected from a limited number of sensors. Because of this there is no PLM infrastructure in place to handle this real time data collection. To-be, Future scenario concept Describe in more detail the To-be solution/implementation. Describe it in such a way that it is related to the As-is description in section 0 above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The to-be situation is the incorporation of more sensors on the machine as a “standard” with the PLM infrastructure to utilize the valuable data. Business effects (own business) – negative aspects Describe the negative business effects the application scenario (described in section 1) will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.)

- Caterpillar is a large global organisation with products in use on every continent. This would require systems to be produced in many languages and the system would be required to handle very large amounts of data.

- Caterpillar machines are serviced by independently owned dealers. Implementation and training of such a system will/would require a large investment with these dealers.

- Some customers may perceive that Caterpillar is spying on them in order to avoid paying warranty claims.

Business effects (own business) – positive aspects Describe the business effects the application scenario will/could have on your business. (e.g. Improved business situation Business improvements opportunities (productivity, quality, environment, social issues) etc. For EOL activities, the critical data for the machine could be obtained without the expense (of the customer) of stopping the machine. This could improve customer satisfaction. This could also allow dealers to better manage their resources and be more profitable. It would also allow them to better service their customer, giving Caterpillar an advantage over their competition.


@

Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per PEID, support systems etc? It’s important to identify the maximum price range that can be added to a product/vehicle etc as a consequence of the aspects described in this application scenario. Describe therefore aspects that will have a consequence for costs, and in what range the “hurting” price for the customer (or users etc) will be. This would need to be determined on a cost-benefit basis. Caterpillar customers buy machines to make money. Considering this fact and the fact that the customer has spent a quite large sum of money on a machine, cost would not be the primary focus if the device would allow for lower owning and operating costs. Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field. N/A


@

2.3 Value-chain issues A2 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. For EOL consideration the business relationships must be established primarily in the recycle and disposal arena. Any component or part of a component that has potential recycle value must be identified as such. The recycle process must be fully developed and documented. A business to take the part and convert it to a somewhat original form must be identified and the process has to be established to transport theses parts to the appropriate location. The same relationship may be required for reuse process. However, many organizations have internal remanufacturing facilities. Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) What kind of consequences will the application scenario have for the partners/business associates/customers etc in the value-chain (identified in 5.1). E.g. Dismantler: Dismantler must invest in new systems for reading/handling discarded products etc, but will have an upside regarding their operations of reuse/remfg etc as they more readily can… E.g. Customer: Customer will experience changes in their maintenance program this can be perceived as a positive or negative aspect (briefly describe why/how) The business case for recycle and disposal is not well defined. In many cases it may be more expensive than doing nothing at all. Other aspects related to the Value-chain issues If some aspects are not are covered above, please use this field. N/A


@

2.4 Environmental issues A2 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate. Energy efficiencies will come primarily from remanufacturing of parts and components. Published data shows that remanufacturing requires only about 15% of the energy used to make the product from scratch. Current data shows a 120 trillion Btu’s savings resulting from remanufacturing activities worldwide. Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. Real-time predictive and real-time preventative measures during the life cycle of the product will prevent hard failures and promote the retention of value added from the original manufacturing. Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. Baseline data shows that annually the material savings resulting from worldwide remanufacturing activities is 14 million tons. Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field. The primary advantage that is not covered above is the conservation of landfill space and the decrease in the use of virgin natural resources that will result from increased reuse and recycling..


@

2.5 Social issues A2 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions

• Improved training processes. • Proactive maintenance • Information feedback to the design and manufacturing process will produce user friendly

products. . (operator comfort, safety, satisfaction of the product user …) Social Impact on society Describe, if any, implications of the application scenario regarding Social Impact on society Reduced pressure on natural resources. Reduced green house gas emissions Ethical issues Is there ethical issues related to the application scenario? IF Yes explain Privacy? Does Caterpillar have the right to monitor the use of a customer’s machine? Other aspects related to the Social issues If some aspects are not are covered above, please use this field. NONE


@

DELIVERABLE NO Input to DR 3.1, relates to WP A3


VERSION NO. 2.1



Application Scenario Description BIBA/INDYON EOL

Written by: Andreas Plettner, INDYON Martin Schnatmeyer, BIBA


@

Revision History

Date (dd.mm.yyyy)


13/01/2005 1 Dr. Andreas Plettner, INDYON

13/01/2005 1 Martin Schnatmeyer, BIBA

22/03/2005 2 Martin Schnatmeyer, BIBA Example included (see annex)


Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisation E-mail Tel Fax Dr. Andreas Plettner INDYON [email protected] +49 89 54759128

+49 89 54759100

Martin Schnatmeyer BIBA [email protected] +49 421 218 5532 +49 421 218 5610


3 Application scenario description A3 BIBA/INDYON EOL Where discrepancies, the Demonstrator-document overrides all aspects of this scenario. Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario The objective of this WP is to develop an application which supports the tracking and tracing of products for recycling by using the PROMISE PEID technology and PDKM system in combination with indoor and outdoor navigation systems. Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil Related to the other 2 EOL scenarios (EOL information management for monitoring End of Life Vehicles and for heavy load vehicle decommissioning) this objective has a more generic approach and is open for other scenarios outside the EOL vehicle sector. Beside this the objective covers also logistic process steps, which have to be fulfilled after the monitoring and decommissioning of vehicles for closing the product life cycle loop. Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work This scenario is related to the EOL sector, which has to be covered by PROMISE, and will test the PROMISE PEID and PDKM system in the EOL environment. Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL This scenario is focused on the EOL sector but is also applicable on the other sectors, especially on the production level (BOL). For improving the recycling rate, data coming from the BOL and MOL sector, shall be used for an optimised reverse logistic. Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues. The main material is plastic (production waste, e. g. from the automotive industry foreseen for a reuse in this sector or in other sectors needing a high plastic material quality).


@

Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL The picture below describes the single process steps on a generic level, starting with the collecting of production waste and ending finally in the production again. Between each step there are normally interfaces based on paper documents, telephone calls, manually written fax documents or e-mail and an ERP (AMIC A1) / Microsoft office (mainly EXCEL and ACCESS) systems, all depending on commands coming from the PC key board (i. e. human interface or interaction).

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

Figure 1: PEID based tracking and tracing of plastic material


@


Access Point

T r a n s p o n d e r

This is atransponder antenna

Server

5 mm

40 mm

Transponder

around 1 transponder/storage location

Figure 2: Illustration of application scenario


@

Illustration of the information flow (flowchart) In order to identify informational requirements, illustrate the flow of information and clearly identify information/data flows by denoting this in the figure. Use rectangles, arrows, circles etc with text. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file.

ERP System

PPS System WMS System PLM System

Recycling Machines Transport System Control Systems

PDKM System

Data Flow Recycling System

Figure 3: Data Flow

This is the general structure of the system. There are still some data flows to be defined during the project and these are the data flows between PPS and WMS and PLM. There more definition work is to be done in order to generate an appropriate system that uses the existing capabilities/interfaces between these main components.


@

Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here. PDKM system inputs from research clusters are needed. Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) The main challenges for this scenario are the interfaces to the PROMISE PDKM systems and the PROMISE PLM system. The questions to be answered are to define the level of intelligence of the PDKM system in order to make decisions about e.g. recycling process to be used, this means putting some PLM functionality into the PDKM system (controller). Economical: fast return on invest of these systems is essential Ethical: Too much control Customer: Too much control Environmental: Too much RF in the air (although the systems comply to the legal regulations). Other aspects related to the Application Scenario If some aspects are not are covered above, please use this field. Not applicable at the moment


@

3.1 Technical issues A3 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA The sort of data is listed in the centre of Figure 1. The PEID is part of the packing material use for the transport of the milled plastic material. Data from the PEID will be collected via a reader antenna (distance antenna – tag 1 m maximum or less). Data will go via W-LAN into the internal IT network (step 5, 6, 7) or into the internet (step 1 – 4, 8,9) Data&Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc). At the moment its foreseen only to use the ID code on the tag, the rest will come from the database. Related to the PROMISE PEID normal ASCII code is sufficient and – if feasible – around 500 kBit storage capacity would be an alternative to the ID code solution. See also PAIN-POINTS (PROBLEMS/CHALLENGES) where the question arise whether to put more intelligence into PEID reader systems. If this is done more data than the ID will be needed on the PEID. Data&Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc). See DATA&INFORMATION: INPUT DATA Data&Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs) See DATA&INFORMATION: INPUT DATA Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed.

1. PEIDs 2. PEID Readers 3. WLAN equipment 4. Panel PC with WLAN 5. Server 6. LAN

Hardware: Life span of devices What is the needed minimum life span of the devices? All components should be suitable for industrial use and have common lifetime. Lifetime of PEIDs can vary between 1 year and 10 years depending on the specific use.


@

Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc) Industrial working conditions, partly outdoor application and therefore temperatures between -20oC and +60 oC. Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. PEID Reader controller SW in order to enhance decision capabilities of the PDKM system. Software: Middleware (software that allows different software applications to communicate)Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Implementation of SW that allows in this specific case the data flows between recycling machines, transport systems and control systems. This layer of SW can be a part of the PDKM system. Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. A communication between the packing material (e. g. in a storage unit) is sensible. If the PEIDs are passive, an external radio field is necessary. If the PEIDs are active (with own energy supply) an autonomous communication between the packing material is useful for an process optimisation. Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Depends on the future SW infrastructure. Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Standard backend modules like ERP, WMS, PPS, Oracle DB, PLM. Related to decision making, agent technology is for the logistic sector a good basis (for operative business processes). For strategic decision making a logistic simulation system is perhaps the better solution. Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. In autonomous logistic systems software should act local and has to be controlled by a remote system. Technical interfaces Describe what sort of technical interfaces would be considered to be used or as needed to be developed. ?


@

Facility and quality technical requirements 4 or more storage racks, fork lift, packing material + plastic material storage area of round about 100 m2, swap trailer. Hardware and software platforms in use 100 Transponder (125 kHz), antenna (125 kHz) + controller, 4 or more PEIDs, PEID antenna + controller, display, Panel PC, backend server, Oracle database, W-LAN, keyboards, mouse, monitor. Other aspects related to the Technical issues If some aspects are not are covered above, please use this field. GPS system for outdoor navigation can be integrated if needed.


@

3.2 Business/economical issues A3 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. See figure below describes the as-is situation (paper based / manual data input):

CollectingSorting

MillingFilling

Loading

TansportMeasuring of Heaviness

Loading (in)ControllingQuality checkMeasuring of HeavinessStoringLoading (out)

MixingExtrudingGranulatingFilling

Production waste

Production

Loading (in)StoringLoading (out)

TransportMeasuring of Heaviness

A

A

A

A

A

A

A

A Paper documents / Manual data input

Figure 4: As-is situation in the plastic recycling loop

To-be, Future scenario concept Describe in more detail the To-be solution/implementation that are used today (either as your company or others uses). Describe it in such a way that it is related to the As-is description in above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The goal is to deny each kind of paper and human interacting related to the data transfer between the different steps in Figure 4. GAP analysis of As-is and To-be Identify the gaps between the As-is and the To-be. See TO-BE, FUTURE SCENARIO CONCEPT


@

Business effects (own business) – negative aspects Describe the negative business effects the application scenario (described in section 1) will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.) Since we are not the users of such a system there are no effects to our business. For the user:

- Investment to establish a system - Running costs of such a system

Business effects (own business) – positive aspects Describe the business effects the application scenario will/could have on your business. (e.g. Improved business situation Business improvements opportunities (productivity, quality, environment, social issues) etc. Since we are not the users of such a system there are no effects to our business. For the user:

- Less paper, less costs - Higher degree of transparency in all processes - Optimised decision making

Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per device. These data depend mainly on the coming results. From today’s point of view the systems being developed in the project will generate a positive return on invest to the users in cases where many transactions (today flow of information on paper) take place. Cost per device depends on the use cycles. An active tag has and can be used many cycles and therefore a price of 10-100 € can still be economical. On the other hand single use tags have to prove themselves for single use. This is now still not viable, but in supply chains where the tag attached to a product is used by many participants of the supply chain the economical calculation can justify the use. The prices for these tags range between 0,3 and 2,0 €. Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field. Not applicable, depends on results.


@

3.3 Value-chain issues A3 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file.

Value Chain for A3

AutomotiveIndustry/User RecyclerLogistic

ServicesLogisticServices

WasteManagementv v

Field of applicationscenario A3

Figure 5: value chain The value chain here is subdivided between the user of the material due for recycling, the logistics that transport or store the material, the recycler, logistics to store the recycled products and bring the recycled material back to a user or to waste management (e.g. incineration). It is also possible to find the logistics services attached to either the automotive industry or the recycler. This value chain fits with other application scenarios where the automotive industry is involved.


@

Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) Customers downsides 1. The data security on the customer side 2. If the customer wants to use the technology advantages coming from the PEIDs, he has to

install an suitable system environment. Customer upsides 1. Higher product availability 2. Transparent (logistic) processes Supplier downsides 1. The data security on the supplier side 2. The supplier has to invest in an suitable system environment. Supplier upsides 1. Fast delivery service 2. Transparent (logistic) processes Partner downsides 1. Data security 2. They have to invest in an suitable system environment. Partner upsides 1. Better co-operation 2. Process optimisation 3. Transparent (logistic) processes Other aspects related to the Value-chain issues If some aspects are not are covered above, please use this field. -


@

3.4 Environmental issues A3 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate. Due to the higher data transparency the logistic processes are more efficient. The guesstimate is 10% less energy consumption based on own experience in this sector. Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. Based on more efficient logistic processes, the material recycling (also from smaller fractions) becomes more attractive than incineration or disposal on a garbage dump. The guesstimate is 10% less raw material consumption based on own experience in this sector. Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. See SOCIAL IMPACT ON SOCIETY Improved LCA indications If the PEID or the system behind the PEID is able to collect and interpret data, which are useful for an LCA, the results of LCA will have a better quality. Improved MOL/BOL/EOL options If the PEID or the system behind the PEID is able to collect and interpret data, which are useful for the MOL/BOL/EOL phases, the amount of feasible options will be higher in this phases. Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field. Maybe the radio fields related to the PEID system are bad for human health and his nature environment (belongs also to section 7) but there are clear rules about frequencies and related emissions. Other aspect is also the recyclability of the PEIDs and the energy consumption of the PEID system in his whole product life cycle (BOL, MOL, EOL).


@

3.5 Social issues A3 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions Maybe the radio fields related to the PEID system are bad for human health and his nature environment. Workers has to be educated in the PEID technology. Furthermore data security and possibility of the surveillance of workers will maybe prohibit that they accept the system. Social Impact on society Describe the implications of the application scenario regarding Social Impact on society Especially related to the reduced raw material consumption the social impact is positive. Ethical issues Last, but not least, discuss the ethical issues related to the application scenario Data security and data ownership is an important factor which has to be taken into account from all stake holders in the value chain. Other aspects related to the Social issues If some aspects are not are covered above, please use this field. Looking on the global market place, PROMISE has to take into account that all regions on the world can have access to the technology (especially reading and interpreting data from the PEID). 3.6 Annex A3

3.6.1 Recycling of Car Bumpers with RFID Technology as an Example for A31 For a better understanding of the opportunities of the RFID technology in the product life cycle management, this chapter describes a possible recycling scenario for car bumpers. Figure 3 describes possible application fields for the RFID technology in the life cycle of car bumpers with an attached or embedded tag from the producer side: After use and dismantling the single bumper or bumper fraction goes to the collection point (e. g. an open container) by passing a reader gate (see Error! Reference source not found.). This reader gate reads all data from the single bumper tag and writes data on the tag (see Table 1).

1 Following Hans, C.; Schnatmeyer; M.; Schumacher, S.; Thoben, K.D.: Using Transponder Technology to Support the End-of-Life Phase in Product Life Cycle Management. Proceedings International IMS Forum 2004, S. 1448 – 1455. Biassono (Milano) 2004.


@

CollectingSorting

MillingFilling

Loading








Waste

Production / use



Information Break

Information Break

Information Break

Figure 3: Use of RFID technology in the life cycle of bumpers The milling starts after a sufficient amount of bumpers is available. Before the milling, a manual or automated sorting system sorts the bumpers for recycling from the container fractions. After milling and filling the material goes via a truck to another recycling facility. There the material goes into a storage system. On customer demand this facility produces new plastic granulate, which is basis for new plastic products. The different process steps have different requirements of data exchange. Table 1 describes examples for an information exchange between the transponder and the collecting / sorting production, transport, loading and storing systems. The transponder technology enables in this example the data acquisition of the collected material types and -mix at the collecting point, i. e. at the place of waste collecting, in temporary storage facilities systems or in storage systems of external logistic services. Advantages are the ubiquitous availability of data about the material during the whole recycling process. Breaks in the information chain (cf. Figure 3) are buffered via the transponder chips. The fast information exchange by passing reading systems is more efficient than the manual scanning of barcodes. As an additional functionally it is possible to control the temperature of the packed material (granulated plastic is self inflammable).


@

Process step Data exchange (examples)

Collecting / Sorting

Bumper transponder to production system: Additives, brand, colour, consistence of material, bumper identification number (external), type of material, weight Recycler production system to bumper transponder: Day of storage, personal data, place of storage (in), bumper identification number (internal), quality

Production Production system to packing transponder: Additives, consistence of material, day of filling, personal data, place of filling, packing unit identification number, status, type of material, weight, machine number Packing transponder to production system: Packing identification number, temperature

Transport Packing transponder to truck: Packing unit identification number, material, place of storage on truck, weight, temperature Truck to packing transponder Personal data, truck number plate

Loading Packing transponder to fork lift: Packing unit identification number, material, place of storage on truck, weight Fork lift to packing transponder: Day and time of loading, fork lift identification number, personal data

Storing Packing transponder to storage system: All collected data on the transponder (e. g. additives, consistence of material, material, packing material, personal data, packing unit identification number, temperature, weight) Storage system to packing transponder: Storage place, date and time, quality status

Table 1: Date exchange during the recycling process of bumpers (examples)

3.6.2 Real Time Decision Support The ubiquitous availability of information accompanying the material flow can be further used in order to realise innovative decision support tools, which can be adopted for various issues within enterprise networks and the process chains in the field waste and recycling management. Tools on top of data acquisition solutions as mentioned above can conduct further processing of the data coming along with individual entities (like bumpers) or batches. During this process data becomes information, which can be used to make better decisions on the operational, tactical and even strategic level. Examples for potential improvements on each of these levels are as follows: Operational level

• Reaction on interference during the collection process (e. g. due to road construction) of waste or recycling material

• Reaction on unavailability of vendor parts or material in production and recycling • Allocation for required resources for inbound and outbound flow of material / products for

warehousing (loading unloading, packing, unpacking etc.)


@

• Control and better utilisation of transportation networks, as well as production and warehousing resources because of better information and forecasts based on real time data

Tactical level • Clustering of areas, route planning for collection of recycling material or waste considering

seasonal variability • Production or recycling planning based on reliable information and forecasts for demand and

availability • Specification and adaptation of suitable warehousing policies (e. g. for reordering or delivery) • Short-term adaptations of existing (recycling) networks as a result of a breakdown of a

partner (e.g. selection of a new supplier) Strategic level

• Composition and decomposition and of recycling networks (design and global optimisation) • Long-term decisions as the location of new facilities for production, warehousing etc. • Assessment of new technologies systems for collection, production, transport, warehousing,

loading, unloading etc. Thus real-time information concerning the various decision problems along the composition, operation and decomposition recycling networks or process chains offers huge optimisation potentials. In addition real-time information allows better forecasts and estimations regarding uncertainties and variability, which are inherent everywhere in production or recycling. In combination with tools following a holistic approach decisions and solutions can be developed which fulfils all requirements regarding efficiency, robustness and sustainability at the same time. Today there are quite a number of approaches available in order to support the planning, control and optimisation problems related to the operation of production or recycling networks. The range covers pure mathematical methods (systems of equations), methods from Operations Research (mathematical programming), Soft Computing (evolutionary algorithms, neural networks, fuzzy methods), System Dynamics, Benchmarking or Simulation. While thinking about suitable approach for the realisation of a decision support system all of these approaches come along with specific disadvantages. Most of them are caused by the complexity of the underlying system. In this context it is questionable whether mathematical models, Operations Research or system dynamics can build adequate representations of reality. Although Soft Computing can solve even NP (Non-deterministic Polynomial-time) -hard problems and therefore fulfils the requirements regarding complexity it must be considered as a black box as the way to come to the solution, which was delivered, cannot be comprehended by the user. Another approach, which is widely used in practice, is Benchmarking. But this method requires reference cases (which are not necessarily available) in order to allow estimations about the quality of a certain decision or system configuration. Furthermore all of the methods mentioned so far do not support a holistic view for the decision support as they are either focussed one certain aspects of networks or the underlying processes. In contrast to the other methods simulation (nearly) don’t have any limitations regarding the complexity and supports a holistic view on the system to be considered. In addition simulation allows the integration of variability and uncertainty, which are always inherent in existing production and recycling systems. Thus it appears as a good candidate for an innovative decision support system. Unfortunately there are also disadvantages coming along with simulation. First of all each simulation study requires a model of the reality which will be executed within the simulator in order to get insights into the dynamics of the model which allows to draw conclusions on the behaviour of the real system. Usually the modelling process requires significant effort in terms of time and money. Therefore the application of simulation for complex but short-term scenarios is difficult due to the time, which is required for model building.


@


Interface

Information BaseInteractive InformationRetrieval

SimulationOptimisationOptimisation



Common




Data AcquisitionData Acquisition

Figure 4: Architecture of a simulation-based decision support tool Another problem covers the development of optimal or at least good solutions for a given decision problem. Due to its characteristic an environment for the emulation of systems simulation cannot propose such solutions on it’s own. In fact they are developed by conducting various experiments with slightly different parameter sets in order get insights regarding the sensitivity of certain parameters concerning the overall model behaviour. Afterwards the model can be adapted considering this knowledge. However in order to find a good solution some expertise and experience in modelling and analysis of simulation data is required which domain experts as decision makers and thus the users of a decision support tool usually do not have. However the obstacles depicted so far can be overcome with the availability of real-time information whereas the modelling effort can significantly decrease by utilising the available information in an (semi-) automatic way. Such an integrated simulation environment can be further interconnected with an optimisation module (whereas the feasibility of such an approach was already realised within the EU-funded project ONE – Optimisation methods for Networked Enterprises (Project No. GRD1-2000-25710), which in turn can support domain experts in order to identify good system configurations and make the right decisions. Figure 4 shows the architecture of such a simulation-based decision support tool. The tool comprises several functional components addressing the acquisition of data, which are delivered by external entities (e. g. transponders while passing reader gates). After data processing the resulting information is stored within a global information base. This component provides all of the information, which is required by the other components and can be interactively accessed by the component for information retrieval. Further modules are the integrated simulator, which allows the execution of models by integrating real time information delivered from the information base. The optimisation of specific models or scenarios is furthermore supported by the communication with optimisation components whereas as different versions can be integrated into the environment each of which addressing different objectives. Finally different components for animation and visualisation allow the representation of dynamic aspects related to the underlying system or functional modules as the simulator. All of these different components are integrated by using the same communication infrastructure which is accessed by a common interface whereas the approach depicted here follows the architecture proposed by the High Level Architecture (HLA) which was developed by the American Department of Defence for distributed simulation (Originally the idea for the HLA was derived based from the problem of reutilisation of existing simulation environment in order to save development time and costs).


@

At the end such enhanced environments will support the decision maker in order to identify system configuration or concepts covering the whole life-cycle of products which are flexible, efficient, robust and sustainable at the same time by using an holistic approach while considering system inherent variability and uncertainties at the same time. Further application fields of the solution proposed here covers training and education of decision makers based on a “virtual reality” which can be provided by the tool.

3.6.3 Conclusion and Outlook It’s obvious that the use of transponder technology in the whole product life cycle becomes a more important role. Traditional systems, like the barcode systems, will still exist especially in domains where the product price is on a relatively low level. Another possibility is e. g. the combination of both systems, barcode and transponder systems. This offers a high flexibility between both systems, which are depended on appropriate reader technology and safety information flows. If the storage capacity of transponder chips is higher than 100 kB it will be possible to store complete documents (e. g. data sheets) or language based information on the chip. Additionally a data collection during the whole life cycle of the product will ease the information generation of the impact from the product on the environment and human being. This will be important for strategic stakeholder decisions and offers new business models (e. g. payment of the product use and not product ownership). In future product embedded data storage systems might transform today’s centralised approaches in data storage to more independent data storage systems. In consequence this leads to new concepts of product ownership, where the owner not only owns the product but also related information gathered during the various stages of the life cycle.


@


@



VERSION NO. 1.3



Application Scenario Description CRF MOL



@

Revision History

Date (dd.mm.yyyy)


13.12.04 1.0 Mario Gambera The draft version submitted SINTEF














12.1.05 1.2 Mario Gambera Updated from point 3.8 on


Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisation E-mail Tel Fax Mario Gambera CRF [email protected] +39 (0)11 9083047


4 Application scenario description A4 CRF MOL Where discrepancies, the Demonstrator-document overrides all aspects of this scenario. Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario

- Assess usability of predictive maintenance strategies during usage of the vehicle in order to optimise maintenance policy in terms of

nr. of interventions saving of spare parts increase of vehicle availability

- Evaluate the use of PEID and wireless communication system in order to provide

complete and real time feedback to the company (design, production, after sales and marketing) about the:

mission profile of the vehicle mission profile and reliability of critical components and vehicle systems

Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil In the short period, increasing vehicle availability is essential especially for commercial trucks. Predictive maintenance strategies can greatly increase the “productivity on the road” concept. IVECO is putting great emphasis on this aspect. On a more long term view, the lack of information about vehicle and component mission profile is one of the major limits to the optimisation of product design. The collection of information made possible with the transmission of information to a ground station will allow to overcome this problem. Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work The proposed scenario relates to all four objectives of PROMISE inasmuch:

− It develops a new closed loop life cycle information model; − It contributes to the definition of a PLM and IT infrastructure; − It will contribute to new standards concerning Predictive maintenance strategies − It develops new business models appropriate to the MoL phase.

Specifically the objective more addressed by this applications are

− New standards concerning Predictive maintenance strategies − Business models appropriate to the MoL phase.

Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL MOL mainly Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues.


@

Trucks, ranking from light truck (IVECO Daily) to heavy lorry (IVECO Stralis). The scenario is also applicable to Bus for public transport. Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL The definition of statistics summarising the mission profile of the vehicle / component can be used for:

- provide direct feedback to the company design and production department - provide “forward” quantitative and certified feedback to:

o second hand vehicle owners o EOL applications for the last vehicle owner



MISSION PROFILE ID.

MISSION ANALYSIS


GROUND STATION


E C U

GPS GSM/GPRS

Signals



MAINTENANCE

REMOTE DIAGNOSTIC

LINK


Consumption analsys


MISSION PROFILE ID.

MISSION ANALYSIS


GROUND STATION


E C U

GPS GSM/GPRS

Signals



MAINTENANCE

REMOTE DIAGNOSTIC

LINK


Consumption analsys


@


C O M P A N Y

A fte r S a le s D e p t

D e s ig n D e p t

P ro d u c t io n D ia g n o s is g ro u pS U P P L IE R

U N A U T H O R IS E D G A R A G E

T ru c k o w n e r

P R E V E N T IV E A N D B R E A K D O W N M A IN T E N A N C E A S - IS IN F O R M A T IO N F L O W

A U T H O R IS E D G A R A G E

D ia g n o s is & m a in te n a n c e to o ls

O w n e r m a n u a lO n B o a rd D ia g n o s tc s


C o m p u te r ise d S y s te m fo r v e h ic le d ia g n .T ra in in gE x p e r t is e

C O M P A N Y

A fte r S a le s D e p t

D e s ig n D e p t

P ro d u c t io n D ia g n o s is g ro u pS U P P L IE R

U N A U T H O R IS E D G A R A G E

T ru c k o w n e r

P R E V E N T IV E A N D B R E A K D O W N M A IN T E N A N C E A S - IS IN F O R M A T IO N F L O W

A U T H O R IS E D G A R A G E


O w n e r m a n u a lO n B o a rd D ia g n o s tc s


C o m p u te r ise d S y s te m fo r v e h ic le d ia g n .T ra in in gE x p e r t is e

C O M PA N Y

A fter Sales D ept

D esign D ep t

P roduction D iagnosis groupSU PP L IE R

U N A U T H O R ISE D G A R A G E

T ruck ow ner

PR E V E N T IV E A N D B R E A K D O W N M A IN T E N A N C E A S - IS IN FO R M A T IO N FL O W

A U T H O R ISE D G A R A G E

T aylorised M aintenance C on tract

O utside W arran ty period only

W ith out m aintenance con trac t on ly

100% w ith in W arran ty period100% W ith m aintenance c on tra c t

F requenc y: N ot c ontinu ous, i.e . a t u se rs " in itia tive" (p lanned m aint or b reakdow n)N ot in realtim e

Som e rou gh in fo ab ou t vehic le h istory (m ilea ge , m ain repa ir and p lanned m ain te nance)P ossib le dow nload of som e e rror c odes com ing from O n B oard D ia gn)N o in fo ab ou t m ission p rofile

100% of ec on om ic de tails

B reakd ow n m aintenance on lyM ajor p roble m s on lyN ot rea l tim e

T echn. FeedbackT echn. FeedbackT echn. FeedbackT echn. FeedbackT echn. FeedbackT echn. FeedbackT echn. FeedbackT echn. Feedback


@

Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here. Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) Technical: The definition of the wireless transmission solution should be found compromising among these aspects:

- Amonunt of data - Transmission distance - Transmission frequency - Transmission cost - Cost of the wireless device

Ethical (other): Privacy problems are possible when tracking / recording user habits Other aspects related to the Application Scenario If some aspects are not are covered above, please use this field.


@

4.1 Technical issues A4 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA

Serial Network(CAN)

Wireless comm. System

Wireless Connection

Information flow Information flow (technical point of view)(technical point of view)

ECU 1

Possible Additionaldiagnostic

sensors

PEIDDiagnostic ECU

Component working condition

Component working condition

ECU 2

GROUND STATION

Information Typology

Low Inf. Density High detail Large space

Hig Inf. Density Low detail Small space

User messageALARM ALARM

PREPRE--ALARM ALARM

GOOD GOOD WORKING WORKING

ALARM ALARM

PREPRE--ALARM ALARM

GOOD GOOD WORKING WORKING


@

Data & Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc). Referring to the illustration above, and having in mind a PEID as a “network” of board computer + transm. devices, a first hypothesis of data going into the PEID can be classified as “raw data”, (mainly time histories), coming from:

Normal production sensor Added sensors Vehicle computer network in general

The amount of data and the typology of information that can flow into the PEID is, in principle, huge. Data & Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc). Referring to the illustration above, there are 2 kind of “data” (information) going out from the PEID:

User message to be displayed on the dashboard related to preventive maintenance strategies

synthesis / statistics related to preventive maintenance strategies and vehicle / components mission profile description

Data & Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs) Input data described above easily sum up to 100 different quantities Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed. See data flow. A body computer system in a modern truck is a Multiplex system with Several Body Computers, output devices (or output doors). Most of the computational capacity of this system is dedicated to the real-time management of the vehicle; the aspects of data collection and synthesis for “promise” purpose are less exploited Hardware: Life span of devices What is the needed minimum life span of the devices? 15 years Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc) In the vehicle there are mainly 2 working environment: motor compartment: temp: -20 + 100 high vibrations elsewhere: temp –2 + 40 low vibrations Some PEID for predictive maintenance won’t necessarily stay in the motor compartment (apart from some sensor)


@

Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Existing sw technology today used for on-line control strategy should be adequate. Some attention should be paid to the storing capacity of the PEID. Software: Middleware (software that allows different software applications to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Existing sw technology is adequate Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Existing sw technology is adequate Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Existing sw technology is adequate Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. A PLKM is assumed for management of information collected from the vehicles fleet during its entire life. Specific modules shall be provided with facilities for:

data mining pattern recognition decision making (decision support modules)

This software must be therefore able to perform advanced data analysis, statistical elaboration and provide adequate decision.


@

Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. There are at the moment 2 possibility to use synthesis / statistics related to preventive maintenance strategies and vehicle / components mission profile description information. The first solution foresee an architecture with a remote Backend software devoted to collect and analyse all the data collected from the vehicles. Decision support modules are described in section SOFTWARE: BACKEND SOFTWARE. The second solution foresee an architecture where data is processed locally (on the vehicle): no backend server is required. In this hypothesis, a “small” and “local” decision support module is foressen. In this case, the decision support module will obviously elaborate decision regarding the single vehicle only. Other aspects related to the Technical issues If some aspects are not are covered above, please use this field.


@

4.2 Business/economical issues A4 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. At present predictive maintenance is not yet an industrial application. As is situation described in Inf. Flow for MOL appl.ppt describes break down maintenance and preventive maintenance only. Maintenance policy is organised as follows: during the warranty period is performed by the company. Maintenance interventions can be preventive or due to a break down. Preventive maintenance plan is organised in a predefined and rigid maintenance calendar, (See picture). Maintenance policy outside the warranty period can be framed in personalised “maintenance contracts” or can be performed “at user request”. Maintenance interventions can be preventive or due to a break down. There is scarce possibility to foresee a breakdown and consequently to plan an intervention of this kind in advance.

TRADITIONAL PREVENTIVE MAINTENANCE CALENDAR

OIL

BRAKES

AIR filt.

Mileage

TRADITIONAL PREVENTIVE MAINTENANCE CALENDAR

OIL

BRAKES

AIR filt.

Mileage


@

To-be, Future scenario concept Describe in more detail the To-be solution/implementation. Describe it in such a way that it is related to the As-is description in above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Predictive maintenance strategies will act on 2 sides Regarding the preventive maintenance, it will be possible to define a user defined preventive maintenance calendar. This calendar will be at the same time more flexible and will be based on the actual consumption of the components; it will therefore allow a considerable spare. See figure illustrating customised maintenance calendar. Regarding the break down maintenance, the definition of predictive strategies will allow to increase the foresee some major breakdown. This will avoid an increasing percentage of breakdown and will give the possibility to plan these intervention.

Business effects (own business) – negative aspects Describe the negative business effects the application scenario (described in section 1) will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.) Development of effective preventive maintenance strategy for each critical component. These strategy should be developed:

for each component for each failure mode

They should be also enough general to be applied to several “alternatives” of the component. Updating of the maintenance strategy with the evolution of the component technology is also an issue.

OIL

BRAKES

AIR filt.

Vehicle availability

PREVENTIVE CUSTOMISED MAINTENANCEMileage

OIL

BRAKES

AIR filt.

Vehicle availability

PREVENTIVE CUSTOMISED MAINTENANCEMileage


@

Business effects (own business) – positive aspects Describe the business effects the application scenario will/could have on your business. (e.g. Improved business situation Business improvements opportunities (productivity, quality, environment, social issues) etc. Optimised maintenance with big economical impacts and environmental impacts. Referring to the “to be framework” par. TO-BE, FUTURE SCENARIO CONCEPT the following advantages can be foreseen:

saving of material / spare parts increase of vehicle availability and reliability increase of flexibility in the maintenance plan prodct cost reduction (design cost and product cost)

Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per PEID, support systems etc? It’s important to identify the maximum price range that can be added to a product/vehicle etc as a consequence of the aspects described in this application scenario. Describe therefore aspects that will have a consequence for costs, and in what range the “hurting” price for the customer (or users etc) will be. n.a. Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field.


@

4.3 Value-chain issues A4 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Actors considered in the scenario are (see also file”Inf flow for MOL pred. maint.ppt” and derived .pps):

the company afters sales dept the company design dept. (and related diagnosis group) the company production dept. the truck owner the authorised garage network the (generic) unauthorised garage the company suppliers network

Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) What kind of consequences will the application scenario have for the partners/business associates/customers etc in the value-chain (identified in 5.1). E.g. Dismantler: Dismantler must invest in new systems for reading/handling discarded products etc, but will have an upside regarding their operations of reuse/remfg etc as they more readily can… E.g. Customer: Customer will experience changes in their maintenance program this can be perceived as a positive or negative aspect (briefly describe why/how) Predictive maintenance development will impact on the whole value chain. The principal changes will regard:

after sales department. A data mining / dss unit must be foreseen for managing all the information. The natural host for this ground station is the after sales dept. New competencies should be acquired.

maintenance policy. An increase in the “full proof” maintenance contracts is unavoidable.

Authorised garage. They should be able to cope with prevdictive maintenance strategies and messages.



@

4.4 Environmental issues A4 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate. Considering par BUSINESS EFFECTS (OWN BUSINESS) – POSITIVE ASPECTS and preliminary evaluations, up to 30% saving of energy for each topic / component equipped with predictive maintenance strategies can be foreseen. Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. Considering par BUSINESS EFFECTS (OWN BUSINESS) – POSITIVE ASPECTS and preliminary evaluations, up to 30% saving of energy for each topic / component equipped with predictive maintenance strategies can be foreseen. Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. Considering par BUSINESS EFFECTS (OWN BUSINESS) – POSITIVE ASPECTS and preliminary evaluations, up to 30% saving of energy for each topic / component equipped with predictive maintenance strategies can be foreseen. Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field.


@

4.5 Social issues A4 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions See VALUE-CHAIN ISSUES Social Impact on society Describe, if any, implications of the application scenario regarding Social Impact on society n.a. Ethical issues Is there ethical issues related to the application scenario? IF Yes explain n.a. Other aspects related to the Social issues If some aspects are not are covered above, please use this field.


@



VERSION NO. 1.3

ELECTRONIC FILE CODE

dr3_2 appendix b application scenarios~1.doc


Application Scenario Description Caterpillar MOL

Written by: Howard Ludewig: Caterpillar Anthony Grichnik: Caterpillar Jean-Jacques Janosch: Caterpillar Keith Herman: Caterpillar Pat Ludewig: Caterpillar


@

Revision History

Date (dd.mm.yyyy)


1.0 See front page The draft version submitted SINTEF














1.2 Keith Herman, Howard Ludewig, Jean Jacques Janosch, Pat Ludewig Many changes


Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisatio

n E-mail Tel Fax

Keith Herman Caterpillar [email protected] Howard Ludewig Caterpillar [email protected] Jean Jacques Janosch Caterpillar [email protected] Pat Ludewig Caterpillar [email protected]


5 Application scenario description A5 CATERPILLAR MOL Where discrepancies, the Demonstrator-document overrides all aspects of this scenario. Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario The purpose of this scenario is to identify the basic framework for implementing the PROMISE methodology on construction and mining equipment. The application scenario focuses on information that is gained during MOL events and how rigorous management of the information can improve MOL responsive to the event as well as provide feedback to BOL functions and tracking of EOL information. The demo case for this scenario will be based on the Track Type Loader (TTL) or Track Type Tractor (TTT) as shown in Figures1 and 2, respectively.

Figure 1: Caterpillar Track Type Loader.

Figure 2: Caterpillar Track Type Tractor. The primary objective of the proposed scenario is to take available information on the vehicle and convert it into an action that improves responsiveness to customer requirements. In addition this information can provide feedback to the design and manufacturing sources as well as waste stream management to make these processes more robust. Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil The scenario will be used to identify, test, and document the information requirements, component requirements, information flow, and business case relative to life cycle management. The focus of the scenario is MOL responsiveness to customers needs. However, there is a requirement for a systematic approach for identifying the opportunities to convert the data that is gathered during the defined MOL process into useful knowledge to better manage the design, production, and waste management processes. In this context the waste management processes includes recycling, remanufacturing, and disposal. Standard systems must be developed where possible to facilitate data flow and data management.


@

Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work PROMISE main objective #1: To develop new closed-loop life cycle information flow models for BOL, MOL and EOL. This scenario will use information relative to component life and failure modes gained during MOL to enhance the design process in BOL. It will use field population data and implied demand to enhance the logistics information for the component providers in the production phase of BOL. It will also provide for the study of waste stream data to optimise EOL processes. PROMISE main objective #2: To develop new PLM system and IT infrastructure exploiting the capabilities of smart product embedded information devices. Embedded devices will form the bases of the data and information tracking during the MOL event that triggers the process. These devices will continue to be used during MOL to track and document data relative to the product performance, service, and maintenance. PROMISE main objective #3: To develop new standards to allow the technologies and associated tools to be developed by the PROMISE project to be accepted by the market and allow it to expand quickly by creating an appropriate environment for the development of new innovative applications. Standards will be required to convert the event data into a actionable information package. In addition the scenario will support the need for standards in device and information protocols. PROMISE main objective #4: To develop new working and business models appropriate for the use and exploitation of the new technologies and tools to be developed by all actors involved in a product lifecycle. The scenario will be used to identify, test, and document the information requirements, component requirements, information flow, and business case relative to life cycle management. This will include processes and information management that will facilitate EOL activities including quantification of recyclable content and processes to validate proper levels of recyclable content as well as disposal processes. Opportunities for safety improvements will also be investigated. Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL This scenario is primarily related to MOL activities. However, it impacts both BOL and EOL process as previously stated. Information will be collected from the machine during use. When onboard data processing determines that there is an “event”, this event data will be transmitted to the appropriate source. For example, a major failure should transmit information directly to the service people (MOL). Logistics information would also be sent out so the replacement part(s) (BOL) could be put in route to the destination of the failure. Manufactures would also be contacted in the case that no parts are available or if the supply of the needed part(s) falls below a designated quantity (MOL). Other importance performance data could be transmitted to the service people and/or designers to help understand how to determine the source of the problem or improve the design. (BOL). Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues. The product to be used in this scenario will be either a track type tractor or a track type loader, depending on which fits better with the Promise scenario.


@

Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL The interfaces between the lifecycle phases are shown in ILLUSTRATION OF THE INFORMATION FLOW. There are two feedback points from MOL to BOL. The first is where part information is feed back to the design process. This includes but is not limited to cause of failure, usage data, and length of life. The second point is information feedback to the production process. This includes logistics information relative to field population, implied demand, and forecasting. The last interface point is between MOL and EOL processes. This includes recyclable content data as well as validation data for waste stream management. Illustration of the application scenario Provide an illustration of the application scenario that can be used for communication purposes (e.g. in trade magazines, on the front of reports, slide shows etc). Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file.

Service

Manufacturing

Recycle

Remanufacture

Dispose

Sensors/ RFID

Technology


Sensors/ RFID

Technology


PDKM

Production Needs

Logistics Information

Logistics

Automatic Service Call

Performance Information

Design Engineering

Critical Machine Information

EOL

Information on Machines put out of service


@

Illustration of the information flow (flowchart) In order to identify informational requirements, illustrate the flow of information and clearly identify information/data flows by denoting this in the figure. Use rectangles, arrows, circles etc with text. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Product Life Cycle Managemnt

End Of LifeMiddle Of LifeBeginning Of Life

Product Operatingin a Field

Application

Event Trigger

Diagnostics & Logistics ActionPrognostics Extension

CommonTransmission

Device

Action to be taken

RFID info ofaffected components

Service Provider Logistics PullTriger

New ComponentsUpdated RFID

Information

Information onwaste streamcomponents

Recyclable contenthow to measure

how to verify

Remanufacture

Recycle

Dispose

LogisticsInformation forPart Provider

DesignInformation

What is failingWhy it fails

usage data (RFID)Length of life

Field PopulationImplied Demand

ForecastingPrognostics

Trigger Table

Figure 3: Flow chart of the TTL Application Scenario.

Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here. Collection and documentation of User Requirements is not a straightforward process relative to a broad based implementation of this scenario. The best way to get this information is through a combination of interviews and brainstorming sessions. If the right people can be pulled together, a series of “focus group” brainstorming sessions may be the best tool to fully understand the process requirements. Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) The single most important challenge will be getting consensus of standardization issues in both hardware and software protocol, communications, and data structures.


@

Other aspects related to the Application Scenario If some aspects are not are covered above, please use this field. There are several requirements for this scenario that must be fulfilled for it to be successful. The real challenge is to develop standard methods and protocols that can be used for a number of different applications. The process start point is defined as a TTL or TTT operating in the field as illustrated in the top of the MOL box in figure 3. In fact this can be characterised as any machine with some diagnostic and prognostic capability operating in its designed application. The diagnostic and prognostic capability is unique to the machine and out of scope for the PROMISE scenario. What is in scope and needed to facilitate the implementation of this scenario is the trigger table that converts the diagnostic and/or prognostic output into an actionable item. An example of what a trigger table might look like is presented in Figure 4.

MOL Event Action to be takenLevel 1 Maintenance Required Contact Field Service (low Priority) Level 2 Service Required Contact Field Service (medium Priority) Level 3 Service Required Part Failure (high Priority) Level 4 Machine Down Major part failure (immediate action required)

Figure 4: Example of a trigger table.

Figure 4 is a very simple example to illustrate the structure of the trigger table. The PROMISE team will have to better develop the table in detail for it to be useful across multiple applications. The next major issue is selection a common transmission device that can appropriately communicate action requirements. This has to include the integration of the RFID of affected components. The challenge will be in developing standard protocols and data structures. The final challenge will be to fully define the information flow between the MOL process and the BOL and EOL processes. Some high level concepts are included in Figure 2. However, these will have to be further defined and specified by the PROMISE team. If RFID readers are to be installed on machines, a safety opportunity could be available. Dangerous items (electricity, fuel), other machines, and people could carry “warning” RFID’s. When the machine gets in proximity of one of these “dangers”, the operator could be notified. Other safety scenarios could be developed by considering that catastrophic failures could be sensed before they occur letting the operator know to shut down the machine.


@

5.1 Technical issues A5 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA. Data will be collected from sensors. In a finished product, this sensor data would be processed by an on-vehicle PC. For the Promise demonstration an alternative solution will need to be established to simulate this PC. It is in the on-board PC that the decision will be made to trigger an event and what information must be transferred. There should also be an interface for service man and/or operators to enter information about service, performance, etc.

Machine (TTL)

On-v ehicle PC(ex: machine)

Sensor

Sensor

Sensor

Sensor

TransmissionDev ice

Operator /Maintenance

ManualInterf ace

Serv ice Inf ormationProcessedEv ent trigger

inf ormation

PLM Sy stem

Ev ent Trigger Inf o (Wireless)

On-v ehicle PC(ex: engine)

Processed Ev entTrigger Inf ormation

ComponentSuppliers (BOL)

Logistics inf ormation -Qty & Timing

Dealers (serv ice)

Serv iceNeeds &Priority

Design Control(BOL)

Perf ormanceData

ComponentRFID

ComponentRFID

ComponentRFID

RFID Reader

On-board components& Serial Numbers

Part Numbers &Serial Numbers

Logisticsinf ormation

Manuf acturing(BOL)

MfgIssues

EOL

Remanuf actured Components

Data&Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc).

• Sensor data from a range of sensors. • Manually entered data from servicemen • RFID information identifying machine components


@

Data&Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc).

• Time/Date stamp • Event type • Relevant Event data • Action Required • Product serial number (TTT or TTL) • Component serial number (Specific component in question) • Machine hours • Component hours • Relevant sensor information (condensed or raw data) • Maintenance information • Misc. user input - . . If there are large amounts of sensor data that cannot be transmitted, an event could be triggered which informs a service man to come and manually collected the needed data from the machine and clear the storage device.

Data&Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs) At this point, it is not clear where or what data will be stored. The application scenario needs a bit further refinement to come to that stage. Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed. Unknown Hardware: Life span of devices What is the needed minimum life span of the devices? Since Caterpillar machines live for decades (50+ years) in the field, the life should be quite long. This should, at a minimum, match the time to the first major overhaul of the machine where devices could possibly be replaced. Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc) Caterpillar machines work in very rugged conditions. Both extreme heat (55 °C) and extreme cold (-30 °C) conditions are encountered. Vibration, impact, large amounts of dust, oil, rain, mud, etc are also part of the normal operating conditions. These machines work in all weather conditions.


@

Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Software should be user configurable and relatively open so that the user (Caterpillar or a dealer) can customise it to fit a specific customer’s needs. It could then also be customised monitor multiple components on a machine (engine, critical structures, etc) Software: Middleware (software that allows different software applications to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. See SOFTWARE: FIRMWARE (EMBEDDED SOFTWARE) Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. See SOFTWARE: FIRMWARE (EMBEDDED SOFTWARE) Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. See SOFTWARE: FIRMWARE (EMBEDDED SOFTWARE) Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. In a final product, all decisions would be made by proprietary Caterpillar software, however we will need a solution for the Promise demonstration. Possibly a portable PC could be placed on board the product to perform data analysis and storage for the demo. The need for storage would most likely be needed only in the case that the volume is too great to transfer with the chosen communication device. Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. See SOFTWARE: BACKEND SOFTWARE Other aspects related to the Technical issues If some aspects are not are covered above, please use this field. N/A


@

5.2 Business/economical issues A5 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The as-is situation is that all information from the machines must be manually collected from a limited number of sensors. Because of this there is no PLM infrastructure in place to handle this real time data collection. To-be, Future scenario concept Describe in more detail the To-be solution/implementation. Describe it in such a way that it is related to the As-is description in section 0 above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The to-be situation is the incorporation of more sensors on the machine as a “standard” with the PLM infrastructure to utilize the valuable data. Business effects (own business) – negative aspects Describe the negative business effects the application scenario (described in section 1) will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.)

- Caterpillar is a large global organisation with products in use on every continent. This would require systems to be produced in many languages and the system would be required to handle very large amounts of data.

- Caterpillar machines are serviced by independently owned dealers. Implementation and training of such a system will/would require a large investment with these dealers.

- Some customers may perceive that Caterpillar is spying on them in order to avoid paying warranty claims.

Business effects (own business) – positive aspects Describe the business effects the application scenario will/could have on your business. (e.g. Improved business situation Business improvements opportunities (productivity, quality, environment, social issues) etc. For MOL activities, the critical data for the machine could be obtained without the expense (of the customer) of stopping the machine. This could improve customer satisfaction. This could also allow dealers to better manage their resources and be more profitable. It would also allow them to better service their customer, giving Caterpillar an advantage over their competition.


@

Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per PEID, support systems etc? It’s important to identify the maximum price range that can be added to a product/vehicle etc as a consequence of the aspects described in this application scenario. Describe therefore aspects that will have a consequence for costs, and in what range the “hurting” price for the customer (or users etc) will be. This would need to be determined on a cost-benefit basis. Caterpillar customers buy machines to make money. Considering this fact and the fact that the customer has spent a quite large sum of money on a machine, cost would not be the primary focus if the device would allow for lower owning and operating costs. Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field. N/A


@

5.3 Value-chain issues A5 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. For replaceable or “consumable” parts of a machine, the supplier/manufacturer of a specific component could automatically be contacted in advance of the need of a new component as sensed by the machine. This would allow for the new component to be produced and delivered to the appropriate location just before it is actually needed. In many cases, this replacement could occur during the normal maintenance schedule of the machine. See diagram in section ILLUSTRATION OF THE APPLICATION SCENARIO. Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) What kind of consequences will the application scenario have for the partners/business associates/customers etc in the value-chain. E.g. Dismantler: Dismantler must invest in new systems for reading/handling discarded products etc, but will have an upside regarding their operations of reuse/remfg etc as they more readily can… E.g. Customer: Customer will experience changes in their maintenance program this can be perceived as a positive or negative aspect (briefly describe why/how)

• At a high level, a large investment will be needed to implement the needed infrastructure and supporting processes. If the customer will accept such a system.

• Customers may not agree to have Caterpillar monitoring their machines. For example, if Caterpillar could prove that the customer was abusing their machine (regularly exceeding established capacity), they would be denied

• In some countries, there could be legal issues with Caterpillar monitoring a customer’s machine.

Other aspects related to the Value-chain issues If some aspects are not are covered above, please use this field. N/A


@

5.4 Environmental issues A5 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate. We do not fully know the level of scope for this application at this time. However, the utilization of a predictive and preventative maintenance tool will optimise energy efficiency of the product. Thus, energy will be realized in reduced fuel consumption. Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. Real-time predictive and preventative measures during the life cycle of the product will prevent hard failures and promote the retention of value added from the original manufacturing. Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. Baseline data shows that annual worldwide material savings resulting from remanufacturing activities is 14 million tons, according to the “National Center for Remanufacturing and Resource Recovery”. Other sources indicate that this represents less than 20% of the total opportunity. Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field. The primary advantage that is not covered above is the conservation of landfill space and the decrease in the use of virgin natural resources that will result from improved proactive fleet management.


@

5.5 Social issues A5 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions • Improved training processes. • Proactive maintenance Information feedback to the design and manufacturing process will produce user-friendly products. (Operator comfort, safety, satisfaction of the product user …) Social Impact on society Describe, if any, implications of the application scenario regarding Social Impact on society

• Reduced pressure on natural resources. • Reduced green house gas emissions

Ethical issues Is there ethical issues related to the application scenario? IF Yes explain Privacy? Does Caterpillar have the right to monitor the use of a customer’s machine? This is an issue that probably varies from country to country. Other aspects related to the Social issues If some aspects are not are covered above, please use this field. N/A


@


@



VERSION NO. 1.4



Application Scenario Description FIDIA

Written by: Daniele PANARESE, FIDIA Michele SURICO, FIDIA


@

Revision History

Date (dd.mm.yyyy)


10.12.2004 1.0 Fabrizio MEO The draft version submitted SINTEF
















2.9 – 3.1 – 3.4 - 3.5 - 3.9 - 5.1 - DESCRIPTION UPDATED


Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisation E-mail Tel Fax Daniele PANARESE FIDIA [email protected] +39 080 5856270 Michele SURICO FIDIA [email protected] +39 080 5856270


6 Application scenario description A6 FIDIA Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario Fidia is a world leader in the design, construction and marketing of integrated systems for the machining of complex forms for the moulds and dies industry. Moulds and dies are used in the manufacturing of mass-produced products. Consequently, they find application in a very wide and increasing range of production sectors owing to the cost-effective pressing and moulding production process. Fidia manages all the technological areas, allowing for complete management of the milling process, from the post-design phase to the finished product. In particular, Fidia produces and markets: Numerical controls for milling systems; High-speed milling systems; Servo drives for milling systems. Fidia technology is focused on the production of more complex moulds and dies (i.e. where the form to be produced involves extremely sophisticated machining of the material). It finds application largely in the automotive industry (style models, tools, dies and moulds), aeronautical industry (undercarriage, turbines), footwear sector (style models, prototypes, dies and moulds) and for the manufacturing of various complex items. Fidia machines are often customised according to the needs of each individual customer, and high costs are usually incurred in production losses due to machinery breakdown, customers ‘on-site’ assistance during the set-up stages, as well as during the later stages of the life cycle of the machine, whenever maintenance work is needed, especially in the frequent case where the user site is several hundreds or thousands of kilometres from the supplier site. Modern Information Technologies offer the opportunity of dramatically reducing machine unavailability through the enhancing of their diagnostic performances. According to these issues the scenario objectives are:

• diagnosis of the machine (prediction of interventions for substitution of mechanical parts, self tuning);

• traceability of components. Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil Prediction of interventions for substitution of mechanical parts is important because it allows to optimize the management of production. It is very important to prevent faults and to minimize machine unavailability. Traceability is important because allows the machine builder to know at any time in which machine a component is installed. Some eletrical or mechanical components once repaired could be installed on other machines, but the machine builder could ignore on which system that component was installed. At the next fault or reparation, it could be desiderable to know the provenience and the ‘history’ of that element for two reasons: statistical analysis of working conditions; feedback to the engineering team.


@

Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work Diagnosis of the machine and Traceability of its parts and components, have as goal the use of smart embedded IT systems monitoring product information during its lifecycle at any moment and at any place in the world fully according to PROMISE objectives. Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL Machine diagnosis in the sense of a preventive maintenance is related to the MOL because it monitors how the machine is working day by day and how it is going to work in the next future, related to the degradation of components. Traceability is related mainly to the MOL, but it involves relation with BOL and EOL because it allows to know the whole life of a component of a machine. Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues. Product considered in PROMISE scenario is milling machine. Milling is the process of cutting away material by a rotating cutter. Milling systems are made up of multiple mechanical axes moved by electric drives that are able to translate and rotate the milling head in the workspace. The milling head is made up of a rotating spindle equipped by a set of many different machining tools that allow the realization of various and complex forms. Fidia milling systems are small-medium working range high-speed systems, that offer substantial advantages compared to traditional milling machines. Fidia high-speed technology has improved quality and reduced manifacturing times significantly. The milling systems are controlled by a numerical control. Fidia numerical controls are designed to control milling systems for the machining of complex forms. Accuracy and the quality of the finished product are their most important characteristics. Numerical controls are electronic devices which, by means of specific data processing software programs, automate the operation of machine tools and production plants. The software incorporated in the numerical control "reads" the static mathematical data and transforms this data into dynamic electrical data, i.e. into commands for making the tool execute the sequence of movements required in order to produce the desired shape by milling the part. Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL RFIDs could be useful in order to store data of each component of a milling system from the beginning of its life to the end. In fact in BOL could be stored data like dimension, weight, material, etc… in MOL could be added data reflecting how the component is working (scenario objectives), and at the EOL it could be possible to understand reading the huge amount of information stored in the RFIDs the behavior of the component for a feedback to the manifacturing designers. The application scenario even offers an interface to BOL and design. One of the results is the continuous improvement of products: the diagnostic module will be able to identify the most critical parts in the system, and to substitute them, through a change in the design of the product.


@

Illustration of the application scenario Provide an illustration of the application scenario that can be used for communication purposes (e.g. in trade magazines, on the front of reports, slide shows etc). Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Illustration of the information flow (flowchart) In order to identify informational requirements, illustrate the flow of information and clearly identify information/data flows by denoting this in the figure. Use rectangles, arrows, circles etc with text. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. See Illustration of Application scenario Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here. In order to be integrated in a milling machine RFIDs are needed to be small few millimeters, cheap less than 10 euros, capacious at least 200 kByte. More accurate estimate will be provided during the project. Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) None Other aspects related to the Application Scenario If some aspects are not are covered above, please use this field. None

Machine tool Component

RFIDs

CNC

Sensors

Software for Diagnosis and

Preventive Maintenance



@

6.1 Technical issues A6 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA In order to allow diagnosis applications and traceability features on Fidia Machines , RFIDs should gather information like: who built the component and when; when the component was installed on a machine, disinstalled and installed on another machine…; information to be used as a term for comparison for detection of degradation, condition diagnosis. This information flow should be realized by radio transmission between RFIDs and the Computerized Numerical Control (CNC). Data&Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc). Data related to the design of component; Data related to the life of component. The life of component is represented by a set of suitable parameters that take a picture of the state of the component. Data&Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc). Same as input data Data&Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs) Due to monitoring and traceability purposes it is required a huge amount of data to be stored during the life of the component. Memory required could be exstimated in kbytes Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed. Sensors (position, temperature) are currently used in a milling machine and they have a wire connection. RFID wireless technology will be developed in order to integrate data and information gathered by sensors and to develop new knowledge and decision making features. Hardware: Life span of devices What is the needed minimum life span of the devices? RFIDs in order to be applicable to the components of a milling machine, should have life span not less than life span of the components that should be monitored (about 30 years).


@

Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc) Fidia would apply RFID on its milling systems that have hostile working conditions. Milling centres are characterized by smokes, metal shavings, heat. It would be desirable to install RFIDs on mechanical components which translate or rotate in their working conditions. Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. None Software: Middleware (software that allows different software applications to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Middleware is FIDIA user interface running on Windows or Linux operating system. Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. None Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. D2B software should allow devices (RFIDs) to communicate with the CNC. CNC should be able to read data from and write data on RFIDs. This could be achieved using software tecnologies like “dll” or “ocx” . Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Backend software should manage a database containing data of all the components of a machine, and should be able to do statistical analysis, in order to evaluate “health state” of each single component, and its estimated end of life. This would allow a more efficient production management. Backend software would run on the CNC of each machine or on a Central PC dedicated to the management of several machines. Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Decision support software, gathering data from RFIDs, will run locally on the PC of the Numerical Control. This software should do: suitable tests on the machine; elaboration of data and extraction of relevant parameters; making decision, starting from these parameters, trough A.I. algorithms (neural networks, kalmann filters, etc…). Data and parameters need to be read/written in RFIDs using libraries mentioned in 3.11 .


@

Other aspects related to the Technical issues If some aspects are not are covered above, please use this field. Hardware and software platforms in use CNC is a computer with several boards integrated on bus PCI. The PC of the CNC is based on Windows operating system that allows several Windows software applications to be runned. The User Interface is a Visual C++ application that allows the user to manage overall the machine.


@

6.2 Business/economical issues A6 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Today a failure on a milling machine implies:

the sudden interruption of a manufacturing process (loss of production); the intervention of a technician to repair the machine (travelling and manpower costs).

These costs weigh on the Builder Machine and on the End User. To-be, Future scenario concept Describe in more detail the To-be solution/implementation. Describe it in such a way that it is related to the As-is description above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. In the future the diagnostic module could:

minimize the unavailability of the machine because it could prevent sudden interruption; reduce the maintenance costs because the technician would intervene only when a

component substitution is required. GAP analysis of As-is and To-be Identify the gaps between the As-is and the To-be. Reduction of costs for both the Builder Machine and the End User. Business effects (own business) – negative aspects Describe the negative business effects the application scenario (described in section 1) will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.) None Business effects (own business) – positive aspects What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per PEID, support systems etc? It’s important to identify the maximum price range that can be added to a product/vehicle etc as a consequence of the aspects described in this application scenario. Describe therefore aspects that will have a consequence for costs, and in what range the “hurting” price for the customer (or users etc) will be. Increase of production; and Increase of quality of technical assistance to the End User. Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per device. Because of RFIDs would be installed on several components and several RFIDs could be installed per component, the device should cost less than € 10. Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field. None


@

6.3 Value-chain issues A6 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Customers: Higher quality of technical assistance to the End User. Fewer production stoppages. Lower technical assistence fares. Technical Assistence: Lower travelling and manpower costs for each intervention. Facilitations in their work. Design department: Better comprehension of malfunctions and breaks. Improvement of design (reliability, technical quality,etc…) Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) What kind of consequences will the application scenario have for the partners/business associates/customers etc in the value-chain. E.g. Dismantler: Dismantler must invest in new systems for reading/handling discarded products etc, but will have an upside regarding their operations of reuse/remfg etc as they more readily can… E.g. Customer: Customer will experience changes in their maintenance program this can be perceived as a positive or negative aspect (briefly describe why/how) None Other aspects related to the Value-chain issues If some aspects are not are covered above, please use this field. None


@

6.4 Environmental issues A6 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate. None Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. None Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. The integrated use of RFIDs in a diagnosis module, clearly extends product life because to intervene at the beginning of a failure can avoid serious consequencies to the machine. The use of RFIDs for traceability issues can allow the reuse of a substituted component being sure of its “quality” due to the history written on itself. Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field. None


@

6.5 Social issues A6 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions None Social Impact on society Describe, if any, implications of the application scenario regarding Social Impact on society None Ethical issues Is there ethical issues related to the application scenario? IF Yes explain None Other aspects related to the Social issues If some aspects are not are covered above, please use this field. None


@



VERSION NO. 1.3



Application Scenario Description A7 MTS MOL

Written by: Marra Lorenzo: Teleassistance Manager, MTS


@

Revision History

Date (dd.mm.yyyy)


20.12.2004 01 Lorenzo Marra First draft of MTS gas boiler application scenario














14.01.2005 1.2 Lorenzo Marra • 2.11 Added security issue;

• 6.3 extended lifetime of boiler control board is mentioned;


Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisation E-mail Tel Fax Lorenzo Marra Teleassistance

Manager [email protected] +39-071-7200568 +39-071-7100275


7 Application scenario description A7 MTS MOL Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario The goal is to systematically collect and store the data relevant to the application and to apply evolutionary diagnostic and prognostic algorithms over the product lifespan (MOL). Gas boilers will be installed in the field and data collected will be handled by PLM developed in PROMISE. The goal of this application cluster is to validate on a real application what developed on RC2, RC3 and RC4 by other partners. The purpose of the scenario is to give to after sale service a tool to improve the maintenance and repairing operations of wall hung gas boilers during MOL. Prognostics algorithms are very relevant in this application scenario because they allow service people to replace a component before it has a failure, thus allowing higher availability of the gas boiler (the user will not have a cool house because the boiler is in lock-out). Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil The objective is important because the maintenance and repairing operations during MOL are responsible of keeping gas boilers working with high efficiency, low polluting emissions and always available. The objective is important to fulfil because it will improve environment and customer satisfaction. Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work MTS application scenario is related to following PROMISE objectives:

• PROMISE intents to realise the seamless e-Transformation of Product Lifecycle data and Information to Knowledge;

• PROMISE will develop new tools and interfaces to allow human beings to seamlessly communicate with products;

• PROMISE invests on smart Product Embedded Information Devices (tags) as a basis of the proposed technology.

Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL MTS application scenario is related to MOL. The relevance of MOL is explained by the interest of MTS to efficient operation of Service Companies working on maintenance and repair of MTS’ boilers. Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues. MTS will make available a certain number of wall hung gas boilers, that have to be supplied by Natural Gas and installed in domestic houses. They are suitable for both istantaneous Domestic Hot Water production and Central Heating. The output power can be modulated between 8KW and 24KW.


@

Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL At the time being in MTS structure there is not an interface between BOL/MOL to EOL; so MTS doesn’t receive back from the field information on EOL of its boilers. On the contrary there is an information flow from MOL (boiler repairing) to BOL (boiler developing and production). MTS receives from After Sale Service companies informs MTS Call Centre or Quality department of malfunctions, installation problems, frequent failures of components. These information are used to correct project error or improve quality, e.g. acting on internal production process or on production processes of MTS’ suppliers. Illustration of the application scenario Provide an illustration of the application scenario that can be used for communication purposes (e.g. in trade magazines, on the front of reports, slide shows etc). Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file.


MTS Brown-goods demonstrator for MOL

Serial protocol already implemented on boiler control board

PEID (developed in RC2 and provided by involved partners)

Sensor: developed in RC2 and provided by involved partners

RF short distance

Internet communication (long distance)

-PLM -Preventive Maintenance algorithms Developed in RC4

Boiler provided by MTS


@

• Gas boiler control board:

o it manages both safety and regulation functions of the boiler; o it is provided by MTS and certified with the boiler itself. The gas boiler control board

has a certain number of digital (central heating pressure switch, air pressure switch,…) and analog input (central heating flow temperature, central heating return temperature, Domestic Hot Water temperature) and also a certain number of digital (220VAC for fan/pump/diverter valve driving) and analog output (for gas valve modulator);

o it is provided with a serial protocol through a 3 wires connection (RX-TX-GND) directly connected to the UART of gas boiler control board’s microprocessor; through this protocol the PEID can retrieve from the gas boiler control board all info on input/output status and can also read/modify functional software parameters of control board;

o the specification of this serial protocol will be provided under NDA by MTS to the Promise partner which will develop the PEID for long distance communication over the internet to Promise PLM; this partner will implement MTS protocol and MTS will support this partner in testing and debugging it;

µP

PROMISE PLM: • Prognostic algorithms for preventive

maintenance; • Failure detection; • Parameter modification in boiler

software;

Internet long distance communication

Service Centre company can access Promise PLM web site to access info on already detected boiler failure, prognostics of future failures. It can also dial/open a connection with PEID and so view actual boiler sensor/actuators state and view/change boiler SW parameters (e.g. heating system temperature). In case of a detected failure or prognostic of a future failure Promise WEB site sends an e-mail to Service Centre e-mail address

PLM WEB site

Service engineer (the technician that is in the car going to repair boilers) have to receive an e-mail and/or SMS to be informed real time of a detected failure

WEB site internet access

e-mail

e-mail and/or SMS

Gas Boiler

Gas Boiler control board µP

3 (Tx,Rx,GND); 0-5V UART

Sensors with RF short distance communication (optional)

PEID with RF short distance comm. and internet long distance communication to Promise PLM

RF short distance communication

End user can switch ON/OFF the heating system and set the desidered room temperature from WEB site or SMS. The PLM have then to transmit this command to the PEID and the PEID to the gas boiler.


@

o in order to guarantee the gas boiler safety, the RX-TX-GND of PEID must be compliant to SELV (Safety Low Voltage Directive); EMC testing on Gas Boiler equipped with PEID + Sensors with RF communication must be performed in order to achieve the CE approval and so to be allowed to install these boilers in the field;

Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here. • It must be possible to have bi-directional communication to Gas boiler control board through

Gas boiler control board serial protocol (MTS protocol); • It must be possible to access data related to gas boiler through a WEB site; • Service Centres and Service engineers must be advised through WEB site, e-mail and SMS of

an already happened failure or of failures that are going to happen. • It must be possible to get an information that a failure is going to happen through prognostic

algorithms (PREVENTIVE MAINTENANCE); Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) The most important challenge is related to the reliability of a prognostic algorithm to estimate the probability that a failure on a specific component can happen in a certain time period. This reliability depends on the statistics technique used to analyze data, on mathematical models used to describe the gas boiler on the DOE technique used to gather data from the boiler through limited amount of experiments. MTS has not the expertise and know-how on DOW, statistics technique and mathematical models; this expertise is expected from other partners, like CRF. MTS has the expertise on the product, on the failures which are more important to detect before they happen, has the laboratory facility to carry out experiments and has products on which apply what developed in PROMISE in order to evaluate in the field the performance of the project. Other aspects related to the Application Scenario If some aspects are not are covered above, please use this field. Security issue must be considered, not only regarding possibility that an hacker takes control of household appliances but also regarding privacy and security of all information flowing and stored in PLM. Passwords and Usernames must be treated with highest level of security and also the communication over short distance and long distance must be protected. In any case, we have already implemented in boiler control board microprocessor a protocol with checksum that ensures again corrupted data wrong handling. I would like to point out very clearly that any wrong communication or hacker cannot drive the gas boiler into a not safe condition (e.g. an hacker could switch on the boiler but cannot let the valve be opened even if there is not flame detected, thus generating a flow of unburned gas that can cause explosion). This is not possible because the safety of the boiler in ensured by its control board against any kind of disturbances or/and errors.


@

7.1 Technical issues A7 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA

Data&Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc). Temperatures, switches status, actuator status (both digital/analog), historical data, parameters value, boiler status (Central heating, Domestic hot water), command to modify parameters (e.g. Central heating temperature). Few megabytes/year max should be transmitted. Data&Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc). The same data retrieved by PEID from Gas boiler control board, through MTS serial protocol, and from eventually present other sensors, through RF short distance communication, must be locally logged and sent to PLM in case of:

• A failure is detected by PEID; • Other diagnostic events are detected by PEID; • Timer of X days expired (this timer must be implemented in PEID software); • Request sent by PLM to PEID to retrieve data present in log memory; • Counter of Y nr of cycles expired (this counter must be implemented in PEID software); • Counter of Z nr of burning hours expired (this counter must be implemented in PEID

software); • Other events to be specified;

Gas Boiler control board

Additional sensors with RF short distance communication

Temp Sensors

Flow/Pressure Switches

Actuators (Pump, fan, gas valve,…)

PEID

MTS serial protocol

RF short distance communication

Promise PLM

Service Center Office

SMS/e-mail

Service Center Technician

WEB site and SMS

WEB site and e-mail

Final User


@

Data&Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs) 1 Mybte of data flash should be enough Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed. MTS has not specific technology to require. Hardware: Life span of devices What is the needed minimum life span of the devices? 20 years Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc) -10°C; +75°C Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. MTS has not specific technology to require. Software: Middleware (software that allows different software applications to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. MTS has not specific technology to require. Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. PEID must implement the MTS protocol to communicate to gas boiler control board. Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. MTS has not specific technology to require. Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. MTS has not specific technology to require. Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. MTS has not specific technology to require.


@

Other aspects related to the Technical issues If some aspects are not are covered above, please use this field. MTS has not specific aspects to require


@

7.2 Business/economical issues A7 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. At the moment MTS has developed a GSM/GPRS modem to be connected to gas boiler control board. This modem retrieves info from the MTS protocol and sends it to a WEB site. From the WEB site it is also possible to dial the boiler and see sensors/actuators status. It is also possible to see/modify functional parameters. When an error occurs, service center can see on the WEB site all info related to the failure and the service engineers is advised of the failure by SMS. To-be, Future scenario concept Describe in more detail the To-be solution/implementation. Describe it in such a way that it is related to the As-is description in section 0 above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. In the future scenario, not only must be possible to inform Service organization of an already happened failure, but must also be possible to advise the service organization of a failure that is going to happened in the next future (PREVENTIVE MAINTENANCE). It must be possible to detect also in which component is the failure going to happen. In this way the service engineer can plan in advance to visit the customer and bring with him the right spare parts. This will allow to reduce double visits, being the service engineer informed exactly of what is the problem, improve the service efficiency, avoiding that the service engineer replaces a component that is not responsible for the malfunction, and offering to the end user 100% availability of the boiler because a failure will never happen thank to prognostic algorithm. The gap between the AS-IS and the TO-BE, is mainly due to the absence of prognostics algorithms, decision support software that are able to inform service engineers of a failure that is going to happen and to the action to be done (replace a component, clean the exchanger,…) to avoid it. Business effects (own business) – negative aspects Describe the negative business effects the application scenario (described in section 1) will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.) Such application scenario will reduce the amount of manpower needed to service organizations, thus creating potential conflicts with service engineers. In addition the final user can feel as observed from a ‘Big brother’ that can intrude in appliances installed in his house.


@

Business effects (own business) – positive aspects Describe the business effects the application scenario will/could have on your business. (e.g. Improved business situation Business improvements opportunities (productivity, quality, environment, social issues) etc. Service organizations can be more efficient, thus improving their profitability. Also the user can than get cheaper service contracts. The amount of component replaced will be reduced (not always the service engineer is able to find the real problem and so it can happen that he changes s component that is working fine) and so the waste of materials too. With possibility to adjust parameters from remote it is possible to let the boiler working in the most suitable condition, thus increasing the life cycle. If it is possible, through additional sensors, to measure the air/gas ratio the temperature of exhausts and inlet air, it is also possible to measure indirect efficiency of a boiler, so knowing when it is necessary to clean the heat exchanger to bring the efficiency back to its nominal value. Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per PEID, support systems etc? It’s important to identify the maximum price range that can be added to a product/vehicle etc as a consequence of the aspects described in this application scenario. Describe therefore aspects that will have a consequence for costs, and in what range the “hurting” price for the customer (or users etc) will be. The maximum cost per device must be around 10% of the industrial cost of the appliance and so around 20€. The communication cost per year must not exceed 4€. Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field. MTS has not other aspects to describe.


@

7.3 Value-chain issues A7 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The value chain depends on the country:

• Italy, France, UK, Spain: MTS has not its own service organization, but there is a big number of service organizations that are trained and authorized by MTS to repair and maintain MTS boilers. These service organization will benefit of the possibility to have info on gas boiler failures, thus improving their profitability and service level. MTS will ask to these Service organization to pay a fee to MTS for each boiler where a PEID is installed. MTS have to give to service organization password and user name to access the PLM web site, and MTS have to pay the data center where the PLM servers are hosted.

• Switzerland, Germany, Austria and Holland: MTS has its own service organization (under the brand ELCO). So in this case MTS will benefit directly of the possibility to have info on gas boiler failure, thank to improvement of its service efficiency.

Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) What kind of consequences will the application scenario have for the partners/business associates/customers etc in the value-chain E.g. Dismantler: Dismantler must invest in new systems for reading/handling discarded products etc, but will have an upside regarding their operations of reuse/remfg etc as they more readily can… E.g. Customer: Customer will experience changes in their maintenance program this can be perceived as a positive or negative aspect (briefly describe why/how) Please refer to OVERVIEW OF THE VALUE-CHAIN Other aspects related to the Value-chain issues If some aspects are not are covered above, please use this field. MTS has not other aspects to describe.


@

7.4 Environmental issues A7 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate. 10%. It is obtainable in particular in condensing boilers, where the weather compensator parameter setting is very difficult to be done. By remote and by intelligent algorithm it will be possible to do it better, letting boiler compensate more. Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. 10%. It is obtainable for reduction of component replaced as defect but in reality perfectly working. Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. MTS is not able to give indication on this point because at the time being MTS has not any experience on this field. In gas boiler market there is no kind of reuse of components or extended product lifetime estimation thanks to a PLM. What can be said is that 50% of control board MTS receives back from the field as broken component replaced on a boiler are in reality perfectly working. The problem is that service people are not always able to find the real problem occurred and so replace the control board. This means that, through a smart system which can improve the diagnostic, it will possible to reduce the amount of component replaced because believed not working while they are. This will not extend the product lifetime but will extend the lifetime of control board, because they will not be replaced by error. I guessestimate that the percentage of replaced ‘well working’ control board can be reduced by 20%. Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field. MTS is not able to give indication on this point.


@

7.5 Social issues A7 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions Lower number of service engineers is needed. Some of them less skilled (they have just to go to the customer and simply replace a component the PLM told him to change because it is probable that it will break down), some other much more skilled (they have to access a web site and have the capability of plan visit, and deal with informatics issues, while today they are a little bit more than a plumber) Social Impact on society Describe, if any, implications of the application scenario regarding Social Impact on society Service engineers can be trained to be more skilled or be unemployed Ethical issues Is there ethical issues related to the application scenario? IF Yes explain Final user has to accept that information can be shipped from an appliance in his house to somewhere and someone who can see them. A problem with privacy respect is possible. Other aspects related to the Social issues If some aspects are not are covered above, please use this field. MTS has not other aspects to describe.


@



VERSION NO. 1.3



Application Scenario Description WRAP MOL

Written by: Pier Andrea Pracchi, Business Development, Wrap SpA


@

Revision History

Date (dd.mm.yyyy)


Dec 2004 1.0 Pier Andrea Pracchi The draft version submitted SINTEF














13.01.2005 1.2 Pier Andrea Pracchi

14.02.2005 1.3 Maurizio Tomasella, Andrea Matta The final version submitted SINTEF. Updated v1.2 document.

Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisation E-mail Tel Fax Pier Andrea Pracchi Wrap SpA [email protected]

+39-0732-636.2222 +39-0732-

636.2001


8 Application scenario description A8 WRAP MOL Where discrepancies, the Demonstrator-document overrides all aspects of this scenario. Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario The purpose is to offer to white goods manufacturer the opportunity to reduce both production and maintenance cost. Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil The objective is to be capable of showing a white good ready to be connected to a network at a minimal added cost and without the need to choose a home network protocol and yet reducing time and cost for inline testing and for maintenance. The importance of having a connected appliance capable of generating, transmitting and receiving data is threefold: 1) the manufacturer wil generate useful information on the appliance behaviour by acquiring consumption/usage data and that can either grant the possibility to deliver service to the consumer (preventive maintenance like) as well as doing appliance better that last longer 2) the user will benefit from the service delivered and yet from the “Peace of Mind” for having the appliance constantly monitored 3) The appliance itself is free from any communication protocol (EHS, LonTalk, Zigbee) and NO communication cost need to be installed within it, thus to create a standard for appliance connectivity (by using the Wrap Ultra Low cost Power Line) to a proxy device. The proxy device is free to adopt whatever protocol and node is needed acting as a bridge to connect the appliance to a chosen Network. Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work Basically, it will be easily shown how such an innovative technology can speed up testing time and monitoring the behaviour of a WG appliance at the same time which becomes easier to maintain through a more specific and punctual service delivery. Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL BOL/MOL: by enabling bidirectional communication with the Appliance it is given the chance to TEST it in a quicker (when compared to the current method) and more effective way. MOL: communication will allow the collection of relevant information stored within the appliance itself thus providing a powerful tool for maintenance throughout the product life cycle. EOL: it is given the possibility (i.e.: for a Refrigerator) to see how many cycles the compressor had completed to understand the remaining cooling gas and find the best way either to recycle or to waste it. Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues. The product chosen is a modified Refrigerator (Ariston branded, Merloni Elettrodomestici SpA). Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL


@

MOL: the monitoring of the appliance for each of its critical component will possibly give valuable information to the manufacturer (which will be in charge of the Dismantling/recycling) in the EOL phase. From the generated (during the MOL) knowledge repository, which would have collected periodically the data from the Appliance Main Board, information like COOLING circuit STATUS and COOLING GAS Level can possibly be found or at least estimated. Illustration of the application scenario Provide an illustration of the application scenario that can be used for communication purposes (e.g. in trade magazines, on the front of reports, slide shows etc). Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file.

Illustration of the information flow (flowchart) In order to identify informational requirements, illustrate the flow of information and clearly identify

Refrigerator Under Test

Proxy Device

Ultra Low Cost Power-line

Diagnosis by Performance

Wireless Link



@

information/data flows by denoting this in the figure. Use rectangles, arrows, circles etc with text. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file.

Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here. …………………………

HOME GATEWA

Intern


Proxy

Refrigerator

Proxy

Washing Machine

Http Server (to gather data from GW)

Databases (to record data)

expert system Based on Inferential Engine

Third Parties Web site

Multipurpose xml files

Multipurpose xml files

Main

Third Parties dBase

Service

Support applications


@

Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) 1. each appliance has to store locally the history of the appliance usage; 2. each appliance has to be able to communicate with the external world, at the lowest possible cost (WRAP plans to use a technology developed in another EU project (TEAHA), named Ultra LowCost Powerline Technology); 3. a number of parameters has to be measured using an external Proxy Device, such as power, powerfactor (COSφ), time. Other aspects related to the Application Scenario If some aspects are not are covered above, please use this field.


@

8.1 Technical issues A8 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA The refrigerator used for this specific purpose, a NO-FROST double door with one compressor only, is/will be capable of electronically collecting:

• Internal temperature • External temperature • Compressor time on • Compressor time off • Compressor ratio T(on/off+off) • Fan cosφ

The refrigerator is/will be also capable of storing all the above information in the internal flash memeory (properly sized) with the aim reconfiguring it to create a statistic set of rules for PREVENTIVE/PROGNOSTIC MAINTENANCE. Data&Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc). The amount of data going into the appliance can be drafted down in a range from 1 to 16 bytes Data&Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc). The amount of data going outbound can be drafted down in a range from 1 to 256 bytes Data&Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs) We foresee that 1kbyte can store 1 week of monitoring data plus relevant historical information as needed (assuming that we never download this data from the Memory of the appliance this would generate a total of 260Kbyte per lifecycle – 5 years.). Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed. By taking the electronic mainboard as a given within the appliances a number of component must be added to enable communication. These list of components can be summarised as :

• Passive components • Triac • Internal Lamp (10W) • Ad hoc Software routines (either on board or in a custom microchip)

Hardware: Life span of devices What is the needed minimum life span of the devices? 5 years


@

Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc) Regular indoor climate conditions (dry, 10-50 °c) Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Few routines need to added to the regular Appliance Firmware Software: Middleware (software that allows different software applications to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. tbd Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. tbd Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. tbd Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. The development of a remote Inferential Engine rules based is required to understand :

• Compressor fails to start • Refrigerator Unplugged • Compressor On for too long • Defrost not Starting • Door left open

Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. The backend software remotely receives from the Appliance. The Software consists in an inferential engine that elaborates diagnostic information and is also able to reprogram the local device in order to access their diagnostic basic functions. Other aspects related to the Technical issues If some aspects are not are covered above, please use this field.


@

8.2 Business/economical issues A8 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. As of today we are not ware of any Remote monitoring system for White Goods Appliances To-be, Future scenario concept Describe in more detail the To-be solution/implementation that are used today (either as your company or others uses). Describe it in such a way that it is related to the As-is description above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. tbd Business effects (own business) – negative aspects Describe the negative business effects the application scenario will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.) The negative aspect that can be foreseen is the added cost of a communication node either within the appliance or as a retrofit. Again, the WG appliance market is mature and price competition is fierce, the consumer do not recognise a premium unless the benefit for him are worth it. Business effects (own business) – positive aspects Describe the business effects the application scenario will/could have on your business. (e.g. Improved business situation Business improvements opportunities (productivity, quality, environment, social issues) etc. By monitoring WG the manufacturer can:

• Prevent any fault or malfunctioning • Extend warranty and service (say 5 years) • Understand how to better make appliances • Environmental respect • Dismantling options

Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per PEID, support systems etc? It’s important to identify the maximum price range that can be added to a product/vehicle etc as a consequence of the aspects described in this application scenario. Describe therefore aspects that will have a consequence for costs, and in what range the “hurting” price for the customer (or users etc) will be. Refrigerator (€400) / Proxy Device Prototype (€150) / Residential Gateway (€200) Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field.


@

8.3 Value-chain issues A8 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Today Value Chain Monitoring Added Value Chain

Compressor supplier RefrigeratorManufacturer

Retailer /Distribution Chain Consumer

Service Provider

Service Provider

Compressor supplier RefrigeratorManufacturer

Retailer /Distribution Chain

DIRECT ServiceFrom the manufacturer

Consumer

Service Provider

Central Data Collectionrepository


@

Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) What kind of consequences will the application scenario have for the partners/business associates/customers etc in the value-chain E.g. Dismantler: Dismantler must invest in new systems for reading/handling discarded products etc, but will have an upside regarding their operations of reuse/remfg etc as they more readily can… E.g. Customer: Customer will experience changes in their maintenance program this can be perceived as a positive or negative aspect (briefly describe why/how) Customer downside: Privacy related issue / Upside: technology enthusiast will see it as a gadget (value) Supplier Downside: competition and in depth analysis might scare them/ upside: data comparison to better understand their product Partners (Home Service Provider) downside: they can be substitute with a DIRECT customer service (Manufacturer to Consumer) / Upside: they might be given a service tool to better assist consumer Other aspects related to the Value-chain issues If some aspects are not are covered above, please use this field. NA


@

8.4 Environmental issues A8 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate.

Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. NA Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. NA Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field. NA

Frost Building up Compressor Time On too longTremendous Energy Waste

Energy consumption can rise up to 10% on annual operations, from 603KWh to 670KWh; assuming a product lifetime of 14 years and a Net cost for KWh of 8.5 cents we can estimate a lifetime operating cost $797.3 the waste for single inefficient refrigerator will be $79.7

SolutionSolution DiagnosysDiagnosys byby PartPart6677KKWWhh XX 330000MMLL == 2200,,11BBll KKWWhh


@

8.5 Social issues A8 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions NA Social Impact on society Describe, if any, implications of the application scenario regarding Social Impact on society NA Ethical issues Is there ethical issues related to the application scenario? IF Yes explain NA Other aspects related to the Social issues If some aspects are not are covered above, please use this field. NA


@


@



VERSION NO. 1.3



Application Scenario Description INTRACOM MOL

Written by: Dimitra Pli Maria Anastasiou


@

Revision History

Date (dd.mm.yyyy)


Dec 2004 1.0 See front page The draft version submitted SINTEF














28.04.2005 1.2 Dimitra Pli Updated application scenario


Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisation E-mail Tel Fax Dimitra Pli INTRACOM [email protected] +30 210 6674370 Maria Anastasiou INTRACOM [email protected] +30 210 6674205


9 Application scenario description A9 INTRACOM MOL Where discrepancies, the Demonstrator-document overrides all aspects of this scenario. Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario The objectives of the scenario are:

1. To enable registering information related to the hardware and software combination used in a specific deployment scenario. Selecting statistical information related to product performance will enable in advance undertaking of reparative actions in the cases of similar scenarios, thus improving product’s reliability.

2. To facilitate and improve the communication of product misbehaviour from technical support (maintenance) to engineering team.

3. To support the maintenance team in diagnosis and solution identification with knowledge gained from similar previous problems.

Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil These objectives are important in order to improve the quality of the product, the services provided to the customer and support the maintenance team in their every day work. Although, some data can be gathered from the field related to product function and malfunction, there is not a systematic approach to convert the data that is gathered into useful knowledge. In addition, there is not a standard procedure to provide the engineering team with this knowledge. Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work The scenario provided by INTRACOM corresponds to PROMISE objective to close the loop of information flow from customer site back to product development. In addition, the scenario is related to the project objective to convert product data that is gathered into useful knowledge. Finally, the goal is the above to be supported by appropriate functionalities and IT infrastructure that are to be developed within PROMISE, as well as by new process and business models. Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL The scenario concerns MOL including service and maintenance but also EOL as the implementation of PROMISE concept is expected to facilitate product repairability, as well as product’s parts reusability. In addition, the collection and management of information coming from the deployment sites can be exploited and used back at the BOL to realise improvements of the product.


@

Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues. The product in the scenario is called IBAS, INTRACOM Broadband Access System, and is a Next Generation Multi-Service Access Node (MSAN) featuring broadband and narrowband subscriber interfaces. It is one of the DSLAM family products, which is the last element in the access network before the subscriber’s home, and is thus the vehicle for delivering broadband services.

IBAS product includes software and hardware components (line cards). Line cards hold their serial number and type hard coded on a special tag, as well as on their flash memory. IBAS keeps alarms in the form of log files to report on its performance, malfunction, and throughput degradation. The alarms are classified into Real, Active and Historical. Alarms maybe critical warning about a failure or simple ones that warn about throughput degradation or indicating that a problem may occur. Periodically, the IBAS alarms are reported to and processed by the Element Management System (EMS) that resides at the Network Operation Centre (NOC). It should be highlighted that the IBAS product is distinguished using its IP address on the Network. Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL The interface between MOL and BOL depends heavily on the role of the company and the agreement with the customer. Full access to IBAS operation information is possible when INTRACOM is also responsible for the operation of the customer’s network. Otherwise, depending on the Service Level Agreement (SLA), INTRACOM may have remote access to the EMS. Currently, there are no standard procedures to support information gathering from the technicians during support services provided in the field. In addition, there is no standard procedure facilitated by the appropriate tools to transfer the knowledge gained in the field to the development team.


@


TECHNICIAN

PROMISEPDKM

SIS

EMS

Network Operation Center

ENGINEER

Operator

Long Distance (G

SM)

Short Distance (linked on the product)

IBAS

Customer Center

Call TrackingSystem

CustomerSupport

Required Applications1. Best Proctices Identification2. Product Historical and Operational Knowledge Management3. Decision Support for preventive maintenance, identificationof product improvement actions

Note: The green color indicate development anticipated to beperformed in PROMISE


@

Illustration of the information flow (flowchart) In order to identify informational requirements, illustrate the flow of information and clearly identify information/data flows by denoting this in the figure. Use rectangles, arrows, circles etc with text. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or PowerPoint-file.

Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here. Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) As it is described in Section PRODUCT CONSIDERED IN SCENARIO, by IBAS nature, data on product performance and failures are already kept and reported to network operation management. The issue is that INTRACOM has not always access to this information. This depends on the role of the company and the agreement with the customer. The main problem / challenge in the application scenario could be realised when INTRACOM is not responsible for the operation of the network on which the product is deployed. In that case, the company has no access to the EMS and consequently no access to the data related to product performance and failures, with the exception of some cases. The same applies to the information that resides on the product itself. INTRACOM can have access to these data with the supervision of the customer, when a technician visits the customer site to solve a reported problem. In addition, there are cases that product components (e.g. line cards) are replaced by the customer without informing INTRACOM. The replaced line cards are sent to INTRACOM maintenance lab in a batch mode. In this case, useful information about the card as well as about IBAS is being lost. Customers should be motivated and facilitated to provide the company with this information.

TECHNICIAN

PROMISEPDKM

SIS

EMS

Network Operation Center

ENGINEER

Operator

Short Distance (linked on the product)

IBAS

Customer Center

Call TrackingSystem

CustomerSupport

IBAS Performance Data (inthe form of log files)

TroubleshootingInformation1. Requests for

troubleshooting Information

2. Hardware updates, product

performance

Web Interface

1. Requests

for similar best practices,

2. Request fo

r product or its components

historical information

3. Update the product history

4. Update best p

ractices

5. Update Customer S

ite information

1. Similar b

est practic

es,

2. Histo

rical in

formation

3. Custo

mer Site information

Statistically processed information aboutproduct failures

1. Requests for similar best practices,2. Request for product or its componentshistorical information3. Update best practices


@

Other aspects related to the Application Scenario If some aspects are not covered above, please use this field.


@

9.1 Technical issues A9 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA As it is mentioned in section PRODUCT CONSIDERED IN SCENARIO, IBAS product by its nature uses appropriate technology (software, hardware, sensors etc) for recording information about its performance and producing alarms indicating malfunction or throughput degradation. The Element Management System (EMS) uses this information and allows efficient operation management of the element (IBAS). In addition, the serial number and the type of each line card is hard coded on a special tag, as well as, on the flash memory of the card. However, it is under further investigation to use an RFID tag on the cabinet of IBAS, in order IBAS and its components to be efficiently allocated. Data&Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc). It will be specified in detail later in the project Data&Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc). It will be specified in detail later in the project Data&Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs) It will be specified in detail later in the project Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed. It will be specified in detail later in the project Hardware: Life span of devices What is the needed minimum life span of the devices? It will be specified in detail later in the project Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc) It will be specified in detail later in the project Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. It will be specified in detail later in the project


@

Software: Middleware (software that allows different software applications to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Regarding the communication with the EMS, EMS implements a CORBA based North Bound Interface (NBI). NBI should be used to communicate with the EMS. It should be also highlighted that for the communication between INTRACOM and the related NOC a VPN (Virtual Private Network) should be used. Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. No specific requirements. Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. IBAS uses Simple Network Management Protocol. This protocol should be used if the product is to communicate with middleware and/or other software applications. There are also security concerns. As in the case of communicating with the EMS, for the communication with the IBAS itself a VPN should be used. Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. INTRACOM don’t have a specific technology to require. Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. INTRACOM will require to the support of decision support software both locally and remotely. There is not any requirement for specific software technologies to be used for this. Other aspects related to the Technical issues If some aspects are not are covered above, please use this field.


@

9.2 Business/economical issues A9 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Support Levels Call Center and 1st Level Support When customers experience problems that require software or hardware support, they call INTRACOM’s hotline handled by the Technical Support Help Desk. The hotline personnel (Help Desk) then forwards the problem to a dispatcher who creates a trouble ticket on the call tracking system and pass the call to the appropriate engineer. This process will allow technical support personnel to be notified and respond immediately to a request for service. At this level, the ability to provide general information concerning the product and basic support regarding hardware and software with fair perception of the end-users environment is required in order to solve basic problems that may arise. On the field support When a customer problem is not resolved during the previous procedure then a technician visits the customer’s site. The ability to provide specific information concerning the end-users environment including the ability to troubleshoot unique problems that may arise is required. At the customer’s site the technician could have access to the EMS and the product itself with the supervision of the customer. As it has already been mentioned, in some cases the agreement between INTRACOM and its customer, allow the company to remotely access the system. Several cases are identified:

The problem diagnosis has already been done at the previous level and the technician visits the site to solve the problem.

The problem diagnosis has not been done, and the technician needs to investigate further at the customer site to perform diagnosis.

The problems may relate to software or hardware or combination. Usually, software problems are solved via software updates. Very often, equipment (cards) replacement is required in order to provide a solution to the problem in hand. Maintenance at the lab There cases that the customer problem is related to problems of a card, and the technician replace this card with one provided by the company stock. The card that was replaced is provided to the maintenance lab and specific procedures are followed to register the problem and the solution. The lab personnel uses SIS system to registered the problems and solutions, as well as to keep the cards’ history. Every three months, the lab personnel statistically process the available information, and in case of repetitive faults the Quality Department is informed. Then, they collaboratively prepare a report to be provided to the Product Manager. Identified Needs Issues related to Element Management System (BBMS, NBNS, integrated system) The need was identified to be able to have filtered information related to an element performance and have alarms reported coded and hierarchically structured. This is required to support the operation of the network and facilitate preventive maintenance. For INTRACOM, this will be helpful in the cases that the company is also responsible for the operation of the network, as well as when remote access is allowed and requested by the customer.


@

Issues related to Service Levels The call tracking system already used by the company should be linked with PROMISE PDKM. The

possibility to statistically process the data gathered during the various customer calls is required. Simple troubleshooting information shall be available on line for customers. The need was identified the technicians that visit the customer site to register and update information

about special characteristics and description of the customer site that need to be taken into consideration in troubleshooting and fault diagnosis. This information should be available to the technicians that are going to visit the customer site in future. This is also important in cases that the customer problem has to do with the customer site and not with the product itself.

The technician needs to have access to the history of the system, and components of it. In the case of equipment replacement, the expert should register the replacement made. It would be helpful, the technician to have access to previous similar symptoms and diagnosis made for

those, as well as to solutions given. PROMISE PDKM should interoperate with SIS system.

To-be, Future scenario concept Describe in more detail the To-be solution/implementation. Describe it in such a way that it is related to the As-is description above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The Future scenario is illustrated in the application scenario description made in section 2.7. Some issues are following highlighted.

When a technician tries to solve a problem through the hotline, then he/she will be able to find in the knowledge base cases with similar symptoms, the diagnosis made, as well as the solution given. The technician will update the PDKM accordingly when the issue is solved.

When a technician has to visit the customer site then he/she will be able to search in the PDKM for special characteristic of the customer site, as well as to the history of the related IBAS in order to be able to get appropriately prepared.

The technician will have part of the information locally in the laptop, based on the customer site to be visited. (Because of the large amount of data, and the low speed of transferring a mechanism should be available to allow technicians to transfer the appropriate relevant information to their laptop before visiting the customer site.)

The technician will update the knowledge base accordingly (see also identified needs in the previous section).

The procedures and tools used in the lab will be integrated with the PROMISE solution. The customers will have access to simple troubleshooting through the web. The customers will provide information about hardware updates and problems in their network

through a web interface. Engineers will have filtered access to the PDKM supported by decision support applications to

identify critical problems and repetitive problems. Customer support will have filtered access to the information coming from the EMS systems in

order to perform preventive maintenance.


@

Business effects (own business) – negative aspects Describe the negative business effects the application scenario will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.) The following negative aspects could be identified:

Additional effort will be required by technicians to register in the appropriate way information related to the diagnosis made, solution given, as well as to customer site specific information.

Customer will be requested to provide information about the operation of the product, as well as about actions taken in components of it (e.g. cards replacements).

Change management will be required in some cases to overcome actors’ resistance to changing tools and procedures.

Additional training effort High confidentiality issues especially with regard to the communication of PROMISE system with

an IBAS element or EMS. Business effects (own business) – positive aspects Describe the business effects the application scenario will/could have on your business. (e.g. Improved business situation Business improvements opportunities (productivity, quality, environment, social issues) etc. The following positive aspects could be identified:

Technicians will be facilitated in their everyday work by being able to exploit knowledge gained through previous similar situations.

Process will be established and facilitated in order engineers to be informed about repetitive faults that occur and could lead to decision-making about improvements to the product.

Improve product quality and consequently minimise fault occurrence. Improve Preventive maintenance. Customers will be provided with services of higher quality. Customer satisfaction will be increased. Reduce the environmental impact by extended the life span of the materials (reusability,

repairlability). Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per PEID, support systems etc? It’s important to identify the maximum price range that can be added to a product/vehicle etc as a consequence of the aspects described in this application scenario. Describe therefore aspects that will have a consequence for costs, and in what range the “hurting” price for the customer (or users etc) will be. It is neither expected nor wanted the implementation of the application scenario to have any impact on the product price to the customer. Additional services will be added. Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field.


@

9.3 Value-chain issues A9 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The actors involved are:

The technical support department The development department The related product manager Network operator Customer

Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) What kind of consequences will the application scenario have for the partners/business associates/customers etc in the value-chain. E.g. Dismantler: Dismantler must invest in new systems for reading/handling discarded products etc, but will have an upside regarding their operations of reuse/remfg etc as they more readily can… E.g. Customer: Customer will experience changes in their maintenance program this can be perceived as a positive or negative aspect (briefly describe why/how) Customer:

Technicians will be facilitated in performing their everyday tasks but this will have a downside concerning the resistance to change tools and procedures.

Customers will be provided with higher quality of services and products. However, their collaboration is required to provide the manufacturing with product operation information.

Engineers will be provided with information and knowledge related to the product performance and be able to take better justified decisions on that.



@

9.4 Environmental issues A9 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate. Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. It is expected that PROMISE concept will enhance product repairability and therefore an extension of product life is anticipated. Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field.


@

9.5 Social issues A9 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions More effort will be required by the technicians in order to upload information regarding the product, problems occurred and solutions provided, and the customer site and populate PROMISE PDKM. In some cases, additional effort will be required by the customer to inform INTRACOM about the product updates and performance. All the involved actors will have to use the PROMISE PDKM and the related applications. Social Impact on society Describe, if any, implications of the application scenario regarding Social Impact on society Ethical issues Is there ethical issues related to the application scenario? IF Yes explain The confidentiality of the information flow between the customer site and INTRACOM is a very important issue that must be taken into consideration. Other aspects related to the Social issues If some aspects are not are covered above, please use this field.


@


@



VERSION NO. 1.3



Application Scenario Description BT-LOC Bombardier Transportation (BOL)

Written by: Markus Frey, Bombardier Transportation


@

Revision History

Date (dd.mm.yyyy)


08.12.2004 D00 Markus Frey First draft

13.12.2004 D01 Markus Frey Inclusion of some remarks from DfX specialists and partners














14.01.05 1.2 Markus Frey New respectively updated content due to first review by DfX specialists in following chapters:

• Abstract • 2.1 Purpose and objectives of the scenario • 2.2 Scenario objective(s) rationale • 2.5 Product considered in scenario • 2.6 Interfaces between lifecycle phases • 2.7 Illustration of the application scenario • 2.8 Illustration of the information flow • 2.9 Specific requirements • 3.1 to 3.14 (various chapters) • 4.1 As-is, current solution/implementation of the

scenario or similar tasks/situations • 4.2 To-be, future scenario concept • 4.3 Business effects (own business) – negative

aspects • 4.5 Cost models • 5.1 Make an overview of the value-chain related to

the application scenario • 5.2 Describe possible downsides / upsides • 6.1 Savings of energy • 6.3 Reuse or extended product life

• 7.1 Changed labour/work conditions



@

Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisation E-mail Tel Fax Markus Frey BT LOC [email protected] +41 1 318 3817 +41 1 318 1000

Abbreviations: Abbreviations used in this application scenario:

BOL Beginning of Life

BT Bombardier Transportation

CM Condition Monitoring

CBM Condition Based Maintenance

DfX Design for X (where X can stand for: RAM/LCC, Product Safety, Environment, etc.)

EOL End of Life

ERP Enterprise Resources Planning

LCC Life Cycle Cost

MOL Middle of Life

PDA Personal Digital Assistant

PDKM Product Data & Knowledge Management

PEID Product Embedded Information Device

PLM Product Lifecycle Management

RAM Reliability, Availability & Maintainability

TRAXX Trademark of Bombardiers product family of locomotives


10 Application scenario description A10 BOMBARDIER BOL Where discrepancies, the Demonstrator-document overrides all aspects of this scenario. Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario

The overall objective is to close the loop of information between experience embedded in field data (captured mainly by Service and/or product embedded devices) and knowledge (concentrated on Design for X aspects) needed by the engineers to improve the designs and realize more competitive products.

The scenario contains the “translation” and “transformation” of field data into Design for X knowledge,

• To be used in the various DfX processes, mainly

- Design for Acoustics and Vibration

- Design for Aero & Thermo Dynamics

- Design for Electrical Systems Compatibility

- Design for Environment

- Design for Product Safety

- Design for Reliability, Availability, Maintainability & Life Cycle Costs

- Design for Six Sigma

- Design for Structural Mechanics

- Design for Testing

- Design for Vehicle Dynamics

- Design to Cost,

• Manageable in common PDKM systems,

• Supported by a decision making process.

The field data is mainly available through


• Diagnosis System

• Event Recorder

• Maintenance Management Systems

• Inspection Information

• Failure Reporting Analysis and Corrective Action System (FRACAS)


@

Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil

BT gathers already various field data (e.g. from the TRAXX Platform locomotives). This data is primarily used within the specific contract to validate the fulfilment of costumer requirements (e.g. RAM/LCC) and to improve the product performance.

But this data does not flow back as DfX knowledge into the Engineering so that it could be used to design new and more competitive products.

Therefore it is important to close the loop of information between experience embedded in field data and knowledge needed in the various DfX processes.

The developed methodologies and software package shall support this data transformation and provide integration into a PDKM system environment used within Engineering.

Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work This scenario corresponds primarily with the PROMISE objectives to develop new closed-loop life cycle information flow models over the complete product lifecycle.

But it will also include elements concerning the PROMISE objectives to develop

- new PLM functionalities and adapted IT infrastructure and

- new working and business models. Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL Product data will be gathered from the service of the product (MOL).

But the gained DfX knowledge will be used to improve the design of new products (BOL). Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues. The products considered in this scenario are electric locomotives. Locomotives are usually in service for more than 30 years.

Other railway vehicles and / or systems will be taken into consideration as appropriate to fulfil the objectives.

The demonstrators will concentrate on electrical and mechanical elements of the traction chain (from pantograph to wheel). If specifically required other systems or subsystems will be included, e.g. brake system for Design for Safety investigations. Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL Adequate field data is available from warranty phase (usually 1 to 3 years), but generally not from the service by the operators over the product lifespan of over 30 years.


@

Illustration of the application scenario Provide an illustration of the application scenario that can be used for communication purposes (e.g. in trade magazines, on the front of reports, slide shows etc). Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Illustration of ‘Design for X’ application scenario:

Scop

e of

Sce

nario ‘DfX’ Transformer

• Aggregation of field information

• Transformation into appropriate DfX knowledge

• Management of baseline-oriented configurations (as offered, as designed, as built, as maintained

Decision Support System

• Supporting the transformation of field information into knowledge

• Deriving of actions


PDKM Environment

• Management of DfX knowledge

• Application-specific presentation of DfX knowledge

Field Data

Field Info Database(Captured by CM / CBM, FRACAS,

Service and/orProduct-Embedded Devices)

Other Info Sources(PDM, Databases,

Standards & Regulations, etc)



@

Illustration of the information flow (flowchart) In order to identify informational requirements, illustrate the flow of information and clearly identify information/data flows by denoting this in the figure. Use rectangles, arrows, circles etc with text. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Overview on the ‘Design for X’ information flow:


Field Info Database

Other Info Sources(PDM, eBoK, LN Databases,

Internet, etc)

Decision SupportSystem

PDKM

Condition Monitoring / Condition Based Maintenance (1)

‘DfX

’Tra

nsfo

rmer

Des

ign

for

RAM

/LC

C

Des

ign

for

Pro

duct

Saf

ety

Des

ign

for

Env

ironm

ent

Des

ign

for …

Product-EmbeddedDevices (3)FRACAS Process (2)

CM / CBM Tool

Vehicle Control System

MAXIMO / Vipscarsis


CM & CBM and corresponding tools are currently under development.

FRACAS is supported by a toolset that includes for locomotives mainly MAXIMO & VIPSCARSIS.

Currently sensors are used as ‘Product-Embedded Devices’ to register specific behaviours and conditions. The data is gathered and evaluated by the vehicle control software and provided via GSM to the operation base (if needed).

The following definitions are used:

Data - data are raw symbols (the display of a digital thermometer reads 98.6 deg-F, which can be directly encoded in ASCII, Unicode, etc.).

Information - information is data processed to be useful (my body temperature is 98.6 deg-F, which can be represented, for example, in XML using the previous data encoding but with special tags defined to convey the notion of


@

temperature and measure).

Knowledge - knowledge is information processed to be useful (if my body temperature is greater than 98.6 deg-F, then I may be ill, which can be represented, for example, in XML, using the previous data encoding but with special tags defined to convey its rule-based nature.)

[source: www.fiatech.org ‘Definition of Key Terms’]

Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here. • The DfX knowledge shall be manageable in common PDKM systems (e.g. SAP PLM, UGS

Teamcenter).

• The translation / transformation of data into knowledge shall be performed by appropriate specialists and shall be supported by a decision making process & tool (where necessary).

• This scenario will primarily concentrate on the important ‘Design for X’ aspects Reliability, Availability & Maintainability (RAM), Life Cycle Costs (LCC), Product Safety and Environment:

- Design for RAM/LCC: The demonstrator shall support the DfRAM/LCC process by providing appropriate knowledge – mainly regarding reliability & availability information, failure analyses, maintenance procedures and cost information – needed to fulfil the RAM/LCC performance requirements of a new product.

- Design for Product Safety: The demonstrator shall support the DfS process by providing appropriate knowledge – mainly regarding potential hazards, appropriate mitigation mechanisms and performed safety analyses – needed to fulfil the performance requirements regarding safety of a new product.

- Design for Environment: The demonstrator shall support the DfE process by providing appropriate knowledge – mainly regarding material choice (e.g. BT list of prohibited & restricted material), end-of-use aspects, energy and emission related issues – needed to fulfil the environmental performance requirements of a new product.

• The demonstrator shall be as close to the ‘reality’ as possible, mainly by using

real field information available through Condition Monitoring / Condition Based Maintenance, Diagnosis System, Event Recorder, Maintenance Management Systems, Inspection Information, Failure Reporting Analysis and Corrective Action System (FRACAS)

and other relevant data and information from various sources (PDM systems, databases, intranet, etc.).


@

Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) A major challenge will be that adequate field data is mainly available from warranty phase, but not really from the product service by operators. But nevertheless the DfX knowledge should cover the complete lifespan.

A true representation of LCC may not be possible due to the complex nature of the Production, Delivery and Operation Contracts for railway rolling stock and the commercially sensitive nature of cost information. Other aspects related to the Application Scenario If some aspects are not are covered above, please use this field. Not applicable


@

10.1 Technical issues A10 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA For this application scenario all kind of data and information is used that can be transformed into DfX knowledge. Regarding PEID’s, only the data gathered from currently installed PEIDs (e.g. sensors) will be used. But most probably no data gathering with specifically designed PEID’s will be necessary.

For the DfX demonstrator the necessary data and information shall be provided through currently used information sources (see DATA&INFORMATION: INPUT DATA). For the demonstrator most probably no data gathering with specifically developed PEIDs is feasible.

Only if needed data and information can not be made available as described above, the usage of PEIDs shall be considered. The intention is then to use developments from other application scenarios (e.g. WP A4, A5 & A6). Data&Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc). Not applicable regarding specifically designed PEID’s (see DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS).

Concerning the overall application scenario, the needed input are various data and information on all kind of characteristic and behaviour of the considered products, systems and components and available in


• Diagnosis System

• Event Recorder

• Maintenance Management Systems

• Inspection Information

• Failure Reporting Analysis and Corrective Action System (FRACAS)

• PDM system

• Lotus Notes databases

• eBoK’s (Intranet)

• Internet

• and other similar data & information sources (DfX basic data, standards, etc.)

Only electronic data and information is considered as direct input. Non-electronic data and information has first to be pre-processed into electronic format before it can be transformed into DfX knowledge.


@

Data&Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc). Not applicable regarding specifically designed PEID’s (see DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS).

Concerning the overall application scenario, the needed output are various DfX knowledge manageable in a common PDKM system. Data&Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs) Not applicable regarding specifically designed PEID’s (see DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS).

This has to be evaluated in more detail regarding the overall application scenario. Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed. Not applicable regarding specifically designed PEID’s (see DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS).

[Example for demonstrator: description of diagnostic system (necessary information on used sensors, onboard computers, GSM system, etc)] Hardware: Life span of devices What is the needed minimum life span of the devices? May not be applicable regarding specifically designed PEID’s (see DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS).

However, should PEID's be considered a minimum useful life expectancy of 30 years would be required.

This is also valid for all other kind of devices within the overall application scenario. Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc) May not be applicable regarding specifically designed PEID’s (see DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS).

However PEID's for use in the railway environment must fulfil the environmental requirements of EN 50155 for electronic devices, e.g. exacting shock and vibration requirements, extended temperature range (-45° to +80°C) and fully resistant to water ingress.

This is also valid for all other kind of devices within the overall application scenario.


@

Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Not applicable regarding specifically designed PEID’s (see DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS).

[Example for demonstrator: description of diagnostic system (necessary information on used sensors, onboard computers, GSM system, etc)] Software: Middleware (software that allows different software applications to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Not applicable regarding specifically designed PEID’s (see DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS).

[Example for demonstrator: description of diagnostic system (necessary information diagnostic software)] Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Not applicable regarding specifically designed PEID’s (see DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS).

[Example for demonstrator: necessary description of vehicle bus / communication] Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. Not applicable regarding specifically designed PEID’s (see DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS).

[Example for demonstrator: necessary description on vehicle bus / communication, GSM interface] Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. For the transformation / translation of process only one ‘easy to use’ user interface shall exist, which provides access to all needed data and functionality (portal). The client shall run on Windows XP.

All product relevant data, information and knowledge shall be managed in a common PDKM system. The PDM system used today for the product definition is Teamcenter Enterprise (Metaphase CF2). All relevant data for logistics, etc. will be transferred automatically to the ERP system (SAP R3).


@

Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. The decision support software shall use field information (from field info database) and existing knowledge (from eBoK’s, Lotus Notes databases, internet, etc.) to let the DfX specialists efficiently decide how the product data and information has to be translated / transformed into knowledge.

The decision support software can be used locally by the DfX specialists (as part of the portal, see SOFTWARE: BACKEND SOFTWARE) and run on Windows XP. Other aspects related to the Technical issues If some aspects are not are covered above, please use this field. The scenario includes the provision of the appropriate knowledge for the main DfX processes based on the available data resp. information.

• Design for RAM/LCC: The DfRAM/LCC process requires mainly knowledge of products, systems and components regarding

- Reliability & availability information (e.g. MTBF, environmental conditions) - Failure analyses (e.g. FMEA) - Spare parts information - Maintenance procedures & plans - Cost information, including maintenance task times

• Design for Product Safety: The DfS process requires mainly knowledge of products, systems and components regarding

- Asphyxiation - Burns (typically caused by exposure to hot surfaces or substances, as distinct from fires) - Exposure to Biological Hazards - Exposure to Chemicals - Collision (of the vehicle) - Crush - Cut - Derailment - Fall - Fire - Electrocution - Impact (people hitting walls, equipment, etc. or equipment falling onto people, usually as a

result of rapid acceleration or deceleration) - Medical Equipment Incompatibility

- Malfunction of safety relevant functions

• Design for Environment: The DfE process requires mainly knowledge of products, systems and components regarding

- Material choice (BT list of prohibited & restricted material) considering the categories ‘prohibited material’, ‘restricted material’, ‘recycled material’ and ‘renewable material’


@

- End-of-use aspects (recycling, marking, take back obligations, disposal cost) - Energy related issues (total energy use, energy solutions) - Emissions (e.g noise)


@

10.2 Business/economical issues A10 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file.

BT gathers already various field data resp. information (e.g. from the TRAXX Platform locomotives). This information is primarily used within the specific contract to validate the customer requirements and to improve the product performance.

This information is usually in a format that only specialists can interpret and use.

But this information does not flow back as DfX knowledge into the Engineering so that it could be used to design new and more competitive products.

To-be, Future scenario concept Describe in more detail the To-be solution/implementation. Describe it in such a way that it is related to the As-is description above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The field information shall flow back as DfX knowledge – managed by a common PDKM system – mainly into the Engineering in a format that it can directly be used by the engineers & designers to design new and more competitive products.

The GAPS between AS-IS and TO-BE are mainly:

• field data / information are not complete regarding DfX, e.g. condition / environmental information

• transformation of field information into knowledge

• knowledge directly to be used by engineers & designers

• knowledge to be managed by a common PDKM system Business effects (own business) – negative aspects Describe the negative business effects the application scenario will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.) The following negative business could come up:

• Additional effort to get appropriate field data from operator and / or additional effort for customer to provide field data

• Additional effort for involved persons due to usage of new processes and tools

• Additional effort for implementation activities for involved persons because of changes in current processes and tools

• Inspiring of inadequate (customer) expectations / requirements


@

Business effects (own business) – positive aspects Describe the business effects the application scenario will/could have on your business. (e.g. Improved business situation Business improvements opportunities (productivity, quality, environment, social issues) etc. The main benefit is to establish a process (incl. supporting tools) for the transformation of field information into DfX knowledge resulting in

• improved and more competitive product designs, mainly by adequate re-use of proven designs

• increased customer satisfaction due to improved fulfilment of customer requirements

• reduced design effort by allowing engineers to have direct access to discrete and meaningful DfX product data in every design phase

• minimized design changes during product service life (respectively warranty period) due to improved component selection during initial design

Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per PEID, support systems etc? It’s important to identify the maximum price range that can be added to a product/vehicle etc as a consequence of the aspects described in this application scenario. Describe therefore aspects that will have a consequence for costs, and in what range the “hurting” price for the customer (or users etc) will be. Most probably the costs can not be handed on to the customer.

Therefore the investments (PEID’s, SW & HW, user training, etc.) and yearly costs (e.g. SW maintenance) shall be reasonable, so that a return on investment occurs at least within 2 years.

Further more detailed requirements could be defined in the near future. Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field. Not applicable


@

10.3 Value-chain issues A10 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The following general value chains are valid for this application scenario:

• Main case (e.g. for most state owned operators):

Operating CompanyVehicle Manufacturer

SystemSuppliers

Manufacturing CommissioningEngineering(incl. DfX specialists)

Operator

MaintenanceOrganisation

After SalesServices

Information flowMaterial flow

Legend:

Case I: Operating Company performs Maintenance

• Secondary case (e.g. for private operators):


SystemSuppliers


Operator

After Sales& Maintenance


Legend:

Case II: Vehicle Manufacturer performs Maintenance


@

• Further case:

3rd Party Company


SystemSuppliers


Operator

MaintenanceOrganisation

After SalesServices


Legend:

Case III: Third Party Company performs Maintenance

Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) What kind of consequences will the application scenario have for the partners/business associates/customers etc in the value-chain. E.g. Dismantler: Dismantler must invest in new systems for reading/handling discarded products etc, but will have an upside regarding their operations of reuse/remfg etc as they more readily can… E.g. Customer: Customer will experience changes in their maintenance program this can be perceived as a positive or negative aspect (briefly describe why/how) • Customer:

A downside is mainly the disclosure of information about service usage of locomotives by the operators. On the other hand will the operator benefit from improved products.

• Suppliers: System suppliers could benefit from improved field information respectively knowledge regarding their scope of supply. But for the system integrator more detailed conclusions on their system performance & quality will be possible.

• Partners companies / consortiums: Partners companies / consortiums could benefit from improved field information respectively knowledge regarding their scope of supply. But more detailed conclusions on their system performance & quality will be possible for all partners - which could also be competitors in other areas.

Other aspects related to the Value-chain issues If some aspects are not are covered above, please use this field. Not applicable


@

10.4 Environmental issues A10 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate. Savings of energy will be low.

Most probably some potential can be identified in the field of Design for Environment, where energy consumption of a system / component is a criterion. Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. Savings of material will be low to null.

At best some potential can be identified in the field of Design for Environment, where material consumption of a system / component could be a criterion. Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. The amount of reusing the same system / component design for another product design will be high. This is one of the major benefits of this scenario.

The reuse and / or life extension of the product itself will probably be low. The objective of the scenario is to improve the performance (fulfilling customer requirements, e.g. regarding reliability & LCC) of the product during its life and not really to extend it. Therefore a reuse and / or life extension would only be an additional benefit. Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field. Lifecycle aspects shall noticeably be improved, because this is a major objective of this application scenario.


@

10.5 Social issues A10 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions Commissioning and servicing persons would probably need to collect more product data in the field info database.

Engineers & designers will have to take more care to evaluate the usage of existing designs & knowledge, instead of ‘re-designing’ it again. Social Impact on society Describe, if any, implications of the application scenario regarding Social Impact on society None Ethical issues Is there ethical issues related to the application scenario? IF Yes explain None Other aspects related to the Social issues If some aspects are not are covered above, please use this field. None


@



VERSION NO. 1.5



Application Scenario Description Politecnico di Milano

Written by:

Maurizio Tomasella, POLIMI Andrea Matta, POLIMI Gian Maria Secco Suardo, CRF Mario Gambera, CRF


@

Revision History

Date (dd.mm.yyyy)


10.12.2004 1.0 Maurizio Tomasella The draft version submitted SINTEF














14.01.2005 1.2 Maurizio Tomasella, Andrea Matta The (first) “final” version submitted SINTEF. Updated v1.1 document.

14.02.2005 1.3 Maurizio Tomasella, Andrea Matta The final version submitted SINTEF. Updated v1.2 document.

18.02.2005 1.3 Maurizio Tomasella, Andrea Matta Updated version


Author(s)’ contact information In order to contact your company regarding the application scenario, please fill in the author(s) contact information. Name Organisation E-mail Tel Fax Andrea Matta POLIMI [email protected] +39 0223994891 +39 0270638377 Maurizio Tomasella POLIMI [email protected] +39 0223994892 +39 0270638377 Gian Maria Secco Suardo

CRF [email protected]

Mario Gambera CRF [email protected]


@

11 Application scenario description A11 POLIMI BOL Where discrepancies, the Demonstrator-document overrides all aspects of this scenario. Purpose and objective(s) of the scenario Give a detailed description of the scenario objective – What is the purpose of the scenario The purpose of this application scenario is to demonstrate how the PROMISE platform can be used to improve the overall enterprise performance by adapting the production system to the large number of product and process modifications prompted by the availability of feedback information concerning the whole product life cycle. Scenario objective(s) rationale Describe the rationale for the objective, i.e. why is the objective important and why the objective is important to fulfil Malfunctioning, early wearing or failure of products during MOL and EOL phases are closely connected with the design of the product, its production process and the production system used to realize the same process. These design activities can be improved by tracking the status of products during their use and disposal, thanks to the great amount of data collected. If the information loop is properly closed, the same amount of data can be transformed into knowledge, useful to identify product criticalities, their causes and to provide practical guidelines for the improvement of the product. The frequency of requests of product modifications is expected to increase in a PROMISE context due to the availability of feedback information. Therefore producers will introduce modifications on the system, which may cause performance losses if not adequately forecasted. Relations with PROMISE objectives Relate the application scenario to the PROMISE objectives as described in the Declaration of Work As underlined in section 2.3 of the Description of Work document, the PROMISE project has four main objectives. This application scenario will contribute, to objectives #1 and #4. The first is because the demonstrator developed for the scenario will become one of the elements of the PROMISE Decision Support System, in particular the one for the implementation of the Adaptive Production paradigm. So it will be finally included in the integrated PROMISE product lifecycle management system. The second is because the demonstrator will explore human and social issues towards the development of a sustainable business model, in particular in the field of adaptive production, where the integrated product/process/system design will be carried out from a sustainable point of view. Lifecycle phase relevance (BOL, MOL, EOL) Relate the scenario application to BOL, MOL, EOL, and clearly state the relevance to BOL, MOL and/or EOL Adaptive Production application scenario mainly involves the BOL phase of a product, so that an integrated approach to the product/process/system design can be carried out .


@

Product considered in scenario Describe the products in the scenario (e.g. car, truck). Include related functionality and life cycle issues. The product to be considered in the scenario will be one of the major subsystems of the car, and in particular the cylinder head group. The production system is the “JTD line” for the production of diesel engines. The layout is composed by a set of three stations, each one having three identical machine tools. Also two buffers are provided in the layout: the former is used both as the buffer for the first station and as inter-operational buffer between the first and the second station. The latter is then used as inter-operational buffer between the second and the third station. Arrows of different colours show the product flows from one station to another.

Interfaces between lifecycle phases Describe the interfaces between relevant BOL, MOL and/or EOL This application scenario mainly involves BOL issues but also affects and is affected by the MOL and EOL phases. However the Adaptive Production theme does not require any explicit interface between the three phases.

Buffer #1

Station 1

Station 3

Station 2

Buffer #2.


@

Illustration of the application scenario Provide an illustration of the application scenario that can be used for communication purposes (e.g. in trade magazines, on the front of reports, slide shows etc). Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The Adaptive Production scenario can be illustrated as reported below. The aim is to reconfigure the system, given the modifications to the product/process. In the green blocks you can see the life cycle phases from the PROMISE point of view; Design and Production constitute together the BOL phase. In the orange blocks you can see the life cycle of the production system. An emphasis will be given to the sustainability of the system reconfiguration. With the word “system” is intended here the set of hardware and software resources whose aim is to realize the whole production process, (e.g. production lines, FMSs, job shops, ...). With PDKM (Product Data Knowledge Management) is intended the storage and management system of product data and knowledge, one of the essential elements of the PROMISE platform. With SDKM (System Data Knowledge Management) is intended the set of data ( with the relative knowledge) concerning the production system. The PROMISE platform gathers data from the whole product lifecycle, which are transformed into knowledge concerning the product. This can be used by the different product lifecycle stakeholders to improve one or more of the lifecycle phases and sub-phases. For instance they can be used in the BOL to modify features of the product as required by e.g. Predictive Maintenance or EOL processing. The collected data will increase product/process modifications relative to the current situation. Once the modifications have been decided, it is essential to make the system work according to the new “rules” in the most efficient way possible. To achieve this it is important to have a kit of tools which will help the decision maker to reconfigure the production system (e.g. the production line) or even to design/configure a new one. This is the area of the demonstrator developed in WP A11 for the present scenario. The related information flow about the system/process/product is depicted in dashed red lines.


@

Scenario description The process/product modifications affecting a family of products are identified and properly modelled, e.g. a set of scenarios for these type of modifications is given with the relative set of probability distributions. The Adaptive Production paradigm forces the decision maker to decide how the system layout should be modified ( e.g. “Should the number of machine tools be increased, decreased, or remain the same?” And, if in the case, “How many new machine tools should be added and what kind of machine tools?”) or how the inter-operational buffers should be modified in order to maximize a certain type of objective function (e.g. the system throughput), following the product/process modification scenarios. The reconfiguration activities should take into consideration the whole set of modification scenarios concerning the product/process, considering also all the implications which a certain feasible configuration of the production system can cause to its lifecycle.


@

Illustration of the information flow (flowchart) In order to identify informational requirements, illustrate the flow of information and clearly identify information/data flows by denoting this in the figure. Use rectangles, arrows, circles etc with text. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. An information flowchart for the application scenario has already been described in the answer to the previous question. Specific requirements needed in order to fulfil the objective (user requirements related to WP R1) If there are some specific requirements that are needed to be fulfilled, please state them here. None Pain-points (problems/challenges) Identify the most important problems/challenges related to this scenario (e.g. technical, economical, ethical, environmental, customer related, partner related) The main pain point is surely the analysis and modelling of the future most probable scenarios for the product/process modifications. The problem is that not all markets give the possibility to the decision maker to collect all the needed data about product/process modifications, which are essential for the analysis. Other aspects related to the Application Scenario If some aspects are not are covered above, please use this field.


@

11.1 Technical issues A11 Data&Information: Product Information requirements List what sort of data is to be gathered from e.g. PEIDs. Show how the data is to be transformed into information. Use a tree diagram to illustrate the flow of data, starting with the data gathering from e.g. wheel, dampers etc to the right, and flowing into the PEID. From the PEID indicate output flows and show whether the data is sent by internet, radio, gathered by technician to e.g. a PDA As this section called “Technical issues” has been intended by the authors of this document as the definition of the PEID related issues regarding the product involved in the scenario, answers to these questions cannot be given from this point of view. This because, as stated above, this application scenario focuses on the production system, the product being anyone of the products involved in the rest of PROMISE application scenarios. So we do not need any PEID to be attached to the machine tool because we do not need to follow the system lifecycle. Anyway here a simple model of the input and output data can be found, in order to state from the very beginning all data and information involved in the scenario.

Data&Information: Input data Describe the input data going into the PEIDs (type of data, believed amount of data etc). With regard to the application scenario definition given in the answer to question 2.7 and the diagram in the answer to the previous question, one may underline that the ownership of the appropriate data about the future evolution of process plans, bills of materials and demand will enable the decision maker to face the scenario.

system configuration

SDKM

PDKM

Adapt production

system

Design product


@

Data&Information: Output data Describe the output data going out from the PEIDs (type of data, believed amount of data etc). The Adaptive Production Scenario has one and only output, which is a (new) configuration for the production system, in particular the one that best fits to the objective chosen before the analysis. The output data will contain for example the number/type of machine tools, the number/type of inter-operational buffers (in particular their capacity), and so on. Data&Information: Amount of data Describe the need for storage in the PEIDs (this in order to get a picture of how much storage is needed in e.g. the PEIDs)

“Not applicable” See answer to DATA&INFORMATION: PRODUCT INFORMATION REQUIREMENTS

Hardware: Hardware Describe what sort of hardware technologies (PEID, sensors, GPS, networks etc) would be considered to be used or as needed to be developed.


Hardware: Life span of devices What is the needed minimum life span of the devices?


Hardware: Working conditions Describe under what sort of working conditions the devices are believed to be working under (like impacts, heat, cold, moisture etc)


Software: Firmware (embedded software) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed.


Software: Middleware (software that allows different software applications to communicate)Describe what sort (if any) software technologies would be considered to be used or as needed to be developed.


Software: D2D (software that allows devices to communicate) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed.



@

Software: D2B (software that allows devices to communicate with middleware and/or other software applications) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed.


Software: Backend software (software for data management, decision making etc) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. The backend software needed for the present application scenario relies on the presence of, at least, two software tools for data management, which correspond to the two big data bases contained in Fig. 1. The PDKM software is the one defined and used inside the PROMISE platform, as been designed and implemented by the activities performed in WP R7. The SDKM is a simple list providing the needed data about the system.. Software: Decision support software (Local? Remote?) Describe what sort (if any) software technologies would be considered to be used or as needed to be developed. The demonstrator developed in this scenario will become part of the PROMISE decision support system. Other aspects related to the Technical issues If some aspects are not are covered above, please use this field.


@

11.2 Business/economical issues A11 As-is, current solution/implementation of the scenario or similar tasks/situations Describe the As-is solution/implementation that are used today (either as your company or others uses). Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. Reconfiguration of production systems is nowadays carried out without taking into consideration the different sort of product/process modifications. This is because of the unavailability of the proper data needed for the analysis. To-be, Future scenario concept Describe in more detail the To-be solution/implementation. Describe it in such a way that it is related to the As-is description above. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. The implementation of the PROMISE system will enable the decision maker to decide the best configuration for a production system making use of data collected during the entire product lifecycle, so the solution to the reconfiguration problem will be less partial than it is today. The gap from the “as-is” and the “to be” situations can only be filled by the existence of a system that takes into account from the beginning the future evolutions of the product. Business effects (own business) – negative aspects Describe the negative business effects the application scenario (described in section 1) will/could have on your business. (E.g. manpower needs, economy, new business areas, ethical, environmental etc.) The implementation of the Adaptive Production paradigm inside an already existing firm could have some negative aspects on business management, like:

• The justification of costs due to either the first acquisition of the needed software or to the updating activities of the same software.

• The difficulties inside the enterprise to implement the new system configuration due to the cost of the reconfiguration activities, though these system modifications are strongly based on some economical motivations, and more generally the hostilities to accept the output of the decision support system.


@

Business effects (own business) – positive aspects Describe the business effects the application scenario will/could have on your business. (e.g. Improved business situation Business improvements opportunities (productivity, quality, environment, social issues) etc. The use of the software tool will allow advantages both in the general approach with which the enterprise chooses its facilities and in the reconfiguration itself. First of all, engineers will have the possibility to use a rapid tool to design the system by exploring a wide set of potential alternatives in a structured way. Then, more specific benefits can be gained with the adoption of the new configuration which takes into consideration some information about the product/process, which were unknown at the time the system was first configured, e.g. :

• Modification needs about the product/process requested by the market. If the enterprise becomes aware of the most probable product/process future modifications, system configuration activities could be carried out evaluating different scenarios. In this way the enterprise can prove the feasibility of new solutions to its production problem, with a nearly complete analysis.

• Modification “plans” about the product/process, in order to force the introduction of innovative solutions for the next future. In this way the enterprise role becomes proactive, compelling its competitors to react to the new changes.

Such important piece of information can be used to study which new system configuration best accomplishes to the enterprise objectives, and to provide an estimate of the potential improvements in terms of the most important technological factors, such as productivity, manufacturing flexibility, product/process quality, … The added value which can be found in such a type of analysis derives from the information concerning process/product modifications, which are not adequately considered in the current situation. Cost models What sort of cost models is viable for the application scenario? I.e. how much is the maximum price per PEID, support systems etc? It’s important to identify the maximum price range that can be added to a product/vehicle etc as a consequence of the aspects described in this application scenario. Describe therefore aspects that will have a consequence for costs, and in what range the “hurting” price for the customer (or users etc) will be. The Adaptive Production scenario does not need neither specific PEID devices nor the related hardware/software/firmware/… , so the main costs involved in the scenario could be costs concerning the software for decision support in the system (re)configuration. It is impossible for the moment to give a detailed estimate of all of these costs; anyway here the typical costs concerning the decision support software can be listed:

• Software acquisition cost • Software maintenance cost • Employees/workers training cost • Software customization cost

With “Software customization costs” are intended all of the costs concerning the activities of customizing the software to the specific production system. Other aspects related to the Business/Economical issues If some aspects are not are covered above, please use this field.


@

11.3 Value-chain issues A11 Make an overview of the value-chain related to the application scenario Describe the partners/business associates/customers etc related to the application scenario. If this already has been covered by earlier illustrations/descriptions, please indicate this in the field below. Feel free to illustrate with figures as fit. Use the font Arial Narrow no smaller than 8 pts. If the illustration does not fit the format of this page, insert it and make it fit by dragging the figure smaller. Remember to include the figure as a separate file (in JPEG, GIF, Visio-format or include it in a Word or Powerpoint-file. This Application Scenario mainly involves as a unique big stakeholder the extended enterprise as a whole, with particular regard to the business unit which manufactures the product. In fact all activities concerning the (re)configuration of the system can be accounted to this business unit, whose aim is to obtain the product (with or without modification, following the market needs) by realizing the production process in the most efficient way. So a real value-chain for this Application Scenario cannot be described. However a list of the people directly involved in the scenario can be given:

• System designers. The most involved in the benefits deriving from the scenario. They directly use the decision support software to prove the feasibility of new system configurations with the aim to react to the process/product modifications following the new market needs or to force new product/process solutions playing a first row role in the same market.

• Product designers. The product designer is involved in the scenario because he determines the inputs to the (re)configuration activities and, at the same time, to the decision support software. If the new product solutions cannot be implemented in any new system configuration, due to their unfeasibility, the product designers should generate alternative product modifications to satisfy the market.

• Process designers. Same role as the one played by product designers, but concerning the process.

• System managers. System managers can have a certain number of benefits from the (re)configuration of the production system, deriving from the improvement in productivity, quality, and so on. They can also have some downsides due to the difficulty to decide and implement the new management policies for the production system.

Describe possible downsides/upsides related to: Customers (categorized), Suppliers (categorized), Partners/cooperating companies (categorized) What kind of consequences will the application scenario have for the partners/business associates/customers etc in the value-chain. E.g. Dismantler: Dismantler must invest in new systems for reading/handling discarded products etc, but will have an upside regarding their operations of reuse/remfg etc as they more readily can… E.g. Customer: Customer will experience changes in their maintenance program this can be perceived as a positive or negative aspect (briefly describe why/how) See answers to BUSINESS EFFECTS (OWN BUSINESS) – POSITIVE & NEGATIVE EFFECTS Other aspects related to the Value-chain issues If some aspects are not are covered above, please use this field.


@

11.4 Environmental issues A11 Savings of energy Based on today’s As-is situation, try to guesstimate the savings of energy due to the new application scenario (if any). Justify the guesstimate. Not applicable Savings of material Based on today’s As-is situation, try to guesstimate the savings of material due to the new application scenario (if any). Justify the guesstimate. Not applicable Reuse or extended product life Based on today’s As-is situation, try to guesstimate the amount of reuse and/or extended product life due to the new application scenario (if any). Justify the guesstimate. Not applicable Other aspects related to the Environmental issues If some aspects are not are covered above, please use this field.


@

11.5 Social issues A11 Changed labour/work conditions Describe the implications of the application scenario regarding changed labour/work conditions Changes in the labour/work conditions can only be described in the specific case of enterprise implementing and using the decision support system based on the Adaptive Production demonstrator. Social Impact on society Describe, if any, implications of the application scenario regarding Social Impact on society None. Ethical issues Is there ethical issues related to the application scenario? IF Yes explain None. Other aspects related to the Social issues If some aspects are not are covered above, please use this field.


@

DR3.2 PROMISE Demonstrators & State-of-the-art · DR3.2 PROMISE Demonstrators & State-of-the-art...

Documents

Transcript of DR3.2 PROMISE Demonstrators & State-of-the-art · DR3.2 PROMISE Demonstrators & State-of-the-art...