d2.2_out

The PREMANUS project (285541) is co-funded by the European Union under the Information and Communication Technologies (ICT) theme of the

7th Framework Programme for R&D (FP7).

This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be

made of its content.

Programme Factories of the Future PPP

Strategic Objective ICT-2011.7.3 Virtual Factories and Enterprises

Project Title Product Remanufacturing Service System

Acronym PREMANUS

Project # 285541

D2.2 - REQUIREMENTS ANALYSIS

REPORT

Work Package WP2: Reference Architecture

Lead Partner 2: POLIMI

Contributing Partner(s) 1 (SAP), 3 (LBORO), 4 (TIE), 5 (SKF), 6 (CRF),

7 (EPL)

Security Classification PU (Public)

Date 16th July 2012

Version 1.2

COPYRIGHT © Copyright 2012 by PREMANUS Consortium

Legal Disclaimer The information in this document is provided „as is‟, and no guarantee or warranty is given that the information is fit for any particular purpose. The above

referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages

that may result from the use of these materials subject to any liability which is mandatory due to applicable law.

This document may not be copied, reproduced, or modified in whole or in part for any purpose without written permission from all of the Copyright owners. In

addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all

applicable portions of the copyright notice must be clearly referenced.

All rights reserved. This document may change without notice.”

Project –No

Date

Classification

285541

16-July-12

PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

ii

Document history

Version Date Comments Author

0.1 14/04/12 ToC and first Draft Tobias Wieschnowsky (SAP)

0.2 29/05/12 Update Requirements of RSG Oscar Garcia (TIE)

0.3 10/06/12 Update Requirements of RIS, RSG, BDSS

Tobias Wieschnowsky

(SAP), Oscar Garcia (TIE),

David Potter (Polimi)

0.4 25/06/12 Template Fixing Oscar Garcia (TIE)

0.5 26/06/12 Executive Summary David Potter (Polimi)

0.6 27/06/12 Added section 2.2 Jacopo Cassina (Polimi)

0.7 28/06/12 Consolidation for final contributions David Potter (Polimi), Stefan

Schleyer (SKF)

0.8 30/06/12 Further Consolidation David Potter (Polimi)

1.0 03/07/12 1st Revision Oscar Garcia (TIE)

1.01 05/07/12 Internal Review Stuart Campbell (TIE)

1.02 09/07/12 Partial Revision Federico Magalini & David

Potter (Polimi)

1.03 10/07/12 Inclusion of revisions, Changes to different sections Oscar Garcia (TIE), Benedikt

Schmidt (SAP)

1.04 11/07/12 Revisions and changes for various sections Tobias Wieschnowsky

(SAP), Oscar Garcia (TIE)

1.05 12/07/12 Minor revisions and formatting fixes Tobias Wieschnowsky (SAP)

1.06 13/07/12 Further quality check. David Potter (Polimi)

1.07 16/07/12 Minor corrections and format repair Tobias Wieschnowsky (SAP)

1.08 16/07/12 Finalizing document Nicolas Liebau (SAP)

1.2 08710/12 Adding requirements for product IDs Nicolas Liebau (SAP)

The research leading to these results has received funding from the European Community‟s Seventh Framework Programme

Project –No

Date

Classification

285541

16-July-12


iii

(FP7/2007-2013) under grant agreement no285541.

Project –No

Date

Classification

285541

16-July-12


iv

Table of contents

1 EXECUTIVE SUMMARY ........................................................................................................... 6

2 INTRODUCTION & OVERALL PREMANUS SYSTEM REQUIREMENTS...................... 8

2.1 SUMMARY OF PREMANUS USAGE SCENARIOS ...................................................................... 9 2.1.1 Summary CRF use case ..................................................................................................... 9 2.1.2 Summary SKF use case ................................................................................................... 10

2.2 CONCLUSIONS: OBJECTIVES AND CRITERIA FOR REQUIREMENTS ANALYSIS ........................ 11 2.2.1 Technical Requirements .................................................................................................. 11

3 REQUIREMENTS FOR REMANUFACTURING INFORMATION SERVICES .............. 12

3.1 PRODUCT IDENTIFICATION & INFORMATION NETWORK ........................................................ 14 3.1.1 Central Network Structure .............................................................................................. 14 3.1.2 Decentralized Network Structure .................................................................................... 15 3.1.3 Hybrid Network Structure ............................................................................................... 15 3.1.4 Conclusions ..................................................................................................................... 16

3.2 PRODUCT & COMPONENT IDENTIFICATION & MAPPING ........................................................ 16 3.2.1 ID Mapping ..................................................................................................................... 17 3.2.2 ID Resolution .................................................................................................................. 19 3.2.3 Conclusions ..................................................................................................................... 19

3.3 SEARCH AND LOOKUP MECHANISM ....................................................................................... 20 3.4 DISTRIBUTED PRODUCT INFORMATION STORE (DPIS) .......................................................... 22

3.4.1 Types of data ................................................................................................................... 22 3.4.2 Distributed storage .......................................................................................................... 22 3.4.3 Amount of data ................................................................................................................ 23 3.4.4 Semantic enriched content .............................................................................................. 23 3.4.5 DPIS Requirements ......................................................................................................... 23

3.5 INFORMATION RETRIEVAL MECHANISM ................................................................................ 24 3.6 ROLE-BASED ACCESS CONTROL ............................................................................................. 25

4 REQUIREMENTS FOR REMANUFACTURING SERVICES GATEWAY ....................... 26

4.1 SEMANTIC SERVICE BUS ........................................................................................................ 27 4.1.1 Introduction ..................................................................................................................... 27 4.1.2 SSB Requirements ........................................................................................................... 27

4.2 INFRASTRUCTURAL SERVICES ................................................................................................ 29 4.2.1 Generic Services .............................................................................................................. 29 4.2.2 Semantic services ............................................................................................................ 30 4.2.3 Gateway services ............................................................................................................. 32

4.3 DEVICE AS A SERVICE, MAINTENANCE AS A SERVICE ........................................................... 33 4.4 RESULTING HIGH LEVEL FUNCTIONAL CONCEPT .................................................................. 34

5 REQUIREMENTS FOR BUSINESS DECISION SUPPORT SYSTEM ............................... 36

5.1 BUSINESS DECISION SUPPORT SYSTEM FOUNDATION ........................................................... 36 5.1.1 PREMANUS Data Store .................................................................................................. 36 5.1.2 PREMANUS Data Store’s Data Structure ...................................................................... 36 5.1.3 PREMANUS Search Engine ............................................................................................ 37 5.1.4 Access to further IT Systems of the Remanufacturer ....................................................... 37 5.1.5 Conclusion PPREMANUS Business Decision Support System Foundation ................... 37

5.2 END-OF-LIFE PRODUCT RECOVERY PROCESS ECO-EFFICIENCY EVALUATOR ...................... 38 5.3 KPI OPTIMIZER ....................................................................................................................... 40 5.4 HUMAN COMPUTER INTERACTION ......................................................................................... 42

Project –No

Date

Classification

285541

16-July-12


v

5.4.1 User Experience .............................................................................................................. 42 5.4.2 Complex Systems – BDSS-specific .................................................................................. 43 5.4.3 Process flexibility: Control and coordination by task-centred information systems and

business processes ......................................................................................................................... 45

6 SUMMARY OF REQUIREMENTS .......................................................................................... 48

7 APPENDIX A: REFERENCES .................................................................................................. 57

Project –No

Date

Classification

285541

16-July-12


6

1 Executive Summary

This document examines the requirements for the different components that will be needed in the

PREMANUS Architecture from both functional and non-functional points of view. Whereas the

deliverable D1.3 provides a high level user-oriented overview of user‟s expectations and requirements

for the PREMANUS architecture, this document more closely examines the requirements, especially

with respect to functional and non-functional technical requirements.

In order to facilitate better decision making for remanufacturing, PREMANUS must consolidate

product information of different types from a wide variety of sources. In particular, information such

as a product‟s bill of material combined with usage and maintenance information gathered during its

entire lifecycle are critical. Such information needs to be brought together using a number of services

to locate, retrieve, index and consolidate information so that it can be used by functions of the

PREMANUS Business Decision Support System (BDSS).

Figure 1 – PREMANUS Conceptual Infrastructure

Figure 1 shows the different requirements for an architecture that must be realized in PREMANUS. A

central node coordinates information searches between the different PREMANUS partners. Each

partner operates a local PREMANUS node that operates on local data, and that can be used to access

external data.

Main components of local PREMANUS nodes are the Remanufacturing Information Service, the

Remanufacturing Service Gateway and the Business Decision Support System.

The Remanufacturing Information Service (RIS) provides the functionality to enable searching for

relevant information and enabling a product to be tracked across different stakeholders during its

lifecycle.

The Remanufacturing Service Gateway (RSG) is responsible for communication between functional

Project –No

Date

Classification

285541

16-July-12


7

modules and enabling information extraction and import to the PREMANUS Business Decision

Support System from heterogeneous information sources (like databases and content types) via

adapter services and semantic services.

The BDSS provides a single point of information for remanufacturing decisions. Users access KPIs

and product information using the BDSS. To enable this, the BDSS is the front end for the RSG and

RIS as well as being a system to calculate product specific KPIs based on user queries.

The requirements are examined per component and a summary of the requirements is given at the end

of this deliverable.

Project –No

Date

Classification

285541

16-July-12


8

2 Introduction & Overall PREMANUS System Requirements

This deliverable presents the technical requirements for PREMANUS based upon the usage scenarios

described in the deliverables D1.1, D1.2, and D1.3.

The PREMANUS DoW organizes the work tasks and deliverables with respect to three functional

components (see Figure 2). This document follows this component structure and identifies

requirements for the Remanufacturing Information Service (RIS), the Remanufacturing Service

Gateway (RSG), and the Business Decision Support System (BDSS).

Figure 2 - Three architectural pillars of PREMANUS

The RIS ensures that information relevant to remanufacturing decisions can be searched for

efficiently. This information is mainly data about products and is distributed across the stakeholders

of the remanufacturing ecosystem. In the DoW, three services were already identified that the RIS

needs to provide:

Product ID resolution and mapping: This enables PREMANUS to cope with different IDs

within the stakeholders‟ IT systems

Persistency service: This allows storage of information that helps tracking a product across

its lifecycle

Role-based access control: This enables the implementation of confidentiality requirements.

The RSG enables the communication of the functional components and the access to information

stored in structured and unstructured information sources. Within the DoW three services were

already identified that the RSG needs to provide:

Semantic Service Bus: Allows the interconnection of the functional modules and provides

message routing. It also provides semantic capabilities

Infrastructural services: For example the automated generation of interfaces to information

sources

Adapter services: These allow the connection of different information sources such as

databases or devices.

The BDSS enables analysis of information about the product to be remanufactured and provides

decision support to the user. Two core services have been identified in the DoW:

The End of Life product recovery process eco-efficiency evaluator: This will take into

consideration the environmental impact of the End of Life (EoL) product recovery process

Project –No

Date

Classification

285541

16-July-12


9

The KPI Optimizer: Provides Decision Support for Remanufacture/Reuse/Disposal based on

economic KPIs.

In order to formulate the technical requirements, the next section will summarize the usage scenarios

which are result from WP1.

2.1 Summary of PREMANUS Usage Scenarios

D1.3 provided a high-level, user-oriented overview of users‟ expectations and requirements for the

PREMANUS architecture. The differences and unique elements of the two use cases demand that the

architecture should be sufficiently flexible to meet the needs of these and other different

industries/remanufacturing sectors. The two use cases and the expectations from PREMANUS

include activities occurring in different stages of the remanufacturing process itself and supporting

business in multiple ways as summarized in D1.3, Chapter 5.3 and in particular:

Definition of estimated costs for the remanufacturing process based on previous

contract/activities or in-house knowledge-base/information

Supporting the general remanufacturing strategy at product or specific component level, based

on access to PLM data or in-house knowledge/information

Supporting operations during dismantling and/or re-assembly phase, enabling the effective

implementation of a company‟s strategy regarding, among other things, salvages, component/

sub-assemblies/product stocks, purchase of external components/products etc.

Developing and maintaining an in-depth knowledge-base as overarching tool to support

operations and business strategy

Integrating existing information stored/maintained in other IT System within the company

2.1.1 Summary CRF use case

In the CRF Use Case, PREMANUS‟ users will benefit from PREMANUS in three main stages of the

remanufacturing process:

Deciding the remanufacturing strategy for each engine arriving at the plant (i.e.

remanufacturing the entire engine, remanufacturing only selected components or sub-

assemblies or discard to material recovery)

Supporting the remanufacturing process at the operational level, particularly providing step-

by-step dismantling and re-machining instructions to operators, depending on PLM data and

other KPIs and keeping track of real activities of operations

Supporting assembly operations; particularly providing step-by-step assembly instructions

and keeping track of real activities of operations

Currently CRF uses the following information systems for most its manufacturing businesses:

In-house ERP system called OCTAL

In-house high-level KPI visualizer, retrieving data from OCTAL, called PlantDashboard.

In-house PLM system (tracking actual maintenance activities during warranty period) called

link.e.entry.

In-house system for assembly and disassembly instructions called eLearn

Plant simulation tool by Siemens Tecnomatix (Plant Simulation v.10)

In order to achieve the expected benefits, the PREMANUS architecture should:

Provide interfaces for operators, allowing:

Project –No

Date

Classification

285541

16-July-12


10

o Proper retrieval and display of unique IDs assigned once the engine arrived at the

plant. The plant ERP (i.e. home-grown software “OCTAL”) system connects an ID to

all relevant information (e.g. engine serial number, stock level, expected demand of

remanufactured engine, rotation rate, etc.)

o Proper interfaces to access specific IT systems and particularly:

the link.e.entry system to retrieve detailed PLM and BoM data to feed the

PREMANUS BDSS

the e.learn system to print detailed, step-by-step dismantling and assembly

instructions

o The display of a job-order for each specific engine and/or component that will be

created on the basis of information stored in OCTAL and algorithms in PREMANUS

BDSS. Job orders might include different scenarios (e.g. from engine-to-engine, from

engine-to-subassemblies, both with or without intermediate warehousing of

components)

o The recording of specific activities carried out during operations, including potential

deviations from planned job-order due to on-the-line assessment, as well as recording

of activity time to elaborate detailed KPIs

Enable access and retrieval of data from relevant IT systems (OCTAL, link.e.entry, e.learn)

with the following objectives:

o To feed PREMANUS BDSS (e.g. BoM, PLM data, elaborated KPIs)

o To allow access to information stored and managed in such systems (e.g. detailed

dismantling and assembly instructions) under control of proper user identification.

Allow the export of data for business analysis (e.g. CSV).

2.1.2 Summary SKF use case

In the SKF Use Case, PREMANUS users will benefit from the tool in three main stages of the

remanufacturing process as follows:

Initial Quotation: An initial ball-park quote for each potential customer requesting for gear-

box substitution or remanufacturing will be created. The quote is based on both information

available at customer level, in-house specific knowledge and in-house historical data

(including availability of components). Other information sources are standard or estimated

workloads derived from in-house knowledge or past remanufacturing processes

Firm Quotation & remanufacturing process: A final and firm quote is created in the

disassembly process based on the product insight gained and knowledge-based enrichment:

The remanufacturing process of each product brings new information about the process. The

newly gained knowledge is used to increase the in-house knowledge and build-up a

knowledge-base. The management of the information supports future activities, in particular

initial ball-park quotations.

Currently SKF uses the following information systems for most its manufacturing businesses:

In-house ERP system (MCSS for production, SKF Office for sales)

PLM and CAD systems by PTC - Pro-Engineer (now called Creo) and Windchill

WindCon (remote wind turbine monitoring system by SKF)

WinDog for the inventory of the installed WindCon systems

Suppliers and customers also use different types of CAD and PLM systems

In order to achieve the expected benefits, the PREMANUS architecture should:

Provide interfaces for operators, allowing:

Project –No

Date

Classification

285541

16-July-12


11

o Access and retrieval of information stored in other IT Systems in order to assess

availability of components, the current prices or stock levels, the schedule of

remanufacturing plant and the workload of involved operators

o Proper interfaces to access specific IT systems and particularly:

“WinDog” to retrieve detailed bearing information (in case SKF bearings are

used in a gearbox) including bearing type, number of rolling elements, size &

geometry, etc.

o Display of specific information (e.g. photo, CAD representations, notes,..) from

previous processes or related to specific components in order to estimate the potential

economic impact of the remanufacturing process, but also supporting the disassembly

once the gearbox arrives at plant

o Recording of specific activities carried out during operations within SKF; in

particular all details of the disassembly process, including results of inspections, tools

used, time and workload of staff, all un-expected events etc, in order to build a

detailed knowledge-base

Enable access and retrieval of data from relevant IT systems with the following objectives:

o To feed PREMANUS BDSS (e.g. BoM, PLM data, elaborate KPIs)

o To allow access to information stored and managed in such systems (e.g. workload of

operators, prices and availability of components, potential outsourcing for gearbox),

under the control of proper user identification

o To allow access to PLM data in the case “WindCon” system is used on the wind

turbines from which the gearbox has to be remanufactured.

Allow the export of data for business analysis (e.g. CSV, XML).

2.2 Conclusions: Objectives and Criteria for Requirements Analysis

In addition to requirements arising within the project, some concepts and ideas were also considered

to make the PREMANUS solution commercially sound and more attractive. Some of the ideas have

arisen from meetings held between POLIMI and some Italian SMEs in the remanufacturing area.

2.2.1 Technical Requirements

The following high-level technical requirements are derived mostly from the PREMANUS

description of work. Interoperability with existing IT systems at the use case partners, and later at the

users of the PREMANUS middleware, requires standardized interfaces in order to connect to those IT

systems. Another requirement is to keep the PREMANUS system modular, which makes it more

extensible and customizable according to the needs of the end-user deploying the PREMANUS

middleware.

In short the high-level technical requirements are:

The PREMANUS system should be modular

The interfaces should be based on open standards

The BDSS should be able to interact, through standardized interfaces, with third party

systems

Project –No

Date

Classification

285541

16-July-12


12

3 Requirements for Remanufacturing Information Services

The RIS serves as layer for providing product-related information to the RSG. To realize this, the RIS

provides the mechanisms for distributed storage and retrieval of product information. In order to

define the functional and non-functional requirements, an understanding of today‟s environment, of

which the RIS has to be part, is required.

For production enterprises working in supply chains, products consist of components either produced

in-house or supplied by different manufacturers. Different manufacturers make up a supply chain that

coordinates a production process (see Figure 3 showing 3 such organizations). Other factors might be

non-physical elements like Service Level Agreements (SLAs) about the promised performance of the

product, guarantees, service contracts, liability agreement, insurances, etc. The data that describes the

product and its components is called the product‟s master data. Master data is relatively constant and

is only updated if the components of the product change or variants are created.

Figure 3 - Supply Chain

During the lifecycle of a product it will be maintained, components might be repaired, overhauled,

and replaced; the product‟s status may be monitored using sensor measurements and analysed. This

data is referred to as lifecycle information of a product. The product‟s lifecycle information can be

much more extensive than the master data and is often frequently updated.

For End-of-Life re-manufacturing decisions, all this information (master data and lifecycle

information) can contribute significantly to the quality of the decision (see Section 2.1 Summary of

PREMANUS Usage Scenarios).

In order to find and retrieve the information, several core requirements must be fulfilled:

The RIS must be enabled to clearly identify an individual product and its components via

an identification scheme

The product identity must be related to the correct master data and lifecycle

information via efficient data querying/discovery mechanisms

The challenge for the PREMANUS system is the setup of the ecosystem it has to operate in. It is

composed of many distributed, independent parties, each with their own independent and

unlinked/exposed information sources. Each party (component supplier, original equipment

manufacturer, maintenance service provider, etc.) might also use its own methodology for recording

and storing product master data and product lifecycle information.

Accordingly, another core requirement is relevant for PREMANUS:

Product Information Transformation mechanism that transforms retrieved into a unified

data format so it can serve as input to the BDSS.

Project –No

Date

Classification

285541

16-July-12


13

Taking into account these requirements, the PREMANUS RIS will establish a Product Identification

and Information Network that the BDSS will use to collect all available inputs for the

remanufacturing decision (Figure 4 - Product Identification & Information Network).

Figure 4 - Product Identification & Information Network

The following table summarizes the main PREMANUS requirements for the Product Identification &

Information Network.

Product Identification & Information Network Requirements

RIS.PIIN.1 ID Information Discovery Functional

PREMANUS should discover which information for a given ID is available

from which stakeholder

Information discovery should allow a stakeholder to gather all necessary

information for an ID to use for assessment or disassembly

RIS.PIIN.2 Information Retrieval Functional

Once a stakeholder has been identified as holding relevant information, there

should be some (probably standardized) mechanism to discover which

information & services are available to other PREMANUS stakeholders

There should be an interface to retrieve/use the information/services.

RIS.PIIN.3 Information Transformation Functional

RIS should manage a canonical data structure to support import from

heterogeneous information sources into PREMANUS by a transformation

service.

The transformation service should enable simple information processing into

the BDSS.

Project –No

Date

Classification

285541

16-July-12


14

Before discussing each of the core requirements in more detail, the alternatives for building an

information network within a remanufacturing ecosystem will be discussed. The structure of the

information network influences the sub-requirements for each of the core requirements.

3.1 Product Identification & Information Network

There are three different types of networks that can be distinguished: Centralized, decentralized, or

hybrid (see Figure 5).

Figure 5 - Alternative Concepts for the Product Identification and Information Network

The different alternatives will be evaluated according to the following criteria:

Commercial soundness of concept; that is, based on commercial reasoning is it likely that

the individual parties within a remanufacturing ecosystem would join such a network

structure?

Technical soundness of concept; that is, is the technology required to setup such a network

architecture mature, reliable and can it be operated effectively?

Business Model support; that is, is there a business model that would support setting up and

operating such a network structure within a remanufacturing ecosystem?

3.1.1 Central Network Structure

In a centralized network, all product information is stored at a central node. Thus, each party in the

ecosystem who is creating product information throughout the lifecycle of an individual product must

upload this information and all or certain parts of information may also be propagated to other

individual nodes. Advantages of this approach are that information will be transformed into a unified

format when it is uploaded. Further, all information remains available, even if a party is leaving an

ecosystem (e.g. due to bankruptcy or acquisition). Disadvantages are that one organization is required

to operate this central node. All parties in the ecosystem would need to agree to work with such a

central node and be dependent on it, potentially introducing a single point of failure. Thus all parties

have to establish commercial relationships with the entity operating the node.

3.1.1.1 Evaluation

It is unlikely that manufacturers would agree to a central network. The party operating the central

node would have access to all product information; much of that information a company considers it

intellectual property, e.g. its customer base or supply chain. Thus, only a completely neutral entity

with no commercial interest in the information could operate such a node for the ecosystem. To the

Project –No

Date

Classification

285541

16-July-12


15

project‟s knowledge there is currently no such entity existing, therefore this alternative has a weak

commercial soundness and is not discussed any further in this model.

3.1.2 Decentralized Network Structure

In a decentralized network all information remains at a node controlled by the party that created the

information. When information is required, the information must be located at one of the nodes of the

ecosystem or subscribed to. This requires fully decentralized mechanisms for identification, search,

subscription and lookup.

Completely decentralized information systems have been intensively researched within the overlay

network [1] and peer-to-peer systems [2] , [3] research areas.

3.1.2.1 Evaluation

Although researched, fully decentralized IT systems have not yet been successfully introduced for

industry applications. This is due to some inherent challenges of these systems, especially regarding

firewall traversal and reliability; an overlay network requires that each node of the overlay network

can be reached by each other node. For industry applications this requirement is difficult to achieve,

as IT departments will not easily open up their IT systems to a whole ecosystem. Further, fully

decentralized systems are difficult to manage – for example, it is difficult to determine the root cause

of a failure if there is no central node available that monitors the network‟s state.

Peer-to-Peer systems face another problem regarding commercialization that also applies to

PREMANUS. A party has to build the network and take responsibility for correct operations.

However, the fully distributed nature provides a challenge for doing so. Further, as there is no central

IT node and all investment and operating costs are with the network nodes, it is difficult to build a

business model around a fully decentralized network.

Accordingly, this network structure is weak in the technical soundness and support of business models

and again will not be further discussed.

3.1.3 Hybrid Network Structure

In a hybrid network the information is stored at the decentralized nodes. At a central node an index for

the information is kept so any information can be localized quickly. When information is created on

the decentralised nodes, the node storing the information will publish an “advertisement” to the

central node where the advertisement (or annotations) will be stored in a database. The advertisement

contains the unique identification of the data access point and further descriptors that are meaningful

for search.

When information is searched, queries on the central node will be used to determine the required

information and location of it. Then, the information will be retrieved from the storing nodes.

Hybrid systems have been deployed in large scale e.g. based on the BitTorrent content distribution

protocol [4] .

3.1.3.1 Evaluation

Each party is still in full control of its information and can decide with whom to share which

information; which is the same scenario as with normal business. Therefore, commercially the

Project –No

Date

Classification

285541

16-July-12


16

concept is sound.

Technically, a hybrid network is less complex to setup and maintain than a fully decentralized system.

Scalability issues are handled due to the decentralized information storage. Accordingly, this structure

also can be implemented with a sound technical concept.

However, still there is a central node, even if used primarily for indexing, and hence it requires a party

to operate it. But since the central node does not impose direct advantage of information, there is no

commercial threat established by the operator unlike in a centralised system. Further, the operator of

such a central node would take the role of a technical enabler for the ecosystem. Based on the central

node, the operator could offer interoperability among the parties as well as security and trust for the

ecosystem. The operator could also establish further services on top which may be attractive to users.

However, some of the negative points mentioned for centralised systems are still relevant.

3.1.4 Conclusions

Only the hybrid approach fulfils all evaluation criteria (technical complexity, data privacy) for the

Product Identification & Information Network Structure. Therefore a remanufacturing ecosystem with

a central node is assumed as the foundation for the remaining requirements. The central node stores

the identifiers and links of relevant product master data and product lifecycle information.

RIS Remanufacturing Information Service

RIS.PIIN.0 Product Identification & Information Network

Structure

Functional

The Remanufacturing Information Service should be built in a hybrid

structure

o Content should be stored by each stakeholder locally

o A central node should realizes directory service with search, lookup, ID

resolution, mapping, and a retrieval service

o A directory service should store advertisements/annotations that

describe information available at the stakeholders

Table 1: Requirements for the Structure of the PREMANUS Identification & Information Network

3.2 Product & Component Identification & Mapping

In order to make the right remanufacturing decisions for a product, information on the individual

product must be available. This information is composed of:

Product Master Data, such as:

o Product identification

o Product composition into component classes

o Individual components for the component classes

Lifecycle information of a product, such as:

o Service history

o Component replacements

Project –No

Date

Classification

285541

16-July-12


17

o Sensor readings, e.g.:

Operating hours

Oil temperature

Oil pressure

Etc.

In order to locate product master data and corresponding lifecycle information, it is important that the

system provides the ability to reference and correlate products by any identifier that may have been

assigned to them, either at the unique ID or product type level.

Today in the manufacturing industry there is no common identifier scheme used across the

companies. Rather each company uses its own identification scheme for products and services. To

make it even more complex, OEMs often use two different identification schemes, one internally and

one externally for customer relations. Accordingly, the specific challenge for remanufacturing is that

although every product ID is unique and relevant to the OEM who has produced it, the ID may not

currently be resolvable by other stakeholders in the manufacturing ecosystem. Hence, PREMANUS

needs to provide some way of resolving IDs across the entire ecosystem, allowing stakeholders to

exchange information about a unique product without changing their internal ID systems. The high-

level requirements for an ID scheme are:

3.2.1 ID Mapping

There are two basic concepts that can resolve the different internal IDs and communication with other

systems in the PREMANUS network. The first is a direct mapping between the unique IDs of each

partner to each other partner‟s IDs. This way each partner always knows by what ID the product is

referred to in each system within PREMANUS. The second alternative is to map each partner‟s ID for

a particular product instance to one common PREMANUS ID which can then be used to request data

from any system connected to PREMANUS.

The mapping strategies are evaluated based on the same criteria used for the evaluation of the network

structure: Commercial soundness of concept, Technical soundness of concept and Business Model

support.

3.2.1.1 Direct ID Mappings

The first of the two alternatives maps each product ID of a partner directly to the product ID in

another partner‟s system, enabling communication between those two partners. This mapping would

have to be repeated for each pair of partners that communicate with each other. Whenever a new

partner joins the network, each participating partner would then need to map their IDs to the new

partner if they wish to use each other‟s information. During communication between two partners, the

internal ID of the first partner can be directly translated into the internal ID of the receiving partner

via the mapping for these two partners.

3.2.1.2 Evaluation

Direct mapping requires a one-to-one mapping from each internal ID of one stakeholder to the

internal ID of another stakeholder for the same product instance. Since the mapping stakeholder has

no idea how the ID of the creating stakeholder is constructed, mapping could be difficult.

Additionally, when using multiple ID schemes created by different stakeholders, there is no guarantee

that an ID is unique. Hence two identical IDs could exist that refer to completely different items,

which is unacceptable and could lead to incorrect recommendations being made by the BDSS.

Project –No

Date

Classification

285541

16-July-12


18

Additionally direct mapping requires an increasingly large number of mappings, as more stakeholders

join the system. This means that resource usage (both hardware and personnel) increases every time

the system grows. PREMANUS is in essence a system for information sharing, and its usefulness

increases with each information-providing stakeholder. An ID mapping method that grows more

complex with overall system size is in direct conflict with this core concept of PREMANUS. This

leads to the conclusion that direct mapping is not a technically viable approach for ID mapping in

PREMANUS.

3.2.1.3 Central ID Mapping

In a central mapping method, one central ID scheme would exist to which all partners map their

internal IDs. However this internal ID scheme would not intrude on the already existing one and only

exist within the PREMANUS software. Rather PREMANUS would receive the internal ID together

with some key pieces of information required for the mapping and then resolve the ID internal to a

PREMANUS ID. If desired, the PREMANUS ID could be hidden from the client entirely and only

exist within the PREMANUS client and server. All communication within the PREMANUS system

would utilize the central ID and each stakeholder‟s PREMANUS client would resolve the central ID

to their internal ID locally when required. When a new partner joins, only the mapping from their

internal ID to the central ID scheme has to be created.

During communication between two partners, the sending partner will translate their internal ID to the

common PREMANUS ID locally, or if he has no mapping yet, send information to the central ID

resolution service and receive the appropriate PREMANUS ID and then store the internal ID to

PREMANUS ID mapping in his local system. The receiving partner proceeds similarly: either they

already have a mapping for the PREMANUS ID locally, or they request the basic information about

the ID from the PREMANUS ID resolution service and receives the all information necessary to map

the ID to his internal ID if such a product exists in their system.

3.2.1.4 Evaluation

Central mapping involves a comparatively small effort when it comes to mapping a stakeholder‟s

internal ID to the rest of the system, especially compared to direct mapping. Only the new stakeholder

has to create a translation of their internal IDs to the shared ID, with no effort involved for existing

stakeholders. This also means that no knowledge of other stakeholders‟ ID schemes is required.

However, a central system that manages ID resolution requests is required. Since each additional

stakeholder in the system will also increase the number of requests of ID resolution, this central

service will have to grow with the ecosystem, causing increased costs. However, such a central

system is technologically and commercially viable and since no sensitive or stakeholder internal

information is managed by the central system, it is also sound from a business model standpoint.

The reduced effort of joining such an ecosystem in comparison to the direct mapping also means that

new partners will be able to join the ecosystem much more easily, making this approach more

attractive.

3.2.1.5 Conclusions

When considering the three set criteria, Commercial soundness of concept, Technical soundness of

concept and Business Model support, it becomes apparent that central mapping is superior to direct

mapping for PREMANUS. Especially the reduced effort for integrating new stakeholders and the

local encapsulation of internal ID schemes is a key advantage.

Project –No

Date

Classification

285541

16-July-12


19

3.2.2 ID Resolution

One central question is how a stakeholder can resolve the information that exists for a product

instance within his system into a common ID. This section will look at what information should

typically be available and useable for ID resolution at a stakeholder within the PREMANUS system.

One case is of course, that no information is available at all. However if a stakeholder has absolutely

no information about a product (not even who made it and what it is), there is no possibility of

matching this product instance to a common ID since there are no features that indicate that it is the

same instance that is associated with the common ID.

The most basic information about a product would be who made it and what it is (for example a 1.2

litre V4 diesel engine from manufacturer X). This information is most likely available to all

stakeholders that interact with the product; or at least can be determined by them. This information is

constant which means it is viable to use it to identify the product type as time progresses. However it

is also common to all other product instances of that make and therefore is by itself not enough to

identify a unique instance. It could however be used to map the product instance to a common ID for

the type of product and help in the retrieval of information relevant to all instances of that type

(properties, part lists, construction plans and similar types of data). This does however not include any

information pertaining to the lifecycle of a particular instance, which is one of the key features

required in PREMANUS.

In some cases the product instance will have a unique ID (e.g. an engine number) assigned by the

OEM. If this is the case, this ID could be used to uniquely identify the product instance across time,

provided the ID is not removed from the product and understanding that ID is only (probably) unique

in the OEM/OEM Product. The unique product ID along with information discussed in the previous

paragraph (OEM and product type) could be used to determine a common ID that can be resolved by

all partners that have these key pieces of information (OEM, product type and product ID assigned by

OEM).

Any information about a product instance that is not assigned by the OEM, such as third party IDs or

information about the current state of the instance (such as wear or defects) are subject to change and

could be different as new stakeholders interact with the product instance. If such information was to

be used to establish a resolution to a common ID, it would yield different IDs at different points in

time, which defeats the purpose of the common ID scheme, which is to uniquely identify a product

instance across time and interactions with multiple stakeholders.

3.2.3 Conclusions

In conclusion, PREMANUS will require a common ID that clearly identifies and as such consists of

the three components:

OEM

Product type

Unique product ID.

This conforms to the Uniform Resource Identifier (URI) standard, described in IETF‟s RFC 3986.

Using a specific ID scheme that satisfies these requirements will enable the PREMANUS middleware

to resolve product IDs across the ecosystem along the lifecycle of a product.

This common ID will be managed at a central node where the ID mapping of the ID schemes of

individual parties to the common ID scheme is assigned and administrated. All parties can implement

Project –No

Date

Classification

285541

16-July-12


20

and add to their local IT systems a functionality that will execute the ID mapping “Individual party ID

to PREMANUS ID” locally.

Product & Component Identification & Mapping

RIS.PCIM.1 Unique IDs Functional

Each product instance represented in the PREMANUS system should be

uniquely identifiable across all stakeholders

Unique IDs should be used to share information between stakeholders

The unique IDs should be compliant with the URI standard.

RIS.PCIM.2 ID Resolution & Mapping Functional

Each stakeholder should be able to retrieve a PREMANUS ID for a physical

product instance

ID retrieval should be possible with minimal information about the product

ID mappings shall be managed for all stakeholders in the remanufacturing

ecosystem at a central node

Product IDs shall consists of three components

o OEM

o Product type

o Unique product ID

Table 2: Requirements for Product & Component Identification & Mapping

3.3 Search and Lookup Mechanism

The following section distinguishes between lookup and search. A distinction that is frequently made

for distributed systems:

Search is a keyword based search that returns the IDs of content that matches the keywords.

Lookup is the process of determining the location of a piece of content based on its ID.

Thus, in PREMANUS finding a specific document is split into these two steps. First, the document

needs to be described and a “search” in a directory will be performed returning the matching

document IDs. Then the IDs are used to “lookup” the location of the information, i.e. in which

database it is stored.

Based on the previous findings of this section the Search and Lookup mechanisms will work in a

hybrid approach. That is, there is a central node in the ecosystem operated by a third party that

manages ID Mapping and Resolution. Using this functionality, lookups can be performed.

Based on the conclusions for the Product Identification and Information Network (Section 0) it can be

argued that a fully decentralized search is not a viable option for PREMANUS. The search

Project –No

Date

Classification

285541

16-July-12


21

functionality should be also implemented on the central node that implements the ID Mapping and

Resolution service. Accordingly this service needs to be extended by information that describes

documents in order to enable search.

In conclusions, the search and lookup functionality will require the project to build the following

process, which is split into a “publish” and a “search” phase:

Figure 6 - Resulting Process for Search and Lookup

The owner of the information relevant to PREMANUS decides if the information shall be made

available to ecosystem partners and to which ones (access policy). The information is described, e.g.

to which individual it relates and what its content is, e.g. a maintenance report. This description is

published in form of an advertisement at the central node that operates the search and lookup

functionality and the ID resolution and ID Mapping service. The ID Mapping service assigns the

PREMANUS ID to the information. A stakeholder searching for the information describes it and

sends the query to the centralized search and lookup service. The search service composes a list of

documents that match the description and access policy. The stakeholder receives a list of potential

results. They select the ones they would like to retrieve. They send a lookup query to the search and

lookup service and receive the access information for the requested documents. The stakeholder now

uses a retrieval service to retrieve the documents.

This overall structure of search and lookup is similar to the functionality which the EPC global

standard “Object Name Service” (ONS) provide together with the discovery service [14] . It also

complies with the requirements deducted for ID Resolution, applying the URI standard.

Table 3 summarizes the requirements for search and lookup of product information.

Project –No

Date

Classification

285541

16-July-12


22

Search and Lookup Requirements

RIS.PCIM.3 ID Information Discovery Functional





The overall structure of search and lookup shall comply with the EPC

Global standard “Object Name Service” (ONS).

The information discovery is split into two phases

o The owner of product data what information about a product is

available to the remanufacturing ecosystem.

Advertisements/annotations are used to publish this information.

o Search within the advertisements for product information. The search

result details, which product data can be where and how retrieved.

Table 3: Search and Lookup Requirements

3.4 Distributed Product Information Store (DPIS)

Storing data is needed for the PREMANUS solution, and for many other software applications.

Before specifying the requirements that PREMANUS will have related to the DPIS component, it is

necessary to locate the different points that the development team should focus on. These are the

following:

Types of data

Distributed storage

Amount of data

Semantically enriched content.

All these points are detailed in the following sub-sections. At the end of the section, a table with the

requirements derived from these is published.

3.4.1 Types of data

PREMANUS needs to store data, however it is not the same as storing simple pairs of property-value

than storing documents and linking them to a given content. Thus, it is necessary to store the three

kinds of data presented in the D2.1 document in the section Distributed Product Information Store:

Structured data, like KPIs calculations

Semi-structured data, like the XML files containing the indexes to the stored information

Unstructured data, like PDF, pictures or CAD files.

3.4.2 Distributed storage

In addition to the kind of data, there is a need to store the information that PREMANUS will deal with

in a distributed environment. This is because both the wind turbine farms and car plants are dispersed,

not only in different locations but also in different countries. The DPIS should be effectively

Project –No

Date

Classification

285541

16-July-12


23

distributed so the different locations would have their own storage controlling the access to the

information stored locally.

However, this causes another problem: how to access the data which is not controlled by the local

PREMANUS node. This situation may be resolved by developing adapter services to access first the

metadata of the information from remote stores and then retrieve the desired content. Metadata is

accessed first to avoid downloading large volumes of information and later realizing it is not the

information that was required.

3.4.3 Amount of data

Big Data is another point to be considered since there will be large amounts of information coming

from the wind turbine sensors or the different car plants and workshops. Big Data refers to the

massive amounts of data collected over time difficult to be analyzed and handled using common

database management tools. Then, the DPIS component should be able to deal with big amounts of

data coming from those collecting points. As stated in the deliverable D2.1, there are several tools in

the market which might help the PREMANUS project in solving this problem.

3.4.4 Semantic enriched content

The usage of unstructured information implies that the search mechanisms should consider the fact

this information cannot be indexed as easily as the structured information. Within PREMANUS it is

necessary to perform indexing of the unstructured data “manually” using the tools proposed in the

D2.1 document. With this action, it would be possible to retrieve the correct information by using

natural language.

This can be performed by using semantics. Semantics are the bridge between the natural language

used by the potential users and the machine language used by the system to be used, mainly, in the

communications among systems. This bridge is built upon the semantic annotation of the data to be

stored (especially the unstructured data, but also structured data and semi-structured) by attaching

metadata (or simple tags) which would be used by the search engine to enhance search capabilities.

In any case this semantic metadata has to be stored in a semantic storage, as it would be fully

compliant with the project‟s semantic needs, and include, if possible, a searching mechanism of its

own. Furthermore, it would be also necessary to include an indexing service, such as yellow pages, to

grant direct access to the information stored in the different repositories. This is described in Section

3.3.

3.4.5 DPIS Requirements

The following table summarizes the requirements exposed in the previous sections:

Distributed Product Information Store Requirements

RIS.DPIS.1 Distributed Product Information Store Functional

The Distributed Product Information Store (DPIS) stores the information

that is published in first phase of the ID Information Discovery process,

according to the requirements RIS.PIIN.1.

The DPIS is operated on a central node where the distributed IT systems of

Project –No

Date

Classification

285541

16-July-12


24

the stakeholder within the remanufacturing ecosystem publish the product

information to, according to the requirements of RIS.

RIS.DPIS.2 Support to structured data Functional

It is necessary to utilize (or develop) a storage capable of providing support to

structured data, like KPI data (properties and values).

RIS.DPIS.3 Support to semi-structured data Functional

It is necessary to utilize (or develop) a storage capable of providing support to semi-

structured data, like the XML files data containing the indexes of the stored

information.

RIS.DPIS.4 Support to unstructured data Functional

It is necessary to utilize (or develop) a storage capable of providing support to

unstructured data, like PDF, pictures or CAD files.

RIS.DPIS.5 Data stored should be easily accessible Functional

The data stored, independently of the storage used and its physical location, should

be easily accessible for local and remote nodes of PREMANUS through the usage of

Web Services.

RIS.DPIS.6 Big amount of data Functional

It is necessary to provide support to the big amount of data coming from the two

user industries. This requires a proper storage capable of both managing the quantity

of data, maintaining the capability of indexing and fast finding and processing.

RIS.DPIS.7 Semantic storage Functional

It is necessary to semantically annotate the data stored to enable natural search

languages and to facilitate the indexing of the mainly unstructured data.

Table 4 - DPIS requirements

3.5 Information Retrieval Mechanism

Once it has been determined that a certain stakeholder has information related to an ID (through the

search and lookup mechanisms discussed above), the querying stakeholder needs the ability to

discover what kinds of information and services they can get from the providing stakeholder. Which

information can be provided and is available might also depend on the querying stakeholder‟s access

rights.

In addition to discovering the information, there also needs to be some system of annotation that

allows the querying stakeholder to make sense of the information and services made available to

them. Ideally this annotation should also support some level of automation (for example automated UI

generation as performed in the project Omelette [15] ). This is especially important for structured data

that is going to be used in the BDSS component. To summarize, the requirements for the information

retrieval are:

To provide a discovery mechanism for available information and services

To annotate information and services with retrieval information so they can be understood by

other stakeholders and possibly used automatically.

Project –No

Date

Classification

285541

16-July-12


25

Table 5 summarizes the extended requirements for information retrieval.

Information Retrieval Mechanism Requirements


Once relevant information have been identified, annotations to this

information will provide the

o Location, where the product information can be accesses

o How the product information can be retrieved

o Which further services are available to other PREMANUS stakeholders

An interface is required to retrieve/use the information/services.

Table 5: Information Retrieval Requirements

3.6 Role-based Access Control

Although the primary purpose of the PREMANUS System is to share information, there will always

be some restrictions about who may access specific information within the system. This leads to the

requirement for an access control component to prevent unauthorized access to sensitive information.

This component needs to fulfill the following requirements:

Prevent unauthorized access by authenticating users before allowing access

Enable different levels of access rights for different users

Enable different access requirements for different pieces of information and services

Ensure that user authentication and all other aspects of the access control system are secure

Enable the validation of authentication and integrity of documents

The ideal solution for access control in PREMANUS is a role-based access control system. For a role-

based access system, some more specific requirements can be created: A central service that is

independent of any specific stakeholder should be used for authentication of users and determining

what roles are assigned to the user.

Each stakeholder when receiving a request from a PREMANUS user can query the central

server to retrieve the user‟s roles

Each stakeholder can decide locally what information to make available to whom based on a

user‟s assigned roles. This is called the access policy for a piece of information

Each stakeholder can define new roles and maintain a list of users that are granted each role in

the central service.

Project –No

Date

Classification

285541

16-July-12


26

4 Requirements for Remanufacturing Services Gateway

According to the previous chapter the PREMANUS Remanufacturing Information Service will

consist of several functional elements that need to communicate with each other and also

communicate with the intelligent component of PREMANUS, the Business Decision Support System.

The Remanufacturing Services Gateway (RSG) is responsible for managing this communication. This

section describes the requirements for building the RSG.

The RSG allows for efficient use of the information managed by the RIS by allowing product centric

collaboration and exposing product data oriented services for EoL product recovery. In addition, the

BDSS will also be connected to the Semantic Service Bus (SSB) and, as such, it will have some

impact on the functionality and the services in the SSB. The RSG will be implemented following

Service Oriented Architectures (SOA) principles, using advances in that area. Support for Web

services and REST (Representational State Transfer) interfaces will allow PREMANUS to create

service compositions, or so-called “mashups”. The RSG will be realized as an extension of the

Enterprise Service Bus (ESB) concept which facilitates seamless distributed connectivity through

binding components and service composition through service components, which may implement a

specific service or logically compose services. To facilitate loose coupling and great concurrency

between different threads, the RSG will communicate via asynchronous message passing, which

means senders can send messages even in the absence of receivers. The RSG will buffer messages and

perform topic-based filtering specified by service consumers.

To help in the search and retrieval of the necessary information as proposed in the RIS component,

there are several core requirements to be fulfilled by the RSG:

Connect: A means to connect the different components so information flows are aligned to

user expectations

Transform: A way to transform the format in which the information is expressed to allow the

different business partners to understand it

Deliver: A mechanism to deliver the information requested in a transparent and timely way

Annotation: The provision of annotation mechanisms and routines so the information can be

searched (and retrieved) according to semantic querying tasks

3rd

party applications: The means to connect with 3rd

party applications and systems through

gateways to get the information and the remanufacturing processes already developed.

This chapter defines the requirements to build and develop the RSG components:

Semantic Service Bus

Infrastructural services:

o Generic services, like Transformation, Mediation, Remanufacturing Specialized

services or Service Composition

o Semantic services, like Annotation and Publishing or connection to Semantic storages

o Gateway services, like the services to connect PREMANUS components, with

Databases, 3rd

party systems and applications, etc.

Other services, like services to access devices and maintenance applications.

Project –No

Date

Classification

285541

16-July-12


27

4.1 Semantic Service Bus

4.1.1 Introduction

The PREMANUS RSG will be based upon a Semantic Service Bus (SSB) which will be built upon an

Enterprise Service Bus (ESB), annexing semantically enhanced services to allow the content and the

messages to reach their destination. Then, it is a software architecture model used for designing and

implementing the interaction and communication between mutually interacting software applications

in a SOA. This section deals with the requirements to build both the SSB and the semantic services.

The services to be developed need to be semantically orientated as it is necessary to provide

connectivity among different semantic components or semantically enhanced components. As such,

the data storage holds semantically enriched content, the search engine provides the user with a

semantic layer for a better fine tuning of the search results, and so on. The following sections (see 4.2

and 4.3) define the different services to be attached to the ESB in order to transform it into an SSB.

The semantic services are described in section 4.2.2.

The SSB has to support communication between different kinds of components which might be

running on different platforms. Furthermore, the SSB has also to be pluggable into different

topologies, to allow communication between the different companies.

4.1.2 SSB Requirements

The following table shows the main PREMANUS needs on data exchange, message routing and

service technologies regarding the SSB and which should be added.

Semantic Service Bus Requirements

RSG.SSB.1 Orchestration Functional

The usage of Business Workflow Models (BPML) is demanded by PREMANUS final

users, as they already use BPML based engines in their current configurations. This

feature will allow advanced service composition that can be configured at each of the

end users.

RSG.SSB.2 Integration of software components & data

sources

Functional

The integration of software components and other data sources is necessary for the

following reasons:

Allowing component deployment (desirable hot deployment) with component

versioning

Polyglot applications ( .net, java, php, ...)

Minimizing efforts for integration of 3rd

party components (with predefined

adaptors, e.g. XMPP)

In PREMANUS the following kinds of components are envisaged: Distributed

security & access control.

Project –No

Date

Classification

285541

16-July-12


28

RSG.SSB.3 Message channels and routing Functional

It is necessary to add functionality regarding the processing of composed messages.

With respect to the messaging and routing it is necessary to take into account the

following points:

Point-to-point messaging

Publish-subscribe messaging

Splitter

Aggregator

Content Based Router

Message Filter

Dynamic Router

Recipient List.

RSG.SSB.4 Transport protocol Functional

The ESB must allow different transport protocols in the anchor points for the

applications, as well as transport protocol conversion.

RSG.SSB.5 Connectivity Functional

The ESB must allow different components to be connected e.g.:

Different types of data stores (triple stores, relational, noSQL, XML, etc.)

3rd

party applications (ERP, PLM,...)

User interfaces

Internal functional elements:

o Business Decision Support System

o Unique ID routing mechanism

o Semantic gateway & query mechanism (query decomposition and

routing to specific data stores).

RSG.SSB.6 Execution Functional

A common component execution environment is necessary, that will conform the

PREMANUS node, containing the specific functional components, and the way of

communicating with the rest of components along the PREMANUS environment.

RSG.SSB.7 Support of different topologies Functional

Due to the current status of the project, some generic and open support for different

topologies is needed. Some of the partners see the architecture as a centralize (unique

distributed over the cloud) infrastructure, while some others see it as instances installed

at the final user, and communicated with the rest of instances using a central

coordination point. Flexibility is needed in order to afford both configurations, and to

change from one to another with no or minimal penalty.

RSG.SSB.8 Security Functional

Although the project is not focused on security, some basic authentication and role

based access control is requested. The distributed nature of the architecture makes this

feature implementation challenging and risky from a technology point of view.

Table 6 - SSB requirements

http://camel.apache.org/content-based-router.html

http://camel.apache.org/message-filter.html

http://camel.apache.org/dynamic-router.html

http://camel.apache.org/recipient-list.html

Project –No

Date

Classification

285541

16-July-12


29

4.2 Infrastructural Services

The Infrastructural Services are a bunch of cross-cutting services to allow the SSB to get the

necessary information and execute the different processes triggered by the user. These services are

covered in the following sections.

4.2.1 Generic Services

Those services which support other components, and which cannot be classified under other slots, can

be classified as generic services. The functionality provided by the services grouped in this set are

covered in the following sections.

4.2.1.1 Transformation services

Every single organization uses different data types and documents. One solution is that the

organizations involved in a business transaction agree to use a common format. This solution implies

that these organizations should develop transformation engines to allow the translation between the

common format and their internal ones.

Within PREMANUS, when the different information sources are connected to the BDSS, the

information stored in them can be searched and retrieved to satisfy BDSS requests. Once the

information is retrieved, the last step is to store such information in a local storage so the data can be

analyzed for the remanufacturing decision. This requires the transformation [16] of the information

into the structure and format the BDSS will use.

The challenge for the PREMANUS system is to support transformation services also for unstructured

information based on semantic annotation.

4.2.1.2 Mediation services

Since the PREMANUS RSG will be managing the different processes being executed, it is necessary

to develop a set of mediation services to help the SSB when it needs to launch several processes.

4.2.1.3 Remanufacturing Specialized services

These services are ad-hoc services for the remanufacturing industries and their definition will directly

come from the BDSS and from specific existing stakeholder systems; these include existing systems

at CRF and SKF relevant to PREMANUS. Although an overview of these services can be found in

section 2.1.1 for the CRF case and section 2.1.2 for the SKF case, the following list could be

considered as the main services to be developed:

Access and retrieval of data from relevant IT systems with the following aims

Export data for business analysis (e.g. CSV, XML).

Project –No

Date

Classification

285541

16-July-12


30

4.2.1.4 Service Composition

Service Composition allows the linking of simpler, more basic services to create larger ones of greater

functionality and complexity. There are two ways to combine services: orchestration and

choreography.

Services orchestration describes an executable process that can interact with itself or other

services. The process flow is controlled by a central coordinator whilst each service itself only

has a local scope and can make decisions only for processes within its scope

Services choreography means that each service has its own task in the total composition.

There is no central program to verify that the task is being implemented correctly.

If the description of the services has its semantics in machine process able form, a process can decide

which service is invoked after it has begun or it can be easier to (manually) design and compose

services. Another advantage of composing services relies on the fact the performance of the system

itself is better given that the output parameters from a particular service are already inserted as input

parameters of a second service and the execution of the action does not wait for human intervention.

Therefore, composition of services improves the performance of the system.

4.2.1.5 Generic services Requirements

The following table summarizes the requirements related to the generic services:

Generic Services Requirements

RSG.GS.1 Transformation services Functional

There must be a mechanism to allow the transformation of different data formats e.g.

XML files or Excel files, are used. This mechanism must be implemented in the SSB.

RSG.GS.2 Mediation services Functional

There must be a mechanism to allow the RSG to select the appropriate process or service

to be executed. This mechanism must be implemented in the SSB.

RSG.GS.3 Composition of services Functional

Composition of services is needed to improve the performance of the system and to

generate larger services by linking smaller services.

Table 7 - Generic Services requirements

4.2.2 Semantic services

Semantic services act as a bridge between the natural language used by the users while they are

interacting with the system. Also, they are used by different systems (or components) to communicate

easily. Within PREMANUS, the purpose of the semantic services is to enable the BDSS and other

components to locate information. This is mainly related to the execution of search and lookup tasks.

Project –No

Date

Classification

285541

16-July-12


31

4.2.2.1 Services to connect with the Semantic storages

The usage of the semantic storages allows semantically enriched information to be maintained, as

described in section 3.4. This information is used specifically to enable better searching and indexing

of the documents. Usually, these kinds of stores come with interfaces to allow the systems to interact

with each other. However, these APIs only provide basic functionality.

Therefore, it is necessary to extend the SSB with semantic functionality and services. These services

will provide access to the semantic storages in the form of Web Services so the content stored in them

will be accessible by the rest of the components of the PREMANUS architecture in a transparent and

straightforward way.

4.2.2.2 Annotation

Finding data and documentation easily is one of the priorities of the PREMANUS middleware. The

best way to fulfill this need is by annotating the stored data.

This can be done by relating names, attributes, comments, descriptions, etc. within a document or

plain data. These attachments provide additional information about an existing piece of data and are

the metadata to be used by the publishing services.

Therefore, it is necessary for PREMANUS to develop annotation services or makes use of tools which

help the user to prepare the information for the next step in the semantic chain: the publication of the

information.

4.2.2.3 Publishing

These services provide a way for the PREMANUS middleware to understand the structure and, also,

the meaning of the published information. With this action it will be easy to conduct searches for

information (independently from its format) as all the information is correctly published and also will

integrate the different data in a more efficient way. This would be achieved by using metadata (after

the annotation process) to describe the information.

Thus, it is necessary that PREMANUS should develop publishing services to make the information

and the services more accessible to the user and to PREMANUS components.

4.2.2.4 Semantic services requirements

The following table summarizes the requirements related to the semantic services:

Semantic Services Requirements

RSG.SS.1 Access to Semantic storages Functional

It is necessary to access the semantic storages which would have the annotation of the

information stored in other storages.

RSG.SS.2 Annotation Functional

In the case of unstructured content, it is necessary to semantically annotate the data to be

stored so it can be easily found and retrieved.

Project –No

Date

Classification

285541

16-July-12


32

RSG.SS.3 Publishing Functional

As the PREMANUS middleware is dealing with content and also services offered by the

components, it is necessary to publish them so they can be easily found and retrieved

(content) or executed (services).

RSG.SS.4 Reaching information Functional

The information and the services belonging to different components must be reachable

by every component through the SSB.

Table 8 – Semantic Services requirements

4.2.3 Gateway services

These services act as bridge between the PREMANUS middleware and the external world in the form

of 3rd

party systems. The PREMANUS middleware must be able to interact with many other systems

with different purposes.

4.2.3.1 Services to connect the different PREMANUS components

There are several components within the PREMANUS architecture that need access to data stored in

different repositories (for documents) and databases (for plain data). The BDSS, the ID resolution

module and the Search engine are some of them.

To retrieve information the BDSS would trigger a getDocument(id) function through the SSB. The

SSB will be in charge of connecting the request from the BDSS and the component in charge of

returning back the information.

Like the BDSS, the ID resolution module must have access to the services related to information

recovery and routing.

Finally, the PREMANUS search engine must also have access to services to retrieve information and

to route data from storage to the proper component. In addition to these services, the search engine

also needs indexing services, like yellow pages, where the content is indexed. These indexes allow the

SSB to easily find both component and information.

4.2.3.2 Database as a Service - DaaS (Databases)

The earlier section (Distributed Product Information Store (DPIS)) stated that there is a need to

develop some persistency components able to store all the necessary information produced for and by

PREMANUS. However, there exists much complementary information, like e.g. #oil_changes,

already stored in different in-house databases. PREMANUS also needs to connect to existing

databases, e.g. ERP systems, to retrieve any kind of information required by the BDSS to perform its

calculations. Therefore interfaces are needed to connect with those DBs: in short, Database as a

Service (DaaS).

Project –No

Date

Classification

285541

16-July-12


33

4.2.3.3 Application as a Service - AaaS (ERP/PLM connectors)

As specified in the summary of the use cases (see sections 2.1.1 and 2.1.2), the user has 3rd

party

applications such as ERPs or PLMs they would like to connect to PREMANUS. Then, similarly to the

DbaaS components, Application as a Service (AaaS) connectors should be developed to enable these

3rd

party applications to connect and provide new data to the PREMANUS middleware.

4.2.3.4 Connection to external unstructured storages

While in section 4.2.3.2, the connectivity to external databases (outside the PREMANUS architecture)

has been described, this section deals with external unstructured storages. Among these external

storages, PREMANUS should take into account legacy systems which store valuable and sometimes

confidential information in an unstructured format. Consequently, there is a need to access not only

the document but also pieces of it in an efficient and direct way.

Therefore a process is required to semantically annotate the content while importing documents. This

process would increase the chances to find the proper information even when using natural language

searches.

4.2.3.5 Gateway services requirements

The following table summarizes the requirements related to the gateway services:

Gateway Services Requirements

RSG.GWS.1 DBaaS services Functional

The PREMANUS middleware needs to access to external DBs to retrieve the data

required by the BDSS to perform its calculations.

RSG.GWS.2 AaaS services Functional

The PREMANUS middleware needs to communicate and exchange information with

3rd

party applications such as ERPs, PLMs, PCos (Plant Connectivity) like e.g. the

ones utilized by the users… and their associated storages to get the requested

information needed by the BDSS to perform its calculations.

RSG.GWS.3 Connection to external unstructured storages Functional

As in RSG.GWS.1, the PREMANUS middleware needs to access external

unstructured storages to retrieve the data required by the BDSS.

Table 9 - Gateway Services requirements

4.3 Device as a Service, Maintenance as a Service

In order to properly influence remanufacturing decisions, PREMANUS will need comprehensive and

good quality product lifecycle information that must be collected from a product‟s Beginning-of-Life

and Middle-of-Life phases.

Project –No

Date

Classification

285541

16-July-12


34

Much valuable information about how a product has been used during its life may be dispersed in a

number of different places, especially in maintenance systems that might belong either to the original

manufacturer and authorized or independent service agents. Many of these systems are proprietary in

nature and even in the case where they might implement some kind of industry-specific maintenance

management information standard, the necessary application-specific information still needs to be

extracted and adapted for the kinds of decision processes needed for PREMANUS.

Another vital source of Middle-of-Life information is found in on-board devices that are attached to

or are an inherent part of a product. The ten industrial demonstrator cases of the EU PROMISE

Project [13] highlighted the diversity of such devices and the lack of a consistent information standard

or common interface. The PROMISE Project concluded that it would be virtually impossible to

impose a common cross-industry, cross-platform standard that should be integrated into all such on-

board devices and additional sensor inputs. Therefore it was decided to apply adaptation to existing

information devices and to propose a common means of exchanging the lifecycle information. This

has been continued into the emerging QLM standards proposed to be used by PREMANUS.

Adapter services have been proposed to allow the PREMANUS middleware to retrieve data from pre-

existing information stores, and, in the case of already pre-existing systems, a similar approach for

maintenance systems and on-board devices seems also to be the most pragmatic approach. For new

systems, it would be desirable to encourage the use of QLM standards to generate information output

from these sources.

4.4 Resulting High Level Functional Concept

Based on the requirements of Chapter 3 and this chapter, a high level functional concept for the

PREMANUS architecture can be defined as shown in Figure 7.

Figure 7: Functional Concept of PREMANUS System by Roles

In Chapter 3 it was concluded that a hybrid architecture would be best suited to fulfill PREMANUS‟s

Project –No

Date

Classification

285541

16-July-12


35

requirements to search and retrieve information about products within a remanufacturing ecosystem.

Accordingly, there are 3 core functional roles required for PREMANUS:

The PREMANUS node where the Business Decision Support System (BDSS) is operated,

which requires

A local data store (PData Store for PREMANUS Data Store) that holds the

information on which the BDSS calculates its analyses. The data store will use a

specific data structure suitable for PREMANUS (see next chapter for more details).

For successful data import from different information sources a data extract,

transformation and load service (ETL) is required also for the PREMANUS node.

A search engine that enables the BDSS to search and retrieve missing product

information in the remanufacturing ecosystem.

At the ecosystem partners, services are required that allow locating and extracting information

from local information stores. These services are located in the so-called PREMANUS

Gateway. It shall be a non-intrusive component located at a partners‟ data center. The

Gateway will provide

Adapter services that enable PREMANUS to access heterogeneous information

stores. These also implement required security policies via access control

mechanisms.

Annotation services that describe available information and publish that information

at the central RIS node.

Publish-subscribe functionality in order to monitor information stores for relevant

added or changed product information in order to trigger annotation services when

required.

A directory service and an on-demand data import service will be located at a central node.

The directory service requires

An ID Mapping and Resolution Services which enables tracking all information about

a product across its lifecycle and across the ecosystem. For this purpose here a central

PREMANUS ID will be managed for products.

A publish-subscribe service that works together with the PREMANUS Gateway. It

publishes descriptions about product information in the central directory in order to

enable tracking all information about a product across its lifecycle.

A search engine that works together with the search engine at the PREMANUS

BDSS that enables searching the central directory for relevant product information

based on the available descriptions. The search engine will provide to the BDSS these

descriptions together with information on location and access methodology.

As PREMANUS strives to provide a general framework for many different

remanufacturing scenarios, it is meaningful to manage a canonical data structure at

the central node. Then different remanufactures can use an adapted data structure for

customized BDSS algorithms. For this purpose, an ETL service is also meaningful at

the central node. It would transform the information from different partners into a

canonical data structure before it is transmitted to the PREMANUS remanufacturing

node, where the other ETL service transforms and loads the information into the

PREMANUS Data Store.

The Requirements for the Business Decision Support System will be defined in the following chapter.

Project –No

Date

Classification

285541

16-July-12


36

5 Requirements for Business Decision Support System

PREMANUS BDSS will support remanufacturing plants in the optimization of eco-efficiency of the

entire process. Different remanufacturing options exist for each product entering the remanufacturing

plant as already highlighted in D1.2 and D1.3. The goal of the BDSS is to enable decisions from

different users and actors in the remanufacturing process based on sustainability, viability and

economic worth for each specific product based on product lifecycle information available to the

PREMANUS BDSS.

5.1 Business Decision Support System Foundation

The BDSS requires a technical foundation to build the analyses and algorithms on. This foundation is

a data store for relevant product information

a related data structure that support efficient extraction of structured information required by

the BDSS

A search engine supporting enabling to fill the data store with information distributed across

the remanufacturing ecosystem;

5.1.1 PREMANUS Data Store

As the information to be analysed is distributed across a whole ecosystem, the data first has to be

imported into a local data store, via RIS/RSG, to facilitate processing. In the following, the local data

store is referred to as the PREMANUS Data Store. The BDSS analytic algorithms will access the

PREMANUS Data Store in order to read required data and write generated data to be stored, e.g. data

required for training the BDSS using machine learning mechanisms. Data that is requested by the

BDSS but not available in the PREMANUS Data Store will be searched for via the PREMANUS

Search Engine (see below) and retrieved from the ecosystem using the RIS and RSG.

The data store needs to be secured against unauthorized access via appropriate security mechanisms,

like role based access control.

5.1.2 PREMANUS Data Store’s Data Structure

The PREMANUS Data Store requires implementation of a data structure that efficiently supports the

analyses to be performed. For PREMANUS that is a data structure that represents the relations

between the information pieces that relate to a product. That is the component structure of products

and the lifecycle data collected, such as usage data and service reports. The PROMISE [13] project

researched such a data structure and one outcome of this project is the Open Group‟s Quantum

Lifecycle Management (QLM) standard [19] . Such a data structure can be used as a canonical data

structure for PREMANUS.

The PREMANUS Data Store‟s data structure should comply fully with a standard like QLM while

being customised with the specific usage scenarios. For efficiency reasons QLM is a likely choice.

For customized PREMANUS Data Store‟s data structure also customized transformation services are

likely to be required.

Project –No

Date

Classification

285541

16-July-12


37

5.1.3 PREMANUS Search Engine

In order to fill the PREMANUS Data Store with information, queries need to be defined that will

retrieve the correct information. As composing the correct queries requires a deep knowledge of the

PREMANUS system, a business user will probably not be able to compose these. Accordingly, a

query composer at user level must be provided that composes the required queries from user input.

The search engine will then store the returned query results in the PREMANUS data store in the form

of the PREMANUS data structure.

Using this technical foundation of PREMANUS Data Store, PREMANUS Data Structure and

PREMANUS Search Engine the different BDSS functionalities can be implemented. These are

described in the following section.

5.1.4 Access to further IT Systems of the Remanufacturer

In order to embed the BDSS into the operational landscape of the remanufacturer the BDSS will need

access to different IT system.

Access to CAD drawings of products and components in order to provide information to the

employee operating the BDSS. This information is typically held in PLM systems.

For assessing the costs of remanufacturing, access to the history of the remanufacturing

operations. This information typically is administered in manufacturing execution systems.

Information on stock level of parts and components. This information is typically

administered in enterprise warehouse systems.

Feedback from the remanufacturing operations on actual remanufacturing costs and duration

in order to improve the BDSS‟ accuracy over time.

5.1.5 Conclusion PPREMANUS Business Decision Support System Foundation

The following table summarizes the requirements for the PREMANUS BDSS foundation.

BDSS Requirements

PREMANUS BDSS should support domain experts who have open-ended,

unstructured and complex problems.

The PREMANUS system should be designed to reduce complexity of

human tasks by structuring, filtering and presenting relevant information in

appropriate ways to support processing of large volumes of data involved in

extensive and recursive decision-making.

BDSS.1 BDSS Data Storage Functional

PREMANUS should provide a local data store at the PREMANUS

Remanufacturing node to run the required analyses.

The BDSS Data Store should store all information needed to prepare a

remanufacturing decision; this information is above all product master data

and product lifecycle information such as usage data, service reports, and

sensor data.

Project –No

Date

Classification

285541

16-July-12


38

The storage should use a sophisticated data structure, so the analyses

conducted by the BDSS can be performed efficiently and correctly. A

canonical PREMANUS data structure will be used as standard; adaptations

to it to specific use cases must be enabled.

BDSS.2 Data Structure Functional

The analysis of the PREMANUS system should run efficiently and correct

by using sophisticated data structures. A canonical PREMANUS data

structure should be used as standard; adaptations to it to specific use cases

must be enabled.

BDSS.3 Query Composition Functional

PREMANUS should provide a Query Composition user interface for

business users to specify which data is needed for the remanufacturing

decision to be taken.

A Query Composition should compose queries from the user input that the

PREMANUS system can correctly execute, search and retrieve the correct

data from the ecosystem.

BDSS.4 Access to Information and Tracking Activities Functional

PREMANUS system should track all activities at operational level during

the remanufacturing process. This includes input, output and specific

resources.

PLM data, warehouse component‟s stock, customers‟ demand and

expectations should be accessed by the BDSS.

Table 10: BDSS Foundation Requirements

5.2 End-of-Life Product Recovery Process Eco-Efficiency Evaluator

In remanufacturing plants different remanufacturing options typically exist and in particular:

Refurbishment of entire product or specific components

Material recovery, at least for components/materials not having value, or over-stock

Disposal, particularly for hazardous materials, or other kinds of material, which is normal for

certain fractions during remanufacturing process.

Different activities are carried out during the remanufacturing process, as described in D1.3. Such

activities encompass not only operations but also sales and commercial departments – for example, at

plant level they might include inspections, cleaning, disassembly, reassembly, re-painting and so on.

For each activity, specific input (e.g. product or components), expected output (e.g. product, sub-

assemblies, components, …), and resources used (e.g. specific tools, energy, working hours, …) are

all needed to assess the feasibility of the activity.

PLM data for each specific product, as well as boundary conditions such as stock level of components

/sub-assemblies, or customer‟s demand for specific refurbished products, influence the

remanufacturing strategy and operations (e.g. job-order or disassembly or re-assembly process) at

Project –No

Date

Classification

285541

16-July-12


39

plant level.

Within the plant different alternatives, options or sequences of activities might exist for the same type

of product (i.e. the engine in the case of CRF or the gearbox for SKF). The remanufacturing process is

influenced by many factors, and the sequence of activities to be carried out might change from

product to product depending on specific boundary conditions, like undiscovered damages, specific

wear status and so on.

Different aspects of the entire remanufacturing process, including evaluation of different strategies or

alternatives need to be taken into account from different perspectives:

Economic evaluations that consider inputs from sales, procurement, remanufacturing

operations

Environmental evaluations, taking into account Life Cycle Assessment (LCA) calculations for

different alternatives

Such elements provide the basis for the BDSS development in WP5.

The combination of economic and environmental dimensions can allow the decision maker and the

user of PREMANUS platform to rank alternatives of remanufacturing strategies and, in case different

options are technically feasible from an operations perspective, decide which is the most suitable one.

Accordingly, the End-of-Life Product Recovery Process Eco-Efficiency Evaluator should provide

information to the user on

The expected ecological eco-efficiency of a remanufacturing strategy, based on

o Generated hazardous/non-hazardous waste

o CO² footprint generated by remanufacturing operations, involved logistical processes,

etc. Different indicators could be used, according to different LCA Impact

Assessment methodologies chosen (e.g. Single score Eco-Indicator 99, CO2

emissions, Damages to Human Health,..) allowing decision makers to use different

perspectives in evaluation of remanufacturing performances.

Other criteria given either by existing regulations (e.g. recovery percentages

according to ELV Directive) or company specific policy (e.g. minimum

salvage benchmark), or specific KPIs (e.g. environmental benefits achieved

over economic resources used in the process, etc.)

The risk of deviation from the expected or benchmarked ecological efficiency, or the main

activities having impact of the remanufacturing performances.

Project –No

Date

Classification

285541

16-July-12


40

The following table summarizes the main PREMANUS requirements for the End-of-Life Product

Recovery Process Eco-Efficiency Evaluator.

End-of-Life Product Recovery Process Eco-Efficiency Evaluator Requirements

BDSS.5 End-of-Life Product Recovery Process Eco-

Efficiency Evaluator

Functional

PREMANUS should provide evaluation results for:

o Economical evaluations

o Environmental evaluations, taking into account Life Cycle Assessment

(LCA) calculations

o Ecological eco-efficiency evaluation, based on

Generated hazardous/non-hazardous waste

Generated CO2 footprint

o Risk of deviation from the expected or benchmarked ecological

efficiency

Table 11: End-of-Life Product Recovery Process Eco-Efficiency Evaluator Requirements

5.3 KPI Optimizer

The KPI Optimizer is the functional component in the PREMANUS system that provides decision

support to the user based on economic considerations.

From the initial identification in D1.2, KPIs from SKF and CRF can be roughly categorised as:

Financial: Sales, Margin, Variable Costs

Production/Manufacturing Management: Throughput/lead time, Product/component

salvage rate, equipment utilisation

Logistics/Inventory Management: Core grade/mix, WIP cost, Core/product rate

Manufacturing Process: Technical Errors

Quality: Machining and assembly Quality

Purchasing: Component costs

Work Analysis: Time consumed in each phase of operations

Human Resources: Personnel Saturation

Sales: Response time, Success Rate to Offers

This list of KPIs is not exhaustive and only reflects initial interactions with the two remanufacturing

businesses. However, it is sufficient to say that KPI as a business-centred measure will benefit from

the implementation of the PREMANUS information infrastructure, information storage, retrieval and

communication based solutions as well as computerised optimizers. Nevertheless, KPI as indicators

do not prescribe underlying mechanisms that uphold or improve them. To design proper mechanisms,

investigation into remanufacturing decision types is necessary.

The literature survey conducted in D1.1 showed that a remanufacturing decision can belong to a range

Project –No

Date

Classification

285541

16-July-12


41

of categories:

Market and Economic Decisions: The decisions related to market positioning and customer/

market interactions in certain remanufacturing industry

Strategic and Life cycle Decisions: The prediction of business financial outcome as well as

other KPIs by planning different product designs and reacting upon different life cycles and

return patterns

Operational Decisions: Inventory management, production planning and scheduling have

been widely adopted in most manufacturing enterprises. They do, however, require new

considerations in dealing with wide ranges of uncertain patterns in remanufacturing

production processes

EoL Decisions: Focus on how End-of-Life products are best processed (e.g. remanufacture,

recondition, repair, recycle, dispose) in terms of certain criteria (financial, environmental,

etc).

All decisions have been studied in certain literatures with particular industrial backgrounds. However,

SKF and CRF have relatively clear situations with regard to their market and strategic decisions. The

main challenges remaining are lifecycle and operational decisions, which are commonly addressed

through planning and control methods such as resource distribution, inventory and production process

planning and control. Since the detail of such optimisation techniques will not be addressed until

WP5, only a few examples will be presented here to demonstrate the types of planning and control

that might be adopted.

Product/Component Salvage Planning and Control: Special planning tools might need to be

developed to maximise product/component salvaging, taking into consideration of market

demand, core/component conditions, values and process cost, stock level, spare price,

personnel and equipment availability and other factors.

Personnel Saturation/Equipment Utilisation Planning and Control: There is also a need to

perform Personnel Saturation/Equipment Utilisation Planning.

Production Process Planning and Work Analysis: These should be performed to enhance

process efficiency and avoid operational errors.

Multi-criteria analysis support: Since most business resources can be measured financially, it

is relatively straightforward to jointly plan product salvaging and equipment utilisation,

although they are different goals. When other factors than financial (for instance, legal, social,

environmental) are taken into account, some multi-criteria optimisation will be necessary.

Although optimisation based planning and control will provide highly sophisticated decision support,

other types of information support will also be needed for decision making. These might include but

not limited to:

Purchasing/Sales support: These roles/departments should be able to gain support by quickly

gathering relevant information and perform numerical synthesis upon them for responsive

decision making.

Financial analysis support: There should be a general tool/interface for plant managers to get

informational and computational support to calculate general financial consequences of

certain major decisions, this might be based on combined solutions of simulation and other

knowledge based mechanisms.

Project –No

Date

Classification

285541

16-July-12


42

The following table shows the main PREMANUS requirements for the KPI Optimizer.

KPI Optimizer Requirements

BDSS.6 KPIs Calculator Functional

PREMANUS should provide different types of KPIs, that can be configured

in a flexible manner.

KPIs for the different internal stakeholder to the remanufacturing operations

shall be supported.

KPIs, as business centered measures should benefit from implementation of

computerized calculations, given the access of PREMANUS to relevant

information storage databases.

Table 12: KPI Optimizer Requirements

5.4 Human Computer Interaction

5.4.1 User Experience

Complex information systems, such as the Business Decision Support System (BDSS) to be

developed in the PREMANUS project, require a carefully planned and elaborated user interface (UI)

development. Complex systems are those which support domain experts with open-ended,

unstructured and complex problems which include large volumes of data and extensive and recursive

decision-making [6] .

Due to the complexity of the underlying task to be supported, it is very crucial to design the system in

a way that it actually reduces the complexity of the human task by structuring, filtering and presenting

relevant information in an appropriate way. Complex systems differ in some ways from simpler ones

and therefore have specific UI requirements which will be discussed later in this section. First, some

basic UI design guidelines are presented which are applicable to all kinds of interactive systems.

Ensuring a good UI design by drawing on general, well-established design guidelines can be seen as a

basis and a prerequisite for the further designing of a complex and information-intense system.

Designing for a good usability of a system can be supported by constantly keeping design principles

in mind and iteratively evaluating the system against these principles during the development of the

system. A well-established set of design principles, also called heuristics, was developed by Nielsen

[5] . The ten heuristics, which can be perceived as overarching requirements, are a guide to good

interaction design and help enhancing the usability of a system:

Visibility of system status. The system should always keep users informed about what is

going on, through appropriate feedback within reasonable time

Match between system and the real world. The system should speak the users' language,

with words, phrases and concepts familiar to the user, rather than system-oriented terms.

Follow real-world conventions, making information appear in a natural and logical order

User control and freedom. Users often choose system functions by mistake and will need a

clearly marked "emergency exit" to leave the unwanted state without having to go through an

extended dialogue. Support undo and redo

Project –No

Date

Classification

285541

16-July-12


43

Consistency and standards. Users should not have to wonder whether different words,

situations, or actions mean the same thing. Follow platform conventions

Error prevention. Even better than good error messages is a careful design which prevents a

problem from occurring in the first place. Either eliminate error-prone conditions or check for

them and present users with a confirmation option before they commit to the action

Recognition rather than recall. Minimize the user's memory load by making objects,

actions, and options visible. The user should not have to remember information from one part

of the dialogue to another. Instructions for use of the system should be visible or easily

retrievable whenever appropriate

Flexibility and efficiency of use. Accelerators -- unseen by the novice user -- may often

speed up the interaction for the expert user such that the system can cater to both

inexperienced and experienced users. Allow users to tailor frequent actions

Aesthetic and minimalist design. Dialogues should not contain information which is

irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the

relevant units of information and diminishes their relative visibility

Help users recognize, diagnose, and recover from errors. Error messages should be

expressed in plain language (no codes), precisely indicate the problem, and constructively

suggest a solution

Help and documentation. Even though it is better if the system can be used without

documentation, it may be necessary to provide help and documentation. Any such information

should be easy to search, focused on the user's task, list concrete steps to be carried out, and

not be too large.

Conducting heuristic evaluations on system prototypes is a quick, cheap, and easy evaluation of a user

interface design. It is a helpful method for rapid iterative prototyping, especially in development cases

with difficult access to the real end-users. Within the PREMANUS project, the end users are a very

specific user group difficult to access for personal evaluations. Heuristic evaluations are therefore

planned for the evaluation of the system interspersed with end-user tests.

5.4.2 Complex Systems – BDSS-specific

As already mentioned, complex interactive systems differ from the world of well-structured tasks in

many ways. Redish [7] collected a set of attributes specific to complex interactive systems, which

helps to understand the specific requirements for the design of these systems. Based on his work and

further literature research, a list of additional principles specifically useful for the design of complex

systems is presented in the following.

Avoid information overload. In complex interactive systems, such as the PREMANUS BDSS,

information overload is endemic. Such systems risk forcing the user to sift through more information

than he can deal with. The human is a “limited-capacity information processor” [20] and therefore, it

is very crucial to minimize the amount of data to be processed by the human without affecting the

quality of decision making. One basic way to handle the presentation of complex information is

Schneiderman‟s mantra of “overview first, zooms and filters, details on demand”. By applying this

heuristic during the interaction design, the amount of data to be processed in every single interaction

step is reduced. Information can be “chunked” and processed sequentially without overcharging the

user.

A concrete design guideline drawn from this principle is the provision of a visually discrete

multi-level menu structure (e.g. a primary, secondary and tertiary menu placed on different

screen locations). In the BDSS, such a bundling can be done on the level of KPI abstraction,

Project –No

Date

Classification

285541

16-July-12


44

e.g. grouping the KPIs in high-, medium- and low-level of detail families. By this, the levels

of hierarchies which need to be kept in mind during navigation through the system is reduced.

If the chunks of information (e.g. the bundling of KPIs) is done in a (for the user) meaningful

way, information can be found and processed easier.

Reduce cognitive overload by data visualization. Data analysis and recursive decision-making are

cognitively very burdensome; people have little cognitive workload available for dealing with huge

amounts of unstructured data. A very effective way to avoid cognitive load for the processing of

complex data is the graphical visualization of data (e.g. [8] ). There are many methods to facilitate

learning and cognitive processing of complex data, e.g. using three-dimensional representations rather

than two-dimensional, color-coding of information objects or information classes, using animated

diagrams to e.g. visualize processes, providing interactive graphics to allow the exploration of data,

and many more.

In the context of the BDSS, the highest cognitive load will be demanded in the final decision

phase. Here, all information gathered and analyzed beforehand needs to be integrated to draw

the “big picture”. In this phase, a support by comprehensive and intuitive graphics is crucial.

These graphics furthermore need to be interactive, since the user might want to change some

parameters leading to the calculated „outcome‟ and see in real time how relevant key figures

are affected.

Design for learnability. The users of BDSSs are typically domain experts. However, they may not be

computer or systems experts. The demands of their work may make it difficult for them to put much

time or effort into the learning curve of new programs or new presentation methods. A simple and

easy to use interface is therefore twice as important.

To achieve a fast learnability of the system, several aspects have to be considered. First,

although the system is a very specific kind of software, it relies on common controls, labels,

wordings and UI elements placement. Second, the system needs to provide help functions.

Uncommon controls and functions should come along with a callable description about their

scope and functionality. Third, continuous cross-checking with the end-users is a must.

Allow adaptability and personalization. From the point of view of interaction design, this is one of

the most frequently mentioned requirements for Decision Support Systems ([9] [10] , [11] ). These

systems are usually used by different users with different roles and responsibilities. It is very

important to respond to the unique requests of individual end-users. The system must be adaptable to

the various styles, needs and roles of different users. Thus, the system must provide the possibility to

personalize different aspects of the interface, e.g. the configuration of menus and the process of

information seeking.

Two concrete design decisions can be drawn from this principle. First, the system must come

with a predefined configuration (e.g. of interface elements and menu points) for different user

roles (e.g. the plant manager, the disassembly manager, the sales person etc.). The pre-

configuration needs to be carefully validated by prior end-user feedback. More importantly,

these pre-configurations need to be adaptable easily. E.g. the user needs to be able to adapt

the KPIs which are included in the final calculation / decision. As another example, the users

should be able to chunk relevant KPIs into their own, meaningful patterns (i.e. information

from different sources are grouped and presented in predefined menu points but need to be

adaptively displaceable to freely selected menu points to allow a personally meaningful

information grouping).

Design for consistency. In complex systems, users have to process a lot of information and orient

themselves in a large a menu structure which is possibly hard to overlook. Every additional cognitive

demand, e.g. induced by an inconsistent wording, layout or other design factors, needs to be avoided.

Project –No

Date

Classification

285541

16-July-12


45

A consistent interface design, e.g. where the same commands or menu entries can always be found at

the same place, is very crucial for complex information systems ([9] ). Before the interface of

PREMANUS is designed, a design guideline should be created.

Work in a user-centered design process. The PREMANUS BDSS is designed for domain experts,

e.g. users with specific knowledge and their specific ways of decision taking. Knowing the end-users

requirements is especially crucial for such a specific group of end-users. Taking a user-centered

design in the development of the system is therefore very beneficial to the usefulness and ease of use

of the system. It has been shown that a greater participation of the end-users in the development and

implementation process of a BDSS has a positive effect on use of and satisfaction with the system

([12] ). As an example for specific needs, according to [6] , the trickiest aspect of designing complex

problem-solving systems is finding the appropriate level for analysis. Usefulness is maximized when

the level at which users define and “chunk” their information entities and work processes is met. A

user-centered approach that involves the end-users continuously in design decisions is appropriate.

The design principles listed here guide the whole process of prototyping and implementing of the

BDSS. Each design decision will be cross-checked with these principles. As much feedback as

possible will be gathered from the end-users to ensure a good usability, usefulness and quality of the

system.

5.4.3 Process flexibility: Control and coordination by task-centred information

systems and business processes

Business process management (workflow management) systems and task management systems

represent software that is intended to support the control and coordination of value delivering

processes in companies. For PREMANUS the use cases that have been identified for SKF and CRF

need to be supported by the control and coordination capabilities of the software (for a description of

the use cases, see D1.3).

Control and coordination is realized based on the externalization of goals and process knowledge.

Existing systems can be distinguished among their formalization degree: a) Data-centric approaches,

b) Task-centric approaches and c) Process-centric approaches (see Figure 9). Data-centric approaches

are coordination and control agnostic, as they offer a set of functionalities to interact with data without

goal or process notion. In the following, task and process-centric approaches are presented. Then their

appropriateness for PREMANUS is discussed. Appropriateness needs to address: a) Flexibility

requirements for the use cases and b) Integration of SKF and CRF requirements in business processes.

5.4.3.1 Task-centric approaches: Task management systems

Task or To-do management systems provide capabilities to externalize individual goals as tasks.

Tasks comprise a goal, an anticipated execution process and triggers for the realization process.

Triggers may be time or location. Tasks as externalized goals especially support processes of work

organization:

Delegation of tasks among groups

Sequencing of execution processes

Tracking of progress and spent resources.

In this sense, task management systems especially support the prospective memory of individuals and

groups. Although, the execution process for tasks is underspecified, different methods to provide

process knowledge for recurring tasks (task similarity is based on goal similarity) have emerged. One

Project –No

Date

Classification

285541

16-July-12


46

example is task patterns. Task patterns are collectors of execution process related information that can

be accessed when a user works on a task.

5.4.3.2 Process-centric approaches: Business processes management/Workflow management

Process-centric approaches formalize execution processes to a high degree. The most popular

realization is given with business process management systems that control and coordinate the

execution of a value adding activity among different parties in one or several organizations.

Different process notations have evolved that often support the structured transformation of a business

perspective towards a process to an executable process in an IT-system. The quasi industry standard is

BPMN [17] with 59 OMG listed implementations. It was introduced in 2002 with the aim of

providing a graphical notion that is easy to use for business analysts. BPMN 2.0 addresses

shortcoming of BPMN 1.1 by standardized execution semantics, serialization and support for cross-

organizational scenarios. OMG's BPMN2 specification aims at unifying business and IT needs across

industries in one notation.

The high degree of formalization not always suites the requirements of processes that are executed in

environments that contain uncertainty with respect to effects or with respect to required activities.

Both complicate a static view on organizational processes as predefined entities that are executed.

To address uncertainty with respect to activities task-centric information systems with additional

capabilities for knowledge management, like task pattern are a promising direction. To address

uncertainty with respect to effects of events on business processes, flexibilization of business

processes has emerged as research domain.

“The generic term workflow flexibility comprises a large variety of features discussed in industry and

research. On a coarse granular level, two main flexibility types and their associated challenges can

be identified. Design time flexibility aims at supporting the definition of multiple allowed execution

traces depending on context conditions, i.e. workflow variants, before an instance has been started.

Traditional WfMS typically only allow for a one-by-one modeling of variants and therefore foster the

creation of redundant and hardly maintainable business logic. Runtime flexibility aims at changing

the course of a workflow instance after it has been started in a way that it does not necessarily

correspond to the underlying model anymore, for example due to unforeseen context changes.” [18]

These demands have been addressed by identifying adaptation patterns for business processes [18]

that improve error management and integration of time constraints. Döhring has proposed a rule based

integration of adaptation patterns into workflows based on an extended notion of BPMN 2.0. Overall,

existing work on business flexibilization exists on research level, not yet on product level.

5.4.3.3 Conclusion: Support type for execution processes

Flexibility requirements: Deliverable 1.3 highlights a demand for flexibility (see D1.3, p.8).

There is a core decision process, to limit uncertainty with respect to the execution and

outcome of the remanufacturing process. Due to different availability of information about a

product and different degrees of expertise regarding the product to be remanufactured, many

decisions are taken within the respective processes. A formalization of the flexibility demand

requires elaborate flexibilization techniques. As described, such techniques are currently

subject to intensive research, but not yet productized

Integration of SKF and CRF requirements in business processes. Although SKF and CRF

share a base use case – the remanufacturing decision – the actual use cases significantly

Project –No

Date

Classification

285541

16-July-12


47

differ. SKF addresses remanufacturing of gearboxes from the entire market (GRBQUOTE,

DISASSGRB, REMANU scenarios) whereas CRF addresses engines from the CRF family

(EGNPLT, RMNOPT, ASSOPR scenarios). These use cases are based on different

information availability and are differently embedded in the enclosing business of the

company. Although the use cases and the respective scenarios are comparable, they would

require different business processes which complicate the maintenance of the processes and

their validation.

Overall, task-centric approaches seem to be more suitable to address the flexibility requirement and

the differences between the use cases.

The following table summarizes the PREMANUS requirements for Human Computer Interactions of

the BDSS.

Human Computer Interaction Requirements

BDSS.7 Information Set Non-functional

The amount of data to be processed by a human should be minimized

without affecting the quality of decision making.

PREMANUS should reduce the amount of data processed in every single

step by first an overview shall be provided, then zooming and filtering,

showing details on demand.

BDSS.8 Data visualization Non-functional

PREMANUS should avoid cognitive load for processing information by

using graphical visualization of data, three-dimensional representations,

color-coding, animated diagrams, interactive graphics and other tools to

allow exploration of data.

BDSS.9 Learnability Non-functional

User Interfaces should allow for easy use and stick to common controls,

labels, wording and element‟s placement as users of BDSS might not be

systems experts.

BDSS.10 Personalization Non-functional

The system should be adaptable to various styles, needs and roles because

users will have different roles and responsibilities.

Personalization of UI, configuration of menus and process for information

seeking should be allowed.

BDSS.11 Consistency Non-functional

PREMANUS UI design should allow users to find command and user

interface elements in the same place

Table 13: Human Computer Interaction Requirements

Project –No

Date

Classification

285541

16-July-12


48

6 Summary of Requirements

A functional concept for PREMANUS has been derived from the requirements of the

Remanufacturing Information Service, the Remanufacturing Service Gateway, and the Business

Decision Support System. This is summarized below:

Central cloud component

o Offering a “directory service” that stores “advertisement” (annotations) of content

What is the content? (QLM based)

What is the format?

Where is it?

How can it be accessed?

What is the access policy?

o Search happens against this directory service

o Product ID Management and Mapping

Required for mapping information like service reports to the right product

instances

Required for information generated at different stakeholders for the same

product, or product changing owners, etc.

Gateway at ecosystem partner, non-intrusive to on-premise IT.

o Using a pub-sub approach to

Generate advertisement for each content, that should be available to the

ecosystem

Publish the advertisements to the directory service

Manage access control to content

Adapter service connecting to local storage systems

Annotator service generating the advertisements

Pub/sub monitoring updates of content and added content

o Transformation service:

transforming content from local format to QLM

- BDSS component

o QLM base storage

o BDSS application(s)

o Transformation service

transforming content from local format to local customized QLM format (for

optimized BDSS)

o User Interface elements (gadgets)

Figure 8 shows the requirements that need to be addressed by a PREMANUS architecture.

Three main technical roles are relevant in PREMANUS:

The Remanufacturing Information Service (RIS) being responsible for enabling search of

relevant information and enabling to track a product across different stakeholders along its

lifecycle

The Remanufacturing Service Gateway (RSG) being responsible for communication between

functional modules and enabling information extraction and import to the PREMANUS

Business Decision Support System from heterogeneous information sources (like databases

and content types) via adapter services and semantic services

The PREMANUS Business Decision Support System.

Project –No

Date

Classification

285541

16-July-12


49

Figure 8 - PREMANUS Architectural Concepts according to Functional Roles

The following table summarizes the requirements per core component.

ID Name Category

GTR General Technical Requirements

The PREMANUS system should be modular

The interfaces should be based on open standards

The BDSS should be able to interact, through standardized interfaces, with

also other systems

The PREMANUS system should be cloud ready.

RIS Remanufacturing Information Service Functional

RIS.PIIN.0 Product Identification & Information Network

Structure

Functional

The Remanufacturing Information Service should be built in a hybrid

structure

o Content should be stored by each stakeholder locally

o A central node should realizes directory service with search, lookup,

ID resolution, mapping, and a retrieval service

o A directory service should store advertisements that describe

information available at the stakeholders

Project –No

Date

Classification

285541

16-July-12


50

RIS.PIIN.1 ID Information Discovery Functional







The information discovery is split into two phases

o The owner of product data what information about a product is

available to the remanufacturing ecosystem.

Advertisements/annotations are used to publish this information.

o Search within the advertisements for product information. The

search result details, which product data can be where and how

retrieved.


Once relevant information have been identified, annotations to this

information will provide the

o Location, where the product information can be accesses

o How the product information can be retrieved

o Which further services are available to other PREMANUS stakeholders

An interface is required to retrieve/use the information/services.

RIS.PIIN.3 Information Transformation Functional

RIS should manage a canonical data structure to support import from

heterogeneous information sources into PREMANUS by a transformation

service.

The transformation service should enable simple information processing into

the BDSS.

RIS.PCIM.1 Unique IDs Functional

Each product instance represented in the PREMANUS system should be

uniquely identifiable across all stakeholders

Unique IDs should be used to share information between stakeholders

RIS.PCIM.2 ID Resolution & Mapping Functional

Each stakeholder should be able to retrieve a PREMANUS ID for a physical

product instance

ID retrieval should be possible with minimal information about the product

ID mappings shall be managed for all stakeholders in the remanufacturing

Project –No

Date

Classification

285541

16-July-12


51

ecosystem at a central node

Product IDs shall consists of three components

o OEM

o Product type

o Unique product ID



RIS.DPIS.1 Distributed Product Information Store Functional

The Distributed Product Information Store (DPIS) stores the information

that is published in first phase of the ID Information Discovery process,

according to the requirements RIS.PIIN.1.

The DPIS is operated on a central node where the distributed IT systems of

the stakeholder within the remanufacturing ecosystem publish the product

information to, according to the requirements of RIS.

RIS.DPIS.2 Support to structured data Functional

It is necessary to utilize (or develop) a storage capable of providing support

to structured data, like KPI data (properties and values).

RIS.DPIS.3 Support to semi-structured data Functional


to semi-structured data, like the XML files data containing the indexes of the

stored information.

RIS.DPIS.4 Support to unstructured data Functional


to unstructured data, like PDF, pictures or CAD files.

RIS.DPIS.5 Data stored should be easily accessible Functional

The data stored, independently of the storage used and its physical location,

should be easily accessible for local and remote nodes of PREMANUS

through the usage of Web Services.

RIS.DPIS.6 Big amount of data Functional

It is necessary to provide support to the big amount of data coming from the

two user industries. This requires a proper storage capable of both managing

the quantity of data, maintaining the capability of indexing and fast finding

and processing.

RIS.DPIS.7 Semantic storage Functional

It is necessary to semantically annotate the data stored to enable natural

search languages and to facilitate the indexing of the mainly unstructured

Project –No

Date

Classification

285541

16-July-12


52

data.

RIS.RBAC.1 Authentication Functional

Authentication procedure should exist.

Authentication procedures should avoid access of confidential information

by non-authorized people.

The authentication mechanism should check for every single access to a

given data/document.

However, there should also exist an administrator role to grant access to the

different users.

RSG Remanufacturing Services Gateway

PREMANUS needs to have the different components connected in a

homogeny and transparent way to the user and to the other components.

RSG.SSB.1 Orchestration Functional

The usage of Business Workflow Models (BPML) is demanded by

PREMANUS final users, as they already use BPML based engines in their

current configurations. This feature will allow advanced service composition

that can be configured at each of the end users.

RSG.SSB.2 Integration of software components & data

sources

Functional

The integration of software components and other data sources is necessary for the

following reasons:

Allowing component deployment (desirable hot deployment) with

component versioning

Polyglot applications ( .net, java, php, ...)

Minimizing efforts for integration of 3rd

party components (with predefined

adaptors, e.g. XMPP)

In PREMANUS the following kinds of components are envisaged:

Distributed security & access control.

RSG.SSB.3 Message channels and routing Functional

It is necessary to add functionality regarding the processing of composed

messages. With respect to the messaging and routing it is necessary to take

into account the following points:

o Point-to-point messaging

o Publish-subscribe messaging

o Splitter

o Aggregator

o Content Based Router

o Message Filter

o Dynamic Router

o Recipient List.

http://camel.apache.org/content-based-router.html

http://camel.apache.org/message-filter.html

http://camel.apache.org/dynamic-router.html

http://camel.apache.org/recipient-list.html

Project –No

Date

Classification

285541

16-July-12


53

RSG.SSB.4 Transport protocol Functional

The ESB must allow different transport protocols in the anchor points for

the applications, as well as transport protocol conversion.

RSG.SSB.5 Connectivity Functional

The ESB must allow different components to be connected e.g.:

o Different types of data stores (triple stores, relational, noSQL, XML,

etc.)

o 3rd

party applications (ERP, PLM,...)

o User interfaces

o Internal functional elements:

Business Decision Support System

Unique ID routing mechanism

Semantic gateway & query mechanism (query decomposition and

routing to specific data stores).

RSG.SSB.6 Execution Functional

A common component execution environment is necessary, that will

conform the PREMANUS node, containing the specific functional

components, and the way of communicating with the rest of components

along the PREMANUS environment.

RSG.SSB.7 Support of different topologies Functional

Due to the current status of the project, some generic and open support for

different topologies is needed. Some of the partners see the architecture as a

centralize (unique distributed over the cloud) infrastructure, while some

others see it as instances installed at the final user, and communicated with

the rest of instances using a central coordination point.

Flexibility is needed in order to afford both configurations, and to change

from one to another with no or minimal penalty.

RSG.SSB.8 Security Functional

Although the project is not focused on security, some basic authentication

and role based access control is requested. The distributed nature of the

architecture makes this feature implementation challenging and risky from a

technology point of view.

RSG.GS.1 Transformation services Functional

There must be a mechanism to allow the transformation of different data

formats e.g. XML files or Excel files, are used. This mechanism must be

implemented in the SSB.

RSG.GS.2 Mediation services Functional

There must be a mechanism to allow the RSG to select the appropriate

process or service to be executed. This mechanism must be implemented in

Project –No

Date

Classification

285541

16-July-12


54

the SSB.

RSG.GS.3 Composition of services Functional

Composition of services is needed to improve the performance of the system

and to generate larger services by linking smaller services.

RSG.SS.1 Access to Semantic storages Functional

It is necessary to access the semantic storages which would have the

annotation of the information stored in other storages.

RSG.SS.2 Annotation Functional

In the case of unstructured content, it is necessary to semantically annotate

the data to be stored so it can be easily found and retrieved.

RSG.SS.3 Publishing Functional

As the PREMANUS middleware is dealing with content and also services

offered by the components, it is necessary to publish them so they can be

easily found and retrieved (content) or executed (services).

RSG.SS.4 Reaching information Functional

The information and the services belonging to different components must be

reachable by every component through the SSB.

RSG.GWS.1 DbaaS services Functional

The PREMANUS middleware needs to access to external DBs to retrieve

the data required by the BDSS to perform its calculations.

RSG.GWS.2 AaaS services Functional

The PREMANUS middleware needs to communicate and exchange

information with 3rd

party applications such as ERPs, PLMs, PCos (Plant

Connectivity) like e.g. the ones utilized by the users… and their associated

storages to get the requested information needed by the BDSS to perform its

calculations.

RSG.GWS.3 Connection to external unstructured storages Functional

As in RSG.GWS.1, the PREMANUS middleware needs to access external

unstructured storages to retrieve the data required by the BDSS.

BDSS Business Decision Support System Functional

PREMANUS BDSS should support domain experts who have open-ended,

unstructured and complex problems.

The PREMANUS system should be designed to reduce complexity of

human tasks by structuring, filtering and presenting relevant information in

appropriate ways to support processing of large volumes of data involved in

Project –No

Date

Classification

285541

16-July-12


55

extensive and recursive decision-making.

BDSS.1 BDSS Data Storage Functional

PREMANUS should provide a local data store at the PREMANUS

Remanufacturing node to run the required analyses.

The BDSS Data Store should store all information needed to prepare a

remanufacturing decision; this information is above all product master data

and product lifecycle information such as usage data, service reports, and

sensor data.

The storage should use a sophisticated data structure, so the analyses

conducted by the BDSS can be performed efficiently and correctly. A

canonical PREMANUS data structure will be used as standard, adaptations

to it to specific use cases must be enabled.

BDSS.2 Data Structure Functional

The analysis of the PREMANUS system should run efficiently and correct

by using sophisticated data structures. A canonical PREMANUS data

structure should be used as standard; adaptations to it to specific use cases

must be enabled.

BDSS.3 Query Composition Functional

PREMANUS should provide a Query Composition user interface for

business users to specify which data is needed for the remanufacturing

decision to be taken.

A Query Composition should compose queries from the user input that the

PREMANUS system can correctly execute, search and retrieve the correct

data from the ecosystem.

BDSS.4 Access to Information and tracking activities Functional

PREMANUS system should track all activities at operational level during

the remanufacturing process. This includes input, output and specific

resources.

PLM data, warehouse component‟s stock, customers‟ demand and

expectations should be accessed by the BDSS.

BDSS.5 End-of-Life Product Recovery Process Eco-

Efficiency Evaluator

Functional

PREMANUS should provide evaluation results for:

o Economical evaluations

o Environmental evaluations, taking into account Life Cycle Assessment

(LCA) calculations

o Ecological eco-efficiency evaluation, based on

Generated hazardous/non-hazardous waste

Project –No

Date

Classification

285541

16-July-12


56

Generated CO2 footprint

o Risk of deviation from the expected or benchmarked ecological

efficiency

BDSS.5 KPIs Calculator Functional

PREMANUS should provide different types of KPIs that can be configured

in a flexible manner.

KPIs for the different internal stakeholder to the remanufacturing operations

shall be supported.

KPIs, as business centered measures should benefit from implementation of

computerized calculations, given the access of PREMANUS to relevant

information storage databases.

BDSS.6 Information set Non-functional

The amount of data to be processed by a human should be minimized

without affecting the quality of decision making.

PREMANUS should reduce the amount of data processed in every single

step by first an overview shall be provided, then zooming and filtering,

showing details on demand.

BDSS.7 Data visualization Non-functional

PREMANUS should avoid cognitive load for processing information by

using graphical visualization of data, three-dimensional representations,

color-coding, animated diagrams, interactive graphics and other tools to

allow exploration of data.

BDSS.8 Learnability Non-functional

User Interfaces should allow for easy use and stick to common controls,

labels, wording and element‟s placement as users of BDSS might not be

systems experts.

BDSS.9 Personalization Non-functional

The system should be adaptable to various styles, needs and roles because

users will have different roles and responsibilities.

Personalization of UI, configuration of menus and process for information

seeking should be allowed.

BDSS.10 Consistency Non-functional

PREMANUS UI design should allow users to find command and user

interface elements in the same place

Project –No

Date

Classification

285541

16-July-12


57

7 Appendix A: References

[1] http://en.wikipedia.org/wiki/Overlay_network

[2] http://en.wikipedia.org/wiki/Peer-to-peer

[3] Ralf Steinmetz, Klaus Wehrle (Eds): Peer-to-Peer Systems and Applications, LNCS 3485,

Springer, 2005

[4] http://en.wikipedia.org/wiki/BitTorrent_(protocol)

[5] Nielsen, J. (1994b). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability

Inspection Methods, John Wiley & Sons, New York, NY.

[6] Mirel, B. (2003) Dynamic usability: Designing usefulness into systems for complex tasks, in

M. J. Albers and B. Mazur (Eds.), Content and Complexity: Information Design in Technical

Communication, Mahwah, NJ: Lawrence Erlbaum Associates, pp. 233-262.

[7] J. Redish. Expanding usability testing to evaluate complex systems. Journal of Usability

Studies, 2(3):102–111, 2007.

[8] SCAIFE, M., AND ROGERS, Y. 1996. External cognition: How do graphical representations

work? International Journal of Human-Computer Studies 45, 185–213.

[9] Sankar C.S., F. Nelson, M. Bauer, 1995, „A DSS user interface model to provide consistency

and adaptability‟, Decision Support Systems, 13, 93-104

[10] Wierenga, B., Oude Ophuis, P.A.M., 1997. Marketing decision support systems: Adoption,

use and satisfaction. International Journal of Research and Marketing 14, 275-290.

[11] Maciag, T., Hepting, D.H., Slezak, D.: Personalizing User Interfaces for Environmental

Decision Support Systems. In Proc. Rough Sets and Soft Computing in Intelligent Agent and

Web Technology (2005)

[12] Parker, C., & Sinclair, M. (2001). User-centered design does make a difference. The case of

decision support systems in crop production. Behaviour & Information Technology, 6, 449–

460.

[13] European PROMISE Project (FP6-IST project No. IST-2004-507100).

http://www.promise.no/

[14] Global Standards: Object Name Service. http://www.gs1.org/gsmp/kc/epcglobal/ons/

[15] EU Project Omlette. http://www.ict-omelette.eu/home

[16] Wikipedia: Extract, transform, load. http://en.wikipedia.org/wiki/Extract,_transform,_load

[17] Object Management Group (OMG): Business Process Model and Notation.

http://www.bpmn.org/

[18] Döhring, M. and Zimmermann, B. and Karg, L. (2011): Flexible workflows at design-and

runtime using BPMN2 adaptation patterns, Business Information Systems

[19] The Open Group: The Quantum Lifecycle Management Standard.

https://collaboration.opengroup.org/qlm/

[20] Payne, J. W., Bettman, J. R. & Johnson, E. J. (1993). The adaptive decision maker.

Cambridge, England: Cambridge University Press.

[21] Wikipedia: Uniform Resource Identifier.

http://de.wikipedia.org/wiki/Uniform_Resource_Identifier

http://en.wikipedia.org/wiki/Overlay_network

http://en.wikipedia.org/wiki/Peer-to-peer

http://en.wikipedia.org/wiki/BitTorrent_(protocol)

http://www.promise.no/

http://www.gs1.org/gsmp/kc/epcglobal/ons/

http://www.ict-omelette.eu/home

http://en.wikipedia.org/wiki/Extract,_transform,_load

http://www.bpmn.org/

https://collaboration.opengroup.org/qlm/

http://de.wikipedia.org/wiki/Uniform_Resource_Identifier

Project –No

Date

Classification

285541

16-July-12


58

[22] IETF: RFC 3986. http://tools.ietf.org/html/rfc3986

http://tools.ietf.org/html/rfc3986

d2.2_out

Documents