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 Lead Partner Contributing Partner(s) Security Classification Date Version COPYRIGHT
Copyright 2012 by PREMANUS Consortium

WP2: Reference Architecture 2: POLIMI 1 (SAP), 3 (LBORO), 4 (TIE), 5 (SKF), 6 (CRF), 7 (EPL) PU (Public) 16th July 2012 1.2

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.
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.

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

Document history
Version 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 1.0 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.2 Date 14/04/12 29/05/12 10/06/12 25/06/12 26/06/12 27/06/12 28/06/12 30/06/12 03/07/12 05/07/12 09/07/12 10/07/12 11/07/12 12/07/12 13/07/12 16/07/12 16/07/12 08710/12 Comments ToC and first Draft Update Requirements of RSG Update Requirements of RIS, RSG, BDSS Template Fixing Executive Summary Added section 2.2 Consolidation for final contributions Further Consolidation 1st Revision Internal Review Partial Revision Inclusion of revisions, Changes to different sections Revisions and changes for various sections Minor revisions and formatting fixes Further quality check. Minor corrections and format repair Finalizing document Adding requirements for product IDs Author Tobias Wieschnowsky (SAP) Oscar Garcia (TIE) Tobias Wieschnowsky (SAP), Oscar Garcia (TIE), David Potter (Polimi) Oscar Garcia (TIE) David Potter (Polimi) Jacopo Cassina (Polimi) David Potter (Polimi), Stefan Schleyer (SKF) David Potter (Polimi) Oscar Garcia (TIE) Stuart Campbell (TIE) Federico Magalini & David Potter (Polimi) Oscar Garcia (TIE), Benedikt Schmidt (SAP) Tobias Wieschnowsky (SAP), Oscar Garcia (TIE) Tobias Wieschnowsky (SAP) David Potter (Polimi) Tobias Wieschnowsky (SAP) Nicolas Liebau (SAP) Nicolas Liebau (SAP)

The research leading to these results has received funding from the European Communitys Seventh Framework Programme

ii

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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

iii

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

Table of contents
1 2 EXECUTIVE SUMMARY ........................................................................................................... 6 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 Stores 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

iv

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 7 SUMMARY OF REQUIREMENTS.......................................................................................... 48 APPENDIX A: REFERENCES.................................................................................................. 57

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 users 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 products 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 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 companys 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 subassemblies or discard to material recovery) Supporting the remanufacturing process at the operational level, particularly providing stepby-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 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 gearbox 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:

10

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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

11

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 todays 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 products 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 products status may be monitored using sensor measurements and analysed. This data is referred to as lifecycle information of a product. The products 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.

12

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 Information Retrieval Functional

RIS.PIIN.2

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. Information Transformation Functional

RIS.PIIN.3

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.

13

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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

14

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

projects 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 networks 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

15

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 RIS.PIIN.0

Remanufacturing Information Service Product Identification & Information Network Structure Functional

The Remanufacturing Information Service should be built in a hybrid structure o o o Content should be stored by each stakeholder locally A central node should realizes directory service with search, lookup, ID resolution, mapping, and a retrieval service 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

16

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 highlevel 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 partners 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 partners 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 partners 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 others 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.

17

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 stakeholders 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 stakeholders 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.

18

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 IETFs 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

19

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 RIS.PCIM.2 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. 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 o o OEM Product type 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

20

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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.

21

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

Search and Lookup Requirements RIS.PCIM.3 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 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. 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

22

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 projects 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

23

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 semistructured 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 stakeholders 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.

24

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

Table 5 summarizes the extended requirements for information retrieval. Information Retrieval Mechanism Requirements RIS.PIIN.2 Information Retrieval Functional

Once relevant information have been identified, annotations to this information will provide the o o o Location, where the product information can be accesses How the product information can be retrieved 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 rolebased 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 users roles Each stakeholder can decide locally what information to make available to whom based on a users 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.

25

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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.

26

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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.

27

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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

28

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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).

29

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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.

30

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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.

31

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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).

32

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 products Beginning-of-Life and Middle-of-Life phases.

33

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 onboard 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 preexisting 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 PREMANUSs

34

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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.

35

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 Stores 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 Groups Quantum Lifecycle Management (QLM) standard [19] . Such a data structure can be used as a canonical data structure for PREMANUS. The PREMANUS Data Stores 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 Stores data structure also customized transformation services are likely to be required.

36

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 Data Storage Functional

BDSS.1

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.

37

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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. Data Structure Functional

BDSS.2

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. Query Composition Functional

BDSS.3

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. Access to Information and Tracking Activities Functional

BDSS.4

PREMANUS system should track all activities at operational level during the remanufacturing process. This includes input, output and specific resources. PLM data, warehouse components 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, subassemblies, 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 customers demand for specific refurbished products, influence the remanufacturing strategy and operations (e.g. job-order or disassembly or re-assembly process) at

38

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 o Generated hazardous/non-hazardous waste 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.

39

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 EcoEfficiency Evaluator PREMANUS should provide evaluation results for: o o o Economical evaluations Environmental evaluations, taking into account Life Cycle Assessment (LCA) calculations Ecological eco-efficiency evaluation, based on o Generated hazardous/non-hazardous waste Generated CO2 footprint Functional

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

40

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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.

41

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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

42

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 Schneidermans 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,

43

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 preconfiguration 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.

44

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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

45

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 crossorganizational 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. Dhring 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

46

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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. Data visualization Non-functional

BDSS.8

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. Learnability Non-functional

BDSS.9

User Interfaces should allow for easy use and stick to common controls, labels, wording and elements placement as users of BDSS might not be systems experts. Personalization Non-functional

BDSS.10

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. Consistency Non-functional

BDSS.11

PREMANUS UI design should allow users to find command and user interface elements in the same place
Table 13: Human Computer Interaction Requirements

47

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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.

48

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

Figure 8 - PREMANUS Architectural Concepts according to Functional Roles

The following table summarizes the requirements per core component. ID GTR RIS RIS.PIIN.0 Name 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. Remanufacturing Information Service Product Identification & Information Network Structure Functional Functional Category

The Remanufacturing Information Service should be built in a hybrid structure o o o Content should be stored by each stakeholder locally A central node should realizes directory service with search, lookup, ID resolution, mapping, and a retrieval service A directory service should store advertisements information available at the stakeholders that describe

49

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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 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. Search within the advertisements for product information. The search result details, which product data can be where and how retrieved. Functional

RIS.PIIN.2

Information Retrieval

Once relevant information have been identified, annotations to this information will provide the o o o Location, where the product information can be accesses How the product information can be retrieved Which further services are available to other PREMANUS stakeholders

RIS.PIIN.3

An interface is required to retrieve/use the information/services. 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. Unique IDs Functional

RIS.PCIM.1 RIS.PCIM.2

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 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

50

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

ecosystem at a central node Product IDs shall consists of three components o o o OEM Product type Unique product ID

The overall structure of search and lookup shall comply with the EPC Global standard Object Name Service (ONS). Distributed Product Information Store Functional

RIS.DPIS.1

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. Support to structured data Functional

RIS.DPIS.2

It is necessary to utilize (or develop) a storage capable of providing support to structured data, like KPI data (properties and values). Support to semi-structured data Functional

RIS.DPIS.3

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. Support to unstructured data Functional

RIS.DPIS.4

It is necessary to utilize (or develop) a storage capable of providing support to unstructured data, like PDF, pictures or CAD files. Data stored should be easily accessible Functional

RIS.DPIS.5

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. Big amount of data Functional

RIS.DPIS.6

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. Semantic storage Functional

RIS.DPIS.7

It is necessary to semantically annotate the data stored to enable natural search languages and to facilitate the indexing of the mainly unstructured

51

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

data. RIS.RBAC.1 Authentication 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. 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. Orchestration Functional Functional

RSG

RSG.SSB.1

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. Integration of software components & data sources Functional

RSG.SSB.2

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.

52

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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. Connectivity Functional

RSG.SSB.5

The ESB must allow different components to be connected e.g.: o o o o Different types of data stores (triple stores, relational, noSQL, XML, etc.) 3rd party applications (ERP, PLM,...) User interfaces Internal functional elements: Business Decision Support System Unique ID routing mechanism Semantic gateway & query mechanism (query decomposition and routing to specific data stores). Functional

RSG.SSB.6

Execution

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. Support of different topologies Functional

RSG.SSB.7

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.
Security

RSG.SSB.8

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. Transformation services Functional

RSG.GS.1

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. Mediation services Functional

RSG.GS.2

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

53

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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. Access to Semantic storages Functional

RSG.SS.1

It is necessary to access the semantic storages which would have the annotation of the information stored in other storages. Annotation Functional

RSG.SS.2

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. Publishing Functional

RSG.SS.3

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). Reaching information Functional

RSG.SS.4

The information and the services belonging to different components must be reachable by every component through the SSB. DbaaS services Functional

RSG.GWS.1

The PREMANUS middleware needs to access to external DBs to retrieve the data required by the BDSS to perform its calculations. AaaS services Functional

RSG.GWS.2

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. Connection to external unstructured storages Functional

RSG.GWS.3

As in RSG.GWS.1, the PREMANUS middleware needs to access external unstructured storages to retrieve the data required by the BDSS. Business Decision Support System Functional

BDSS

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

54

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

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. Data Structure Functional

BDSS.2

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. Query Composition Functional

BDSS.3

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. Access to Information and tracking activities Functional

BDSS.4

PREMANUS system should track all activities at operational level during the remanufacturing process. This includes input, output and specific resources. PLM data, warehouse components stock, customers demand and expectations should be accessed by the BDSS. End-of-Life Product Recovery Process EcoEfficiency Evaluator Functional

BDSS.5

PREMANUS should provide evaluation results for: o o o Economical evaluations Environmental evaluations, taking into account Life Cycle Assessment (LCA) calculations Ecological eco-efficiency evaluation, based on Generated hazardous/non-hazardous waste

55

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

Generated CO2 footprint

Risk of deviation from the expected or benchmarked ecological efficiency Functional

BDSS.5

KPIs Calculator

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. Information set Non-functional

BDSS.6

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. Data visualization Non-functional

BDSS.7

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. Learnability Non-functional

BDSS.8

User Interfaces should allow for easy use and stick to common controls, labels, wording and elements placement as users of BDSS might not be systems experts. Personalization Non-functional

BDSS.9

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. Consistency Non-functional

BDSS.10

PREMANUS UI design should allow users to find command and user interface elements in the same place

56

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

7
[1] [2] [3] [4] [5] [6]

Appendix A: References
http://en.wikipedia.org/wiki/Overlay_network http://en.wikipedia.org/wiki/Peer-to-peer Ralf Steinmetz, Klaus Wehrle (Eds): Peer-to-Peer Systems and Applications, LNCS 3485, Springer, 2005 http://en.wikipedia.org/wiki/BitTorrent_(protocol) Nielsen, J. (1994b). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods, John Wiley & Sons, New York, NY. 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. J. Redish. Expanding usability testing to evaluate complex systems. Journal of Usability Studies, 2(3):102111, 2007. SCAIFE, M., AND ROGERS, Y. 1996. External cognition: How do graphical representations work? International Journal of Human-Computer Studies 45, 185213. Sankar C.S., F. Nelson, M. Bauer, 1995, A DSS user interface model to provide consistency and adaptability, Decision Support Systems, 13, 93-104 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. 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) 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. European PROMISE Project (FP6-IST project No. IST-2004-507100). http://www.promise.no/ Global Standards: Object Name Service. http://www.gs1.org/gsmp/kc/epcglobal/ons/ EU Project Omlette. http://www.ict-omelette.eu/home Wikipedia: Extract, transform, load. http://en.wikipedia.org/wiki/Extract,_transform,_load Object Management Group (OMG): Business Process Model and Notation. http://www.bpmn.org/ Dhring, M. and Zimmermann, B. and Karg, L. (2011): Flexible workflows at design-and runtime using BPMN2 adaptation patterns, Business Information Systems The Open Group: The Quantum Lifecycle Management Standard. https://collaboration.opengroup.org/qlm/ Payne, J. W., Bettman, J. R. & Johnson, E. J. (1993). The adaptive decision maker. Cambridge, England: Cambridge University Press. Wikipedia: Uniform Resource Identifier. http://de.wikipedia.org/wiki/Uniform_Resource_Identifier

[7] [8] [9] [10] [11]

[12]

[13] [14] [15] [16] [17] [18] [19] [20] [21]

57

Project No Date Classification

285541 16-July-12 PU

D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION

[22]

IETF: RFC 3986. http://tools.ietf.org/html/rfc3986

58