Download - D2.2_out
The PREMANUS project (285541) is co-funded by the European Union under the Information and Communication Technologies (ICT) theme of the
7th Framework Programme for R&D (FP7).
This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be
made of its content.
Programme Factories of the Future PPP
Strategic Objective ICT-2011.7.3 Virtual Factories and Enterprises
Project Title Product Remanufacturing Service System
Acronym PREMANUS
Project # 285541
D2.2 - REQUIREMENTS ANALYSIS
REPORT
Work Package WP2: Reference Architecture
Lead Partner 2: POLIMI
Contributing Partner(s) 1 (SAP), 3 (LBORO), 4 (TIE), 5 (SKF), 6 (CRF),
7 (EPL)
Security Classification PU (Public)
Date 16th July 2012
Version 1.2
COPYRIGHT © Copyright 2012 by PREMANUS Consortium
Legal Disclaimer The information in this document is provided „as is‟, and no guarantee or warranty is given that the information is fit for any particular purpose. The above
referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages
that may result from the use of these materials subject to any liability which is mandatory due to applicable law.
This document may not be copied, reproduced, or modified in whole or in part for any purpose without written permission from all of the Copyright owners. In
addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all
applicable portions of the copyright notice must be clearly referenced.
All rights reserved. This document may change without notice.”
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
ii
Document history
Version Date Comments Author
0.1 14/04/12 ToC and first Draft Tobias Wieschnowsky (SAP)
0.2 29/05/12 Update Requirements of RSG Oscar Garcia (TIE)
0.3 10/06/12 Update Requirements of RIS, RSG, BDSS
Tobias Wieschnowsky
(SAP), Oscar Garcia (TIE),
David Potter (Polimi)
0.4 25/06/12 Template Fixing Oscar Garcia (TIE)
0.5 26/06/12 Executive Summary David Potter (Polimi)
0.6 27/06/12 Added section 2.2 Jacopo Cassina (Polimi)
0.7 28/06/12 Consolidation for final contributions David Potter (Polimi), Stefan
Schleyer (SKF)
0.8 30/06/12 Further Consolidation David Potter (Polimi)
1.0 03/07/12 1st Revision Oscar Garcia (TIE)
1.01 05/07/12 Internal Review Stuart Campbell (TIE)
1.02 09/07/12 Partial Revision Federico Magalini & David
Potter (Polimi)
1.03 10/07/12 Inclusion of revisions, Changes to different sections Oscar Garcia (TIE), Benedikt
Schmidt (SAP)
1.04 11/07/12 Revisions and changes for various sections Tobias Wieschnowsky
(SAP), Oscar Garcia (TIE)
1.05 12/07/12 Minor revisions and formatting fixes Tobias Wieschnowsky (SAP)
1.06 13/07/12 Further quality check. David Potter (Polimi)
1.07 16/07/12 Minor corrections and format repair Tobias Wieschnowsky (SAP)
1.08 16/07/12 Finalizing document Nicolas Liebau (SAP)
1.2 08710/12 Adding requirements for product IDs Nicolas Liebau (SAP)
The research leading to these results has received funding from the European Community‟s Seventh Framework Programme
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
iii
(FP7/2007-2013) under grant agreement no285541.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
iv
Table of contents
1 EXECUTIVE SUMMARY ........................................................................................................... 6
2 INTRODUCTION & OVERALL PREMANUS SYSTEM REQUIREMENTS...................... 8
2.1 SUMMARY OF PREMANUS USAGE SCENARIOS ...................................................................... 9 2.1.1 Summary CRF use case ..................................................................................................... 9 2.1.2 Summary SKF use case ................................................................................................... 10
2.2 CONCLUSIONS: OBJECTIVES AND CRITERIA FOR REQUIREMENTS ANALYSIS ........................ 11 2.2.1 Technical Requirements .................................................................................................. 11
3 REQUIREMENTS FOR REMANUFACTURING INFORMATION SERVICES .............. 12
3.1 PRODUCT IDENTIFICATION & INFORMATION NETWORK ........................................................ 14 3.1.1 Central Network Structure .............................................................................................. 14 3.1.2 Decentralized Network Structure .................................................................................... 15 3.1.3 Hybrid Network Structure ............................................................................................... 15 3.1.4 Conclusions ..................................................................................................................... 16
3.2 PRODUCT & COMPONENT IDENTIFICATION & MAPPING ........................................................ 16 3.2.1 ID Mapping ..................................................................................................................... 17 3.2.2 ID Resolution .................................................................................................................. 19 3.2.3 Conclusions ..................................................................................................................... 19
3.3 SEARCH AND LOOKUP MECHANISM ....................................................................................... 20 3.4 DISTRIBUTED PRODUCT INFORMATION STORE (DPIS) .......................................................... 22
3.4.1 Types of data ................................................................................................................... 22 3.4.2 Distributed storage .......................................................................................................... 22 3.4.3 Amount of data ................................................................................................................ 23 3.4.4 Semantic enriched content .............................................................................................. 23 3.4.5 DPIS Requirements ......................................................................................................... 23
3.5 INFORMATION RETRIEVAL MECHANISM ................................................................................ 24 3.6 ROLE-BASED ACCESS CONTROL ............................................................................................. 25
4 REQUIREMENTS FOR REMANUFACTURING SERVICES GATEWAY ....................... 26
4.1 SEMANTIC SERVICE BUS ........................................................................................................ 27 4.1.1 Introduction ..................................................................................................................... 27 4.1.2 SSB Requirements ........................................................................................................... 27
4.2 INFRASTRUCTURAL SERVICES ................................................................................................ 29 4.2.1 Generic Services .............................................................................................................. 29 4.2.2 Semantic services ............................................................................................................ 30 4.2.3 Gateway services ............................................................................................................. 32
4.3 DEVICE AS A SERVICE, MAINTENANCE AS A SERVICE ........................................................... 33 4.4 RESULTING HIGH LEVEL FUNCTIONAL CONCEPT .................................................................. 34
5 REQUIREMENTS FOR BUSINESS DECISION SUPPORT SYSTEM ............................... 36
5.1 BUSINESS DECISION SUPPORT SYSTEM FOUNDATION ........................................................... 36 5.1.1 PREMANUS Data Store .................................................................................................. 36 5.1.2 PREMANUS Data Store’s Data Structure ...................................................................... 36 5.1.3 PREMANUS Search Engine ............................................................................................ 37 5.1.4 Access to further IT Systems of the Remanufacturer ....................................................... 37 5.1.5 Conclusion PPREMANUS Business Decision Support System Foundation ................... 37
5.2 END-OF-LIFE PRODUCT RECOVERY PROCESS ECO-EFFICIENCY EVALUATOR ...................... 38 5.3 KPI OPTIMIZER ....................................................................................................................... 40 5.4 HUMAN COMPUTER INTERACTION ......................................................................................... 42
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
v
5.4.1 User Experience .............................................................................................................. 42 5.4.2 Complex Systems – BDSS-specific .................................................................................. 43 5.4.3 Process flexibility: Control and coordination by task-centred information systems and
business processes ......................................................................................................................... 45
6 SUMMARY OF REQUIREMENTS .......................................................................................... 48
7 APPENDIX A: REFERENCES .................................................................................................. 57
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
6
1 Executive Summary
This document examines the requirements for the different components that will be needed in the
PREMANUS Architecture from both functional and non-functional points of view. Whereas the
deliverable D1.3 provides a high level user-oriented overview of user‟s expectations and requirements
for the PREMANUS architecture, this document more closely examines the requirements, especially
with respect to functional and non-functional technical requirements.
In order to facilitate better decision making for remanufacturing, PREMANUS must consolidate
product information of different types from a wide variety of sources. In particular, information such
as a product‟s bill of material combined with usage and maintenance information gathered during its
entire lifecycle are critical. Such information needs to be brought together using a number of services
to locate, retrieve, index and consolidate information so that it can be used by functions of the
PREMANUS Business Decision Support System (BDSS).
Figure 1 – PREMANUS Conceptual Infrastructure
Figure 1 shows the different requirements for an architecture that must be realized in PREMANUS. A
central node coordinates information searches between the different PREMANUS partners. Each
partner operates a local PREMANUS node that operates on local data, and that can be used to access
external data.
Main components of local PREMANUS nodes are the Remanufacturing Information Service, the
Remanufacturing Service Gateway and the Business Decision Support System.
The Remanufacturing Information Service (RIS) provides the functionality to enable searching for
relevant information and enabling a product to be tracked across different stakeholders during its
lifecycle.
The Remanufacturing Service Gateway (RSG) is responsible for communication between functional
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
7
modules and enabling information extraction and import to the PREMANUS Business Decision
Support System from heterogeneous information sources (like databases and content types) via
adapter services and semantic services.
The BDSS provides a single point of information for remanufacturing decisions. Users access KPIs
and product information using the BDSS. To enable this, the BDSS is the front end for the RSG and
RIS as well as being a system to calculate product specific KPIs based on user queries.
The requirements are examined per component and a summary of the requirements is given at the end
of this deliverable.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
8
2 Introduction & Overall PREMANUS System Requirements
This deliverable presents the technical requirements for PREMANUS based upon the usage scenarios
described in the deliverables D1.1, D1.2, and D1.3.
The PREMANUS DoW organizes the work tasks and deliverables with respect to three functional
components (see Figure 2). This document follows this component structure and identifies
requirements for the Remanufacturing Information Service (RIS), the Remanufacturing Service
Gateway (RSG), and the Business Decision Support System (BDSS).
Figure 2 - Three architectural pillars of PREMANUS
The RIS ensures that information relevant to remanufacturing decisions can be searched for
efficiently. This information is mainly data about products and is distributed across the stakeholders
of the remanufacturing ecosystem. In the DoW, three services were already identified that the RIS
needs to provide:
Product ID resolution and mapping: This enables PREMANUS to cope with different IDs
within the stakeholders‟ IT systems
Persistency service: This allows storage of information that helps tracking a product across
its lifecycle
Role-based access control: This enables the implementation of confidentiality requirements.
The RSG enables the communication of the functional components and the access to information
stored in structured and unstructured information sources. Within the DoW three services were
already identified that the RSG needs to provide:
Semantic Service Bus: Allows the interconnection of the functional modules and provides
message routing. It also provides semantic capabilities
Infrastructural services: For example the automated generation of interfaces to information
sources
Adapter services: These allow the connection of different information sources such as
databases or devices.
The BDSS enables analysis of information about the product to be remanufactured and provides
decision support to the user. Two core services have been identified in the DoW:
The End of Life product recovery process eco-efficiency evaluator: This will take into
consideration the environmental impact of the End of Life (EoL) product recovery process
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
9
The KPI Optimizer: Provides Decision Support for Remanufacture/Reuse/Disposal based on
economic KPIs.
In order to formulate the technical requirements, the next section will summarize the usage scenarios
which are result from WP1.
2.1 Summary of PREMANUS Usage Scenarios
D1.3 provided a high-level, user-oriented overview of users‟ expectations and requirements for the
PREMANUS architecture. The differences and unique elements of the two use cases demand that the
architecture should be sufficiently flexible to meet the needs of these and other different
industries/remanufacturing sectors. The two use cases and the expectations from PREMANUS
include activities occurring in different stages of the remanufacturing process itself and supporting
business in multiple ways as summarized in D1.3, Chapter 5.3 and in particular:
Definition of estimated costs for the remanufacturing process based on previous
contract/activities or in-house knowledge-base/information
Supporting the general remanufacturing strategy at product or specific component level, based
on access to PLM data or in-house knowledge/information
Supporting operations during dismantling and/or re-assembly phase, enabling the effective
implementation of a company‟s strategy regarding, among other things, salvages, component/
sub-assemblies/product stocks, purchase of external components/products etc.
Developing and maintaining an in-depth knowledge-base as overarching tool to support
operations and business strategy
Integrating existing information stored/maintained in other IT System within the company
2.1.1 Summary CRF use case
In the CRF Use Case, PREMANUS‟ users will benefit from PREMANUS in three main stages of the
remanufacturing process:
Deciding the remanufacturing strategy for each engine arriving at the plant (i.e.
remanufacturing the entire engine, remanufacturing only selected components or sub-
assemblies or discard to material recovery)
Supporting the remanufacturing process at the operational level, particularly providing step-
by-step dismantling and re-machining instructions to operators, depending on PLM data and
other KPIs and keeping track of real activities of operations
Supporting assembly operations; particularly providing step-by-step assembly instructions
and keeping track of real activities of operations
Currently CRF uses the following information systems for most its manufacturing businesses:
In-house ERP system called OCTAL
In-house high-level KPI visualizer, retrieving data from OCTAL, called PlantDashboard.
In-house PLM system (tracking actual maintenance activities during warranty period) called
link.e.entry.
In-house system for assembly and disassembly instructions called eLearn
Plant simulation tool by Siemens Tecnomatix (Plant Simulation v.10)
In order to achieve the expected benefits, the PREMANUS architecture should:
Provide interfaces for operators, allowing:
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
10
o Proper retrieval and display of unique IDs assigned once the engine arrived at the
plant. The plant ERP (i.e. home-grown software “OCTAL”) system connects an ID to
all relevant information (e.g. engine serial number, stock level, expected demand of
remanufactured engine, rotation rate, etc.)
o Proper interfaces to access specific IT systems and particularly:
the link.e.entry system to retrieve detailed PLM and BoM data to feed the
PREMANUS BDSS
the e.learn system to print detailed, step-by-step dismantling and assembly
instructions
o The display of a job-order for each specific engine and/or component that will be
created on the basis of information stored in OCTAL and algorithms in PREMANUS
BDSS. Job orders might include different scenarios (e.g. from engine-to-engine, from
engine-to-subassemblies, both with or without intermediate warehousing of
components)
o The recording of specific activities carried out during operations, including potential
deviations from planned job-order due to on-the-line assessment, as well as recording
of activity time to elaborate detailed KPIs
Enable access and retrieval of data from relevant IT systems (OCTAL, link.e.entry, e.learn)
with the following objectives:
o To feed PREMANUS BDSS (e.g. BoM, PLM data, elaborated KPIs)
o To allow access to information stored and managed in such systems (e.g. detailed
dismantling and assembly instructions) under control of proper user identification.
Allow the export of data for business analysis (e.g. CSV).
2.1.2 Summary SKF use case
In the SKF Use Case, PREMANUS users will benefit from the tool in three main stages of the
remanufacturing process as follows:
Initial Quotation: An initial ball-park quote for each potential customer requesting for gear-
box substitution or remanufacturing will be created. The quote is based on both information
available at customer level, in-house specific knowledge and in-house historical data
(including availability of components). Other information sources are standard or estimated
workloads derived from in-house knowledge or past remanufacturing processes
Firm Quotation & remanufacturing process: A final and firm quote is created in the
disassembly process based on the product insight gained and knowledge-based enrichment:
The remanufacturing process of each product brings new information about the process. The
newly gained knowledge is used to increase the in-house knowledge and build-up a
knowledge-base. The management of the information supports future activities, in particular
initial ball-park quotations.
Currently SKF uses the following information systems for most its manufacturing businesses:
In-house ERP system (MCSS for production, SKF Office for sales)
PLM and CAD systems by PTC - Pro-Engineer (now called Creo) and Windchill
WindCon (remote wind turbine monitoring system by SKF)
WinDog for the inventory of the installed WindCon systems
Suppliers and customers also use different types of CAD and PLM systems
In order to achieve the expected benefits, the PREMANUS architecture should:
Provide interfaces for operators, allowing:
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
11
o Access and retrieval of information stored in other IT Systems in order to assess
availability of components, the current prices or stock levels, the schedule of
remanufacturing plant and the workload of involved operators
o Proper interfaces to access specific IT systems and particularly:
“WinDog” to retrieve detailed bearing information (in case SKF bearings are
used in a gearbox) including bearing type, number of rolling elements, size &
geometry, etc.
o Display of specific information (e.g. photo, CAD representations, notes,..) from
previous processes or related to specific components in order to estimate the potential
economic impact of the remanufacturing process, but also supporting the disassembly
once the gearbox arrives at plant
o Recording of specific activities carried out during operations within SKF; in
particular all details of the disassembly process, including results of inspections, tools
used, time and workload of staff, all un-expected events etc, in order to build a
detailed knowledge-base
Enable access and retrieval of data from relevant IT systems with the following objectives:
o To feed PREMANUS BDSS (e.g. BoM, PLM data, elaborate KPIs)
o To allow access to information stored and managed in such systems (e.g. workload of
operators, prices and availability of components, potential outsourcing for gearbox),
under the control of proper user identification
o To allow access to PLM data in the case “WindCon” system is used on the wind
turbines from which the gearbox has to be remanufactured.
Allow the export of data for business analysis (e.g. CSV, XML).
2.2 Conclusions: Objectives and Criteria for Requirements Analysis
In addition to requirements arising within the project, some concepts and ideas were also considered
to make the PREMANUS solution commercially sound and more attractive. Some of the ideas have
arisen from meetings held between POLIMI and some Italian SMEs in the remanufacturing area.
2.2.1 Technical Requirements
The following high-level technical requirements are derived mostly from the PREMANUS
description of work. Interoperability with existing IT systems at the use case partners, and later at the
users of the PREMANUS middleware, requires standardized interfaces in order to connect to those IT
systems. Another requirement is to keep the PREMANUS system modular, which makes it more
extensible and customizable according to the needs of the end-user deploying the PREMANUS
middleware.
In short the high-level technical requirements are:
The PREMANUS system should be modular
The interfaces should be based on open standards
The BDSS should be able to interact, through standardized interfaces, with third party
systems
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
12
3 Requirements for Remanufacturing Information Services
The RIS serves as layer for providing product-related information to the RSG. To realize this, the RIS
provides the mechanisms for distributed storage and retrieval of product information. In order to
define the functional and non-functional requirements, an understanding of today‟s environment, of
which the RIS has to be part, is required.
For production enterprises working in supply chains, products consist of components either produced
in-house or supplied by different manufacturers. Different manufacturers make up a supply chain that
coordinates a production process (see Figure 3 showing 3 such organizations). Other factors might be
non-physical elements like Service Level Agreements (SLAs) about the promised performance of the
product, guarantees, service contracts, liability agreement, insurances, etc. The data that describes the
product and its components is called the product‟s master data. Master data is relatively constant and
is only updated if the components of the product change or variants are created.
Figure 3 - Supply Chain
During the lifecycle of a product it will be maintained, components might be repaired, overhauled,
and replaced; the product‟s status may be monitored using sensor measurements and analysed. This
data is referred to as lifecycle information of a product. The product‟s lifecycle information can be
much more extensive than the master data and is often frequently updated.
For End-of-Life re-manufacturing decisions, all this information (master data and lifecycle
information) can contribute significantly to the quality of the decision (see Section 2.1 Summary of
PREMANUS Usage Scenarios).
In order to find and retrieve the information, several core requirements must be fulfilled:
The RIS must be enabled to clearly identify an individual product and its components via
an identification scheme
The product identity must be related to the correct master data and lifecycle
information via efficient data querying/discovery mechanisms
The challenge for the PREMANUS system is the setup of the ecosystem it has to operate in. It is
composed of many distributed, independent parties, each with their own independent and
unlinked/exposed information sources. Each party (component supplier, original equipment
manufacturer, maintenance service provider, etc.) might also use its own methodology for recording
and storing product master data and product lifecycle information.
Accordingly, another core requirement is relevant for PREMANUS:
Product Information Transformation mechanism that transforms retrieved into a unified
data format so it can serve as input to the BDSS.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
13
Taking into account these requirements, the PREMANUS RIS will establish a Product Identification
and Information Network that the BDSS will use to collect all available inputs for the
remanufacturing decision (Figure 4 - Product Identification & Information Network).
Figure 4 - Product Identification & Information Network
The following table summarizes the main PREMANUS requirements for the Product Identification &
Information Network.
Product Identification & Information Network Requirements
RIS.PIIN.1 ID Information Discovery Functional
PREMANUS should discover which information for a given ID is available
from which stakeholder
Information discovery should allow a stakeholder to gather all necessary
information for an ID to use for assessment or disassembly
RIS.PIIN.2 Information Retrieval Functional
Once a stakeholder has been identified as holding relevant information, there
should be some (probably standardized) mechanism to discover which
information & services are available to other PREMANUS stakeholders
There should be an interface to retrieve/use the information/services.
RIS.PIIN.3 Information Transformation Functional
RIS should manage a canonical data structure to support import from
heterogeneous information sources into PREMANUS by a transformation
service.
The transformation service should enable simple information processing into
the BDSS.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
14
Before discussing each of the core requirements in more detail, the alternatives for building an
information network within a remanufacturing ecosystem will be discussed. The structure of the
information network influences the sub-requirements for each of the core requirements.
3.1 Product Identification & Information Network
There are three different types of networks that can be distinguished: Centralized, decentralized, or
hybrid (see Figure 5).
Figure 5 - Alternative Concepts for the Product Identification and Information Network
The different alternatives will be evaluated according to the following criteria:
Commercial soundness of concept; that is, based on commercial reasoning is it likely that
the individual parties within a remanufacturing ecosystem would join such a network
structure?
Technical soundness of concept; that is, is the technology required to setup such a network
architecture mature, reliable and can it be operated effectively?
Business Model support; that is, is there a business model that would support setting up and
operating such a network structure within a remanufacturing ecosystem?
3.1.1 Central Network Structure
In a centralized network, all product information is stored at a central node. Thus, each party in the
ecosystem who is creating product information throughout the lifecycle of an individual product must
upload this information and all or certain parts of information may also be propagated to other
individual nodes. Advantages of this approach are that information will be transformed into a unified
format when it is uploaded. Further, all information remains available, even if a party is leaving an
ecosystem (e.g. due to bankruptcy or acquisition). Disadvantages are that one organization is required
to operate this central node. All parties in the ecosystem would need to agree to work with such a
central node and be dependent on it, potentially introducing a single point of failure. Thus all parties
have to establish commercial relationships with the entity operating the node.
3.1.1.1 Evaluation
It is unlikely that manufacturers would agree to a central network. The party operating the central
node would have access to all product information; much of that information a company considers it
intellectual property, e.g. its customer base or supply chain. Thus, only a completely neutral entity
with no commercial interest in the information could operate such a node for the ecosystem. To the
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
15
project‟s knowledge there is currently no such entity existing, therefore this alternative has a weak
commercial soundness and is not discussed any further in this model.
3.1.2 Decentralized Network Structure
In a decentralized network all information remains at a node controlled by the party that created the
information. When information is required, the information must be located at one of the nodes of the
ecosystem or subscribed to. This requires fully decentralized mechanisms for identification, search,
subscription and lookup.
Completely decentralized information systems have been intensively researched within the overlay
network [1] and peer-to-peer systems [2] , [3] research areas.
3.1.2.1 Evaluation
Although researched, fully decentralized IT systems have not yet been successfully introduced for
industry applications. This is due to some inherent challenges of these systems, especially regarding
firewall traversal and reliability; an overlay network requires that each node of the overlay network
can be reached by each other node. For industry applications this requirement is difficult to achieve,
as IT departments will not easily open up their IT systems to a whole ecosystem. Further, fully
decentralized systems are difficult to manage – for example, it is difficult to determine the root cause
of a failure if there is no central node available that monitors the network‟s state.
Peer-to-Peer systems face another problem regarding commercialization that also applies to
PREMANUS. A party has to build the network and take responsibility for correct operations.
However, the fully distributed nature provides a challenge for doing so. Further, as there is no central
IT node and all investment and operating costs are with the network nodes, it is difficult to build a
business model around a fully decentralized network.
Accordingly, this network structure is weak in the technical soundness and support of business models
and again will not be further discussed.
3.1.3 Hybrid Network Structure
In a hybrid network the information is stored at the decentralized nodes. At a central node an index for
the information is kept so any information can be localized quickly. When information is created on
the decentralised nodes, the node storing the information will publish an “advertisement” to the
central node where the advertisement (or annotations) will be stored in a database. The advertisement
contains the unique identification of the data access point and further descriptors that are meaningful
for search.
When information is searched, queries on the central node will be used to determine the required
information and location of it. Then, the information will be retrieved from the storing nodes.
Hybrid systems have been deployed in large scale e.g. based on the BitTorrent content distribution
protocol [4] .
3.1.3.1 Evaluation
Each party is still in full control of its information and can decide with whom to share which
information; which is the same scenario as with normal business. Therefore, commercially the
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
16
concept is sound.
Technically, a hybrid network is less complex to setup and maintain than a fully decentralized system.
Scalability issues are handled due to the decentralized information storage. Accordingly, this structure
also can be implemented with a sound technical concept.
However, still there is a central node, even if used primarily for indexing, and hence it requires a party
to operate it. But since the central node does not impose direct advantage of information, there is no
commercial threat established by the operator unlike in a centralised system. Further, the operator of
such a central node would take the role of a technical enabler for the ecosystem. Based on the central
node, the operator could offer interoperability among the parties as well as security and trust for the
ecosystem. The operator could also establish further services on top which may be attractive to users.
However, some of the negative points mentioned for centralised systems are still relevant.
3.1.4 Conclusions
Only the hybrid approach fulfils all evaluation criteria (technical complexity, data privacy) for the
Product Identification & Information Network Structure. Therefore a remanufacturing ecosystem with
a central node is assumed as the foundation for the remaining requirements. The central node stores
the identifiers and links of relevant product master data and product lifecycle information.
RIS Remanufacturing Information Service
RIS.PIIN.0 Product Identification & Information Network
Structure
Functional
The Remanufacturing Information Service should be built in a hybrid
structure
o Content should be stored by each stakeholder locally
o A central node should realizes directory service with search, lookup, ID
resolution, mapping, and a retrieval service
o A directory service should store advertisements/annotations that
describe information available at the stakeholders
Table 1: Requirements for the Structure of the PREMANUS Identification & Information Network
3.2 Product & Component Identification & Mapping
In order to make the right remanufacturing decisions for a product, information on the individual
product must be available. This information is composed of:
Product Master Data, such as:
o Product identification
o Product composition into component classes
o Individual components for the component classes
Lifecycle information of a product, such as:
o Service history
o Component replacements
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
17
o Sensor readings, e.g.:
Operating hours
Oil temperature
Oil pressure
Etc.
In order to locate product master data and corresponding lifecycle information, it is important that the
system provides the ability to reference and correlate products by any identifier that may have been
assigned to them, either at the unique ID or product type level.
Today in the manufacturing industry there is no common identifier scheme used across the
companies. Rather each company uses its own identification scheme for products and services. To
make it even more complex, OEMs often use two different identification schemes, one internally and
one externally for customer relations. Accordingly, the specific challenge for remanufacturing is that
although every product ID is unique and relevant to the OEM who has produced it, the ID may not
currently be resolvable by other stakeholders in the manufacturing ecosystem. Hence, PREMANUS
needs to provide some way of resolving IDs across the entire ecosystem, allowing stakeholders to
exchange information about a unique product without changing their internal ID systems. The high-
level requirements for an ID scheme are:
3.2.1 ID Mapping
There are two basic concepts that can resolve the different internal IDs and communication with other
systems in the PREMANUS network. The first is a direct mapping between the unique IDs of each
partner to each other partner‟s IDs. This way each partner always knows by what ID the product is
referred to in each system within PREMANUS. The second alternative is to map each partner‟s ID for
a particular product instance to one common PREMANUS ID which can then be used to request data
from any system connected to PREMANUS.
The mapping strategies are evaluated based on the same criteria used for the evaluation of the network
structure: Commercial soundness of concept, Technical soundness of concept and Business Model
support.
3.2.1.1 Direct ID Mappings
The first of the two alternatives maps each product ID of a partner directly to the product ID in
another partner‟s system, enabling communication between those two partners. This mapping would
have to be repeated for each pair of partners that communicate with each other. Whenever a new
partner joins the network, each participating partner would then need to map their IDs to the new
partner if they wish to use each other‟s information. During communication between two partners, the
internal ID of the first partner can be directly translated into the internal ID of the receiving partner
via the mapping for these two partners.
3.2.1.2 Evaluation
Direct mapping requires a one-to-one mapping from each internal ID of one stakeholder to the
internal ID of another stakeholder for the same product instance. Since the mapping stakeholder has
no idea how the ID of the creating stakeholder is constructed, mapping could be difficult.
Additionally, when using multiple ID schemes created by different stakeholders, there is no guarantee
that an ID is unique. Hence two identical IDs could exist that refer to completely different items,
which is unacceptable and could lead to incorrect recommendations being made by the BDSS.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
18
Additionally direct mapping requires an increasingly large number of mappings, as more stakeholders
join the system. This means that resource usage (both hardware and personnel) increases every time
the system grows. PREMANUS is in essence a system for information sharing, and its usefulness
increases with each information-providing stakeholder. An ID mapping method that grows more
complex with overall system size is in direct conflict with this core concept of PREMANUS. This
leads to the conclusion that direct mapping is not a technically viable approach for ID mapping in
PREMANUS.
3.2.1.3 Central ID Mapping
In a central mapping method, one central ID scheme would exist to which all partners map their
internal IDs. However this internal ID scheme would not intrude on the already existing one and only
exist within the PREMANUS software. Rather PREMANUS would receive the internal ID together
with some key pieces of information required for the mapping and then resolve the ID internal to a
PREMANUS ID. If desired, the PREMANUS ID could be hidden from the client entirely and only
exist within the PREMANUS client and server. All communication within the PREMANUS system
would utilize the central ID and each stakeholder‟s PREMANUS client would resolve the central ID
to their internal ID locally when required. When a new partner joins, only the mapping from their
internal ID to the central ID scheme has to be created.
During communication between two partners, the sending partner will translate their internal ID to the
common PREMANUS ID locally, or if he has no mapping yet, send information to the central ID
resolution service and receive the appropriate PREMANUS ID and then store the internal ID to
PREMANUS ID mapping in his local system. The receiving partner proceeds similarly: either they
already have a mapping for the PREMANUS ID locally, or they request the basic information about
the ID from the PREMANUS ID resolution service and receives the all information necessary to map
the ID to his internal ID if such a product exists in their system.
3.2.1.4 Evaluation
Central mapping involves a comparatively small effort when it comes to mapping a stakeholder‟s
internal ID to the rest of the system, especially compared to direct mapping. Only the new stakeholder
has to create a translation of their internal IDs to the shared ID, with no effort involved for existing
stakeholders. This also means that no knowledge of other stakeholders‟ ID schemes is required.
However, a central system that manages ID resolution requests is required. Since each additional
stakeholder in the system will also increase the number of requests of ID resolution, this central
service will have to grow with the ecosystem, causing increased costs. However, such a central
system is technologically and commercially viable and since no sensitive or stakeholder internal
information is managed by the central system, it is also sound from a business model standpoint.
The reduced effort of joining such an ecosystem in comparison to the direct mapping also means that
new partners will be able to join the ecosystem much more easily, making this approach more
attractive.
3.2.1.5 Conclusions
When considering the three set criteria, Commercial soundness of concept, Technical soundness of
concept and Business Model support, it becomes apparent that central mapping is superior to direct
mapping for PREMANUS. Especially the reduced effort for integrating new stakeholders and the
local encapsulation of internal ID schemes is a key advantage.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
19
3.2.2 ID Resolution
One central question is how a stakeholder can resolve the information that exists for a product
instance within his system into a common ID. This section will look at what information should
typically be available and useable for ID resolution at a stakeholder within the PREMANUS system.
One case is of course, that no information is available at all. However if a stakeholder has absolutely
no information about a product (not even who made it and what it is), there is no possibility of
matching this product instance to a common ID since there are no features that indicate that it is the
same instance that is associated with the common ID.
The most basic information about a product would be who made it and what it is (for example a 1.2
litre V4 diesel engine from manufacturer X). This information is most likely available to all
stakeholders that interact with the product; or at least can be determined by them. This information is
constant which means it is viable to use it to identify the product type as time progresses. However it
is also common to all other product instances of that make and therefore is by itself not enough to
identify a unique instance. It could however be used to map the product instance to a common ID for
the type of product and help in the retrieval of information relevant to all instances of that type
(properties, part lists, construction plans and similar types of data). This does however not include any
information pertaining to the lifecycle of a particular instance, which is one of the key features
required in PREMANUS.
In some cases the product instance will have a unique ID (e.g. an engine number) assigned by the
OEM. If this is the case, this ID could be used to uniquely identify the product instance across time,
provided the ID is not removed from the product and understanding that ID is only (probably) unique
in the OEM/OEM Product. The unique product ID along with information discussed in the previous
paragraph (OEM and product type) could be used to determine a common ID that can be resolved by
all partners that have these key pieces of information (OEM, product type and product ID assigned by
OEM).
Any information about a product instance that is not assigned by the OEM, such as third party IDs or
information about the current state of the instance (such as wear or defects) are subject to change and
could be different as new stakeholders interact with the product instance. If such information was to
be used to establish a resolution to a common ID, it would yield different IDs at different points in
time, which defeats the purpose of the common ID scheme, which is to uniquely identify a product
instance across time and interactions with multiple stakeholders.
3.2.3 Conclusions
In conclusion, PREMANUS will require a common ID that clearly identifies and as such consists of
the three components:
OEM
Product type
Unique product ID.
This conforms to the Uniform Resource Identifier (URI) standard, described in IETF‟s RFC 3986.
Using a specific ID scheme that satisfies these requirements will enable the PREMANUS middleware
to resolve product IDs across the ecosystem along the lifecycle of a product.
This common ID will be managed at a central node where the ID mapping of the ID schemes of
individual parties to the common ID scheme is assigned and administrated. All parties can implement
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
20
and add to their local IT systems a functionality that will execute the ID mapping “Individual party ID
to PREMANUS ID” locally.
Product & Component Identification & Mapping
RIS.PCIM.1 Unique IDs Functional
Each product instance represented in the PREMANUS system should be
uniquely identifiable across all stakeholders
Unique IDs should be used to share information between stakeholders
The unique IDs should be compliant with the URI standard.
RIS.PCIM.2 ID Resolution & Mapping Functional
Each stakeholder should be able to retrieve a PREMANUS ID for a physical
product instance
ID retrieval should be possible with minimal information about the product
ID mappings shall be managed for all stakeholders in the remanufacturing
ecosystem at a central node
Product IDs shall consists of three components
o OEM
o Product type
o Unique product ID
Table 2: Requirements for Product & Component Identification & Mapping
3.3 Search and Lookup Mechanism
The following section distinguishes between lookup and search. A distinction that is frequently made
for distributed systems:
Search is a keyword based search that returns the IDs of content that matches the keywords.
Lookup is the process of determining the location of a piece of content based on its ID.
Thus, in PREMANUS finding a specific document is split into these two steps. First, the document
needs to be described and a “search” in a directory will be performed returning the matching
document IDs. Then the IDs are used to “lookup” the location of the information, i.e. in which
database it is stored.
Based on the previous findings of this section the Search and Lookup mechanisms will work in a
hybrid approach. That is, there is a central node in the ecosystem operated by a third party that
manages ID Mapping and Resolution. Using this functionality, lookups can be performed.
Based on the conclusions for the Product Identification and Information Network (Section 0) it can be
argued that a fully decentralized search is not a viable option for PREMANUS. The search
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
21
functionality should be also implemented on the central node that implements the ID Mapping and
Resolution service. Accordingly this service needs to be extended by information that describes
documents in order to enable search.
In conclusions, the search and lookup functionality will require the project to build the following
process, which is split into a “publish” and a “search” phase:
Figure 6 - Resulting Process for Search and Lookup
The owner of the information relevant to PREMANUS decides if the information shall be made
available to ecosystem partners and to which ones (access policy). The information is described, e.g.
to which individual it relates and what its content is, e.g. a maintenance report. This description is
published in form of an advertisement at the central node that operates the search and lookup
functionality and the ID resolution and ID Mapping service. The ID Mapping service assigns the
PREMANUS ID to the information. A stakeholder searching for the information describes it and
sends the query to the centralized search and lookup service. The search service composes a list of
documents that match the description and access policy. The stakeholder receives a list of potential
results. They select the ones they would like to retrieve. They send a lookup query to the search and
lookup service and receive the access information for the requested documents. The stakeholder now
uses a retrieval service to retrieve the documents.
This overall structure of search and lookup is similar to the functionality which the EPC global
standard “Object Name Service” (ONS) provide together with the discovery service [14] . It also
complies with the requirements deducted for ID Resolution, applying the URI standard.
Table 3 summarizes the requirements for search and lookup of product information.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
22
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.
o Search within the advertisements for product information. The search
result details, which product data can be where and how retrieved.
Table 3: Search and Lookup Requirements
3.4 Distributed Product Information Store (DPIS)
Storing data is needed for the PREMANUS solution, and for many other software applications.
Before specifying the requirements that PREMANUS will have related to the DPIS component, it is
necessary to locate the different points that the development team should focus on. These are the
following:
Types of data
Distributed storage
Amount of data
Semantically enriched content.
All these points are detailed in the following sub-sections. At the end of the section, a table with the
requirements derived from these is published.
3.4.1 Types of data
PREMANUS needs to store data, however it is not the same as storing simple pairs of property-value
than storing documents and linking them to a given content. Thus, it is necessary to store the three
kinds of data presented in the D2.1 document in the section Distributed Product Information Store:
Structured data, like KPIs calculations
Semi-structured data, like the XML files containing the indexes to the stored information
Unstructured data, like PDF, pictures or CAD files.
3.4.2 Distributed storage
In addition to the kind of data, there is a need to store the information that PREMANUS will deal with
in a distributed environment. This is because both the wind turbine farms and car plants are dispersed,
not only in different locations but also in different countries. The DPIS should be effectively
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
23
distributed so the different locations would have their own storage controlling the access to the
information stored locally.
However, this causes another problem: how to access the data which is not controlled by the local
PREMANUS node. This situation may be resolved by developing adapter services to access first the
metadata of the information from remote stores and then retrieve the desired content. Metadata is
accessed first to avoid downloading large volumes of information and later realizing it is not the
information that was required.
3.4.3 Amount of data
Big Data is another point to be considered since there will be large amounts of information coming
from the wind turbine sensors or the different car plants and workshops. Big Data refers to the
massive amounts of data collected over time difficult to be analyzed and handled using common
database management tools. Then, the DPIS component should be able to deal with big amounts of
data coming from those collecting points. As stated in the deliverable D2.1, there are several tools in
the market which might help the PREMANUS project in solving this problem.
3.4.4 Semantic enriched content
The usage of unstructured information implies that the search mechanisms should consider the fact
this information cannot be indexed as easily as the structured information. Within PREMANUS it is
necessary to perform indexing of the unstructured data “manually” using the tools proposed in the
D2.1 document. With this action, it would be possible to retrieve the correct information by using
natural language.
This can be performed by using semantics. Semantics are the bridge between the natural language
used by the potential users and the machine language used by the system to be used, mainly, in the
communications among systems. This bridge is built upon the semantic annotation of the data to be
stored (especially the unstructured data, but also structured data and semi-structured) by attaching
metadata (or simple tags) which would be used by the search engine to enhance search capabilities.
In any case this semantic metadata has to be stored in a semantic storage, as it would be fully
compliant with the project‟s semantic needs, and include, if possible, a searching mechanism of its
own. Furthermore, it would be also necessary to include an indexing service, such as yellow pages, to
grant direct access to the information stored in the different repositories. This is described in Section
3.3.
3.4.5 DPIS Requirements
The following table summarizes the requirements exposed in the previous sections:
Distributed Product Information Store Requirements
RIS.DPIS.1 Distributed Product Information Store Functional
The Distributed Product Information Store (DPIS) stores the information
that is published in first phase of the ID Information Discovery process,
according to the requirements RIS.PIIN.1.
The DPIS is operated on a central node where the distributed IT systems of
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
24
the stakeholder within the remanufacturing ecosystem publish the product
information to, according to the requirements of RIS.
RIS.DPIS.2 Support to structured data Functional
It is necessary to utilize (or develop) a storage capable of providing support to
structured data, like KPI data (properties and values).
RIS.DPIS.3 Support to semi-structured data Functional
It is necessary to utilize (or develop) a storage capable of providing support to semi-
structured data, like the XML files data containing the indexes of the stored
information.
RIS.DPIS.4 Support to unstructured data Functional
It is necessary to utilize (or develop) a storage capable of providing support to
unstructured data, like PDF, pictures or CAD files.
RIS.DPIS.5 Data stored should be easily accessible Functional
The data stored, independently of the storage used and its physical location, should
be easily accessible for local and remote nodes of PREMANUS through the usage of
Web Services.
RIS.DPIS.6 Big amount of data Functional
It is necessary to provide support to the big amount of data coming from the two
user industries. This requires a proper storage capable of both managing the quantity
of data, maintaining the capability of indexing and fast finding and processing.
RIS.DPIS.7 Semantic storage Functional
It is necessary to semantically annotate the data stored to enable natural search
languages and to facilitate the indexing of the mainly unstructured data.
Table 4 - DPIS requirements
3.5 Information Retrieval Mechanism
Once it has been determined that a certain stakeholder has information related to an ID (through the
search and lookup mechanisms discussed above), the querying stakeholder needs the ability to
discover what kinds of information and services they can get from the providing stakeholder. Which
information can be provided and is available might also depend on the querying stakeholder‟s access
rights.
In addition to discovering the information, there also needs to be some system of annotation that
allows the querying stakeholder to make sense of the information and services made available to
them. Ideally this annotation should also support some level of automation (for example automated UI
generation as performed in the project Omelette [15] ). This is especially important for structured data
that is going to be used in the BDSS component. To summarize, the requirements for the information
retrieval are:
To provide a discovery mechanism for available information and services
To annotate information and services with retrieval information so they can be understood by
other stakeholders and possibly used automatically.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
25
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 Location, where the product information can be accesses
o How the product information can be retrieved
o Which further services are available to other PREMANUS stakeholders
An interface is required to retrieve/use the information/services.
Table 5: Information Retrieval Requirements
3.6 Role-based Access Control
Although the primary purpose of the PREMANUS System is to share information, there will always
be some restrictions about who may access specific information within the system. This leads to the
requirement for an access control component to prevent unauthorized access to sensitive information.
This component needs to fulfill the following requirements:
Prevent unauthorized access by authenticating users before allowing access
Enable different levels of access rights for different users
Enable different access requirements for different pieces of information and services
Ensure that user authentication and all other aspects of the access control system are secure
Enable the validation of authentication and integrity of documents
The ideal solution for access control in PREMANUS is a role-based access control system. For a role-
based access system, some more specific requirements can be created: A central service that is
independent of any specific stakeholder should be used for authentication of users and determining
what roles are assigned to the user.
Each stakeholder when receiving a request from a PREMANUS user can query the central
server to retrieve the user‟s roles
Each stakeholder can decide locally what information to make available to whom based on a
user‟s assigned roles. This is called the access policy for a piece of information
Each stakeholder can define new roles and maintain a list of users that are granted each role in
the central service.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
26
4 Requirements for Remanufacturing Services Gateway
According to the previous chapter the PREMANUS Remanufacturing Information Service will
consist of several functional elements that need to communicate with each other and also
communicate with the intelligent component of PREMANUS, the Business Decision Support System.
The Remanufacturing Services Gateway (RSG) is responsible for managing this communication. This
section describes the requirements for building the RSG.
The RSG allows for efficient use of the information managed by the RIS by allowing product centric
collaboration and exposing product data oriented services for EoL product recovery. In addition, the
BDSS will also be connected to the Semantic Service Bus (SSB) and, as such, it will have some
impact on the functionality and the services in the SSB. The RSG will be implemented following
Service Oriented Architectures (SOA) principles, using advances in that area. Support for Web
services and REST (Representational State Transfer) interfaces will allow PREMANUS to create
service compositions, or so-called “mashups”. The RSG will be realized as an extension of the
Enterprise Service Bus (ESB) concept which facilitates seamless distributed connectivity through
binding components and service composition through service components, which may implement a
specific service or logically compose services. To facilitate loose coupling and great concurrency
between different threads, the RSG will communicate via asynchronous message passing, which
means senders can send messages even in the absence of receivers. The RSG will buffer messages and
perform topic-based filtering specified by service consumers.
To help in the search and retrieval of the necessary information as proposed in the RIS component,
there are several core requirements to be fulfilled by the RSG:
Connect: A means to connect the different components so information flows are aligned to
user expectations
Transform: A way to transform the format in which the information is expressed to allow the
different business partners to understand it
Deliver: A mechanism to deliver the information requested in a transparent and timely way
Annotation: The provision of annotation mechanisms and routines so the information can be
searched (and retrieved) according to semantic querying tasks
3rd
party applications: The means to connect with 3rd
party applications and systems through
gateways to get the information and the remanufacturing processes already developed.
This chapter defines the requirements to build and develop the RSG components:
Semantic Service Bus
Infrastructural services:
o Generic services, like Transformation, Mediation, Remanufacturing Specialized
services or Service Composition
o Semantic services, like Annotation and Publishing or connection to Semantic storages
o Gateway services, like the services to connect PREMANUS components, with
Databases, 3rd
party systems and applications, etc.
Other services, like services to access devices and maintenance applications.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
27
4.1 Semantic Service Bus
4.1.1 Introduction
The PREMANUS RSG will be based upon a Semantic Service Bus (SSB) which will be built upon an
Enterprise Service Bus (ESB), annexing semantically enhanced services to allow the content and the
messages to reach their destination. Then, it is a software architecture model used for designing and
implementing the interaction and communication between mutually interacting software applications
in a SOA. This section deals with the requirements to build both the SSB and the semantic services.
The services to be developed need to be semantically orientated as it is necessary to provide
connectivity among different semantic components or semantically enhanced components. As such,
the data storage holds semantically enriched content, the search engine provides the user with a
semantic layer for a better fine tuning of the search results, and so on. The following sections (see 4.2
and 4.3) define the different services to be attached to the ESB in order to transform it into an SSB.
The semantic services are described in section 4.2.2.
The SSB has to support communication between different kinds of components which might be
running on different platforms. Furthermore, the SSB has also to be pluggable into different
topologies, to allow communication between the different companies.
4.1.2 SSB Requirements
The following table shows the main PREMANUS needs on data exchange, message routing and
service technologies regarding the SSB and which should be added.
Semantic Service Bus Requirements
RSG.SSB.1 Orchestration Functional
The usage of Business Workflow Models (BPML) is demanded by PREMANUS final
users, as they already use BPML based engines in their current configurations. This
feature will allow advanced service composition that can be configured at each of the
end users.
RSG.SSB.2 Integration of software components & data
sources
Functional
The integration of software components and other data sources is necessary for the
following reasons:
Allowing component deployment (desirable hot deployment) with component
versioning
Polyglot applications ( .net, java, php, ...)
Minimizing efforts for integration of 3rd
party components (with predefined
adaptors, e.g. XMPP)
In PREMANUS the following kinds of components are envisaged: Distributed
security & access control.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
28
RSG.SSB.3 Message channels and routing Functional
It is necessary to add functionality regarding the processing of composed messages.
With respect to the messaging and routing it is necessary to take into account the
following points:
Point-to-point messaging
Publish-subscribe messaging
Splitter
Aggregator
Content Based Router
Message Filter
Dynamic Router
Recipient List.
RSG.SSB.4 Transport protocol Functional
The ESB must allow different transport protocols in the anchor points for the
applications, as well as transport protocol conversion.
RSG.SSB.5 Connectivity Functional
The ESB must allow different components to be connected e.g.:
Different types of data stores (triple stores, relational, noSQL, XML, etc.)
3rd
party applications (ERP, PLM,...)
User interfaces
Internal functional elements:
o Business Decision Support System
o Unique ID routing mechanism
o Semantic gateway & query mechanism (query decomposition and
routing to specific data stores).
RSG.SSB.6 Execution Functional
A common component execution environment is necessary, that will conform the
PREMANUS node, containing the specific functional components, and the way of
communicating with the rest of components along the PREMANUS environment.
RSG.SSB.7 Support of different topologies Functional
Due to the current status of the project, some generic and open support for different
topologies is needed. Some of the partners see the architecture as a centralize (unique
distributed over the cloud) infrastructure, while some others see it as instances installed
at the final user, and communicated with the rest of instances using a central
coordination point. Flexibility is needed in order to afford both configurations, and to
change from one to another with no or minimal penalty.
RSG.SSB.8 Security Functional
Although the project is not focused on security, some basic authentication and role
based access control is requested. The distributed nature of the architecture makes this
feature implementation challenging and risky from a technology point of view.
Table 6 - SSB requirements
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
29
4.2 Infrastructural Services
The Infrastructural Services are a bunch of cross-cutting services to allow the SSB to get the
necessary information and execute the different processes triggered by the user. These services are
covered in the following sections.
4.2.1 Generic Services
Those services which support other components, and which cannot be classified under other slots, can
be classified as generic services. The functionality provided by the services grouped in this set are
covered in the following sections.
4.2.1.1 Transformation services
Every single organization uses different data types and documents. One solution is that the
organizations involved in a business transaction agree to use a common format. This solution implies
that these organizations should develop transformation engines to allow the translation between the
common format and their internal ones.
Within PREMANUS, when the different information sources are connected to the BDSS, the
information stored in them can be searched and retrieved to satisfy BDSS requests. Once the
information is retrieved, the last step is to store such information in a local storage so the data can be
analyzed for the remanufacturing decision. This requires the transformation [16] of the information
into the structure and format the BDSS will use.
The challenge for the PREMANUS system is to support transformation services also for unstructured
information based on semantic annotation.
4.2.1.2 Mediation services
Since the PREMANUS RSG will be managing the different processes being executed, it is necessary
to develop a set of mediation services to help the SSB when it needs to launch several processes.
4.2.1.3 Remanufacturing Specialized services
These services are ad-hoc services for the remanufacturing industries and their definition will directly
come from the BDSS and from specific existing stakeholder systems; these include existing systems
at CRF and SKF relevant to PREMANUS. Although an overview of these services can be found in
section 2.1.1 for the CRF case and section 2.1.2 for the SKF case, the following list could be
considered as the main services to be developed:
Access and retrieval of data from relevant IT systems with the following aims
Export data for business analysis (e.g. CSV, XML).
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
30
4.2.1.4 Service Composition
Service Composition allows the linking of simpler, more basic services to create larger ones of greater
functionality and complexity. There are two ways to combine services: orchestration and
choreography.
Services orchestration describes an executable process that can interact with itself or other
services. The process flow is controlled by a central coordinator whilst each service itself only
has a local scope and can make decisions only for processes within its scope
Services choreography means that each service has its own task in the total composition.
There is no central program to verify that the task is being implemented correctly.
If the description of the services has its semantics in machine process able form, a process can decide
which service is invoked after it has begun or it can be easier to (manually) design and compose
services. Another advantage of composing services relies on the fact the performance of the system
itself is better given that the output parameters from a particular service are already inserted as input
parameters of a second service and the execution of the action does not wait for human intervention.
Therefore, composition of services improves the performance of the system.
4.2.1.5 Generic services Requirements
The following table summarizes the requirements related to the generic services:
Generic Services Requirements
RSG.GS.1 Transformation services Functional
There must be a mechanism to allow the transformation of different data formats e.g.
XML files or Excel files, are used. This mechanism must be implemented in the SSB.
RSG.GS.2 Mediation services Functional
There must be a mechanism to allow the RSG to select the appropriate process or service
to be executed. This mechanism must be implemented in the SSB.
RSG.GS.3 Composition of services Functional
Composition of services is needed to improve the performance of the system and to
generate larger services by linking smaller services.
Table 7 - Generic Services requirements
4.2.2 Semantic services
Semantic services act as a bridge between the natural language used by the users while they are
interacting with the system. Also, they are used by different systems (or components) to communicate
easily. Within PREMANUS, the purpose of the semantic services is to enable the BDSS and other
components to locate information. This is mainly related to the execution of search and lookup tasks.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
31
4.2.2.1 Services to connect with the Semantic storages
The usage of the semantic storages allows semantically enriched information to be maintained, as
described in section 3.4. This information is used specifically to enable better searching and indexing
of the documents. Usually, these kinds of stores come with interfaces to allow the systems to interact
with each other. However, these APIs only provide basic functionality.
Therefore, it is necessary to extend the SSB with semantic functionality and services. These services
will provide access to the semantic storages in the form of Web Services so the content stored in them
will be accessible by the rest of the components of the PREMANUS architecture in a transparent and
straightforward way.
4.2.2.2 Annotation
Finding data and documentation easily is one of the priorities of the PREMANUS middleware. The
best way to fulfill this need is by annotating the stored data.
This can be done by relating names, attributes, comments, descriptions, etc. within a document or
plain data. These attachments provide additional information about an existing piece of data and are
the metadata to be used by the publishing services.
Therefore, it is necessary for PREMANUS to develop annotation services or makes use of tools which
help the user to prepare the information for the next step in the semantic chain: the publication of the
information.
4.2.2.3 Publishing
These services provide a way for the PREMANUS middleware to understand the structure and, also,
the meaning of the published information. With this action it will be easy to conduct searches for
information (independently from its format) as all the information is correctly published and also will
integrate the different data in a more efficient way. This would be achieved by using metadata (after
the annotation process) to describe the information.
Thus, it is necessary that PREMANUS should develop publishing services to make the information
and the services more accessible to the user and to PREMANUS components.
4.2.2.4 Semantic services requirements
The following table summarizes the requirements related to the semantic services:
Semantic Services Requirements
RSG.SS.1 Access to Semantic storages Functional
It is necessary to access the semantic storages which would have the annotation of the
information stored in other storages.
RSG.SS.2 Annotation Functional
In the case of unstructured content, it is necessary to semantically annotate the data to be
stored so it can be easily found and retrieved.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
32
RSG.SS.3 Publishing Functional
As the PREMANUS middleware is dealing with content and also services offered by the
components, it is necessary to publish them so they can be easily found and retrieved
(content) or executed (services).
RSG.SS.4 Reaching information Functional
The information and the services belonging to different components must be reachable
by every component through the SSB.
Table 8 – Semantic Services requirements
4.2.3 Gateway services
These services act as bridge between the PREMANUS middleware and the external world in the form
of 3rd
party systems. The PREMANUS middleware must be able to interact with many other systems
with different purposes.
4.2.3.1 Services to connect the different PREMANUS components
There are several components within the PREMANUS architecture that need access to data stored in
different repositories (for documents) and databases (for plain data). The BDSS, the ID resolution
module and the Search engine are some of them.
To retrieve information the BDSS would trigger a getDocument(id) function through the SSB. The
SSB will be in charge of connecting the request from the BDSS and the component in charge of
returning back the information.
Like the BDSS, the ID resolution module must have access to the services related to information
recovery and routing.
Finally, the PREMANUS search engine must also have access to services to retrieve information and
to route data from storage to the proper component. In addition to these services, the search engine
also needs indexing services, like yellow pages, where the content is indexed. These indexes allow the
SSB to easily find both component and information.
4.2.3.2 Database as a Service - DaaS (Databases)
The earlier section (Distributed Product Information Store (DPIS)) stated that there is a need to
develop some persistency components able to store all the necessary information produced for and by
PREMANUS. However, there exists much complementary information, like e.g. #oil_changes,
already stored in different in-house databases. PREMANUS also needs to connect to existing
databases, e.g. ERP systems, to retrieve any kind of information required by the BDSS to perform its
calculations. Therefore interfaces are needed to connect with those DBs: in short, Database as a
Service (DaaS).
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
33
4.2.3.3 Application as a Service - AaaS (ERP/PLM connectors)
As specified in the summary of the use cases (see sections 2.1.1 and 2.1.2), the user has 3rd
party
applications such as ERPs or PLMs they would like to connect to PREMANUS. Then, similarly to the
DbaaS components, Application as a Service (AaaS) connectors should be developed to enable these
3rd
party applications to connect and provide new data to the PREMANUS middleware.
4.2.3.4 Connection to external unstructured storages
While in section 4.2.3.2, the connectivity to external databases (outside the PREMANUS architecture)
has been described, this section deals with external unstructured storages. Among these external
storages, PREMANUS should take into account legacy systems which store valuable and sometimes
confidential information in an unstructured format. Consequently, there is a need to access not only
the document but also pieces of it in an efficient and direct way.
Therefore a process is required to semantically annotate the content while importing documents. This
process would increase the chances to find the proper information even when using natural language
searches.
4.2.3.5 Gateway services requirements
The following table summarizes the requirements related to the gateway services:
Gateway Services Requirements
RSG.GWS.1 DBaaS services Functional
The PREMANUS middleware needs to access to external DBs to retrieve the data
required by the BDSS to perform its calculations.
RSG.GWS.2 AaaS services Functional
The PREMANUS middleware needs to communicate and exchange information with
3rd
party applications such as ERPs, PLMs, PCos (Plant Connectivity) like e.g. the
ones utilized by the users… and their associated storages to get the requested
information needed by the BDSS to perform its calculations.
RSG.GWS.3 Connection to external unstructured storages Functional
As in RSG.GWS.1, the PREMANUS middleware needs to access external
unstructured storages to retrieve the data required by the BDSS.
Table 9 - Gateway Services requirements
4.3 Device as a Service, Maintenance as a Service
In order to properly influence remanufacturing decisions, PREMANUS will need comprehensive and
good quality product lifecycle information that must be collected from a product‟s Beginning-of-Life
and Middle-of-Life phases.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
34
Much valuable information about how a product has been used during its life may be dispersed in a
number of different places, especially in maintenance systems that might belong either to the original
manufacturer and authorized or independent service agents. Many of these systems are proprietary in
nature and even in the case where they might implement some kind of industry-specific maintenance
management information standard, the necessary application-specific information still needs to be
extracted and adapted for the kinds of decision processes needed for PREMANUS.
Another vital source of Middle-of-Life information is found in on-board devices that are attached to
or are an inherent part of a product. The ten industrial demonstrator cases of the EU PROMISE
Project [13] highlighted the diversity of such devices and the lack of a consistent information standard
or common interface. The PROMISE Project concluded that it would be virtually impossible to
impose a common cross-industry, cross-platform standard that should be integrated into all such on-
board devices and additional sensor inputs. Therefore it was decided to apply adaptation to existing
information devices and to propose a common means of exchanging the lifecycle information. This
has been continued into the emerging QLM standards proposed to be used by PREMANUS.
Adapter services have been proposed to allow the PREMANUS middleware to retrieve data from pre-
existing information stores, and, in the case of already pre-existing systems, a similar approach for
maintenance systems and on-board devices seems also to be the most pragmatic approach. For new
systems, it would be desirable to encourage the use of QLM standards to generate information output
from these sources.
4.4 Resulting High Level Functional Concept
Based on the requirements of Chapter 3 and this chapter, a high level functional concept for the
PREMANUS architecture can be defined as shown in Figure 7.
Figure 7: Functional Concept of PREMANUS System by Roles
In Chapter 3 it was concluded that a hybrid architecture would be best suited to fulfill PREMANUS‟s
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
35
requirements to search and retrieve information about products within a remanufacturing ecosystem.
Accordingly, there are 3 core functional roles required for PREMANUS:
The PREMANUS node where the Business Decision Support System (BDSS) is operated,
which requires
A local data store (PData Store for PREMANUS Data Store) that holds the
information on which the BDSS calculates its analyses. The data store will use a
specific data structure suitable for PREMANUS (see next chapter for more details).
For successful data import from different information sources a data extract,
transformation and load service (ETL) is required also for the PREMANUS node.
A search engine that enables the BDSS to search and retrieve missing product
information in the remanufacturing ecosystem.
At the ecosystem partners, services are required that allow locating and extracting information
from local information stores. These services are located in the so-called PREMANUS
Gateway. It shall be a non-intrusive component located at a partners‟ data center. The
Gateway will provide
Adapter services that enable PREMANUS to access heterogeneous information
stores. These also implement required security policies via access control
mechanisms.
Annotation services that describe available information and publish that information
at the central RIS node.
Publish-subscribe functionality in order to monitor information stores for relevant
added or changed product information in order to trigger annotation services when
required.
A directory service and an on-demand data import service will be located at a central node.
The directory service requires
An ID Mapping and Resolution Services which enables tracking all information about
a product across its lifecycle and across the ecosystem. For this purpose here a central
PREMANUS ID will be managed for products.
A publish-subscribe service that works together with the PREMANUS Gateway. It
publishes descriptions about product information in the central directory in order to
enable tracking all information about a product across its lifecycle.
A search engine that works together with the search engine at the PREMANUS
BDSS that enables searching the central directory for relevant product information
based on the available descriptions. The search engine will provide to the BDSS these
descriptions together with information on location and access methodology.
As PREMANUS strives to provide a general framework for many different
remanufacturing scenarios, it is meaningful to manage a canonical data structure at
the central node. Then different remanufactures can use an adapted data structure for
customized BDSS algorithms. For this purpose, an ETL service is also meaningful at
the central node. It would transform the information from different partners into a
canonical data structure before it is transmitted to the PREMANUS remanufacturing
node, where the other ETL service transforms and loads the information into the
PREMANUS Data Store.
The Requirements for the Business Decision Support System will be defined in the following chapter.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
36
5 Requirements for Business Decision Support System
PREMANUS BDSS will support remanufacturing plants in the optimization of eco-efficiency of the
entire process. Different remanufacturing options exist for each product entering the remanufacturing
plant as already highlighted in D1.2 and D1.3. The goal of the BDSS is to enable decisions from
different users and actors in the remanufacturing process based on sustainability, viability and
economic worth for each specific product based on product lifecycle information available to the
PREMANUS BDSS.
5.1 Business Decision Support System Foundation
The BDSS requires a technical foundation to build the analyses and algorithms on. This foundation is
a data store for relevant product information
a related data structure that support efficient extraction of structured information required by
the BDSS
A search engine supporting enabling to fill the data store with information distributed across
the remanufacturing ecosystem;
5.1.1 PREMANUS Data Store
As the information to be analysed is distributed across a whole ecosystem, the data first has to be
imported into a local data store, via RIS/RSG, to facilitate processing. In the following, the local data
store is referred to as the PREMANUS Data Store. The BDSS analytic algorithms will access the
PREMANUS Data Store in order to read required data and write generated data to be stored, e.g. data
required for training the BDSS using machine learning mechanisms. Data that is requested by the
BDSS but not available in the PREMANUS Data Store will be searched for via the PREMANUS
Search Engine (see below) and retrieved from the ecosystem using the RIS and RSG.
The data store needs to be secured against unauthorized access via appropriate security mechanisms,
like role based access control.
5.1.2 PREMANUS Data Store’s Data Structure
The PREMANUS Data Store requires implementation of a data structure that efficiently supports the
analyses to be performed. For PREMANUS that is a data structure that represents the relations
between the information pieces that relate to a product. That is the component structure of products
and the lifecycle data collected, such as usage data and service reports. The PROMISE [13] project
researched such a data structure and one outcome of this project is the Open Group‟s Quantum
Lifecycle Management (QLM) standard [19] . Such a data structure can be used as a canonical data
structure for PREMANUS.
The PREMANUS Data Store‟s data structure should comply fully with a standard like QLM while
being customised with the specific usage scenarios. For efficiency reasons QLM is a likely choice.
For customized PREMANUS Data Store‟s data structure also customized transformation services are
likely to be required.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
37
5.1.3 PREMANUS Search Engine
In order to fill the PREMANUS Data Store with information, queries need to be defined that will
retrieve the correct information. As composing the correct queries requires a deep knowledge of the
PREMANUS system, a business user will probably not be able to compose these. Accordingly, a
query composer at user level must be provided that composes the required queries from user input.
The search engine will then store the returned query results in the PREMANUS data store in the form
of the PREMANUS data structure.
Using this technical foundation of PREMANUS Data Store, PREMANUS Data Structure and
PREMANUS Search Engine the different BDSS functionalities can be implemented. These are
described in the following section.
5.1.4 Access to further IT Systems of the Remanufacturer
In order to embed the BDSS into the operational landscape of the remanufacturer the BDSS will need
access to different IT system.
Access to CAD drawings of products and components in order to provide information to the
employee operating the BDSS. This information is typically held in PLM systems.
For assessing the costs of remanufacturing, access to the history of the remanufacturing
operations. This information typically is administered in manufacturing execution systems.
Information on stock level of parts and components. This information is typically
administered in enterprise warehouse systems.
Feedback from the remanufacturing operations on actual remanufacturing costs and duration
in order to improve the BDSS‟ accuracy over time.
5.1.5 Conclusion PPREMANUS Business Decision Support System Foundation
The following table summarizes the requirements for the PREMANUS BDSS foundation.
BDSS Requirements
PREMANUS BDSS should support domain experts who have open-ended,
unstructured and complex problems.
The PREMANUS system should be designed to reduce complexity of
human tasks by structuring, filtering and presenting relevant information in
appropriate ways to support processing of large volumes of data involved in
extensive and recursive decision-making.
BDSS.1 BDSS Data Storage Functional
PREMANUS should provide a local data store at the PREMANUS
Remanufacturing node to run the required analyses.
The BDSS Data Store should store all information needed to prepare a
remanufacturing decision; this information is above all product master data
and product lifecycle information such as usage data, service reports, and
sensor data.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
38
The storage should use a sophisticated data structure, so the analyses
conducted by the BDSS can be performed efficiently and correctly. A
canonical PREMANUS data structure will be used as standard; adaptations
to it to specific use cases must be enabled.
BDSS.2 Data Structure Functional
The analysis of the PREMANUS system should run efficiently and correct
by using sophisticated data structures. A canonical PREMANUS data
structure should be used as standard; adaptations to it to specific use cases
must be enabled.
BDSS.3 Query Composition Functional
PREMANUS should provide a Query Composition user interface for
business users to specify which data is needed for the remanufacturing
decision to be taken.
A Query Composition should compose queries from the user input that the
PREMANUS system can correctly execute, search and retrieve the correct
data from the ecosystem.
BDSS.4 Access to Information and Tracking Activities Functional
PREMANUS system should track all activities at operational level during
the remanufacturing process. This includes input, output and specific
resources.
PLM data, warehouse component‟s stock, customers‟ demand and
expectations should be accessed by the BDSS.
Table 10: BDSS Foundation Requirements
5.2 End-of-Life Product Recovery Process Eco-Efficiency Evaluator
In remanufacturing plants different remanufacturing options typically exist and in particular:
Refurbishment of entire product or specific components
Material recovery, at least for components/materials not having value, or over-stock
Disposal, particularly for hazardous materials, or other kinds of material, which is normal for
certain fractions during remanufacturing process.
Different activities are carried out during the remanufacturing process, as described in D1.3. Such
activities encompass not only operations but also sales and commercial departments – for example, at
plant level they might include inspections, cleaning, disassembly, reassembly, re-painting and so on.
For each activity, specific input (e.g. product or components), expected output (e.g. product, sub-
assemblies, components, …), and resources used (e.g. specific tools, energy, working hours, …) are
all needed to assess the feasibility of the activity.
PLM data for each specific product, as well as boundary conditions such as stock level of components
/sub-assemblies, or customer‟s demand for specific refurbished products, influence the
remanufacturing strategy and operations (e.g. job-order or disassembly or re-assembly process) at
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
39
plant level.
Within the plant different alternatives, options or sequences of activities might exist for the same type
of product (i.e. the engine in the case of CRF or the gearbox for SKF). The remanufacturing process is
influenced by many factors, and the sequence of activities to be carried out might change from
product to product depending on specific boundary conditions, like undiscovered damages, specific
wear status and so on.
Different aspects of the entire remanufacturing process, including evaluation of different strategies or
alternatives need to be taken into account from different perspectives:
Economic evaluations that consider inputs from sales, procurement, remanufacturing
operations
Environmental evaluations, taking into account Life Cycle Assessment (LCA) calculations for
different alternatives
Such elements provide the basis for the BDSS development in WP5.
The combination of economic and environmental dimensions can allow the decision maker and the
user of PREMANUS platform to rank alternatives of remanufacturing strategies and, in case different
options are technically feasible from an operations perspective, decide which is the most suitable one.
Accordingly, the End-of-Life Product Recovery Process Eco-Efficiency Evaluator should provide
information to the user on
The expected ecological eco-efficiency of a remanufacturing strategy, based on
o Generated hazardous/non-hazardous waste
o CO² footprint generated by remanufacturing operations, involved logistical processes,
etc. Different indicators could be used, according to different LCA Impact
Assessment methodologies chosen (e.g. Single score Eco-Indicator 99, CO2
emissions, Damages to Human Health,..) allowing decision makers to use different
perspectives in evaluation of remanufacturing performances.
Other criteria given either by existing regulations (e.g. recovery percentages
according to ELV Directive) or company specific policy (e.g. minimum
salvage benchmark), or specific KPIs (e.g. environmental benefits achieved
over economic resources used in the process, etc.)
The risk of deviation from the expected or benchmarked ecological efficiency, or the main
activities having impact of the remanufacturing performances.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
40
The following table summarizes the main PREMANUS requirements for the End-of-Life Product
Recovery Process Eco-Efficiency Evaluator.
End-of-Life Product Recovery Process Eco-Efficiency Evaluator Requirements
BDSS.5 End-of-Life Product Recovery Process Eco-
Efficiency Evaluator
Functional
PREMANUS should provide evaluation results for:
o Economical evaluations
o Environmental evaluations, taking into account Life Cycle Assessment
(LCA) calculations
o Ecological eco-efficiency evaluation, based on
Generated hazardous/non-hazardous waste
Generated CO2 footprint
o Risk of deviation from the expected or benchmarked ecological
efficiency
Table 11: End-of-Life Product Recovery Process Eco-Efficiency Evaluator Requirements
5.3 KPI Optimizer
The KPI Optimizer is the functional component in the PREMANUS system that provides decision
support to the user based on economic considerations.
From the initial identification in D1.2, KPIs from SKF and CRF can be roughly categorised as:
Financial: Sales, Margin, Variable Costs
Production/Manufacturing Management: Throughput/lead time, Product/component
salvage rate, equipment utilisation
Logistics/Inventory Management: Core grade/mix, WIP cost, Core/product rate
Manufacturing Process: Technical Errors
Quality: Machining and assembly Quality
Purchasing: Component costs
Work Analysis: Time consumed in each phase of operations
Human Resources: Personnel Saturation
Sales: Response time, Success Rate to Offers
This list of KPIs is not exhaustive and only reflects initial interactions with the two remanufacturing
businesses. However, it is sufficient to say that KPI as a business-centred measure will benefit from
the implementation of the PREMANUS information infrastructure, information storage, retrieval and
communication based solutions as well as computerised optimizers. Nevertheless, KPI as indicators
do not prescribe underlying mechanisms that uphold or improve them. To design proper mechanisms,
investigation into remanufacturing decision types is necessary.
The literature survey conducted in D1.1 showed that a remanufacturing decision can belong to a range
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
41
of categories:
Market and Economic Decisions: The decisions related to market positioning and customer/
market interactions in certain remanufacturing industry
Strategic and Life cycle Decisions: The prediction of business financial outcome as well as
other KPIs by planning different product designs and reacting upon different life cycles and
return patterns
Operational Decisions: Inventory management, production planning and scheduling have
been widely adopted in most manufacturing enterprises. They do, however, require new
considerations in dealing with wide ranges of uncertain patterns in remanufacturing
production processes
EoL Decisions: Focus on how End-of-Life products are best processed (e.g. remanufacture,
recondition, repair, recycle, dispose) in terms of certain criteria (financial, environmental,
etc).
All decisions have been studied in certain literatures with particular industrial backgrounds. However,
SKF and CRF have relatively clear situations with regard to their market and strategic decisions. The
main challenges remaining are lifecycle and operational decisions, which are commonly addressed
through planning and control methods such as resource distribution, inventory and production process
planning and control. Since the detail of such optimisation techniques will not be addressed until
WP5, only a few examples will be presented here to demonstrate the types of planning and control
that might be adopted.
Product/Component Salvage Planning and Control: Special planning tools might need to be
developed to maximise product/component salvaging, taking into consideration of market
demand, core/component conditions, values and process cost, stock level, spare price,
personnel and equipment availability and other factors.
Personnel Saturation/Equipment Utilisation Planning and Control: There is also a need to
perform Personnel Saturation/Equipment Utilisation Planning.
Production Process Planning and Work Analysis: These should be performed to enhance
process efficiency and avoid operational errors.
Multi-criteria analysis support: Since most business resources can be measured financially, it
is relatively straightforward to jointly plan product salvaging and equipment utilisation,
although they are different goals. When other factors than financial (for instance, legal, social,
environmental) are taken into account, some multi-criteria optimisation will be necessary.
Although optimisation based planning and control will provide highly sophisticated decision support,
other types of information support will also be needed for decision making. These might include but
not limited to:
Purchasing/Sales support: These roles/departments should be able to gain support by quickly
gathering relevant information and perform numerical synthesis upon them for responsive
decision making.
Financial analysis support: There should be a general tool/interface for plant managers to get
informational and computational support to calculate general financial consequences of
certain major decisions, this might be based on combined solutions of simulation and other
knowledge based mechanisms.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
42
The following table shows the main PREMANUS requirements for the KPI Optimizer.
KPI Optimizer Requirements
BDSS.6 KPIs Calculator Functional
PREMANUS should provide different types of KPIs, that can be configured
in a flexible manner.
KPIs for the different internal stakeholder to the remanufacturing operations
shall be supported.
KPIs, as business centered measures should benefit from implementation of
computerized calculations, given the access of PREMANUS to relevant
information storage databases.
Table 12: KPI Optimizer Requirements
5.4 Human Computer Interaction
5.4.1 User Experience
Complex information systems, such as the Business Decision Support System (BDSS) to be
developed in the PREMANUS project, require a carefully planned and elaborated user interface (UI)
development. Complex systems are those which support domain experts with open-ended,
unstructured and complex problems which include large volumes of data and extensive and recursive
decision-making [6] .
Due to the complexity of the underlying task to be supported, it is very crucial to design the system in
a way that it actually reduces the complexity of the human task by structuring, filtering and presenting
relevant information in an appropriate way. Complex systems differ in some ways from simpler ones
and therefore have specific UI requirements which will be discussed later in this section. First, some
basic UI design guidelines are presented which are applicable to all kinds of interactive systems.
Ensuring a good UI design by drawing on general, well-established design guidelines can be seen as a
basis and a prerequisite for the further designing of a complex and information-intense system.
Designing for a good usability of a system can be supported by constantly keeping design principles
in mind and iteratively evaluating the system against these principles during the development of the
system. A well-established set of design principles, also called heuristics, was developed by Nielsen
[5] . The ten heuristics, which can be perceived as overarching requirements, are a guide to good
interaction design and help enhancing the usability of a system:
Visibility of system status. The system should always keep users informed about what is
going on, through appropriate feedback within reasonable time
Match between system and the real world. The system should speak the users' language,
with words, phrases and concepts familiar to the user, rather than system-oriented terms.
Follow real-world conventions, making information appear in a natural and logical order
User control and freedom. Users often choose system functions by mistake and will need a
clearly marked "emergency exit" to leave the unwanted state without having to go through an
extended dialogue. Support undo and redo
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
43
Consistency and standards. Users should not have to wonder whether different words,
situations, or actions mean the same thing. Follow platform conventions
Error prevention. Even better than good error messages is a careful design which prevents a
problem from occurring in the first place. Either eliminate error-prone conditions or check for
them and present users with a confirmation option before they commit to the action
Recognition rather than recall. Minimize the user's memory load by making objects,
actions, and options visible. The user should not have to remember information from one part
of the dialogue to another. Instructions for use of the system should be visible or easily
retrievable whenever appropriate
Flexibility and efficiency of use. Accelerators -- unseen by the novice user -- may often
speed up the interaction for the expert user such that the system can cater to both
inexperienced and experienced users. Allow users to tailor frequent actions
Aesthetic and minimalist design. Dialogues should not contain information which is
irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the
relevant units of information and diminishes their relative visibility
Help users recognize, diagnose, and recover from errors. Error messages should be
expressed in plain language (no codes), precisely indicate the problem, and constructively
suggest a solution
Help and documentation. Even though it is better if the system can be used without
documentation, it may be necessary to provide help and documentation. Any such information
should be easy to search, focused on the user's task, list concrete steps to be carried out, and
not be too large.
Conducting heuristic evaluations on system prototypes is a quick, cheap, and easy evaluation of a user
interface design. It is a helpful method for rapid iterative prototyping, especially in development cases
with difficult access to the real end-users. Within the PREMANUS project, the end users are a very
specific user group difficult to access for personal evaluations. Heuristic evaluations are therefore
planned for the evaluation of the system interspersed with end-user tests.
5.4.2 Complex Systems – BDSS-specific
As already mentioned, complex interactive systems differ from the world of well-structured tasks in
many ways. Redish [7] collected a set of attributes specific to complex interactive systems, which
helps to understand the specific requirements for the design of these systems. Based on his work and
further literature research, a list of additional principles specifically useful for the design of complex
systems is presented in the following.
Avoid information overload. In complex interactive systems, such as the PREMANUS BDSS,
information overload is endemic. Such systems risk forcing the user to sift through more information
than he can deal with. The human is a “limited-capacity information processor” [20] and therefore, it
is very crucial to minimize the amount of data to be processed by the human without affecting the
quality of decision making. One basic way to handle the presentation of complex information is
Schneiderman‟s mantra of “overview first, zooms and filters, details on demand”. By applying this
heuristic during the interaction design, the amount of data to be processed in every single interaction
step is reduced. Information can be “chunked” and processed sequentially without overcharging the
user.
A concrete design guideline drawn from this principle is the provision of a visually discrete
multi-level menu structure (e.g. a primary, secondary and tertiary menu placed on different
screen locations). In the BDSS, such a bundling can be done on the level of KPI abstraction,
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
44
e.g. grouping the KPIs in high-, medium- and low-level of detail families. By this, the levels
of hierarchies which need to be kept in mind during navigation through the system is reduced.
If the chunks of information (e.g. the bundling of KPIs) is done in a (for the user) meaningful
way, information can be found and processed easier.
Reduce cognitive overload by data visualization. Data analysis and recursive decision-making are
cognitively very burdensome; people have little cognitive workload available for dealing with huge
amounts of unstructured data. A very effective way to avoid cognitive load for the processing of
complex data is the graphical visualization of data (e.g. [8] ). There are many methods to facilitate
learning and cognitive processing of complex data, e.g. using three-dimensional representations rather
than two-dimensional, color-coding of information objects or information classes, using animated
diagrams to e.g. visualize processes, providing interactive graphics to allow the exploration of data,
and many more.
In the context of the BDSS, the highest cognitive load will be demanded in the final decision
phase. Here, all information gathered and analyzed beforehand needs to be integrated to draw
the “big picture”. In this phase, a support by comprehensive and intuitive graphics is crucial.
These graphics furthermore need to be interactive, since the user might want to change some
parameters leading to the calculated „outcome‟ and see in real time how relevant key figures
are affected.
Design for learnability. The users of BDSSs are typically domain experts. However, they may not be
computer or systems experts. The demands of their work may make it difficult for them to put much
time or effort into the learning curve of new programs or new presentation methods. A simple and
easy to use interface is therefore twice as important.
To achieve a fast learnability of the system, several aspects have to be considered. First,
although the system is a very specific kind of software, it relies on common controls, labels,
wordings and UI elements placement. Second, the system needs to provide help functions.
Uncommon controls and functions should come along with a callable description about their
scope and functionality. Third, continuous cross-checking with the end-users is a must.
Allow adaptability and personalization. From the point of view of interaction design, this is one of
the most frequently mentioned requirements for Decision Support Systems ([9] [10] , [11] ). These
systems are usually used by different users with different roles and responsibilities. It is very
important to respond to the unique requests of individual end-users. The system must be adaptable to
the various styles, needs and roles of different users. Thus, the system must provide the possibility to
personalize different aspects of the interface, e.g. the configuration of menus and the process of
information seeking.
Two concrete design decisions can be drawn from this principle. First, the system must come
with a predefined configuration (e.g. of interface elements and menu points) for different user
roles (e.g. the plant manager, the disassembly manager, the sales person etc.). The pre-
configuration needs to be carefully validated by prior end-user feedback. More importantly,
these pre-configurations need to be adaptable easily. E.g. the user needs to be able to adapt
the KPIs which are included in the final calculation / decision. As another example, the users
should be able to chunk relevant KPIs into their own, meaningful patterns (i.e. information
from different sources are grouped and presented in predefined menu points but need to be
adaptively displaceable to freely selected menu points to allow a personally meaningful
information grouping).
Design for consistency. In complex systems, users have to process a lot of information and orient
themselves in a large a menu structure which is possibly hard to overlook. Every additional cognitive
demand, e.g. induced by an inconsistent wording, layout or other design factors, needs to be avoided.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
45
A consistent interface design, e.g. where the same commands or menu entries can always be found at
the same place, is very crucial for complex information systems ([9] ). Before the interface of
PREMANUS is designed, a design guideline should be created.
Work in a user-centered design process. The PREMANUS BDSS is designed for domain experts,
e.g. users with specific knowledge and their specific ways of decision taking. Knowing the end-users
requirements is especially crucial for such a specific group of end-users. Taking a user-centered
design in the development of the system is therefore very beneficial to the usefulness and ease of use
of the system. It has been shown that a greater participation of the end-users in the development and
implementation process of a BDSS has a positive effect on use of and satisfaction with the system
([12] ). As an example for specific needs, according to [6] , the trickiest aspect of designing complex
problem-solving systems is finding the appropriate level for analysis. Usefulness is maximized when
the level at which users define and “chunk” their information entities and work processes is met. A
user-centered approach that involves the end-users continuously in design decisions is appropriate.
The design principles listed here guide the whole process of prototyping and implementing of the
BDSS. Each design decision will be cross-checked with these principles. As much feedback as
possible will be gathered from the end-users to ensure a good usability, usefulness and quality of the
system.
5.4.3 Process flexibility: Control and coordination by task-centred information
systems and business processes
Business process management (workflow management) systems and task management systems
represent software that is intended to support the control and coordination of value delivering
processes in companies. For PREMANUS the use cases that have been identified for SKF and CRF
need to be supported by the control and coordination capabilities of the software (for a description of
the use cases, see D1.3).
Control and coordination is realized based on the externalization of goals and process knowledge.
Existing systems can be distinguished among their formalization degree: a) Data-centric approaches,
b) Task-centric approaches and c) Process-centric approaches (see Figure 9). Data-centric approaches
are coordination and control agnostic, as they offer a set of functionalities to interact with data without
goal or process notion. In the following, task and process-centric approaches are presented. Then their
appropriateness for PREMANUS is discussed. Appropriateness needs to address: a) Flexibility
requirements for the use cases and b) Integration of SKF and CRF requirements in business processes.
5.4.3.1 Task-centric approaches: Task management systems
Task or To-do management systems provide capabilities to externalize individual goals as tasks.
Tasks comprise a goal, an anticipated execution process and triggers for the realization process.
Triggers may be time or location. Tasks as externalized goals especially support processes of work
organization:
Delegation of tasks among groups
Sequencing of execution processes
Tracking of progress and spent resources.
In this sense, task management systems especially support the prospective memory of individuals and
groups. Although, the execution process for tasks is underspecified, different methods to provide
process knowledge for recurring tasks (task similarity is based on goal similarity) have emerged. One
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
46
example is task patterns. Task patterns are collectors of execution process related information that can
be accessed when a user works on a task.
5.4.3.2 Process-centric approaches: Business processes management/Workflow management
Process-centric approaches formalize execution processes to a high degree. The most popular
realization is given with business process management systems that control and coordinate the
execution of a value adding activity among different parties in one or several organizations.
Different process notations have evolved that often support the structured transformation of a business
perspective towards a process to an executable process in an IT-system. The quasi industry standard is
BPMN [17] with 59 OMG listed implementations. It was introduced in 2002 with the aim of
providing a graphical notion that is easy to use for business analysts. BPMN 2.0 addresses
shortcoming of BPMN 1.1 by standardized execution semantics, serialization and support for cross-
organizational scenarios. OMG's BPMN2 specification aims at unifying business and IT needs across
industries in one notation.
The high degree of formalization not always suites the requirements of processes that are executed in
environments that contain uncertainty with respect to effects or with respect to required activities.
Both complicate a static view on organizational processes as predefined entities that are executed.
To address uncertainty with respect to activities task-centric information systems with additional
capabilities for knowledge management, like task pattern are a promising direction. To address
uncertainty with respect to effects of events on business processes, flexibilization of business
processes has emerged as research domain.
“The generic term workflow flexibility comprises a large variety of features discussed in industry and
research. On a coarse granular level, two main flexibility types and their associated challenges can
be identified. Design time flexibility aims at supporting the definition of multiple allowed execution
traces depending on context conditions, i.e. workflow variants, before an instance has been started.
Traditional WfMS typically only allow for a one-by-one modeling of variants and therefore foster the
creation of redundant and hardly maintainable business logic. Runtime flexibility aims at changing
the course of a workflow instance after it has been started in a way that it does not necessarily
correspond to the underlying model anymore, for example due to unforeseen context changes.” [18]
These demands have been addressed by identifying adaptation patterns for business processes [18]
that improve error management and integration of time constraints. Döhring has proposed a rule based
integration of adaptation patterns into workflows based on an extended notion of BPMN 2.0. Overall,
existing work on business flexibilization exists on research level, not yet on product level.
5.4.3.3 Conclusion: Support type for execution processes
Flexibility requirements: Deliverable 1.3 highlights a demand for flexibility (see D1.3, p.8).
There is a core decision process, to limit uncertainty with respect to the execution and
outcome of the remanufacturing process. Due to different availability of information about a
product and different degrees of expertise regarding the product to be remanufactured, many
decisions are taken within the respective processes. A formalization of the flexibility demand
requires elaborate flexibilization techniques. As described, such techniques are currently
subject to intensive research, but not yet productized
Integration of SKF and CRF requirements in business processes. Although SKF and CRF
share a base use case – the remanufacturing decision – the actual use cases significantly
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
47
differ. SKF addresses remanufacturing of gearboxes from the entire market (GRBQUOTE,
DISASSGRB, REMANU scenarios) whereas CRF addresses engines from the CRF family
(EGNPLT, RMNOPT, ASSOPR scenarios). These use cases are based on different
information availability and are differently embedded in the enclosing business of the
company. Although the use cases and the respective scenarios are comparable, they would
require different business processes which complicate the maintenance of the processes and
their validation.
Overall, task-centric approaches seem to be more suitable to address the flexibility requirement and
the differences between the use cases.
The following table summarizes the PREMANUS requirements for Human Computer Interactions of
the BDSS.
Human Computer Interaction Requirements
BDSS.7 Information Set Non-functional
The amount of data to be processed by a human should be minimized
without affecting the quality of decision making.
PREMANUS should reduce the amount of data processed in every single
step by first an overview shall be provided, then zooming and filtering,
showing details on demand.
BDSS.8 Data visualization Non-functional
PREMANUS should avoid cognitive load for processing information by
using graphical visualization of data, three-dimensional representations,
color-coding, animated diagrams, interactive graphics and other tools to
allow exploration of data.
BDSS.9 Learnability Non-functional
User Interfaces should allow for easy use and stick to common controls,
labels, wording and element‟s placement as users of BDSS might not be
systems experts.
BDSS.10 Personalization Non-functional
The system should be adaptable to various styles, needs and roles because
users will have different roles and responsibilities.
Personalization of UI, configuration of menus and process for information
seeking should be allowed.
BDSS.11 Consistency Non-functional
PREMANUS UI design should allow users to find command and user
interface elements in the same place
Table 13: Human Computer Interaction Requirements
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
48
6 Summary of Requirements
A functional concept for PREMANUS has been derived from the requirements of the
Remanufacturing Information Service, the Remanufacturing Service Gateway, and the Business
Decision Support System. This is summarized below:
Central cloud component
o Offering a “directory service” that stores “advertisement” (annotations) of content
What is the content? (QLM based)
What is the format?
Where is it?
How can it be accessed?
What is the access policy?
o Search happens against this directory service
o Product ID Management and Mapping
Required for mapping information like service reports to the right product
instances
Required for information generated at different stakeholders for the same
product, or product changing owners, etc.
Gateway at ecosystem partner, non-intrusive to on-premise IT.
o Using a pub-sub approach to
Generate advertisement for each content, that should be available to the
ecosystem
Publish the advertisements to the directory service
Manage access control to content
Adapter service connecting to local storage systems
Annotator service generating the advertisements
Pub/sub monitoring updates of content and added content
o Transformation service:
transforming content from local format to QLM
- BDSS component
o QLM base storage
o BDSS application(s)
o Transformation service
transforming content from local format to local customized QLM format (for
optimized BDSS)
o User Interface elements (gadgets)
Figure 8 shows the requirements that need to be addressed by a PREMANUS architecture.
Three main technical roles are relevant in PREMANUS:
The Remanufacturing Information Service (RIS) being responsible for enabling search of
relevant information and enabling to track a product across different stakeholders along its
lifecycle
The Remanufacturing Service Gateway (RSG) being responsible for communication between
functional modules and enabling information extraction and import to the PREMANUS
Business Decision Support System from heterogeneous information sources (like databases
and content types) via adapter services and semantic services
The PREMANUS Business Decision Support System.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
49
Figure 8 - PREMANUS Architectural Concepts according to Functional Roles
The following table summarizes the requirements per core component.
ID Name Category
GTR General Technical Requirements
The PREMANUS system should be modular
The interfaces should be based on open standards
The BDSS should be able to interact, through standardized interfaces, with
also other systems
The PREMANUS system should be cloud ready.
RIS Remanufacturing Information Service Functional
RIS.PIIN.0 Product Identification & Information Network
Structure
Functional
The Remanufacturing Information Service should be built in a hybrid
structure
o Content should be stored by each stakeholder locally
o A central node should realizes directory service with search, lookup,
ID resolution, mapping, and a retrieval service
o A directory service should store advertisements that describe
information available at the stakeholders
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
50
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.
o Search within the advertisements for product information. The
search result details, which product data can be where and how
retrieved.
RIS.PIIN.2 Information Retrieval Functional
Once relevant information have been identified, annotations to this
information will provide the
o Location, where the product information can be accesses
o How the product information can be retrieved
o Which further services are available to other PREMANUS stakeholders
An interface is required to retrieve/use the information/services.
RIS.PIIN.3 Information Transformation Functional
RIS should manage a canonical data structure to support import from
heterogeneous information sources into PREMANUS by a transformation
service.
The transformation service should enable simple information processing into
the BDSS.
RIS.PCIM.1 Unique IDs Functional
Each product instance represented in the PREMANUS system should be
uniquely identifiable across all stakeholders
Unique IDs should be used to share information between stakeholders
RIS.PCIM.2 ID Resolution & Mapping Functional
Each stakeholder should be able to retrieve a PREMANUS ID for a physical
product instance
ID retrieval should be possible with minimal information about the product
ID mappings shall be managed for all stakeholders in the remanufacturing
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
51
ecosystem at a central node
Product IDs shall consists of three components
o OEM
o Product type
o Unique product ID
The overall structure of search and lookup shall comply with the EPC
Global standard “Object Name Service” (ONS).
RIS.DPIS.1 Distributed Product Information Store Functional
The Distributed Product Information Store (DPIS) stores the information
that is published in first phase of the ID Information Discovery process,
according to the requirements RIS.PIIN.1.
The DPIS is operated on a central node where the distributed IT systems of
the stakeholder within the remanufacturing ecosystem publish the product
information to, according to the requirements of RIS.
RIS.DPIS.2 Support to structured data Functional
It is necessary to utilize (or develop) a storage capable of providing support
to structured data, like KPI data (properties and values).
RIS.DPIS.3 Support to semi-structured data Functional
It is necessary to utilize (or develop) a storage capable of providing support
to semi-structured data, like the XML files data containing the indexes of the
stored information.
RIS.DPIS.4 Support to unstructured data Functional
It is necessary to utilize (or develop) a storage capable of providing support
to unstructured data, like PDF, pictures or CAD files.
RIS.DPIS.5 Data stored should be easily accessible Functional
The data stored, independently of the storage used and its physical location,
should be easily accessible for local and remote nodes of PREMANUS
through the usage of Web Services.
RIS.DPIS.6 Big amount of data Functional
It is necessary to provide support to the big amount of data coming from the
two user industries. This requires a proper storage capable of both managing
the quantity of data, maintaining the capability of indexing and fast finding
and processing.
RIS.DPIS.7 Semantic storage Functional
It is necessary to semantically annotate the data stored to enable natural
search languages and to facilitate the indexing of the mainly unstructured
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
52
data.
RIS.RBAC.1 Authentication Functional
Authentication procedure should exist.
Authentication procedures should avoid access of confidential information
by non-authorized people.
The authentication mechanism should check for every single access to a
given data/document.
However, there should also exist an administrator role to grant access to the
different users.
RSG Remanufacturing Services Gateway
PREMANUS needs to have the different components connected in a
homogeny and transparent way to the user and to the other components.
RSG.SSB.1 Orchestration Functional
The usage of Business Workflow Models (BPML) is demanded by
PREMANUS final users, as they already use BPML based engines in their
current configurations. This feature will allow advanced service composition
that can be configured at each of the end users.
RSG.SSB.2 Integration of software components & data
sources
Functional
The integration of software components and other data sources is necessary for the
following reasons:
Allowing component deployment (desirable hot deployment) with
component versioning
Polyglot applications ( .net, java, php, ...)
Minimizing efforts for integration of 3rd
party components (with predefined
adaptors, e.g. XMPP)
In PREMANUS the following kinds of components are envisaged:
Distributed security & access control.
RSG.SSB.3 Message channels and routing Functional
It is necessary to add functionality regarding the processing of composed
messages. With respect to the messaging and routing it is necessary to take
into account the following points:
o Point-to-point messaging
o Publish-subscribe messaging
o Splitter
o Aggregator
o Content Based Router
o Message Filter
o Dynamic Router
o Recipient List.
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
53
RSG.SSB.4 Transport protocol Functional
The ESB must allow different transport protocols in the anchor points for
the applications, as well as transport protocol conversion.
RSG.SSB.5 Connectivity Functional
The ESB must allow different components to be connected e.g.:
o Different types of data stores (triple stores, relational, noSQL, XML,
etc.)
o 3rd
party applications (ERP, PLM,...)
o User interfaces
o Internal functional elements:
Business Decision Support System
Unique ID routing mechanism
Semantic gateway & query mechanism (query decomposition and
routing to specific data stores).
RSG.SSB.6 Execution Functional
A common component execution environment is necessary, that will
conform the PREMANUS node, containing the specific functional
components, and the way of communicating with the rest of components
along the PREMANUS environment.
RSG.SSB.7 Support of different topologies Functional
Due to the current status of the project, some generic and open support for
different topologies is needed. Some of the partners see the architecture as a
centralize (unique distributed over the cloud) infrastructure, while some
others see it as instances installed at the final user, and communicated with
the rest of instances using a central coordination point.
Flexibility is needed in order to afford both configurations, and to change
from one to another with no or minimal penalty.
RSG.SSB.8 Security Functional
Although the project is not focused on security, some basic authentication
and role based access control is requested. The distributed nature of the
architecture makes this feature implementation challenging and risky from a
technology point of view.
RSG.GS.1 Transformation services Functional
There must be a mechanism to allow the transformation of different data
formats e.g. XML files or Excel files, are used. This mechanism must be
implemented in the SSB.
RSG.GS.2 Mediation services Functional
There must be a mechanism to allow the RSG to select the appropriate
process or service to be executed. This mechanism must be implemented in
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
54
the SSB.
RSG.GS.3 Composition of services Functional
Composition of services is needed to improve the performance of the system
and to generate larger services by linking smaller services.
RSG.SS.1 Access to Semantic storages Functional
It is necessary to access the semantic storages which would have the
annotation of the information stored in other storages.
RSG.SS.2 Annotation Functional
In the case of unstructured content, it is necessary to semantically annotate
the data to be stored so it can be easily found and retrieved.
RSG.SS.3 Publishing Functional
As the PREMANUS middleware is dealing with content and also services
offered by the components, it is necessary to publish them so they can be
easily found and retrieved (content) or executed (services).
RSG.SS.4 Reaching information Functional
The information and the services belonging to different components must be
reachable by every component through the SSB.
RSG.GWS.1 DbaaS services Functional
The PREMANUS middleware needs to access to external DBs to retrieve
the data required by the BDSS to perform its calculations.
RSG.GWS.2 AaaS services Functional
The PREMANUS middleware needs to communicate and exchange
information with 3rd
party applications such as ERPs, PLMs, PCos (Plant
Connectivity) like e.g. the ones utilized by the users… and their associated
storages to get the requested information needed by the BDSS to perform its
calculations.
RSG.GWS.3 Connection to external unstructured storages Functional
As in RSG.GWS.1, the PREMANUS middleware needs to access external
unstructured storages to retrieve the data required by the BDSS.
BDSS Business Decision Support System Functional
PREMANUS BDSS should support domain experts who have open-ended,
unstructured and complex problems.
The PREMANUS system should be designed to reduce complexity of
human tasks by structuring, filtering and presenting relevant information in
appropriate ways to support processing of large volumes of data involved in
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
55
extensive and recursive decision-making.
BDSS.1 BDSS Data Storage Functional
PREMANUS should provide a local data store at the PREMANUS
Remanufacturing node to run the required analyses.
The BDSS Data Store should store all information needed to prepare a
remanufacturing decision; this information is above all product master data
and product lifecycle information such as usage data, service reports, and
sensor data.
The storage should use a sophisticated data structure, so the analyses
conducted by the BDSS can be performed efficiently and correctly. A
canonical PREMANUS data structure will be used as standard, adaptations
to it to specific use cases must be enabled.
BDSS.2 Data Structure Functional
The analysis of the PREMANUS system should run efficiently and correct
by using sophisticated data structures. A canonical PREMANUS data
structure should be used as standard; adaptations to it to specific use cases
must be enabled.
BDSS.3 Query Composition Functional
PREMANUS should provide a Query Composition user interface for
business users to specify which data is needed for the remanufacturing
decision to be taken.
A Query Composition should compose queries from the user input that the
PREMANUS system can correctly execute, search and retrieve the correct
data from the ecosystem.
BDSS.4 Access to Information and tracking activities Functional
PREMANUS system should track all activities at operational level during
the remanufacturing process. This includes input, output and specific
resources.
PLM data, warehouse component‟s stock, customers‟ demand and
expectations should be accessed by the BDSS.
BDSS.5 End-of-Life Product Recovery Process Eco-
Efficiency Evaluator
Functional
PREMANUS should provide evaluation results for:
o Economical evaluations
o Environmental evaluations, taking into account Life Cycle Assessment
(LCA) calculations
o Ecological eco-efficiency evaluation, based on
Generated hazardous/non-hazardous waste
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
56
Generated CO2 footprint
o Risk of deviation from the expected or benchmarked ecological
efficiency
BDSS.5 KPIs Calculator Functional
PREMANUS should provide different types of KPIs that can be configured
in a flexible manner.
KPIs for the different internal stakeholder to the remanufacturing operations
shall be supported.
KPIs, as business centered measures should benefit from implementation of
computerized calculations, given the access of PREMANUS to relevant
information storage databases.
BDSS.6 Information set Non-functional
The amount of data to be processed by a human should be minimized
without affecting the quality of decision making.
PREMANUS should reduce the amount of data processed in every single
step by first an overview shall be provided, then zooming and filtering,
showing details on demand.
BDSS.7 Data visualization Non-functional
PREMANUS should avoid cognitive load for processing information by
using graphical visualization of data, three-dimensional representations,
color-coding, animated diagrams, interactive graphics and other tools to
allow exploration of data.
BDSS.8 Learnability Non-functional
User Interfaces should allow for easy use and stick to common controls,
labels, wording and element‟s placement as users of BDSS might not be
systems experts.
BDSS.9 Personalization Non-functional
The system should be adaptable to various styles, needs and roles because
users will have different roles and responsibilities.
Personalization of UI, configuration of menus and process for information
seeking should be allowed.
BDSS.10 Consistency Non-functional
PREMANUS UI design should allow users to find command and user
interface elements in the same place
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
57
7 Appendix A: References
[1] http://en.wikipedia.org/wiki/Overlay_network
[2] http://en.wikipedia.org/wiki/Peer-to-peer
[3] Ralf Steinmetz, Klaus Wehrle (Eds): Peer-to-Peer Systems and Applications, LNCS 3485,
Springer, 2005
[4] http://en.wikipedia.org/wiki/BitTorrent_(protocol)
[5] Nielsen, J. (1994b). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability
Inspection Methods, John Wiley & Sons, New York, NY.
[6] Mirel, B. (2003) Dynamic usability: Designing usefulness into systems for complex tasks, in
M. J. Albers and B. Mazur (Eds.), Content and Complexity: Information Design in Technical
Communication, Mahwah, NJ: Lawrence Erlbaum Associates, pp. 233-262.
[7] J. Redish. Expanding usability testing to evaluate complex systems. Journal of Usability
Studies, 2(3):102–111, 2007.
[8] SCAIFE, M., AND ROGERS, Y. 1996. External cognition: How do graphical representations
work? International Journal of Human-Computer Studies 45, 185–213.
[9] Sankar C.S., F. Nelson, M. Bauer, 1995, „A DSS user interface model to provide consistency
and adaptability‟, Decision Support Systems, 13, 93-104
[10] Wierenga, B., Oude Ophuis, P.A.M., 1997. Marketing decision support systems: Adoption,
use and satisfaction. International Journal of Research and Marketing 14, 275-290.
[11] Maciag, T., Hepting, D.H., Slezak, D.: Personalizing User Interfaces for Environmental
Decision Support Systems. In Proc. Rough Sets and Soft Computing in Intelligent Agent and
Web Technology (2005)
[12] Parker, C., & Sinclair, M. (2001). User-centered design does make a difference. The case of
decision support systems in crop production. Behaviour & Information Technology, 6, 449–
460.
[13] European PROMISE Project (FP6-IST project No. IST-2004-507100).
http://www.promise.no/
[14] Global Standards: Object Name Service. http://www.gs1.org/gsmp/kc/epcglobal/ons/
[15] EU Project Omlette. http://www.ict-omelette.eu/home
[16] Wikipedia: Extract, transform, load. http://en.wikipedia.org/wiki/Extract,_transform,_load
[17] Object Management Group (OMG): Business Process Model and Notation.
http://www.bpmn.org/
[18] Döhring, M. and Zimmermann, B. and Karg, L. (2011): Flexible workflows at design-and
runtime using BPMN2 adaptation patterns, Business Information Systems
[19] The Open Group: The Quantum Lifecycle Management Standard.
https://collaboration.opengroup.org/qlm/
[20] Payne, J. W., Bettman, J. R. & Johnson, E. J. (1993). The adaptive decision maker.
Cambridge, England: Cambridge University Press.
[21] Wikipedia: Uniform Resource Identifier.
http://de.wikipedia.org/wiki/Uniform_Resource_Identifier
Project –No
Date
Classification
285541
16-July-12
PU D2.2 - REQUIREMENTS ANALYSIS SPECIFICATION
58
[22] IETF: RFC 3986. http://tools.ietf.org/html/rfc3986