D2.4 v1.0 Out

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.4 - LIVING ARCHITECTURE
Work Package Lead Partner Contributing Partner(s) Security Classification Date Version
WP2 Reference Architecture for PREMANUS SAP POLIMI, LBORO, TIE, SKF, CRF, EPL PU 31.08.2013 1.0
COPYRIGHT
Copyright 2013 by PREMANUS partner organisations
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. The circulation of this document is restricted to the staff of the PREMANUS partner organisations and the European Commission. All information contained in this document is strictly confidential and may not be divulged to third parties without the express permission of all of the Copyright owners. All rights reserved. This document may change without notice.
The PREMANUS project (285541) is co-funded by the European Union under the Information and Communication Technologies (ICT) theme of the 7th Framework Programme for R&D (FP7). This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of its content.
Project No Date Classification
285541 31-Aug-13 PU
D2.4 LIVING ARCHITECTURE
Document history
Version 0 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10 0.11 0.12 0.13 0.91 0.92 1.0 Date 14/03/12 03/09/12 17/09/12 24/09/12 08/10/12 09/11/12 27/11/12 30/11/12 14/12/12 31/01/13 05/13/13 06/4/13 06/27/13 20/08/13 27/08/13 29/08/13 12/09/13 Comments ToC Added results from Darmstadt meeting and reworked ToC Added chapter 2.3 Revised chapter 2 Restructured Document Continuous rework of outline and chapter 2 Additions to Chapter 2.1 and 2.2 Additions to Chapter 2.4 Additions to Chapter 3.2 and 3.3 Finalization of Chapter 3 (except ID Mgmt) Author Tobias Wieschnowsky (SAP) Tobias Wieschnowsky (SAP) Tobias Wieschnowsky (SAP) Tobias Wieschnowsky (SAP) Tobias Wieschnowsky (SAP) Tobias Wieschnowsky (SAP) Benedikt Schmidt (SAP) Tobias Wieschnowsky (SAP) Oscar Garcia (TIE) Oscar Garcia (TIE)
Standardization Chapter added and additions to some of the Tobias Wieschnowsky (SAP) existing chapters Expansion of Standardization Chapter Preparation for SAP Handover Full Content Review Resolving last review issues Resolving last review issues Version submitted with final layout Tobias Wieschnowsky (SAP) Tobias Wieschnowsky (SAP) David Potter (Polimi) Nicolas Liebau (SAP) Oscar Garcia (TIE) Federico Magalini (Polimi)
ii
285541 31-Aug-13 PU
The research leading to these results has received funding from the European Communitys Seventh Framework Programme (FP7/2007-2013) under grant agreement no285541.
iii
285541 31-Aug-13 PU
Table of contents
1! 2! EXECUTIVE SUMMARY ........................................................................................................................... 1! DESIGN .......................................................................................................................................................... 2! 2.1! DESIGN GOALS ......................................................................................................................................... 2! 2.2! HIGH-LEVEL ARCHITECTURE CONCEPT .................................................................................................... 2! 2.3! BASIC INFORMATION SHARING PROCESS ................................................................................................. 4! 2.3.1! Share and Index ............................................................................................................................... 5! 2.3.2! Search and Find ............................................................................................................................... 8! 2.3.3! Retrieve and Process ..................................................................................................................... 11! 3! ARCHITECTURE OVERVIEW ............................................................................................................... 13! 3.1! 3.2! 3.3! 3.4! 4! PREMANUS GATEWAY ........................................................................................................................ 13! PREMANUS CLIENT ............................................................................................................................. 14! PREMANUS CLOUD ............................................................................................................................. 15! COMPLETE ARCHITECTURE .................................................................................................................... 16!
PREMANUS GATEWAY ........................................................................................................................... 18! 4.1! OVERVIEW .............................................................................................................................................. 18! 4.2! THE SERVICE BUS................................................................................................................................... 18! 4.3! DB CONNECTOR ..................................................................................................................................... 21! 4.3.1! Architecture ................................................................................................................................... 21! 4.3.2! Diagrams ....................................................................................................................................... 22! 4.3.3! Specification of Interfaces, Protocols and Formats ...................................................................... 26! 4.4! SECURITY ANNOTATOR .......................................................................................................................... 31! 4.4.1! Architecture ................................................................................................................................... 32! 4.4.2! Diagrams ....................................................................................................................................... 32! 4.4.3! Specification of Interfaces, Protocols and Formats ...................................................................... 33! 4.5! TRANSFORMATION ................................................................................................................................. 37! 4.5.1! Architecture ................................................................................................................................... 38! 4.5.2! Diagrams ....................................................................................................................................... 39! 4.5.3! Specification of Interfaces, Protocols and Formats ...................................................................... 40! 4.6! INFORMATION PUBLISHER ...................................................................................................................... 44! 4.6.1! Architecture ................................................................................................................................... 45! 4.6.2! Diagrams ....................................................................................................................................... 48! 4.6.3! Specification of Interfaces, Protocols and Formats ...................................................................... 49! 4.7! PRODUCT ID MANAGEMENT AND MAPPING ........................................................................................... 52! 4.8! INTERFACES WITH THE SSB .................................................................................................................... 53! 4.8.1! MessageTypes ................................................................................................................................ 53! 4.8.2! Classes description ........................................................................................................................ 54!
5!
PREMANUS CLOUD ................................................................................................................................. 55! 5.1! OVERVIEW .............................................................................................................................................. 55! 5.2! INFORMATION DIRECTORY ..................................................................................................................... 56! 5.2.1! Information Indexing ..................................................................................................................... 56! 5.2.2! Search ............................................................................................................................................ 58! 5.2.3! Subscription ................................................................................................................................... 59! 5.2.4! Query types for the PREMANUS System ....................................................................................... 59! 5.2.5! API ................................................................................................................................................. 60! 5.2.6! Directory Service Persistency Type ............................................................................................... 61! 5.2.7! PREMANUS Information Directory Data Model .......................................................................... 62! 5.3! ROLE BASED ACCESS CONTROL ............................................................................................................. 64!
6!
PREMANUS CLIENT ................................................................................................................................ 67!
iv
285541 31-Aug-13 PU
6.1! OVERVIEW .............................................................................................................................................. 67! 6.2! BUSINESS DECISION SUPPORT SYSTEM .................................................................................................. 67! 6.2.1! Overview ........................................................................................................................................ 67! 6.2.2! Service Layer (BDSS Base) ........................................................................................................... 68! 6.2.3! Application Layer (BDSS Algorithms) ........................................................................................... 68! 6.3! PREMANUS GATEWAY ........................................................................................................................ 70! 6.4! INFORMATION MANAGER ....................................................................................................................... 70! 6.4.1! Architecture ................................................................................................................................... 70! 6.4.2! Interactions and Processes ............................................................................................................ 72! 6.4.3! Gateway Interface .......................................................................................................................... 75! 6.4.4! BDSS Information Service ............................................................................................................. 76! 6.4.5! Cloud Interface .............................................................................................................................. 79! 6.4.6! Coordinator ................................................................................................................................... 80! 6.4.7! Subscriptions.................................................................................................................................. 80! 6.4.8! Product Data Store Handler .......................................................................................................... 81! 6.5! PRODUCT DATA STORE .......................................................................................................................... 83! 7! STANDARDIZATION ................................................................................................................................ 87! 7.1! BACKGROUND TO QLM ......................................................................................................................... 87! 7.1.1! Proposal ......................................................................................................................................... 87! 7.2! ADVERTISEMENTS STANDARDIZATION ................................................................................................... 87! 7.2.1! Purpose .......................................................................................................................................... 87! 7.2.2! Structure ........................................................................................................................................ 88! 7.2.3! Other Standards under consideration ........................................................................................... 90! 7.2.4! Security Considerations ................................................................................................................. 91! 8! CONCLUSION ............................................................................................................................................ 93!
285541 31-Aug-13 PU
Executive Summary
This deliverable introduces the PREMANUS architecture, starting from a very high and abstract view of the architecture and gradually going into the details of the individual components and functionalities. Since this deliverable is considered a living document, it is continuously updated as the project progresses and new details or changes to the architecture emerge. On the highest level, the architecture is split among the major types of stakeholder, each with their own major component of the architecture: The Information Consumer is a stakeholder with a need for product information. The product information is used in the Business Decision Support System or BDSS to improve the stakeholders estimates, cost computations, processes and other forms of decision support. The architecture component, which realizes these functionalities, is in this document referred to as the PREMANUS Client. The Information Provider is a stakeholder with information about a product type or a product instance and is willing to share this information with other stakeholders within the PREMANUS Network. Each Information Provider in the PREMANUS Network operates an instance of the PREMANUS Gateway. The Gateway is used to extract existing information from systems which the stakeholder wants to connect to PREMANUS. It is also responsible for regulating access to the provided information and generating metadata for indexing in the final major component of the architecture, the Information Directory. The Information Directory is a cloud component and is operated by the stakeholder administrating the PREMANUS Network. It can be thought of as a cloud-based index of all information shared by the Information Providers within the network. Any Information Consumer can query the Information Directory to locate which Information Consumers hold relevant product information. However, the Information Directory only contains metadata, the actual product information remains at the Information Providers Gateway. This means anyone within the PREMANUS system can locate Information Providers easily through the publically (within the PREMANUS network) available information, but at the same time the Information Providers retain control over who they grant access to their data, since every Information Consumer needs to request the data directly at the Providers Gateway.
After a general introduction to the three main components, the major processes and interactions between these components are described and visualized. From these interactions, a more fine-grained picture of the architecture is derived and explained. After the architecture description, the standardization efforts within the PREMANUS project are described. The main goal of standardization is the reuse the Advertisement structure used to describe available data as an extension to The Open Groups QLM Standards. As this deliverables give the specifications of the PREMANUS architecture, implementation details of the complete PREMANUS System are given in the deliverables of work packages WP3, WP4, and WP5.
285541 31-Aug-13 PU
Design
This chapter gives an overview of the PREMANUS architecture and its design decisions. The first sections details general design goals for the PREMANUS architecture and a very high-level overview of the concepts and structure of the architecture. Once the high-level components of the architecture are established, the major processes of the architecture are introduced. In the chapters following the major processes, a more detailed vision of the architecture will be derived, based on the
2.1
Design Goals
In addition to the requirements derived from the PREMANUS use cases, the architecture has been designed with a number of guiding principles in mind. The goal of these design principles is to improve the overall quality of the architecture and increase the possibilities of reuse as well as interoperability. Standards: The PREMANUS architecture should be based, wherever possible, on established or emerging standards. This increases the potential for reuse and interoperability with other systems and architectures based on the used standards. Extensibility The PREMANUS architecture should be extendible to accommodate new functionalities and requirements wherever possible. Especially the Business Decision Support System needs to be highly adaptable and extendable to accommodate different use cases and requirements from new stakeholders. Information Control One important aspect of the PREMANUS system is the control, which information providers need to have over their own information, which they are sharing. Since most companies are not willing to give up control over who has access to their information, the PREMANUS architecture needs to enable each company to have complete control over which information they share with the system and which other stakeholders are able to access the information they share. Respect data security requirements The PREMANUS architecture integrates into existing company databases and facilitates the data transfer. Information about existing data and the data transfer needs to consider security constraints: data exchange needs to be limited to data that is properly authorised to be shared.
2.2
High-level Architecture Concept
The PREMANUS architecture is split among three work packages, WP3, WP4 and WP5. WP3 corresponds to the Remanufacturing Information Services, WP4 to the Remanufacturing Services Gateway and finally WP5 to the Business Decision Support System. Figure 1 shows an overview of the three work packages, which compose the PREMANUS system.
285541 31-Aug-13 PU
Figure 1 Overview of the 3 Pillars of the PREMANUS Middleware, corresponding to WP 3, 4 and 5 respectively.
Remanufacturing Information Services (RIS) o Product ID resolution o Distributed Persistency o Product Data Query & Modification Interface o Role-based Access Control (RBAC) Remanufacturing Services Gateway (RSG) o Semantic Service bus o Infrastructural Services o Messaging Services o Adapter Services Business Decision Support System (BDSS) o End-of-Life (EoL) Product recovery process eco-efficiency evaluator o Key Performance Indicator (KPI) optimizer o Workbench
However, these work packages are distributed across different components of the architecture. Referring to the components of the architecture in terms of work packages would only serve to complicate the document, hence the rest of this deliverable will view the architecture in terms of the components rather than the work packages defined in the DOW. The following figure provides a quick overview of the components involved in a typical instance of the PREMANUS architecture.
285541 31-Aug-13 PU
!"#$%&'()*+8594 /"0():)"(2):);<((1
!"#$%&'()*+,-.)/"0(1
!"#$%&'( 2345637)/"(21
!"#$%&'( 2345637)/"(21
!"#$%&'( 2345637)/"(21
At the highest level, we have three types of stakeholders in our PREMANUS architecture: Information Provider, Information Consumers and a neutral PREMANUS component, which keeps track of the Information Providers and the information they offer. This maps to the PREMANUS Client (consumer), PREMANUS Gateway (provider) and the PREMANUS Cloud (information directory). In most cases, an Information Consumer is also simultaneously an information provider, which is why each PREMANUS Client usually includes the components of the PREMANUS Gateway. In order to derive the more detailed view of the architecture, the next chapter will introduce the most important process of the PREMANUS architecture, the process or sharing information within the PREMANUS network.
2.3
Basic Information Sharing Process
This chapter describes at a high level, the process of one PREMANUS stakeholder sharing data with the PREMANUS network and another PREMANUS stakeholder searching and retrieving said information through the central PREMANUS Cloud. The process comprises three major sub processes. The first process is information sharing and indexing, which involves only the sharing stakeholders gateway and the central information directory. The next process is the search initiated by an information consumer PREMANUS Client and the Information Directory, which knows where the information can be found. The final part of the process is actually retrieving the data from the information providers Gateway and returning it to the information consumers PREMANUS Client.
285541 31-Aug-13 PU
2.3.1 2.3.1.1
Share and Index Overview
Before any information can be searched or retrieved by an Information Consumer, information must be shared with the PREMANUS network. This interaction involves on the one hand the PREMANUS Stakeholder who is willing to share his information with the PREMANUS network (Information Provider) and on the other side the PREMANUS Cloud Information Directory, which indexes which information is provided by whom and from where the information can be retrieved. The Information Provider creates a listing of available information and shares it with the Information Directory. The Information Directory processes and indexes the provided listing and stores it internally, so that in the future Information Consumers are able to query for the listed information. 2.3.1.2 Detailed Process
Figure 2 Information Sharing and Indexing Process Diagram shows this process in some more detail.
!"#$%&'()$"*+,'%)"-*'".*!"./0)"+,'%)"!"./0)"-
1'('*6$7%2/
1'('*8'"'-/&/"(* '".*9""$('()$"
4'(/5'3
+('%(
9.:/%()6/&/"(* ;%/'()$"*'".* 9--%/-'()$"
9.:/%()6/&/"(* <//.*<)=/ >/-)6(/%* 9.:/%()6/&/"(*<//.
!"#$%&'()$"*1)%/2($%3
!"#$%&'()$"* ?%$:)./%* 1'('@'6/
>/(%)/:/*'".* ?%$2/66* 9.:/%()6/&/"(*<//.
!"./0*'".*+($%/* 9.:/%()6/&/"(6
9.:/%()6/&/"(* 1'('@'6/
A".
Figure 2 Information Sharing and Indexing Process Diagram
The Information Provider stores his information in internal data sources. These sources are usually not part of the PREMANUS system, but rather preexisting systems of the stakeholders. In order to connect these systems to PREMANUS, a specialized Database Connector is created, which adapts the data source to a standardized interface. The Database Connector can then be connected to the
285541 31-Aug-13 PU
PREMANUS system. The Database connector also maps the information of the data source to the data model used in PREMANUS, which is The Open Groups QLM Data Model. Once all necessary data sources have been connected via Database Connectors, the Information Provider compiles a list of information he is willing to share from one or more of his data sources. In PREMANUS these descriptions of available information are called advertisements or ads. Each Information Provider constructs advertisements for all information he wishes to share within the network through a component called the Advertisement Builder. The advertisements are compiled into a feed file, which is registered with the information directory. The feed file includes details of what kind of information is available but never the information itself. The Information Provider retains full control over his data and it is never uploaded into the PREMANUS Cloud. The file also includes details about how other PREMANUS stakeholders with PREMANUS clients can request the information. The Information Provider updates the feed with ads about any new information he has available, but does not have to re-register it. Once the feed file has been registered with the Information Directory in the PREMANUS Cloud, it will retrieve the file and index the advertisements contained within. After the initial processing of the advertisement feed, the Information Directory will periodically check the file for updates and retrieve and reprocess if necessary. The pull mechanism with a feed file has several advantages over a direct push mechanism, where the Information Provider immediately updates the Information Directory with new information. With the pull mechanism, the Information Directory has control over how frequently updates are process, which allows it to manage traffic and performance. If the Information Provider is allowed to push information whenever he wants, the Information Directory could end up constantly updating from many different Information Providers that push every minor change they have. The second advantage is that updates can be performed during low load or low traffic times of the Information Directory, which will improve responsiveness for search queries by Information Consumers.
285541 31-Aug-13 PU
!"#$%&'()*+,-.+/
0+,+12345-
0+,+6+17288-5,24
%9:-4,;1-<-8,)=3;>9-4
%9:-4,;1-<-8,)A--9)A;>-
?8@24<+,;28)0;4-5,24/
A--9)0=
A--9 "-B;1,4+,;28
)A--9)$+8+B-4
%9:-4,;1-<-8,)0=
A--9)!+41-4
Figure 3 Diagram of relevant architecture for the sharing and indexing process
The Share and Index process involves a number of components which are introduced here: PREMANUS Gateway: Data Source: The Data Source itself is usually not part of the PREMANUS System but an existing data source, which belongs to the owner of the Gateway. Data from the source is extracted and integrated with the PREMANUS environment through the Database Connector. Database Connector: The Database Connector encapsulates, extracts and translates a data source in order to integrate it with the PREMANUS system and share the information within with the PREMANUS system. Advertisement Builder: The Advertisement Builder constructs descriptions of data that is available in the Database Connectors of the Gateway and aggregates them into an Advertisement
285541 31-Aug-13 PU
Feed. The Advertisement Feed describes all information available from the Gateway to the rest of the PREMANUS system. PREMANUS Cloud Information Directory: Feed Registration: The Feed Registration allows any PREMANUS Gateway to register their information advertisement feed. Once the feed has been registered, the information being shared by the Gateway providing the feed will be visible through the Information Directory. Feed Manager: The Feed Manager manages the periodical checking of all registered advertisement feeds for updates, and retrieving and processing any feeds that provide new information. Feed Parser: The Feed Parser receives an advertisement feed from the Feed Manager, disassembles it in order to retrieve the information contained within, and saves any new or updated advertisement to the advertisement database in the Information Directory. 2.3.2 2.3.2.1 Search and Find Overview
The next key process of the PREMANUS architecture is the process of an Information Consumer who requires some information to improve their business processes and queries the PREMANUS Cloud Information Directory if any suitable information is available. The Information Directory searches its internal database of indexed advertisements and returns those matching the query of the Information Consumer. The Information Consumer can then decide which advertised information they want to retrieve with the included access information. 2.3.2.2 Detailed Process
This section examines the process of searching the cloud for information in more detail, as depicted in Figure 4 Information Search Process Diagram.
285541 31-Aug-13 PU
!"#$%&'()$"*+,'%-.
+,'%-.
+('%(
!/*3,8$25()$"
A";
12),"(
!"#$%&'()$"* 3,45)%,&,"(
65,%0*1%,'()$"
3,-,)<,*'";*7%$-,88* 3,852(8
!"#$%&'()$"*/)%,-($%0
65,%0*7%$-,88)"9
3,852(8*>?)8(*$#* :;<,%()8,&,"(8@
:;<,%()8,&,"(* /'('='8,
Figure 4 Information Search Process Diagram
The information search process starts when the information consumer has a need for new information to support more intelligent decision making. In the PREMANUS use case, this information requirement comes in the form of a BDSS algorithm requiring information to improve a remanufacturing decision. The BDSS notifies the Query Manager about its information requirement. The Query Manager in turn queries the PREMANUS Cloud Information Directory in order to retrieve any available advertisements for the required information. The Information Directory searches its internal Advertisement Database for advertisements matching the query. It then compiles a list of all advertisements matching the query and returns it to the Query Manager of the PREMANUS Client. The Query Manager processes the advertisements and notifies the BDSS about which information is available within the PREMANUS network. At this point either the BDSS algorithm itself or a user, via a User Interface, can select which of the available information should be retrieved in order to improve the remanufacturing decisions.
285541 31-Aug-13 PU
!"#$%&'()*+,-./
96((
:;-38)$5.5<-3
0.12345/,2.)6,3-7/238
:;-38)0./-3157-
A,?/)21 %=>-3/,?-4-./?
%=>-3/,?-4-./ 65/5@5?-
Figure 5 Search and Find component diagram
The process described above involves a number of components, which are shown in Figure 5. Below is a short description of each components role within the process: PREMANUS Client: Query Manager: The Query Manager coordinates the process of finding information within the PREMANUS network. It takes information requirements from the BDSS, locates the information with the help of the Information Directory and returns a list of available information to the BDSS. Query Interface: The Query Interface of the PREMANUS Cloud Information Directory is the interface for PREMANUS Clients to connect to the Information Directory and query the directory about available information about a product instance or product series. Advertisement Database: The Advertisement Database stores all available advertisements from each registered advertisement feed. The advertisements in the Advertisement Database describe all
PREMANUS Cloud Information Directory: -
10
285541 31-Aug-13 PU
information that is available within the PREMANUS network. 2.3.3 2.3.3.1 Retrieve and Process Overview
The last step in the process is for the client to retrieve the actual data for selected advertisements from the PREMANUS Gateway that offers the data. Once the BDSS or the end user has selected those advertisements that reference relevant data, the PREMANUS clients sends request queries directly to the PREMANUS Gateways, whose access information is indicated in the advertisements themselves. The Gateway first confirms both the identity of the requesting PREMANUS Client and the corresponding permissions. If the Client is allowed to access the information requested, the Gateway will retrieve the actual information from its connected data sources, translate the data into QLM (Quantum Lifecycle Management) format and return it directly to the PREMANUS Client. 2.3.3.2 Detailed Process
The following diagram shows the process of retrieving the actual information and processing it in the BDSS.
!"#$%&'()$"*+,(%),-'.*'"/*0%$1,22)"3
+,(%),-'.*'"/*0%$1,22)"3
:('%(
89::*2,.,1(2* ;/-,%()2,&,"(2
D$()#6*89::*'E$=(* 1$&F.,(,/*/'('* 1$..,1()$"
7$&F=(,*H0!*($* )&F%$-,* +,&'"=#'1(=%)"3* 9,1)2)$"
G"/
7.),"(
+,<=,2(*9'('
+,1,)-,*'"/*2($%,* /'('
0%$/=1(*9'('* :($%,
>,%)#6*!/,"()(6*'"/* ;11,22*+)3?(2
4'(,5'6
+,(%),-,*%,<=,2(,/* /'('
@%'"2.'(,*9'('*)"($* ABC
9'('*:$=%1,
Figure 6 Retrieve and Processing Process Diagram
At the beginning of this process, the BDSS already has all the advertisements about the information it has requested and either the BDSS algorithm or a user selects the advertisements that point to required information. Once the selection is made, the Query Manager coordinates the retrieval and storage of the requested information. It uses the access information included in each advertisement to request the actual data from the corresponding PREMANUS Gateway interface. Once the request has reached the Gateway, it checks the identity of the requesting party and verifies that the requesting party is
11
285541 31-Aug-13 PU
authorized to access the requested information. If they are authorized, the PREMANUS Gateway will start collecting the requested data from the connected Database Connector, which encapsulate the internal data source, which hold the actual data. Besides abstracting the data sources to a standardized interface, the Database Connector sends the result to the Transformation component, which converts the data from their native format into QLM so it can later be processed by the BDSS. Once all the requested data has been collected, the data is returned to the requesting PREMANUS Client. At the client, the Query Manager receives the request and stores the data in the Product Data Store, together with the all the data requested from other sources. Once all requests have been completed, the Query Manager tells the BDSS that all requested data has been collected and is available in the Product Data Store. Now the BDSS can continue its computations. The process described above was used to derive the partial architecture diagram below.
!"#$%&'()*+,-./
!8;@7</)51/1)(/;845(( 67-83)$1.19-8
!"#$%&'()01/-213
01/-213 >./-8?1<-
51/1:;78<-
51/1=1:*;..-</;8
51/1
Figure 7 Retrieve and Process Component Diagram
12
285541 31-Aug-13 PU
Architecture Overview
In this section, the more detailed vision of the architecture will be introduced. The high-level architecture has already been introduced in previous chapters and parts of the more detailed architecture have been introduced in the Basic Information Flow chapter (2.3). This chapter will introduce and describe all major subcomponents of the three main components of the architecture. First, the components will be briefly introduced and their main functionality explained. Then the three major components with their subcomponents will be described in more detail.
3.1
PREMANUS Gateway
The Remanufacturing Services Gateway is responsible for making services and information available to the rest of the PREMANUS system both locally and over the PREMANUS network. The tasks of the Remanufacturing Services Gateway are as follows: In terms of information, the PREMANUS Gateway provides an homogeneous access to heterogeneous sources of information to the PREMANUS client node by: o Providing access to the information stored in such information storages preserving privacy where needed o Providing a mechanism for semantic annotations leveraging searches across the PREMANUS system In terms of services, the PREMANUS Gateway provides an homogeneous access to a variety of services provided by the different PREMANUS components: o For publishing information and subscribing to sources o For solving ID conflicts arising from different sources of information o For preserving private data depending on the relationship between information consumer and provider o For guaranteeing that the messages reach the correct recipient and their response reach the correct requestor.
The following is a quick summary of the functionality of all major components within the PREMANUS Gateway. DB Connector: " " " " Encapsulate Database Translate between DB specific format and QLM Hide data which is not shared and administer access to the information Generate advertisements that describe what information is available from the DB connector
Information Publisher " " " Aggregate advertisements from all DB connectors within the gateway Publish the advertisements in an ATOM based feed file Register the feed with the Information Directory in the PREMANUS cloud
Information Interface " " Allow partners access to advertised information through a web service interface Retrieve the requested information from the corresponding DB connectors
13
285541 31-Aug-13 PU
ID Management " Resolve internal IDs or basic information into a shared and unique URN that is understood by the entire PREMANUS network (involves ID management component in the PREMANUS Cloud) Store mapping between PREMANUS URN and internal IDs so future requests can be resolved more quickly
"
Access Control " " " Ensure that only authorized PREMANUS users can access the information shared by the gateway (involves the PREMANUS cloud Access Control component). Check which information the PREMANUS user is allowed access to in case of several levels of access Allow the stakeholder to verify and manage authorization of users to ensure the security of their data
Service Bus " Provide message routing between the various components of the PREMANUS gateway. If the gateway is part of a PREMANUS client, the service bus is also responsible for routing between the clients components.
3.2
PREMANUS Client
The PREMANUS Client fulfils the role of the Information consumer. In some cases, it additionally fulfils the role of the information and service provider. To that purpose, the PREMANUS Client contains an instance of the PREMANUS Gateway. The main goal of the PREMANUS Client is to make the information, services and resources of the PREMANUS Network available to the client logic, the BDSS. The BDSS, or the Business Decision Support System, utilizes the resources of the PREMANUS network to improve remanufacturing decisions within the client stakeholders organization. Below is a quick description of all major components and their function within the PREMANUS Client: PREMANUS Gateway " The PREMANUS client can include a PREMANUS Gateway, in case the stakeholder owning the PREMANUS client also wishes to share information with the rest of the PREMANUS system. Currently the PREMANUS client includes a gateway by default. The PREMANUS Gateway maintains the same properties and functionalities as stated above.
"
Query Manager " " " " " Receives requests from the BDSS to search for information in the PREMANUS network Searches the PREMANUS Cloud Information Directory for the requested information and receives back advertisements for the available information Presents the advertisements to the BDSS Receives requests from the BDSS to retrieve specific advertised Data Contacts the corresponding gateways and retrieves the requested information
14
285541 31-Aug-13 PU
"
Stores information and advertisements in the Product Data Store and informs the BDSS
Product Data Store " " BDSS " " Gathers information and computes various KPIs to improve and optimize the remanufacturing process Provides an Application Framework for Algorithms computing the KPIs Stores both advertisements and data retrieved from the PREMANUS Cloud and Gateways respectively Builds an internal QLM structure with the QLM information retrieved from various sources
3.3
PREMANUS Cloud
The PREMANUS Cloud provides a number of key services to the PREMANUS Clients and Gateways connected to the PREMANUS network. The most important service is the Information Directory, which captures which information is shared by which party within the network. Additional services include for example Access Control and ID Management services. ID Management " " Resolve basic information (manufacturer, product series, product id) into a PREMANUS URN. (Optional) Checks basic information against an authority (in case of EPC it would be GS1)
Information Directory " " Gather and index advertisements for all available information in the PREMANUS network. Make the stored information searchable and provide an interface for PREMANUS clients to search the advertisements.
Access Control " Provide basic authentication for users within the PREMANUS network.
15
285541 31-Aug-13 PU
3.4
Complete Architecture
The three major components detailed in the previous three subchapters comprise the PREMANUS architecture. Figure 8 shows the complete architecture, and how the three major components and their subcomponents interact with each other.
!"#$%&'()*+:426
%CC
!"#$%&'()=164>1<
?0(()E?1A4E
%CC
%CC
0?)*,224;6,7 /0 $121345426
!7,.-;6)0161)(6,74
D-47<)$121347 /29,7516:,2 !-@+:AB:23 =164>1< /264791;4
*+:426 !"#$%&'()*+,-.
/0)$121345426 (47847
=164>1<
*+:426
/29,7516:,2)0:74;6,7<
=164>1<
*+:426
=164>1<
=164>1<
=164>1<
Figure 8 Overview of the detailed PREMANUS architecture
The following table gives a quick overview of how the architecture components relate to the Work Packages (WP3 RIS, WP4 RSG, WP5 BDSS). Each PREMANUS Gateway node consists of: DB Connector ID Management Information Publisher Gateway Service Bus (RSG) (RIS) (RSG) (RSG) (RSG)
16
285541 31-Aug-13 PU
Each PREMANUS client node contains: One instance of a Gateway node Query Engine Product Data Store BDSS ID Management Information Directory (mostly RSG) (RIS) (RIS) (BDSS) (RIS) (RIS)
The last component of the architecture, the PREMANUS Cloud manages:
17
285541 31-Aug-13 PU
4 4.1
PREMANUS Gateway Overview
The PREMANUS Gateway (RSG) fulfills the role of the information provider in the overall architecture. It is responsible for advertising the information it offers, providing the information and administering access to the information from a variety of internal sources. Thus, this chapter describes the core components forming the PREMANUS Gateway and which provide the functionality for routing the data from the Information Provider (typically, the Data Sources located in the OEMs facilities) to the Information Consumer (typically, the BDSS). The RSG comprises three components, as can be seen in Figure 9: " " " The Semantic Service Bus (SSB) which is a semantic extension of the TIEs commercial Service Bus, TIE SmartBridge The core components that manage the different activities like e.g. ID Management or Information Publishing The interfaces that enable communication between the SSB and the core components.
Figure 9 PREMANUS Gateway
4.2
The Service Bus
The Service Bus interconnects the different components using a message routing mechanism. In the case that the PREMANUS Gateway has to communicate with third party systems, the Service Bus is also responsible for triggering the communication using standard communication protocols such as WebServices. The selected Service Bus within PREMANUS is TIE SmartBridge (TSB). TSB consists of a collection of components, or services, performing a multi-step process in which a document is received from its original source in the source format, adapted (or transformed) to the target format, and delivered to its recipient. A document may need to undergo a series of phases - validation,
18
285541 31-Aug-13 PU
translation, and sending to the intended recipients or business system (e.g. an ERP system). Each phase is executed by a specialized component of TSB. These components communicate with one another through internal messages posted and retrieved to and from the Messages Bus. Figure 10 illustrates the architecture of TSB. Message routing is the main exchange mechanism for sending/receiving messages between the various components of the PREMANUS gateway. If the gateway is part of a PREMANUS client, the service bus is also responsible for routing between the clients components. The architecture shown in the following figure details some elements that are key for the execution of the TSB functionalities: " "
"
"
"
Communication Modules are the components through which documents are sent or received. The CM-FileSystem is a special communication module that can be configured to monitor the content of one or more directories on the system, creating a document and the corresponding message for each of the files that are found in the monitored folder(s). CM-In Activator and CM-Out Activator are the components in charge of controlling the execution of the Communication Modules, triggering the execution of communication sessions when specific command messages are received from the Messages Bus. The Message Storing System is responsible for storing the history of messages received by various TSB components. Based on the content of the Message Storage, the System Management Console (SMC) is able to provide the administrator with a complete history of all messages that passed through the system while processing documents. The role of the Messages Archiving System is to transport outdated message history entries into the Message Archive, once they have been stored in Message Storage for more than a specified number of days.
19
285541 31-Aug-13 PU
Figure 10 TIE SmartBridge (TSB): Architecture
20
285541 31-Aug-13 PU
4.3
DB Connector
The DB Connector is the interface responsible for providing access to the database or data repository to which it is connected. Although there could be many different sources and types of data connected to the PREMANUS Gateway, it follows a generic structure to allow different organizations to send data and receive queries in as the most standardized way possible. Thus, there is only one DB Connector per PREMANUS Gateway regardless of the amount of data sources available. Its main feature is transparency, meaning that the access to the data is, from the technical point of view, independent of the schema or structure of the data source and the technology with which it has been developed. The data (independently of its format) stored in that data source is the basis for the calculations to be carried out by the BDSS. Figure 11 depicts the structure of the DB Connector. In this figure, the following sub-components are listed and described in the following subsections: " " " " DB Change Monitor Query Monitor DB Connector Storage Interface with the SSB, including the message dispatchers/receivers and the connectivity to the data sources via a Web Service communication channel.
Figure 11 DB Connector: Overview
4.3.1 4.3.1.1
Architecture Change Monitor
The Change Monitor is responsible for dealing with the detection of changes produced in the data source. However, the Change Monitor does not actively request the source for the changes. The
21
285541 31-Aug-13 PU
detection of changes, i.e. when any data has been CREATED, UPDATED and/or DELETED, is the responsibility of the owner of the data source. It is also the responsibility of the owner of the data source to develop and fire the corresponding triggers, so meaningful information reaches the PREMANUS Gateway. In the event that any of them occur, i.e. the data source triggers the changes, this event is notified to the rest of the system stating that new information is available or existing information has been changed or is no longer available. These changes (the new, updated or deleted information) are annotated as publishable into the internal Annotation Repository, i.e. the Data Management and Annotation (see section 4.4.1.2) taking into consideration the data publication policies available when the data source was registered in the PREMANUS Gateway. 4.3.1.2 Query Monitor
The main objective of this sub-component is to receive the Query Requests from the PREMANUS Components, typically the BDSS, and forward them to the data source. Also, it receives the responses to these queries forwarding them to the requestor of the query. 4.3.1.3 DB Connector Storage (DBCS)
The main objective of this sub-component is to manage the information provided by the data source and also to manage the different data sources available together with their access coordinate data. In the propagation activity, the information stored in this storage relates to the schemas that have been entered into (or modified/deleted from) the data sources. After these records have been annotated, they are sent by the Change Monitor to internal storage. The change (only references and not values) is stored in the DBCS together with references to the source of information to keep track for queries coming from the BDSS. 4.3.2 Diagrams
This section focuses on the diagrams of the most important activities for the DB Connector. However, these activities do not only affect the DB Connector component but also other PREMANUS components, such as the Transformation or the Information Publisher components: " " " 4.3.2.1 Registration of a new data source. Propagation of a C_UD (Create, Update or Destroy) operation. Request for data. Registration of a new data source
The following figure represents the Activity Diagram of the DB Connector Component when a new data source is registered to the PREMANUS (Figure 12):
22
285541 31-Aug-13 PU
Figure 12 DB Connector: Activity Diagram for registering a new data source
Figure 13 gives an overview of the internal component communication when a new data source is registered.
Figure 13 DB Connector: Sequence Diagram for registering a new data source
Prior to registering a new data source, the schema of the data source must be mapped against the QLM data model (and eventually other relevant ontologies) being the preparatory activity. This preparatory activity ends with the generation of the mapping and the executable file (Link Plan Object (LPO)). These two files are needed for the transformation execution (see section 4.5). When a registration request of a new data source arrives, the following steps are carried out: " " " The DB Connector receives the request and sends the information to the Data Management and Annotation Repository together with the access policy of this new source for registration. The mapping and executable files are uploaded to the Transformation Repository. The DB Connector sends the notification to the Information Publisher, which propagates that a new source of information is available for consultation. The information propagated is a compound of the ID of the Data Source and a list of UDEF codes specifying which attributes are available. Propagation of a C_UD operation
4.3.2.2
The following figure represents the Activity Diagram of the DB Connector Component when a C_UD operation occurs in the data source (Figure 14):
23
285541 31-Aug-13 PU
Figure 14 DB Connector: Activity Diagram for a C_UD operation
The next figure (Figure 15) gives an overview of the internal component communication when a C_UD operation occurs.
Figure 15 DB Connector: Sequence Diagram for a C_UD operation
When a C_UD operation occurs in the data source, the DB connector is notified through the Change Monitor. Thus, the Change Monitor is actively waiting for C_UD notifications from the data source. This notification is sent to the Data Management and Annotation Repository for annotation; these are security aspects: the access policy, related to that particular source, record, and operation is stored on the fly in the C_UD notification. Finally, in the DBCS contained in the DB Connector, a record with the access information (i.e. URL) for that particular set of information, is stored and marked as dirty and a publication is thrown to the rest of the system. 4.3.2.3 Request for data
The following figure represents the Activity Diagram of the DB Connector Component when a request for data has been thrown from any PREMANUS component, typically the BDSS (Figure 16):
24
285541 31-Aug-13 PU
Figure 16 DB Connector: Activity Diagram for requesting data
The next figure (Figure 17) gives an overview of the internal component communication when the request of data, i.e. a query, is sent to the data source.
Figure 17 DB Connector: Sequence Diagram for requesting data
When a data request is received, the Query Monitor is responsible for receiving the message. It then calls the functionalities for extracting the data from the data source. This is done via three different steps: " In the first step, a request to the Data Management and Annotation Repository is sent for checking the permissions for accessing the requested data.
25
285541 31-Aug-13 PU
" " 4.3.3 4.3.3.1
In the second one, and based on the results of the first step (grant access), the query is forwarded to the data source for execution. Finally, the result of the query is sent back to the Message Routing Interface. Specification of Interfaces, Protocols and Formats API specification
Figure 18 represents the DB Connector service interfaces that are provided by the component itself and that are also needed for the normal execution of the component.
Figure 18 DB Connector: Service Interfaces (provided and needed)
4.3.3.2
Content Formats and Protocol Definitions
An XML document is used to transfer data to the DB Connector via the interface. The XML-schema shown below contains all the necessary parameters for invoking the API method specified in the sections above. DB Connector Query message format XML/Schemas http://www.premanus.eu/xmlSchema/DBConnector/QueryReq.xsd http://www.premanus.eu/xmlSchema/DBConnector/QueryResp.xsd Request-Format: An XML document is used to transfer data from a PREMANUS component to each DB Connector, by means of the Message Routing functionality. Messages following the XML-schema shown below are transferred as the payload of the Message Routing call. It contains all necessary parameters for invoking the API method specified in the sections above.
26
285541 31-Aug-13 PU
Figure 19 DB Connector: Query Request XML Schema
Data elements queryID: Unique identifier of the query to be executed. This ID is used to retrieve the details to execute the query by the data source. sourceData: The query sentence itself. This structure contains a name attribute and an encoding attribute, describing if the value data is encoded (base64) or not. In the case of large files, a PREMANUS Gateway uses the Message Routing features for large attachments that allows temporary storage of the file, and uses a URI reference (URI Universal Reference Identifier) to the source data parameter, so the large file can be retrieved when it needs to be accessed. Additional information collected from the incoming Message Routing call. componentID: Identifier of the caller component, so that the query result can be routed to it. from: Identification of the sending user. to: Identification of the recipient user. Response-Format:
Figure 20 DB Connector: Query Response XML Schema
Data elements commandResult: Result of the command executed (OK, ERROR) commandResultDescription: If error, this field describes the cause of the error, so the
27
285541 31-Aug-13 PU
upper process can be informed resultData: The query response. It contains a name descriptor and an attribute describing if the value is encoded or not. In the case of large files, a PREMANUS Gateway uses the Message Routing features for large attachments that allows temporary storage of the file, and uses a URI reference to the source data parameter, so the large file can be retrieved when it needs to be accessed. Additional information embedded in the Message Routing message response. commandID: Unique Identifier for the current query that can be used to access an operation log. from: Identification of the sending user. to: Identification of the recipient user. DB Connector C_UD message format XML/Schemas http://www.premanus.eu/xmlSchema/DBConnector/CUDReq.xsd http://www.premanus.eu/xmlSchema/DBConnector/CUDResp.xsd Request-Format: An XML document is used to transfer data from the DB Monitor to the data source directly connected to the DB Connector by means of the Message Routing functionality. Messages following the XMLschema shown below are transferred as the payload of the Message Routing call. It contains all necessary parameters for invoking the API method specified in the sections above.
Figure 21 DB Connector: C_UD Request XML Schema
Data elements cudRequestID: Unique identifier of the C_UD Request to be checked. This ID is used to retrieve the details of the C_UD activity for, e.g. logging purposes, if needed. sourceData: It contains the Product ID to be monitored. This structure contains a name attribute and an encoding attribute, describing if the value data is encoded (base64) or not. In the case of large files, a PREMANUS Gateway uses the Message Routing features for large attachments that allows temporary storage of the file, and uses a URI reference to the source data parameter, so the large file can be retrieved when it needs to be accessed.
28
285541 31-Aug-13 PU
Additional information collected from the incoming Message Routing call. componentID: Identifier of the caller component, so that the query result can be routed to it. from: Identification of the sending user. to: Identification of the recipient user. Response-Format:
Figure 22 DB Connector: Response XML Schema
Data elements commandResult: Result of the command executed (OK, ERROR) commandResultDescription: If error, this field describes the cause of the error, so the upper process can be informed resultData: The C_UD operation(s) itself. It contains a name descriptor and an attribute describing if the value is encoded or not. In the case of large files, a PREMANUS Gateway uses the Message Routing features for large attachments that allows temporary storage of the file, and uses a URI reference to the source data parameter, so the large file can be retrieved when it needs to be accessed. Additional information embedded in the Message Routing message response. commandID: Unique Identifier for the current query, it can be used to access an operation log. from: Identification of the sending user. to: Identification of the recipient user. 4.3.3.3 DB Connector Storage data formats
In order to describe and store all the information that the DB Connector deals with the definition data model below is used. A database based on MS SQL Server is used to store this descriptive data that is used to track back all the data, the sources, the queries and the messages.
29
285541 31-Aug-13 PU
Figure 23 DB Connector: DB Connector Storage Object Model Description
Publishers This table contains the description of all information publishers. PublisherID: Autocreated Unique ID PublisherUID: Unique publisher name isOnline: Online-indicator LastPublishDate: Date of the last publication URL: For webservice-publishers this is the callback URL address Queries This table contains the queries sending to the publisher and the responses of the publisher. QueryUID: Query unique ID PublisherID: Publisher ID (Table PUBLISHERS) Query: the query itself Response: the response to the query InQueryDate: Query incoming date OutQueryDate: Query sending date InResponseDate: Response incoming date OutResponseDate: Response sending date Queue This table temporary contains the publications received from publisher. MessageID: Auto-generated Unique ID Message: the message itself
30
285541 31-Aug-13 PU
Errorlog This table contains a log of the errors produced in the DB Connector. ID: Auto-generated Unique ID Action: the description of the Action to be carried out Date: Error date ErrorNr: Error Number ErrorText: Error Text
4.4
Security Annotator
Access control is central to every access to the data repositories. Much of the information stored may be accessible only to certain users even though they may belong to the same organization or working team. As such, this data should be subject to privacy and confidential access controls. When the DB connector receives the request for accessing any data, it checks the Security Annotator to see if the requestor has granted permissions to access that particular data. In the case that the requestor does not has access to that data an error message is sent back to the requestor stating a Denial-of-Service (DoS). Thus, the Security Annotator is responsible for storing the mappings between the information and the Role Based Access control. Typically, the source of the concepts to which the information has to be annotated is in the form of ontologies. Figure 24 depicts the structure of the Security Annotator. In that figure, the following sub-components are listed: " " " Annotation Engine Data Management and Annotation Repository Interface with the SSB, including the message dispatchers/receivers
Figure 24 Security Annotator: Overview
31
285541 31-Aug-13 PU
4.4.1 4.4.1.1
Architecture Annotation Engine
The Annotation Engine manages the generation of mappings between the source information and the relevant ontologies. In the case of PREMANUS, these ontologies refer to QLM and other ontologies coming from the industrial area where the system is installed, if they exist, and also Security ontologies. These mappings are used for accessing the information. The Engine gets the schema of the source information, loads the ontology against which the source information is going to be annotated and finally, with the help of the user it performs the mapping and stores it in the Annotation Repository. As an example, when the Information Provider inserts new (changes or deletes) information into his ERP, the DB Change Monitor checks that data source and propagates these changes to the rest of the System. Part of this information is annotated as publishable to certain recipients with the help of the Engine into the annotation repository, i.e. the Data Management and Annotation. 4.4.1.2 Data Management and Annotation Repository
This repository is where the annotated information is stored together with the annotations. 4.4.2 Diagrams
The following figure (Figure 25) represents the Activity Diagram of the Security Annotator Component of PREMANUS:
Figure 25 Security Annotator: Activity Diagram
32
285541 31-Aug-13 PU
The next figure (Figure 26) gives an overview of the internal component communication.
Figure 26 Security Annotator: Sequence Diagram
When an annotation request is received, the Security Annotator component is responsible for receiving the message. The component then calls the functionalities that interacts with the Data Management and Annotation Repository and the Ontologies in order to store/retrieve all the information describing the annotations. This is done in the following steps: " " " 4.4.3 4.4.3.1 In the first step, the engine retrieves the different ontologies present in the PREMANUS system for performing the operations. In the second step, the annotation of the requested concepts is performed against the concepts represented in the relevant ontologies. Finally, the annotation is stored. Specification of Interfaces, Protocols and Formats API specification
Figure 27 Security Annotator: Service Interfaces (provided and needed)
33
285541 31-Aug-13 PU
4.4.3.2
Content Formats and Protocols Definitions
An XML document is used to transfer data to the Security Annotator via the interface. The XMLschema shown below contains all the necessary parameters for invoking the API method specified in the sections above. Security Annotator message format XML/Schemas http://www.premanus.eu/xmlSchema/Annotation/AnnotationReq.xsd http://www.premanus.eu/xmlSchema/Annotation/AnnotationResp.xsd Request-Format: An XML document is used to transfer data from a PREMANUS component to the Security Annotator, by means of the Message Routing functionality. The messages following the XMLschema shown below is transferred as payload of the Message Routing call. It contains all needed parameters for invoking the API method specified in the sections above.
Figure 28 Security Annotator: Request XML Schema
Data elements annotationID: Unique identifier of the annotation to be performed. This ID is used to retrieve the details and auxiliary files needed to perform the annotation by the Engine. sourceData: It is the data to be annotated against the relevant ontology concepts. This structure contains a name attribute and an encoding attribute, describing if the value data is encoded (base64) or not. In the case of large files, a PREMANUS Gateway uses the Message Routing features for large attachments that allows temporary storage of the file, and uses a URI reference to the source data parameter, so the large file can be retrieved when it needs to be accessed. Additional information collected from the incoming Message Routing call. componentID: Identifier of the caller component, so that the annotation result can be routed to it. from: Identification of the sending user. to: Identification of the recipient user. Response-Format:
34
285541 31-Aug-13 PU
Figure 29 Security Annotator: Response XML Schema
Data elements commandResult: Result of the command executed (OK, ERROR) commandResultDescription: If error, this field describes the cause of the error, so the upper process can be informed resultData: The data annotated against the relevant ontologies. It contains a name descriptor and an attribute describing if the value is encoded or not. In the case of large files, a PREMANUS Gateway uses the Message Routing features for large attachments that allows temporary storage of the file, and uses a URI reference to the source data parameter, so the large file can be retrieved when it needs to be accessed. Additional information embedded in the Message Routing message response. commandID: Unique Identifier for the current annotation carried out and can be used to access an operation log. from: Identification of the sending user. to: Identification of the recipient user. 4.4.3.3 Data Management and Annotation Repository data formats
In order to describe and store the annotation operations the definition data model below is used. A database based on MS SQL Server is used to store the descriptive data. This descriptive data refers to not only specific stored XML files that describe the source and destination formats, the mapping files, and other auxiliary files if necessary, but also the information related to the permissions to access the data by the users.
35
285541 31-Aug-13 PU
Figure 30 Security Annotator: Data Management and Annotation Repository Object Model Description
Annotation This table contains the records of the annotation activities carried out. uniqueID: Unique Identifier for the record idStream: Unique Identifier for the data source metadata: Describes the annotation performed sourcePID: Every annotation activity has a source, meaning the concept on the data source. As this data source is registered in the PREMANUS system, it has to be identified by a PREMANUS ID. Then, this attribute refers to this PREMANUS ID Users This table contains the list of the users who have access to the PREMANUS Gateway. userID: Unique Identifier of the user PermissionUsers This table contains a cross list of annotation activities against the users who have access to them and the role they play in this access. uniqueID: Unique Identifier of the record (FK to table Annotation) userID: Unique Identifier of the user role: role of the userID against the uniqueID record AnnotationFile This table contains a list of the annotation files (if necessary). uniqueID: Unique Identifier of the annotation (FK to table Annotation). fileID: Identifier of the Annotation File. fileType: Type of the Annotation File. Errorlog This table contains a log of the errors produced in the Security Annotation component. ID: Auto-generated Unique ID Action: the description of the Action to be carried out
36
285541 31-Aug-13 PU
Date: Error date ErrorNr: Error Number ErrorText: Error Text
4.5
Transformation
The Transformation component manages the transformation of information between different data content formats, i.e. from the format or the schema of the data store where it is located is transformed into any other ontology that can be the target format that was defined during the registration phase. Figure 31 depicts the structure of the Transformation. In that figure, the following sub-components are listed: " " " Transformation Engine Transformation Repository Interface with the SSB, including the message dispatchers/receivers
Figure 31 Transformation: Overview
The main functionality of this component is to transform external data formats, typically message serial formats like XML, sent through the PREMANUS Gateway (e.g. by ERPs), to be used by internal PREMANUS components, such as the BDSS. The Transformation services are typically invoked by the BDSS but can also be invoked by other components within PREMANUS wherever they have a need for data transformation. The descriptions of the available transformations are published in the Transformation Repository component so the different components can know about them. Transformation is a feature with a specific vocabulary as follows: " " Transformation is the total actions necessary to convert syntax or content A(s) into syntax or content B(s) (the s is used since there can be multiple inputs and outputs). Mapping is the design time act of creating the commands/instructions/code to make this conversion. Typically, a mapping file contains the source schema, output schema and the linkage between them both. The mapping file format is specific to the Translation engine.
37
285541 31-Aug-13 PU
4.5.1 4.5.1.1
Architecture Transformation Engine
The Transformation Engine manages the execution of the transformations needed for changing the source format to the target format. These transformations are based upon the mappings generated when the information data source was first registered into the PREMANUS system. The Engine contacts the Transformation Repository to: " " " Obtain the mapping file where all the elements are described. Obtain the executable Link Plan Object (LPO) file of the transformation where all the rules are described. Store the mapping files and the LPO files in the repository when sent by other PREMANUS components.
The Transformation Engine tries always to conduct a transformation by executing the LPO code. If the Transformation Engine tries to get the LPO file and the repository cannot find a unique response, it returns the different mapping files so the Engine can select the most appropriate. Usually, this selection is made by the end user. 4.5.1.2 Transformation Repository
This repository is where the files necessary for the execution of the transformation are stored. As stated in the previous section, there are two types of files stored in this repository. These mapping files are executed by an external translation engine to perform the transformation. The files are the following: " The mapping file. This file contains the relationship of the schema of the information data sources connected to the PREMANUS system and the QLM data model. It is used for disambiguation between concepts. The executable LPO that is the executable version of the mapping file. It is used by the Engine for executing the transformations.
"
38
285541 31-Aug-13 PU
4.5.2
Diagrams
The following figure (Figure 32) represents the Activity Diagram of the Transformation Component of PREMANUS:
Figure 32 Transformation: Activity Diagram
Figure 33 Transformation: Sequence Diagram
When a transformation request is received, the Transformation Engine is responsible for receiving the message. The Transformation Engine then calls the functionalities that interact with the Transformation Repository in order to retrieve all the information describing the requested transformation action. This is done in two different steps:
39
285541 31-Aug-13 PU
" "
In the first step the information describing the transformation operation is retrieved (metadata) In the second one, and based on the results of the first step, the files containing the transformation format descriptions and the mapping files are retrieved.
With all this information and the source data to be transformed, the Transformation Engine performs the translation itself. The Engine gets the result of this operation (the data in the new format, or an error). This result is wrapped in the format of a Transformation Component call return message, and is delivered to the Message Routing component, that returns the result to the caller component. 4.5.3 Specification of Interfaces, Protocols and Formats
The Transformation Component uses the Message Routing API to communicate with other PREMANUS components. The interfaces are called using Web Service commands (XML based) within the message. The following section describes the internal API specification that is used after the interpretation of the message. 4.5.3.1 API specification
Figure 34 Transformation: Service Interfaces (provided and needed)
4.5.3.2
An XML document is used to transfer data to the Transformation Engine via the interface. The XMLschema shown below contains all the necessary parameters for invoking the API method specified in the sections above. Transformation Service message format XML/Schemas http://www.premanus.eu/xmlSchema/Transformation/TransformationReq.xsd http://www.premanus.eu/xmlSchema/Transformation/TransformationResp.xsd Request-Format: An XML document is used to transfer data from a PREMANUS component to the Transformation, by means of the Message Routing functionality. The messages following the XML-schema shown below
40
285541 31-Aug-13 PU
is transferred as payload of the Message Routing call. It contains all needed parameters for invoking the API method specified in the sections above.
Figure 35 Transformation: Request XML Schema
Data elements transformationID: Unique identifier of the transformation definition to be performed. This ID is used to retrieve the details and auxiliary files needed to perform the transformation by the Engine. sourceData: It is the data to be transformed into the required format. This structure contains a name attribute and an encoding attribute, describing if the value data is encoded (base64) or not. In the case of large files, a PREMANUS Gateway uses the Message Routing features for large attachments that allows temporary storage of the file, and uses a URI reference to the source data parameter, so the large file can be retrieved when it needs to be accessed. Additional information collected from the incoming Message Routing call. componentID: Identifier of the caller component, so that the transformation result can be routed to it. from: Identification of the sending user. to: Identification of the recipient user. Response-Format:
Figure 36 Transformation: Response XML Schema
41
285541 31-Aug-13 PU
Data elements commandResult: Result of the command executed (OK, ERROR) commandResultDescription: If error, this field describes the cause of the error, so the upper process can be informed resultData: The data transformed into the required format. It contains a name descriptor and an attribute describing if the value is encoded or not. In the case of large files, a PREMANUS Gateway uses the Message Routing features for large attachments that allows temporary storage of the file, and uses a URI reference to the source data parameter, so the large file can be retrieved when it needs to be accessed. Additional information embedded in the Message Routing message response. commandID: Unique Identifier for the current transformation operation, it can be used to access log of operation. from: Identification of the sending user. to: Identification of the recipient user. 4.5.3.3 Transformation Repository data formats
In order to describe and store the transformation operations, the definition data model below is used. A database based on MS SQL Server is used to store the descriptive data. This descriptive data refers to specific stored binary files that describes the source and destination formats, the mapping files, and other auxiliary files if necessary.
42
285541 31-Aug-13 PU
Figure 37 Transformation: Transformation Repository Object Model Description
The transformation description data is used by the BDSS when making a request for transformation of a data element. This same data is also used by the Transformation Engine itself when called, as it needs to retrieve all auxiliary data from the Transformation Repository component to send it to the Engine. TransformationDefinition This table contains the description of the Transformation itself. UUID: Unique ID description: A human-readable description of the transformation timestamp: A date/time value specifying when this transformation was uploaded version: A version value for tracking back the transformations DataFormat This table contains a description of the data formats involved in the transformation. ID: ID of the transformation description: A human-readable description of the transformation
43
285541 31-Aug-13 PU
type: an indicative if the data format is whether an input or output data format MappingFile This table contains a description to the mapping file. UUID: Unique ID engine: a reference to the transformation engine version: a version value for tracking back the different updates of the mappings OtherFiles This table contains a description of other files valuable for carrying out the transformation. UUID: Unique ID description: A human-readable description of the purpose of the file File This table contains the list of files to be used for the transformation. FileID: An identifier to the file url: an URI pointing to the file Messages This table contains the content used to generate the Transformations. MessageID: Autocreated Unique ID OriginalMessage: An XML containing the original message TransformedMessage: An XML containing the message already transformed by TNS PremanusID: An XML containing the PREMANUS ID provided by IDMGMT Transferred: a datetime providing when the transformation was performed Errorlog This table contains a log of the errors produced in the DB Connector. ID: Auto-generated Unique ID Action: the description of the Action to be performed Date: Error date ErrorNr: Error Number ErrorText: Error Text
4.6
Information Publisher
The Information Publisher is responsible for distributing the data that is available to the rest of the system. The main difference between an Information Broadcaster and a Publisher relies on the fact that the first one distributes the data to all connected recipients while the second one communicates that there is data available to just one recipient: the PREMANUS Information Directory. The main tasks that are responsibility of this component are the following: " Generate the advertisements with the information communicated by all the DB connectors within the PREMANUS Gateway
44
285541 31-Aug-13 PU
" "
Aggregate the Advertisements to conform a Feed and publish it following the ATOM specifications Send the Feed to the Information Directory in the PREMANUS Cloud for registration.
Figure 38 Information Publisher: Overview
Figure 38 depicts the structure of the Information Publisher. In that figure, the following subcomponents are listed: " " " " " 4.6.1 4.6.1.1 Interface Advertisement Generator Feed Merger Feed Dispatcher Feed Repository. Architecture Advertisement Generator
The Advertisement Generator receives the data from the DB Connector using TSB. Then, the generator sends the incoming data to the Transformation Manager to obtain the transformed data and to the Annotator to obtain the necessary security information. After the responses have been received from the Transformation Manager and Annotator, the Advertisement Generator generates the Advertisements and stores them in the Advertisement table. The Advertisement Generator receives the data from the DB Connector via the SSB. The data propagated by the source component is composed of the source of the data and the content that has been C_UD (created, updated or destroyed). After some internal procedures, meaning the transformation of the information received according to the QLM data model and the request of the
45
285541 31-Aug-13 PU
Security aspects (i.e. Access Control), the generator creates the Advertisement itself following the structure specified in Section 7.2 (see Figure 39): " PID: Is a PREMANUS ID of an individual product or product model and has the role of the Advertisement ID. It is composed of a set of traceable IDs (Owner, Model and Product ID) to easily find the Product Information it refers to Owner: Defines the source of the information QLMList: A list of UDEF items identifying the type of information accessible Access InfoList: A list of items defining user access criteria and the security restrictions applicable to the propagated data.
" " "
Advertisement -PID [Owner:Model:ID] - Owner - QLMList[ UDEF1 UDEF 25 UDEF ab ] -Access InfoList [ Address Method Security ]
One UDEF hints to the existence of a part of relation in the system
Figure 39 Information Publisher: Structure of the Advertisements
4.6.1.2
Feed Generator
As its name indicates, the Feed Generator manages the generation of the Feed file for final publication. When the specified time interval expires, the Generator looks for the newly generated Advertisements (and the old ones that are still not published) and generates the Feed file by combination. Once the Feed is built, it is sent for final publication in the Information Directory (in the PREMANUS Cloud) and the Advertisements sent for publishing are marked as published in the Information Publisher Store. 4.6.1.3 Feed Dispatcher
There exist two clear alternatives when the dispatch of a feed is needed, i.e. pushing and pulling the information. There are advantages and drawbacks to both models and the behavior of the component is influenced by the selection of the dispatching mode. The primary difference between push and pull techniques lies in how the information consumers are informed about information changes. In the case of PREMANUS, there is only one information consumer, which is the PREMANUS Cloud. In pushing, the idea is to publish actively the information from the source to the destination. On the other hand, in pulling, the idea is to wait for a request from the destination component for new information that has not been yet published. In other words, push is the technique for taking the information to the consumers, i.e. the Cloud, while pull is the technique to get the consumers to come to the publisher requesting for new information. In the case of the pulling, two main drawbacks are (i) the overload of the system caused by continuous requests from the Cloud to every Information Publisher present in every PREMANUS Gateway connected, and (ii) if urgent/important information is to be published, it has to wait for the next requesting time. However, an advantage is that it is possible to define requesting timeframes and
46
285541 31-Aug-13 PU
perform batch requests to all the Gateways at the same time and specific tasks to process all the feeds at the same time. On the other hand, the pushing has also drawbacks and advantages. A clear drawback is the fact that the cloud has to process the feeds as it receives them. However, the advantages rely on the fact that pulling was failing: urgent/important information can be duly dispatched and it does not cause a system overload with the extra requests coming from the PREMANUS Cloud. The intention of PREMANUS is to develop first the pushing approach. However, it is not the intention of the project to reject the other alternative. Accordingly, the diagram shown in Figure 41 is valid for both approaches. The triggeringSignal() shown in the diagram can be either an internal counter meaning that the limit of pending Advertisements has been reached or a time alarm has been fired or a request from the PREMANUS Cloud. Then, the Feed is prepared, packed, and sent to the Information Directory (located in the PREMANUS Cloud) so all the data likely to be published is communicated to all the potential information consumers. In addition to these activities, i.e. prepare, pack, and send, the Feed Dispatcher also marks the Feed as delivered and finally changes that status in the Feed repository for future eventual tracking. 4.6.1.4 Information Publisher Store
The Information Publisher Store comprises a series of tables where the information generated in this component, i.e. the Advertisements and the Feeds, can easily be tracked. It also contains a log for errors for the eventual case any corrective action might have to be taken. The Advertisement generated can be used for eventual regeneration of already published feeds. This store does not distinguish between temporary and published information from the storage point of view. The information is distinguishable from the access to the content point of view since it is created as temporal by nature and thus stored in the repository. It is only when the information has been dispatched that it is marked accordingly and, therefore, its status changes to published.
47
285541 31-Aug-13 PU
4.6.2
Diagrams
The following figure (Figure 40) represents the Activity Diagram of the Information Publisher Component of PREMANUS:
Figure 40 Information Publisher: Activity Diagram
Figure 41 Information Publisher: Sequence Diagram
When a publication request is received, the Information Publisher is responsible for receiving the message. This component then calls the functionalities for generating the Advertisement, the Feed and carrying out the Publication itself. This is done through the following steps: " " In the first step, the request arrives to the Advertisement Generator. It creates the Advertisement with all the information needed (metadata). In the second step, this advertisement is sent to the Feed Merge. This merges the current temporary feed (by retrieving it from the Feed Repository) with the information contained in the Advertisement. This temporary feed is stored back in the Repository again.
48
285541 31-Aug-13 PU
" "
A third step consists on when a timeout is reached; the Feed Merger retrieves the temporary feed (stored in the Feed Repository) and prepares it for dispatching. In the fourth step, the Feed Dispatcher sends the temporary feed for publication to the PREMANUS Cloud and finally deletes the temporary feed from the Feed Repository. Specification of Interfaces, Protocols and Formats API specification
4.6.3 4.6.3.1
Figure 18 represents the Information Publisher service interfaces that are provided by the component itself and that are also needed for the normal execution of the component.
Figure 42 Information Publisher: Service Interfaces (provided and needed)
4.6.3.2
An XML document is used to transfer data to the Information Publisher component via the interface. The XML-schema shown below contains all the necessary parameters for invoking the API method specified in the sections above. Information Publisher message format XML/Schemas http://www.premanus.eu/xmlSchema/Publication/PublicationReq.xsd http://www.premanus.eu/xmlSchema/Publication/PublicationResp.xsd Request-Format: An XML document is used to transfer data from a PREMANUS component to the Information Publisher, by means of the Message Routing functionality. The messages following the XML-schema shown below is transferred as payload of the Message Routing call. It contains all needed parameters for invoking the API method specified in the sections above.
49
285541 31-Aug-13 PU
Figure 43 Information Publisher: Request XML Schema
Data elements publicationID: Unique identifier of the publication to be performed. This ID is used to trace the details of the publication itself. sourceData: It is the data to be published. This structure contains a name attribute and an encoding attribute, describing if the value data is encoded (base64) or not. In the case of large files, a PREMANUS Gateway uses the Message Routing features for large attachments that allows temporary storage of the file, and uses a URI reference to the source data parameter, so the large file can be retrieved when it needs to be accessed. Additional information collected from the incoming Message Routing call. componentID: Identifier of the caller component, so that the publication result can be routed to it. from: Identification of the sending user. to: Identification of the recipient user. Response-Format:
Figure 44 Information Publisher: Response XML Schema
Data elements commandResult: Result of the command executed (OK, ERROR) commandResultDescription: If error, this field describes the cause of the error, so the upper process can be informed
50
285541 31-Aug-13 PU
resultData: A message saying the data has been queued for publication. It contains a name descriptor and an attribute describing if the value is encoded or not. In the case of big files, a PREMANUS Gateway uses the Message Routing features for big attachments that allows to temporary store the file, and use a URI reference (URI Universal Reference Identifier) into the source data parameter, so the big file can be retrieved just in the moment of its use. Additional information embedded in the Message Routing message response. commandID: Unique Identifier for the current publication feed and it can be used to access log of operation. from: Identification of the sending user. to: Identification of the recipient user. 4.6.3.3 Feed Repository data formats
In order to store the temporary feeds a Feed Repository is envisaged. However, and given the fact that these feeds are only valuable for temporary activities, it is built as a typical folder. As such, this repository is unstructured and, because of its usage and the structure of the Advertisements and the Feeds, it stores ATOM-based files. 4.6.3.4 Information Publisher Storage data formats
In order to describe and store all the information that the Information Publisher deals with the definition data model below is used. A database based on MS SQL Server is used to store this descriptive data. This descriptive data is used to track back all the advertisements, the feeds and the messages.
Figure 45: Information Publisher: Storage Object Model Description
Advertisements This table contains the generated advertisements. AdvertisementID: Autocreated Unique ID AdvertisementUID: Unique advertisement ID
51
285541 31-Aug-13 PU
Date: Advertisements date Advertisement: The XML with the advertisement itself Feed This table contains the feed definition. FeedID: Auto-created unique ID FeedUID: Unique Feed ID DateFrom: feed start date DateTo: feed end date Published: a Boolean value stating whether the feed has been published or not Messages This table contains the content used to generate the Advertisements. MessageID: Autocreated Unique ID OriginalMessage: An XML containing the original message TransformedMessage: An XML containing the message already transformed by TNS SecurityInfo: An XML containing the security information provided by the Security Annotator Advertised: a Boolean value stating whether the advertisement has been created or not Errorlog This table contains a log of the errors produced in the DB Connector. ID: Auto-generated Unique ID Action: the description of the Action to be carried out Date: Error date ErrorNr: Error Number ErrorText: Error Text
4.7
Product ID Management and Mapping
Within any remanufacturing ecosystem, information about a single product might be available from several information providers. In order to link distributed information clearly to the single corresponding product, there must be a way to identify a product clearly. PREMANUS ID Management is responsible for identifying product instances and product line uniquely across the entire PREMANUS network. It is composed of two components, a local ID management component that keeps track of the mappings between the unique ID used in the network and any local ID that may exist. The second component is an ID management component in the cloud part of the RIS. This component is responsible for the resolution of information that identifies a product instance into a URN that is used to identify the product in the PREMANUS network. This component also matches incomplete/incorrect information against a central authority where companies register themselves and their product lines. Full details about product ID management and mapping are described in D3.1. In the PREMANUS prototype, the URN is an EPC ID. The central authority is replaced by a test
52
285541 31-Aug-13 PU
component; however in a real PREMANUS system that uses EPC ID, that authority would be GS1.
4.8
Interfaces with the SSB
All the components already listed in this section have to interact with the SSB. These components have to send and receive information to/from the rest of the components of the PREMANUS system. As such, the interface between them and the SSB must be simple, transparent and homogeneous. In this sense, the entry point to each component is exposed via a set of services and the exchange of information is made with the use of TSB Messaging System. Figure 46 shows how the connectivity of the components is performed.
Figure 46 Interfaces with the SSB
The process performed is the following: 1. The component requesting the execution of another component contacts the Web Service Client Input entry point by sending the parameters requested for the execution in the destination component. These parameters are sent in the form of an XML document. 2. The Web Service Client passes this XML document to the routing service of the TSB. 3. The routing service of the TSB sends the XML to the destination component. 4. The Process is executed and the response of the execution is sent back to the Requestor following the same procedure but this time using the Web Service Client Output entry point. 4.8.1 MessageTypes
A list of message types for distinguishing the different messages being sent through the SSB is provided so the workflow already implemented in the SSB can route them in a correct and transparent way. This list is not final and more message types can be added into it as long as the development process requires more interactions between components.
!"#$%&'()"*'+(,,-.(/0!(,'' ''''1' ''''''''2)3-$%4+(,,-.(''''''''''''''''''''''''''''''''''5'67' ''''''''2)89:"#$%,;(<=:<(!-<(:"#$%&->%9)''''''''''''''''5'?7' ''''''''2)89:"#$%,;(<=@()4+,./<-),89<*(4A9<:"#$%&->%9)''5'B7' ''''''''2)89:"#$%,;(<=@()4@(&"<%>0A9<:"#$%&->%9)''''''''5'C7'
53
285541 31-Aug-13 PU
''''''''2)89:"#$%,;(<=D(,(>@"#,&<%!>%9)'''''''''''''''''5'E7' ''''''''2)89:"#$%,;(<=F-$$#-&G=A((4'''''''''''''''''''''5'??7' ''''''''2)89:"#$%,;(<=F-$$#-&G=D(H"(,>/<-),89<*'''''''''5'?B7' ''''''''2)89:"#$%,;(<=F-$$#-&G=D(H"(,>@(&"<%>0''''''''''5'?C7' ''''''''IJF9))(&>9<=@()4K"(<0'''''''''''''''''''''''''''5'B?7' ''''''''IJF9))(&>9<=F-$$#-&G=L)F;-).('''''''''''''''''''5'CB7' ''''''''IJF9))(&>9<=F-$$#-&G=L)K"(<0''''''''''''''''''''5'CC7' ''''''''IJF9))(&>9<=F-$$#-&G=L)D(,!9),('''''''''''''''''5'CE' ''''MN
4.8.2
Classes description
The following figure (Figure 47) provides an overview of the different classes involved in the exchange of messages and information across the SSB.
Figure 47 SSB Class diagram
54
285541 31-Aug-13 PU
5 5.1
PREMANUS Cloud Overview
The PREMANUS Cloud is a central component independent of any particular stakeholder within the network. The PREMANUS Cloud collects information about available product lifecycle data within the PREMANUS ecosystem, processes queries for such data and provides additional functionality like ID Management and Access Control. The cloud mediates between a client BDSS system as the requesting system and the existing gateways as original data providers. Information about the existing remanufacturing data is organized by so-called advertisements. An advertisement specifies the type of product lifecycle data, the product or product group it is useful for and the system that offers the data. Those advertisements can be queried and the directory service forwards advertisements, which match query conditions to the requesting system. All stakeholders have access to the PREMANUS Cloud and all search requests for information within the PREMANUS network are processed by the PREMANUS Cloud. Direct contact between different PREMANUS stakeholders is only established once a search request has been answered and it has been determined that the stakeholder has relevant information. The PREMANUS Cloud consists of three components, the Information Directory, the ID Management Server and an Access Control Component. This section describes the architecture of the directory service, the provided interfaces and the structure. An assessment of different technologies to realize data persistency and the queries, and considers the data persistency used within the directory service.
55
285541 31-Aug-13 PU
5.2
Information Directory
/01234*+5206753,8+23.
9,,:67= 9,,:6",;5<+3*+520 %:>,3+5<4,0+67=
!"#$%&'( )*+,-*.
9,,:6!*3<,3
9,,:6$*0*;,3
9,,:
(@C<835D+520 $*0*;,3
?@,3.6/0+,31*8,
!"#$%&'(6AB5,0+
Figure 48 Overview of components in the RIS information Directory
The RIS Information Directory is composed of three major blocks of functionalities. The first major block of functionality can be summarized as indexing of available information. In this block of functionality, an overview of all available information within the network is established. In order to achieve this, each stakeholder, who wishes to share information, registers meta information describing the available information with the central Information Directory. In PREMANUS, this meta information is bundled into advertisements. Each advertisement details what information is available for one product type or instance. The stakeholder then bundles all advertisements into an advertisement feed, which is registered with the information directory. The second block of functionality is the search interface, accessible to all PREMANUS Clients through a well-defined web service interface. The search takes a PREMANUS ID (specified in the deliverable 3.1), representing a product type or product instance and optionally one or more UDEF IDs, which specify what type of information is needed about the product. The final block of functionality includes the ability to create subscriptions to a specific query, which will continuously update the client as new information about the product becomes available at the information directory. The subscription functionality will most likely not be implemented in the PREMANUS project prototype since our use case partners do not require it. 5.2.1 Information Indexing
The following is a summary of all components within the Information Directory, which are relevant for the information indexing process of the Information Directory. The individual advertisement feeds need to be registered with the information directory, retrieved for the first time, disassembled and the
56
285541 31-Aug-13 PU
contained information processed. Once a feed is registered, the information directory will periodically pull updates from the feed, to ensure the indexed information is always up to date. Feed Registration: This component provides an interface for information providers to register their information feeds with advertisements. A list of all registered feeds and who registered them is kept in the Feed Database. Feed database: Record of all registered advertisement feeds. Feed Manager: The Feed Manager regularly checks all registered feeds for updates and retrieves them if necessary in order to process new or deleted advertisements in an effort to keep the Information Directory up to date. Feed Parser: The Feed Parser disassembles retrieved Feeds and processes the individual advertisements and then stores them in the Advertisement Database. Advertisement DB: Record of all current advertisements from all registered PREMANUS Gateway systems and the information they provide. The following information flow diagram details how these components interact with each other and outsides systems like the PREMANUS Gateway:
!"#$%"& .$+,-#$.'$$(34".)516
'$$()*$+,-#."#,/0
'$$()12
-"4$517/12
8".)-9::$-8".)-9::$--
57
285541 31-Aug-13 PU
!"#$%"&
'$$()*"+,$+
-./,0+12#134)5"4"6$+
7(8$+#1,$9$4#:;
<19$+= >3"() /">"40$+
6$#'$$(?8"+)0+$($4#1">,@ A"+)'$$( 2"+,$'$$(?8"+)'$$(@
B1,#C"(8$+#1,$9$4#D ,"8$7(8$+#1,$9$4#,?B1,#C"(8$+#1,$9$4#D@
5.2.2
Search
The Search aspect of the Information Directory involves any component required for answering a PREMANUS Client query that wants to know what information is available for a product type or instance within the PREMANUS Network. The search process in the Information Directory involves the following components: Query Interface: The Query Interface provides PREMANUS Clients with a standardized interface, through which they can request advertisements about available information. The Query Interface searches the Advertisement Database for matching advertisements, gathers them and returns them to the client. Advertisement Database: The Advertisement Database holds all the advertisements gathered via the previous process, Information Indexing and is queries by the Query Interface for advertisement about specific products or documents.
58
285541 31-Aug-13 PU
!"#$%&
'($)*+%&$),-.$
'($)*8$)5#.$+69"
/($)*0.&!-"" :$&;-&-<5-)=/($)*>
1#2&3-45$)&#2$6$%&7
1#2&3-45$)&#2$6$%&7
5.2.3
Subscription
The last major functionality for the Information Directory is the subscription mechanism, where a PREMANUS Client can subscribe to updates for a particular query. Once new meta information about a product type or instance is uploaded to the Information directory, it is compared to a list of standing subscriptions in order to determine if there is a match. If a subscription is matched, the corresponding client is updated with the advertisements. The following components are involved in enabling the subscription functionality. Subscription Manager: The Subscription Manager allows PREMANUS Client to register for updates to a query. It keeps track of standing subscriptions and notifies the client when new information relevant to a registered query becomes available. Feed Parser: The Feed Parser notifies the Subscription Manager of new advertisements, which are about to be added to the Advertisement Database. If a subscription exists, the Subscription Manager will notify the client. The subscription functionality will most likely not be implemented in the PREMANUS project prototype since our use case partners do not require it. 5.2.4 Query types for the PREMANUS System
The PREMANUS cloud provides remanufacturing information required by the BDSS for two purposes: 1) an information worker wants to get an overview of all information available for a specific product 2) a BDSS algorithm requires a specific type of remanufacturing data. Based on the requirement engineering for the use cases of the application partners, the following queries must be supported by the PREMANUS Information Directory:
59
285541 31-Aug-13 PU
a. Standard case: Query for all available advertisements for a specific product by PREMANUS ID (manufacturer, product type, product ID). Form: Get all advertisements for PID b. Specific Information Query: Query for all available advertisements for a specific product that contain at least one UDEF out of a list of desired UDEFs. Form: Get all advertisements for PID which contain [udef_specifier] c. Product Type Query: Query for all available advertisements for a specific product type (or model). This query can be implemented by passing a shorter PREMANUS ID, that does not contain the product ID. Thus, this does not require a specific query. These required query types determine the requirements for the API and the data model of the Information Directory. Further, SQL-based queries shall be supported for development and testing purposes. 5.2.5 5.2.5.1 API APIs Management of Gateway Systems Description: a gateway system informs the PREMANUS component about its existance Input var: o FeedURL: URL which provides a Feed of existing data o accessURL: URL to be used to access the advertised data o Description: a short description of the system, e.g. name Return message: o Message about success or reason of failure.
Message registerDataSource(var FeedURL, var accessURL, var Description)
A gateway needs to offer the following REST services to be part of the PREMANUS ecosystem: DataFeed: A data feed provides information about the data available within the service. The service is checked regularly by the cloud component to check for new information getData (var requesterID, var requesterToken, var requestedAdvertisement): the service to provide data described in the advertisements
60
285541 31-Aug-13 PU
5.2.5.2
APIs Admin Services Description: Returns a list of all registered gateway systems Input var: o adminKey: key to assure that only admins use the service Return var: o An xml describing each connected data source, including a unique ID for each data source Description: Deletes a datasource from the list Input var: o adminKey: key to assure that only admins use the service Return var: o message about success or reason of failure
XML getRegisteredDataSources(var adminKey)
Message removeRegisteredDataSources(var dataSourceID )
5.2.5.3
APIs Query Management
The query management API is designed to answer the most important remanufacturing related queries based on the requirement engineering conducted for the application partner use cases. List<advertisements> query) getAdvertisements(var A generic SQL query to be sent to the system A query for all types of data relevant for a PID A query for a specific type of
List<advertisements> getAllAdvertisementsForPID(var PID) List<advertisements> type, var PID) 5.2.6 getDataTypeForPID(var
Directory Service Persistency Type
Persistency of advertisements within the directory service is realized based on a relational database, using the Java Persistency API. In the following, the chosen persistency is explained in detail. Then, an overview of alternative technologies which were considered is given. 5.2.6.1 Java Persistency API (JPA) and Relational Database
Relational databases structure data based on formally described tables. Based on keys given to data inputs and key-based joins of tables, complex data structures can be realized. The Java Persistency API (JPA) provides is an object-based persistency layer on top of a relational database. Persistency entities are POJO (Plan old java object). The abstraction facilitates the database handling for the developer and provides a concise interface to be used within an application. Queries: To query relational databases, the Structured Query Language (SQL) is the most common approach. SQL offers insert, update, delete and select commands and allows the concatenation of tables based
61
285541 31-Aug-13 PU
on join operations. Discussion for PREMANUS: The use of JPA especially benefits from the maturity of the used technologies and the support of the technologies within development environments. Especially the most common search query, the retrieval of advertisements based on a PID are very simple to realize with JPA. Search queries which focus on UDEF details are complex to realize with JPA. The UDEF structure needs to be decomposed and distributed within the object and the related data tables. The partonomic and hierarchical relations among UDEF concepts are not supported within JAP and relational databases. 5.2.6.2 Graph Database
Graph databases use graph structures, nodes, edges and properties, to represent stored data. From a theoretical perspective, graph databases follow graph theory. Different characteristics of graph based databases are very useful for the PREMANUS structure. UDEF is an inherently hierarchical structure which can be modeled easily within a graph structure. Disadvantages of graph based databases exist with respect to the maturity and the dynamicity of the structure. 5.2.6.3 Ontology
An ontology is a formal, explicit specification of a shared conceptualization1. A basic standard for ontology construction is RDF (Resource description framework), a directed, labeled graph data format (w3c). A graph is described based on triple descriptions of the form subject-verb-object. RDF does not include any semantics beyond the definition of types and classes. RDF-S extends RDF by semantics like subclass relations and the specification of explicit schemes for an ontology. RDF with formal reasoning capabilities taken from description logic are standardized in OWL (Ontology web language). Ontologies have been proven useful for application unrelated to the semantic web, in fact applications which require the simple, standardized exchange of machine-readable information while maintaining reasoning and data integration capabilities. Though, related to graph database, the degree of formalization and reasoning capabilities, one time given based on graph theory (graph databases) and one time given based on formal logic (e.g. description logic) are differences between the concepts. Ontologies are queried based on SPARQL (recursive acronym for SPARQL Protocol and RDF Query Language). SPARQL provides functions to retrieve and manipulate RDF data by describing basic graph patterns. Basic graph patterns are like RDF triples excepts that each elements may be a variable. Though the use of ontologies within PREMANUS provides obvious benefits. Specialization and partof relations are very common elements of bills-of materials. Nevertheless, there is extensive effort required to create and maintain an ontology for the remanufacturing sector which is applicable to all use-case partners. Further, it is unlikely that the manufacturing sector can agree on such an ontology. 5.2.7 PREMANUS Information Directory Data Model
Based on the insights gained from reviewing different options for the Information directory services persistency type, it was concluded that a standard relational database is sufficient for the PREMANUS
1
Gruber 1993 Gruber, Thomas R.: A translation approach to portable ontology specifications. In: Knowledge Acquisition 5 (1993), jun, Nr. 2, S. 199-220.
62
285541 31-Aug-13 PU
Information Directory. This section details a model for such a database of the Information Directory. The data model is used to store the information contained within the advertisement feeds and efficiently allow the Information Directory to execute queries for product information. Figure 49 shows the diagram of the data model of the Information Directory. The database consists of four tables: Feeds: The Feed table keeps track of all registered Feeds. Besides the information identifying the feed (ID, published and URL) it also includes a last updated parameter, which is used to keep track when the last update was processed by the information directory. Ads: The Ads (or Advertisement) table summarizes all advertisements from all feeds registered with the directory. The table includes the original xml version of the advertisement pulled from the feed. Product Information: The product information table is the main table queried during the search for product information. It contains the FPID, which identifies the product, the UDef which identifies which information is available for the product and an AdID which identifies which advertisement the information can be found in. FPID: The final table stores all Federated Product IDs, for which information is stored within the Information Directory. It can be used to match partial IDs in requests to a full FPID. The FPID can then be used in conjunction with the Product Information table to retrieve advertisements for the product.
Figure 49: Data Model of the Information Directory
63
285541 31-Aug-13 PU
If the prototype implementation will use a SQL-database and implement this data model, it will be described in D3.2. Another alternative is using Apache Solr2, an open source enterprise search platform that includes full-text search, hit highlighting, faceted search, dynamic clustering, database integration, and rich document (e.g., Word, PDF) handling3. Apache Solr would provide a sufficient performance for PREMANUS prototypes. Here, an explicit data model would not be needed, as Apache Solr would search directly within the advertisements, stored as XML-documents.
5.3
Role based Access Control
During the requirements analysis of PREMANUS it became clear, that role-based access control as a security mechanism is not sufficient. The reason is, that it is almost impossible for a company to manage all the roles of different parties and the rights these parties have to retrieve specific product information. Accordingly, a wider view needs to be taken. Sharing product information in an ecosystem needs to be driven always by a business process. For example a customer has purchased a product and therefore has the right to access specific product information. a customer has a service contract with the OEM and as such is entitled to up-to-date product information like firmware, documentation, etc. a maintenance service company is doing contracted maintenance for the OEM and as such is entitled to up-to-date product information like firmware, documentation, etc.
Accordingly, Figure 50 depicts how a higher-level business process drives the configuration of access rights and ensures a secure exchange of information.
2 3
http://lucene.apache.org/solr/ http://en.wikipedia.org/wiki/Apache_Solr
64
285541 31-Aug-13 PU
Figure 50: Security process for exchanging product data between organizations
First, a contract is created between an OEM (Manufacturer) and a product owner that creates the legal entitlement for the product owner for access to product information. In the following step, Intellectual Property Management manages the intellectual property rights owned by a company either they purchased rights, created rights, or licensed rights owned to other parties (see Figure 51). Within IPM the manufacturer owning the intellectual property for the product, creates a license for the product information for the product owner. This license is connected to the product information, stored in a Data Management System (DMS).
Figure 51: Functionality of Intellectual Property Management
65
285541 31-Aug-13 PU
Then the data is made available via the PREMANUS Gateway to the product owner. When the product owner requests the data, the PREMANUS Gateway will fetch the data from the DMS, encrypt the data using an Enterprise Rights Management System (ERM) and transmit the information to the product owner. At the product owner, a secure client is required to open the information. For this the secure client requests the users rights for the information from the ERM server, the ERM server provides the keys for decryption, and the user can open the document in a secure environment. PREMANUS will work within the standardization activities to standardize this process. Implementation of this process is outside the scope of the PREMANUS project.
66
285541 31-Aug-13 PU
6 6.1
PREMANUS Client Overview
The PREMANUS Client is used to provide business decision support and additional information to a remanufacturing stakeholder (Information Consumer) within the PREMANUS network. The PREMANUS Client includes a PREMANUS Gateway, which encapsulates any preexisting data sources and services, which the stakeholder wishes to integrate into the decision support system. Additionally the client has components, which handle the search for and retrieval of information from the rest of the PREMANUS Network to enhance the quality of the decisions support. The most important component of the Client is the BDSS or Business Decision Support System, which utilizes the data available from both the local Gateway and the Network to provide the remanufacturer with estimates and suggested actions during the remanufacturing process.
6.2
Business Decision Support System
The purpose of the BDSS is to support remanufacturers in their business decisions. To achieve this, a set of custom algorithms are developed, which utilize both pre-existing information, product information from the PREMANUS network and historic information about previously remanufactured products of the same type. The BDSS algorithms attempt to continuously improve themselves by comparing predictions made during the remanufacturing process with the actual results, recorded by the remanufacturer. For more details please see D5.1, D5.2, and D5.3. 6.2.1 Overview
The BDSS comprises three layers, which help realise the decision support for a stakeholders remanufacturing process. The three layers are the service layer, the application layer and the user interface layer. The service layer provides the application layer with the functionality and data it needs to compute the KPIs which power the business decisions. The application layer provides a framework for a collection of apps which compute KPIs and other algorithms necessary for the remanufacturing decisions. The complete or partial results of the apps are provided to the user interface layer through a series of web services. 6.2.1.1 Service Layer
The Service Layer is a framework for both standard PREMANUS Services like the PREMANUS Network, ID Management and the Product Data Store and specialized services, which are often use case specific services or more general services (for example a UDEF translation service). Versioning and dependencies of these services will be handled with OSGi. The modules of the service layer may also offer web services so that they can also provide their service to the UI Layer in addition to the Application Layer. From a MVC (Model-View-Controller) perspective, the Service Layer can be compared to the Model layer, since it provides the required information in QLM. 6.2.1.2 Application Layer
The Application Layer provides a framework for the BDSS apps, which represent the actual Business Decision Support algorithms and decisions. Individual apps can declare required and optional inputs and outputs, which are used to resolve the order in which apps are run. Apps can be bundled into an application which can provide a unified web service interface for the UI layer to user rather than
67
285541 31-Aug-13 PU
individual web service interfaces for each app. In MVC terms, the Application Layer is the controller. It provides the interface to the UI (the View) and controls the flow of execution. 6.2.1.3 UI Layer
The UI Layer of the BDSS is entirely use case specific and can be built on top of the web services provided by apps and/or applications running in the application layer. The web services of both apps and applications implement standardized methods, which provide utility for the UI layer, like progress reports, status methods and similar utility functions. 6.2.2 Service Layer (BDSS Base)
The BDSS Base provides an abstraction layer for the rest of the architecture to the BDSS algorithms running on top of the BDSS Base. It provides a framework and abstraction for standard PREMANUS services (like the Query Manager and the Product Data Store) and non-standard plugin services, which can provide both general and use case specific services to the BDSS algorithms. It also provides scheduling and information exchange for BDSS algorithms through a tuple space and web service interfaces for UIs to display and query the results of BDSS algorithms. 6.2.2.1 Application Framework
The Service Layer provides an Application Framework for BDSS Algorithms. The Application Layer is based on OSGi and thus allows for easy integration of Services into the BDSS Algorithms through OSGis dependency management. Applications within the framework consist of a number of Apps. Each App encapsulates a reusable subpart of the Application. Applications can also export Web services for use with a UI technology. Additional Details about the Application framework can be found in the appendix. 6.2.2.2 Services
The service layer includes both standard PREMANUS components like the Product Data Store, the Query Manager or ID Management components and more use case specific services, like for example a service which provides quotes for recycling or a UDEF translation service. Each service is an OSGi Bundle which exports an Interface. The Interface can be used by the apps of the application layer or other services in the service layer. Each service may also provide web services for its functionality, which allows UIs in the UI Layer to utilize the service. 6.2.3 Application Layer (BDSS Algorithms)
The Application Layer provides a framework for BDSS Apps to run on, declare their dependencies on services or results from other Apps, as well as declare their own outputs and web service interfaces. Apps may also be grouped into an application which simplifies the web service interface and integration with the UI Layer.
68
285541 31-Aug-13 PU
Figure 52: BDSS Layer Interaction
Figure 52 depicts how the different BDSS Algorithms interact via the BDSS Base Layer. An initial algorithm will first request all product information available in the PREMANUS network and store it in the BDSS Product Data Store. Then an initial algorithm will select similar past remanufacturing jobs from history from the BDSS Product Data Store. Another algorithm might estimate parameters for the next algorithms as input. Then the economic and ecological efficiency optimizer will suggest the best remanufacturing option. After remanufacturing, the manufacturing execution (ME) system will store the actual remanufacturing costs for the job, in order to enable a comparison of estimation versus actual values. Finally, a learning algorithm will improve all involved algorithms based on the new findings. 6.2.3.1 Apps inputs and outputs
In order to ensure that apps run in the correct order, each app can define required inputs and optional inputs. An app will not start until all required inputs are available, but will start without the optional inputs. If optional inputs become available while the app is running, they will be delivered to the app. Each app also defines its outputs, both guaranteed and optional. Guaranteed outputs are always produces if the app runs, while optional outputs may or may not be produced. Using the set of inputs and outputs, the Application Layer can ensure that there is a valid order for the apps to run in. The Application Layer keeps track of currently produced outputs and schedules apps which have all required inputs available to them. 6.2.3.2 Web Services
Each app can provide web services, which allows the UI layer to access the results of the app or query the app for results. The web services are partially standardized, meaning they always include certain functionality like a modified method, which allows the UI to check for new information available from the app as well as methods indicating the current status of the app (starting, running, finished). Apps may also be combined with other apps into an application, which represents a more complex process then a single app by itself. The application then provides one unified web service interface,
69
285541 31-Aug-13 PU
which simplifies the interaction with the UI Layer. The provided web services also allow an app to be used like a service, by declaring only optional inputs. Without required inputs, the tuple space will start the app immediately and the UI can request information through the web services. The app can then add input requirements to the tuple space, request the information required for the UIs web service request. Optionally the app may use a service from the Service Layer to gather the information it needs.
6.3
PREMANUS Gateway
Each PREMANUS Client also includes a PREMANUS Gateway. The Gateway maintains the same functionality as a standalone Gateway, but additionally it is also used to supply the rest of the PREMANUS Client directly with the information of the owning stakeholder, without contacting the Information Directory first. The PREMANUS Gateway has no additional components when it is part of the PREMANUS Client so for a detailed description of the components please refer to chapter 4 PREMANUS Gateway.
6.4
Information Manager
The Information Manager is responsible for resolving information requests with the help of the PREMANUS Network. It coordinates both phases of information gathering, the information search in conjunction with the PREMANUS Cloud and the information retrieval with the target PREMANUS Gateways. The following sections introduce the internal architecture of the Information Manager and its interfaces with other components. 6.4.1 Architecture
The Information Manager interacts with four major components of the PREMANUS Architecture (Product Data Store, Information Directory, Gateway and the BDSS). The core of the Information Manager is the Coordinator, which processes all request for advertisements and information and interfaces with all other components of the Information Manager and the overall PREMANUS architecture to fulfil the request.
70
285541 31-Aug-13 PU
91::&9(;#
91::&5)/#$6(2#
!"#$%&'()(*#$
>$,-"2/ 1(/# :/,$#
!"#$%&+,,$-.)(/,$ :"?;2$.@/.,); +4,"5)/#$6(2#
5)6,$=(/.,) 1.$#2/,$%
01&+(23#
<,2(4&7(/#&5)6,$=(/.,) 1.$#2/,$%
7(/#8(%&5)/#$6(2#
<,2(4&7(/#8(%
7(/#8(%
Figure 53 Overview of Clients Query Manager Component
The Information Manager runs as a service in the BDSS service layer and supports the BDSS by finding the information the BDSS needs for its computations. The BDSS can query the Information Manager with an URN, which represents a unique product instance and a list of UDEFs. The Information Manager contacts the RIS Information Directory and tries to find advertisement for the requested information and retrieves them. The advertisements are stored in the Product Data Store and returned to the BDSS so it can select which information should be fetched from the corresponding stakeholders gateway. The Query Coordinator then contacts the gateway, retrieves the data, stores it in the Product Data Store and returns a reference to the data to the BDSS. A more detailed explanation of this process can be found in the following sections. 6.4.1.1 Query Coordinator
The Query Coordinator is the intelligence of the Query Engine, while the other components just interface with the various systems/components that hold the information requested. The Query Coordinator receives the function calls from the Query Engine Interface and fetches the required advertisements and the corresponding information from the PREMANUS Cloud and Gateway respectively. It also controls the storage and caching of both in the Product Data Store.
71
285541 31-Aug-13 PU
6.4.1.2
Subscriptions
The subscriptions component registers and stores all subscriptions that the BDSS requires for its computations. It is notified by the Information Directory if any updates occur that apply to a standing subscription (this happens through the Cloud Interface). The Subscription component then notifies the subscribing BDSS App. The subscription functionality will most likely not be implemented in the PREMANUS project prototype since our use case partners do not require it. 6.4.1.3 Local Gateway Information Directory
The Local Gateway Information Directory is similar to the PREMANUS Cloud Information Directory, but with reduced functionality. It only fetches and stores advertisements from the local gateway component, which is part of the PREMANUS Client. Its purpose is to make local data available to the Query Manager during queries. The interfaces of the Local Gateway Information Directory are identical to the PREMANUS Cloud Directory and can be found in chapter 5 PREMANUS Cloud. 6.4.1.4 Cloud Interface
The cloud interface is responsible for handling communication with the RIS cloud component. The goal of the interface is to hide the complexity of the web service calls required for communication with the PREMANUS Cloud and present a simpler Java interface to the Query Coordinator. It also exposes a web service where the Information Directory can notify the Query Manager about updates to existing subscriptions. 6.4.1.5 Gateway Interface
Similar to the RIS interface, the main task of the Gateway interface is to handle the communication overhead with the gateway systems in the PREMANUS network. 6.4.1.6 BDSS Information Service
The BDSS Information Service runs as an OSGi Service in the BDSS Service Layer as one of the PREMANUS standard services. Any apps or other services running in the BDSS can utilize the Query service to find and retrieve information from the PREMANUS network and store it in the PDS. 6.4.2 Interactions and Processes
The two major processes of the Query Manager are the process of discovering available information in the PREMANUS Cloud for a BDSS App and retrieving specific pieces of discovered information for an App. 6.4.2.1 Information Search
In this process, a BDSS App request information from the PREMANUS network about a certain product type or product instance. The request is send to the Information Service running in the Service Layer of the BDSS. The Service forwards the request to the core of the Query Manager, the Query Coordinator. The Coordinator contacts the Information Directory via the Cloud Interface to search for available information for the provided ID. Finally, the Information Directory returns its results, which are stored by the Query Manager in the Product Data Store and then returned to the BDSS App. The following sequence diagram illustrates this process:
72
285541 31-Aug-13 PU
!"##$%&&
'()*+,-./*($#0+1/20
340+5$6**+7/(-.*+
68*47$'(.0+)-20
'()*+,-./*($"/+02.*+5
:0-+2;$'()*+,-./*($<9'"=
:0-+2;$<9'"=
:0-+2;$<9'"=
:0-+2;$<&/7=
<>"?@:=
<>"?@:=
<>"?@:=
9+*742.$"-.-$#.*+0 #.*+0$<>"?@:=
:.*+0$<>"?@:=
6.4.2.2
Information Search Subscription
This process saves a subscription within the Query Manager and the Information Directory, in order to receive updates about new available data for a specific ID. Once new information becomes available, the Information Directory notifies the Query Manager about the newly available UDEFs. The Query Manager then matches the information with the callback of the subscriber and initiates the callback of the BDSS App, which owns the subscription.
!"##$%&&
'()*+,-./*($#0+1/20
340+5$6**+7/(-.*+
#4892+/&./*($:-(-;0+
#4892+/&./*($"!
6<*47$'(.0+)-20
'()*+,-./*($"/+02.*+5
94892+/80=>'"?$6-<<8-2@A
94892+/80=>'"?$6-<<8-2@A
94892+/80$=>'"?$6-<<8-2@A
9.*+0=>'"?$6-<<8-2@A
94892+/80=>'"A
94892+/80=>'"?6-<<8-2@B0890+1/20A
90-+2HD&7-.0=>'"?$D"EF9?$%22099'()*A
4&7-.0$C>'"?$D"EF9?%22099'()*G
!"##$%&&$6-<<8-2@
;0.#4892+/80+6-<<8-2@=>'"A
;0.=>'"A
9.-+.6-<<8-2@CD"EF9G
=6-<<8-2@A
=6-<<8-2@A
6.4.2.3
Information Source Subscription
An additional option for subscription is allowing a client to subscribe for information from a specific source. In this case the cloud would keep track of the information from a specific source and information the client whenever and update is available. However, this update feature will only concern new types of information rather than updates to specific information about a product instance. This is because the information directory only tracks changes in meta-data not actual data. This
73
285541 31-Aug-13 PU
feature will most likely not be implemented in the prototype since our use case partners do not require it. 6.4.2.4 Information Retrieval
The last major process within the Query Manager is the retrieval of information upon request of a BDSS App. The Query Manager looks up the access information for the request and contacts the PREMANUS Gateway specified in the access information and request the required information and additionally the identification of the client running the Query Manager. The PREMANUS Gateway then decides if the request comes from a valid and authorized PREMANUS member and returns the requested data. The Query Manager stores the data in the Product Data Store and returns to the BDSS App.
!"##$%&&
'()*+,-./*($#0+1/20
340+5$6**+7/(-.*+
8+*742.$"-.-$#.*+0
9-.0:-5$'(.0+)-20
9-.0:-5
;0<40=.$>8'"?$@"AB=C
;0<40=.$>8'"?$@"AB=C
D0.%220=='()*$>8'"?$@"ABC
>%220==$'()*C
;0<40=.$>8'"?$@"AB?$%220==$'()*C
;0<40=.$>8'"?$@"AB?$'70(./.5C
>"*24,0(.C
>"*24,0(.C
#.*+0$>8'"?@"AB?$"*24,0(.C
>"-.-$;0)C
>"-.-$;0)C
>"-.-$;0)C
6.4.2.5
ID Translation
ID Translation is a sub process, which is often executed as part of the above processes. The BDSS has the option to invoke the information discovery and retrieval processes with a local ID rather than a PREMANUS ID (PID). In this case, the ID Translation is invoked in order to provide the process with the required PID instead of the local ID. How a PID is determined based on a local ID is described in detail in Deliverable D3.1. Here, it is only important to understand that in case the Query Coordinator receives a request based on a local ID it will request a PID from the ID Manager.
74
285541 31-Aug-13 PU
!"##$%&&
'()*+,-./*($#0+1/20
3**+4/(-.*+
'"$5-(-60+
70-+289/.8:*2-;'"<:*2-;'"=
70-+289/.8:*2-;'"<:*2-;'"=
.+-(7;-.0$<$:*2-;'"$=
>'" 70-+28<>'"=
6.4.3
Gateway Interface
The main purpose of the Gateway Interface is to encapsulate the communication with the PREMANUS Gateways and provide the Query Coordinator with a simpler Java interface. The interaction and interface with the PREMANUS Gateway can be found in chapter 4 PREMANUS Gateway.. This section will focus on the interaction with the other components of the Information Manager and the Java API provided for this interaction. 6.4.3.1 Interface
6.4.3.2 6.4.3.2.1
Java API Gateway Handler Interface
public interface eu.premanus.bdss.informationmanager.iGatewayHandler
The iGatewayHandler encapsulates the communication with the PREMANUS Gateway and provides a simpler java interface for the rest of the Information Manager. All methods return futures since the response from the Gateway are asynchronous. 6.4.3.2.2 Gateway Handler Methods
public java.util.concurrent.Future retrieveInformationWithPID( String pid, List udefs,
iGatewayHandler.AccessInformation gateway)
Retrieves the requested information (specified through the id and list of udefs) from the corresponding PREMANUS Gateways. Parameters
75
285541 31-Aug-13 PU
pid udefs gateway
PREMANUS ID of the Product for which the information is requested list of udefs which detail the information, which is requested access information for the PREMANUS Gateway from which the information is requested.
Returns
Future<List<Object>> A list of retrieved information
public java.util.concurrent.Future retrieveInformationWithLocalID( String localID, List udefs, iGatewayHandler.AccessInformation gateway)
Retrieves the requested information (specified through the id and list of udefs) from the corresponding PREMANUS Gateways. Parameters
localID udefs gateway some local ID of the Product for which the information is requested list of udefs which detail the information, which is requested access information for the PREMANUS Gateway from which the information is requested.
Returns
Future<List<Object>> A list of retrieved information
6.4.4
BDSS Information Service
The BDSS Information Service runs as an OSGi Service in the BDSS Service Layer as one of the PREMANUS standard services. Any apps or other services running in the BDSS can utilize the Query service to find and retrieve information from the PREMANUS network and store it in the PDS. In essence, the BDSS Information service exposes all functionalities of the Query Manager to the BDSS algorithms. 6.4.4.1 Interface
The Java interface provided to the BDSS Apps consists of the iInformationService interface and the SearchSubscriber interface, allowing for both search and subscription to searches as well as retrieval of Information.
76
285541 31-Aug-13 PU
6.4.4.2 6.4.4.2.1
Java API Information Service Interface
public interface eu.premanus.bdss.InformationService.iInformationService
InformationService Interface to the PREMANUS InformationService component of the PREMANUS Client Allows users of this service to query the PREMANUS network for information about a certain id (either a PREMANUS ID or a local ID, which is translated by the InformationService into a PREMANUS ID with help of the ID Management Component). 6.4.4.2.2 Information Service Methods
public java.util.List searchWithPID (String pid)
Discovers Information in the PREMANUS network by means of a PREMANUS ID Parameters pid Returns List<String> A list of UDEF identifiers in String form PREMANUS ID of the product for which the service will discover information
public java.util.List searchWithLocalID( String localID)
Discovers Information in the PREMANUS network by means of a local ID The local ID is translated into a PREMANUS ID through the ID Management component Parameters localID Returns List<String> A list of UDEF identifiers in String form Some local ID of the product for which the service will discover information
77
285541 31-Aug-13 PU
public java.util.List subscribeToSearchWithPID( String pid, iInformationService.SearchSubscriber subscriber)
Subscribes to information discovery of information for the provided PREMANUS ID. The method returns any information immediately available in form of a list of UDEFs. Any further discoveries will be delivered through the subscriber object callback method. Parameters pid subscriber Returns List<String> List of UDEFs immediately available from the system PREMANUS ID of the product for which the service will discover information subscriber which accepts new udefs, that have been discovered
public java.util.List subscribeToSearchWithLocalID( String localID, iInformationService.SearchSubscriber subscriber)
Subscribes to information discovery of information for the provided local ID. The local ID will be translated into a PREMANUS id by the ID Management component. The method returns any information immediately available in form of a list of UDEFs. Any further discoveries will be delivered through the subscriber object callback method. Parameters localID subscriber Returns List<String> List of UDEFs immediately available from the system Some local ID of the product for which the service will discover information subscriber which accepts new udefs, that have been discovered
public java.util.List retrieveWithPID( String PID, List udef)
Retrieves the information corresponding to the PID and udefs from the corresponding PREMANUS Gateway(s) and returns a list of String references (to be used with the Product Data Store). Parameters PID udef Returns List<String> A list of PDS references to the fetched information PREMANUS ID of the product for which the information will be fetched List of udefs describing the information which will be fetched
78
285541 31-Aug-13 PU
public java.util.List retrieveWithLocalID( String localID, List udef)
Retrieves the information corresponding to the local ID and udefs from the corresponding PREMANUS Gateway(s) and returns a list of String references (to be used with the Product Data Store). Parameters localID udef Returns List<String> 6.4.4.2.3 A list of PDS references to the fetched information local ID of the product for which the information will be fetched List of udefs describing the information which will be fetched
Search Subscriber Interface
public static interface eu.premanus.bdss.InformationService.iInformationService.SearchSubscriber
Interface for the Subscriber associated with the subscribe to discovery methods. Anyone wanting to subscribe to the discovery service should implement this interface. 6.4.4.2.4 Search Subscriber Methods
public void update( List udefs)
Updates the information discovery Subscriber with a list of newly discovered UDEFs. Parameters udefs 6.4.5 Cloud Interface newly discovered UDEFs
Similar to the Gateway Interface, the Cloud interface encapsulates the communication with the cloud from the Query Manager and exposes a simple Java API to communicate with the cloud. In the future, the Cloud Interface might be adapted to include advanced access control mechanisms, in order to authenticate the Query Manager with the Cloud. 6.4.5.1 6.4.5.1.1 Java API for Coordinator Cloud Handler Interface
public interface eu.premanus.bdss.informationmanager.iCloudHandler
The Cloud Handler manages and encapsulates the communication with the PREMANUS Cloud and provides a simple Java interface for the rest of the Information Manager. 6.4.5.1.2 Cloud Handler Methods
public java.util.concurrent.Future search( String pid)
Searches the PREMANUS Cloud for information relating to the provided ID. Returns a list of advertisements in form of a future.
79
285541 31-Aug-13 PU
Parameters PID Returns Future<List<Advertisement>> A future which contains a list of advertisements PREMANUS ID for which this methods tries to find information.
public java.util.concurrent.Future search( String pid, List udefs)
Searches the PREMANUS Cloud for specific information relating to the provided ID. The information is specified by the provided list of udefs. Returns a lsit of advertisements in form of a future. Parameters PID udef Returns Future<List<Advertisement>> A future which contains a list of advertisements PREMANUS ID for which this methods tries to find information. List of udefs which specifies which information is required
6.4.5.2
API for communication with the Information Directory
The API for the communication with the PREMANUS Cloud Information Directory is defined in section 5.2.5. 6.4.6 Coordinator
The coordinator is the core of the Information Manager. It is responsible for initiating requests to both PREMANUS Cloud and Gateways and processing, storing and returning the results to the requesting BDSS App. It receives requests from BDSS Apps through the Information Service Interface and in turn initiates the corresponding requests through the Cloud- and Gateway Handlers. Additionally it interfaces with the Product Data Store Handler, the Subscriptions component and the local Gateway. The main interface of the Coordinator mirrors the interface of the Information Service Interface, but is used by the Information Service running in the Service Layer rather than the apps themselves. Details about the API can be found in section 6.4.4. . Additionally the Coordinator offers an interface to the Subscriptions component to report about new information regarding existing subscriptions. Details about the interface of the Subscriptions component will be detailed in section 6.4.7, if the subscription functionality is implemented. 6.4.7 Subscriptions
The subscriptions component manages all subscriptions for information searches on the Information Managers end. It keeps track which app subscribes to which information as well as the corresponding call-backs. It also exposes a web service interface for call-backs, which is called by the information directory if new information about a subscription is available. Since the subscription component is out of scope for the prototypes developed in the PREMANUS project, this represents just a general
80
285541 31-Aug-13 PU
description of a possible set of functionality without a definitive API. 6.4.8 Product Data Store Handler
The product data store will be connected to the Information Manager via web services, provided by the PDS. The Product Data Store Handler is responsible for encapsulating the web services and presenting a Java interface to the Coordinator, similar to the other handlers within the Information Manager. As explained more in depth later in this document, the so-called Product Data Store is based on a general purpose data model whose aim is to describe the various items involved in product life cycle tracking. In brief, the data model can be thought of as the sum of many heavily correlated data structures, through which one can gain a clear depiction of: Basic and Complex Industrial Processes, Involved Resources (machinery, operators, ), Product Types, Product Instances passing through the Processes.
The PDS has been adapted to fit the distinctive features of EoL/remanufacturing issues, which are at the core of the PREMANUS project. The PDS Handler is the one component needed to get access to the data model from outside. Basically, it consists of a REST web service interface which enables external users and systems to perform read/insert/update operations on the underlying database. Given the complexity of the PDS, it is not possible to list here all web methods; however, we can safely state that there are at least three web methods for each table in the model, allowing for the main data operations to be implemented. In reality, there could be more, usually according to the system architectures needs. Most PDS methods adhere to one of the following syntactical forms:
!"#$%&'O/P'.(>QR9).'%4S'7' !"#$%&'O/P'%),(<>QO/P'9#T(&>S'7' !"#$%&'O/P'"!4->(QO/P'9#T(&>S .
Adherence to syntax rules is not strict but has been enforced as much as possible in order to improve usability. The Handler is compliant with SOA principles and is based on state-of-the-art Java software frameworks, the reliability and flexibility of which is well known in the software industry. Querying the web services can result in either an XML or JSON reply, depending on what was required by the user. For the sake of completeness, we conclude this paragraph by quoting those web methods in the interface which are specifically meant to handle physical product data. This subset of methods has been chosen because it is most representative of the components functioning. It can be assumed that all other tables in the data model do expose quite similar methods, although usually fewer in number.
' !"#$%&':;0,%&-$:<94"&>'.(>QR9).'%4S'7' !"#$%&'R%,>O:;0,%&-$:<94"&>P'.(>QR9).'8<9*7'R9).'>9S'7' !"#$%&'R%,>O:;0,%&-$:<94"&>P',(-<&;' Q@><%).',><%).7'2)>(.(<'!-.(7'2)>(.(<'!-.(@%U(S'7' !"#$%&'2)>(.(<'&9")>Q@><%).',><%).S'7'
81
285541 31-Aug-13 PU
6.4.8.1
!"#$%&'R%,>O:;0,%&-$:<94"&>P'.(>J024/-.QR9).'%4/-.S'7' !"#$%&'R%,>O:;0,%&-$:<94"&>P'.(>J024:;0,%&-$:<94"&>24/-.' QR9).'%4:<94"&/0!(7'R9).'%4/-.S'7' !"#$%&'R%,>O:;0,%&-$:<94"&>P'.(>J024:;0,%&-$:<94"&>J->&;F94(' QR9).'%4:<94"&/0!(7'@><%).'#->&;F94(S'7' !"#$%&':;0,%&-$:<94"&>'%),(<>Q:;0,%&-$:<94"&>'!;0,%&-$:<94"&>S'7' !"#$%&':;0,%&-$:<94"&>'"!4->(Q:;0,%&-$:<94"&>'!;0,%&-$:<94"&>S .
Java API for Coordinator
The Query Manager also enables the PDS to start communications with all other systems involved in PREMANUS. The main reason why the PDS should actively query the other nodes is that the i-LiKe platform does not only act as a storage facility for product/process data, but has also some intelligence embedded in it, particularly when it comes to determining which options are the best in real production sheets definition. To be clearer, it can happen that a remanufacturing process does not stretch linearly from one point to the other, but calls instead for a choice among different alternatives. In this case, the PDS would have to ask the BDSS to calculate which route is the most preferable in terms, for instance, of profitability or environmental impact, and this requires the Query Manager to mediate the request via a specific web interface. It could also occur that the PDS has to retrieve some data (mostly product data) that is stored in one of the gateways connected to the PREMANUS Client. This situation can be dealt through a two-step query, in which a first request is addressed to the Information Directory to determine which gateway contains the correct pieces of information, and then the gateway itself is asked to provide the required data. It is worth noticing that requests to the Information Directory and the gateways are not necessarily coupled and can be carried out separately. Obviously, this calls for another set of web methods exposed by the Coordinator to the PDS. The resulting web service interface goes under the package
eu.premanus.bdss.informationmanager.iPDSHandler
and is shown here:
'
!"#$%&'T-3-V">%$V&9)&"<<()>VA">"<('<(><%(3(2)89<*->%9)A<9*W->(X-0Y%>;:2I (@><%).'!%47'R%,>'"4(8,7'%W->(X-0Z-)4$(<V[&&(,,2)89<*->%9)'.->(X-0), !"#$%&'T-3-V">%$V&9)&"<<()>VA">"<('<(><%(3(2)89<*->%9)A<9*W->(X-0Y%>;R9&-$2I' Q@><%).'$9&-$2I7'R%,>'"4(8,7'%W->(X-0Z-)4$(<V[&&(,,2)89<*->%9)'''' .->(X-0S7 !"#$%&'T-3-V">%$V&9)&"<<()>VA">"<(',(-<&;2)2)89<*->%9)I%<(&>9<0'' Q@><%).'!%4S7' !"#$%&'T-3-V">%$V&9)&"<<()>VA">"<(',(-<&;2)2)89<*->%9)I%<(&>9<0' '''Q@><%).'!%47'R%,>'"4(8,S7 !"#$%&'R%,>OY9<G8$9XP'9!>%*%U(Y9<G8$9X'QY9<G8$9X'X9<G8$9XSV'
The first two web methods are modeled on the almost namesake instructions appearing in the Cloud Interface (see paragraph 6.4.5.2), whereas the fourth and fifth method closely resembles those defining the Gateway Handler (see 6.4.3.2.2). The reader is strongly recommended to study the aforementioned paragraphs in order to get a complete understanding of the methods syntax and functionality.
82
285541 31-Aug-13 PU
The 9!>%*%U(Y9<G8$9X' method' needs some more explanation. It has been specifically designed to allow the PDS to send workflow descriptions to the BDSS, so that the component is be able to perform process optimization. The Workflow type (to which both the methods input and output belong) consists of the aggregation of two smaller data structures: namely, the first field is a structured record of the workflows peculiar parameters, while the second field is a graph in which all workflow activities are arranged according to their priority. When 9!>%*%U(Y9<G8$9X' is called, the user must provide a workflow object describing the production sheet as it is stored in the PDS; what is returned as an output is a list of all possible alternatives calculated by the BDSS, each of them supplied with a quantification the solutions profitability, environmental impact and time convenience. This web interface is based on REST technology and all exchanged messages are in XML format. All methods are of the GET type, with the only exception of 9!>%*%U(Y9<G8$9XV' The latter has been designed in fact as a POST method because of the complexity of its input data structures.
6.5
Product Data Store
The Product Data Store will consist almost exclusively of Holonix i-LiKe and the web services provided by i-LiKe. This chapter will outline the details of the i-LiKe web service interface and the integration into the PREMANUS Client once the web service is implemented. Based on the results of several research projects, Holonix has developed a platform to manage products and services. It has been called i-LiKe: intelligent Lifecycle data and Knowledge. As services provided by i-LiKe are relevant to the vision of PREMANUS, They can be extended to contribute to the goals of the project.
Figure 54 The i-LiKe Platform
The platform is product-centric, meaning that everything is seen from the perspective of being on the product, which is followed during all its life. Its aim is to provide a platform to develop and integrate Lifecycle Management solutions, being able therefore to follow the product in several phases, integrating data coming from them and therefore enabling improved product management, analysis and use.
83
285541 31-Aug-13 PU
It is developed using a modular approach; some modules follow the product during all the lifecycle; others are phase or process specific. Considering the complexity of the topic, the platform is under continuous development; not all the modules are currently fully implemented and it is planned that functionality will continuously increase over time also through partnerships with other solution providers/research centers etc. (e.g. the design module is based on already existing PLM platforms; the warehousing module can exploit functionalities of voice-picking systems, etc.) Two main modules will be used in PREMANUS Project: i-LiKe Base-Platform: it can manage product traceability using the most widespread standards and/or by interfacing to third party systems. By adopting RfID or Barcode technologies it is possible to fully exploit the potential of this module. i-LiKe Production: within the Production Module it is possible to manage the production sheets and in particular it allows the real time control of the process by monitoring the resources used (in terms of materials, machines and operators), the inputs and outputs and the responsible of each activity. It is also possible to take advantage of the Key Perfomance Indicators to measure the production quality and control it during all the processes. All this can be done using the web application, while the operators in the shopfloor can use the handheld computers that graphically support them providing the sequences of the activities to be carried out.
Furthermore, two modules belonging to the End of Life are under development and will be fully integrated in the Platform using the results and evaluations achieved in the BDSS developed in PREMANUS Project. They allow the possibility to assess the environmental impact evaluating the LCC and LCA and to manage the disassembly and recycle processes. They support decisions using algorithms based on the real status of the items and specific enterprise requirements. The i-LiKe platform is programmed in Java; it has Java based web-based interfaces (both for management and operations) and interfaces in C# (for operations with industrial PDAs). The DB is in MySQL. Interaction through web services is currently under development. The platform interaction module has been designed to interact easily through QLM and UDEF. An items traceability can be achieved using RFIDs or other identification technologies (e.g. IMEI for phones, MAC addresses for computers). The Holonix i-LiKe approach to PLM is a "product instance-centric" one. Each instance of a certain product type should be followed all along its life cycle in order to close the desired information loops, thereby creating value. The concept is capable of enabling the link to all these product items and their related information. A central portion of the semantic model should thus reflect this approach and properly represent the information on each product at the item level. As an example, a simplified version of the central class of the information model is described in the following.
84
285541 31-Aug-13 PU
Figure 55 Simplified PHYSICAL_PRODUCT class used as an example
The PHYSICAL_PRODUCT class (figure above) is intended to cover this issue by modelling some basic information on each product item, as reflected by its attributes: Product_Type. This is the name of the product type/model/variant (depending on the meaning given to these words in different industrial contexts) to which the product item belongs. It directly corresponds to the value of the Product_Type_ID attribute of one and only one object of the AS_DESIGNED_PRODUCT class. More precisely, it states the name of the object of the AS_DESIGNED_PRODUCT class from which the general attributes of the product as an instance of a product type are derived, as indicated in the diagram by the classification linking the AS_DESIGNED_PRODUCT class and the PHYSICAL_PRODUCT class. Object_Lot_ID. This shows the ID of the production lot to which the product item belongs, in case it is important to store this information in the specific application considered. For instance, the typical example of situation in which this information turns out to be important can be that of a typical recall campaign a company must carry out when a big defect has been detected in one or more products of the same lot, such as some cases happened in the last years in the automotive industry. Birth_Date. This, models the date at which the existence of the product item actually starts. This can correspond to different time instants in different applications, e.g. the moment at which the product item exits the last station of the production line, or the moment when the product item enters the first stage of that line, etc. The first can be the case of a company which is not interested in following specifically each product item in the different phases of the production cycle, but e.g. is interested in tracking and tracing the product inside the warehouse or/and across its supply chain. The second can be instead the case of a company which gives importance to the tracking and tracing of the product all along the production cycle, such as those companies which daily apply RFID technologies for this reason at the shop floor level. End_Date. This represents the date at which the product item reaches its end of life. The cardinality, differently from the previous attributes which have cardinality of one and only
85
285541 31-Aug-13 PU
one, is in this case zero to one. This reflects the fact that this attribute is not instantiated until the product item reaches its end of life. Parent. This attribute gives the name, i.e. the ID of the father node in the tree corresponding to the structure of the product as a whole. Each node of this tree corresponds to one and only one product item. So it is important to notice that at this level only the product structure for the phases BOL supply, MOL, and EOL, i.e. the structure of physically existing products is actually addressed, while the BOL as-designed structure of the product is treated in an analogue way by the AS_DESIGNED_PRODUCT class. The cardinality of this attribute is zero to one. It is zero when the product structure is the simplest one, i.e. the product is considered as a one-piece product, or if the according product is at the top of the assemblypart hierarchy. It is one when on the contrary the product is modelled as a part of an assembly.
In case of more complex products, it is very important to track the history concerning the physical components/subassemblies belonging to a single physical product entity. To understand the importance of such an information think as an example on a car whose life cycle has to be managed up to the end of life phase, as well as that of its main components, e.g. the clutch, and subassemblies, e.g. the engine, such as in the CRF scenario. The PART_OF association class tracks this kind of history. At the beginning of the car's life, the From attribute of the PART_OF association class related to the link between each of these components/subassemblies and the whole product is set to the current date. Then, if at a certain point in the car's life, a component has to be replaced by another one of the same type, e.g. because its residual life has expired, its To attribute is set to the new current date and, as soon as the new component is attached to the complex product, a new object of the PART_OF class is created and the From attribute related to the new component is set to the proper value.
86
285541 31-Aug-13 PU
Standardization
This chapter summarizes the standardization efforts within the PREMANUS project. The only standardization currently under discussion is the submission of the PREMANUS advertisement structure as a new element of The Open Groups QLM standards.
7.1
Background to QLM
The QLM standards already cover many aspects of the storage, use and exchange of lifecycle information. Currently QLM defines the Data Model used as a foundation in PREMANUS and the QLM Messaging Interface. Existing implementations tend to exchange lifecycle information directly between two parties, and there has been no middleware implementation providing for a larger information network for sharing information like in the proposed PREMANUS network. This lack of lifecycle information sharing network is a great opportunity for the PREMANUS project to make a contribution to the QLM standard by proposing a standardized adaptation of the PREMANUS remanufacturing information network. 7.1.1 Proposal
A QLM Information Network will be comprised of the same basic parties as the PREMANUS remanufacturing information network. These basic parties are the information providers, the information directory and the information consumer. Again similar to the PREMANUS RIS, information providers can also be consumers and vice versa. Along with the three basic parties involved, the QLM Information Network inherits the three major interactions within the network. The first is the sharing of meta information with the Information Directory, in order to establish an overview of all information within the network. The second is a query by an Information Consumer and the final interaction is the actual retrieval of the information from the Information Provider.
7.2
Advertisements standardization
This chapter details the current status of the standardization of the PREMANUS Advertisements for the QLM standard. At the moment this consists mostly of a first draft of the structure of the proposed Advertisement standard. 7.2.1 Purpose
The main purpose of advertisements is to exchanging meta-data about which information is published by an Information Provider within the information network. The advertisements are centrally collected in order to provide an overview of all available information within the network and to allow for an easy search for Product Information. This central metadata store is called the Information Directory, just like in the PREMANUS architecture. The Information Directory can be queried by Information Consumers for product information and will in turn receive selected advertisements about this product. In the final step of the interaction, the Information Consumer contacts the Information Provider, where the advertisement originated, and asks for the corresponding information. So the advertisement serves both as a description of available information and as a token for its retrieval.
87
285541 31-Aug-13 PU
7.2.2
Structure
The prototype structure of the advertisement can be split into 4 major parts: the ID of the product instance for which information exists, the content which describes the available information, the access information required to connect to the information provider and finally metadata for the advertisement itself. " Q-ID o List: Partial IDs ! Schema ! Original ID ! ID Value OEM Product Class Product Serial List ! ! UDEF-ID Human readable UDEF
"
Content o
"
Access Information o o Connection ! Method ! Endpoint Authentication ! Method ! Details User Password Certificate Key Authorization Publishing Date & Time Data Source ID Publisher ! Legal person publishing ! List of Pairs UDEF-ID; Value
o " o o o
Metadata
7.2.2.1
Q-ID
The QLM ID is an aggregate ID composed of any available ID for the product instance, regardless of ID standard. Each partial ID includes information about the standard it subscribes to as well as an OEM, Product Class and Product Serial. 7.2.2.1.1 Partial IDs Each Partial ID represents the product instance or product class within on ID standard. It consists of the original ID, which is in the encoding of the respective ID standard and the non-encoded triplet of OEM, product type and product serial. In some cases, the ID might refer to a product type rather than
88
285541 31-Aug-13 PU
an instance, in which case the product serial will be empty or omitted. 7.2.2.1.1.1 OEM The OEM uniquely identifies the manufacturer of the product instance/type, which is identified by the QID. 7.2.2.1.1.2 Product Type The product type uniquely identifies the series/class of product for the provided OEM. 7.2.2.1.1.3 Product Serial The product serial is the identifier, which uniquely identifies a product instance within a product type. 7.2.2.2 Content (Data)
The content section of the advertisement is used to describe the available information for the product instance identified through the QID. It consists of a list of UDEF IDs which represent the individual bits of information provided by the Information Provider. Each UDEF can optionally come with a human readable translation of the UDEF ID in order to make the advertisement readable for users. 7.2.2.2.1 UDEFs UDEF is a metadata/semantic standard used to describe the individual pieces of information available for a product instance. A more detailed description of UDEF ID s can be found in chapter (insert chapter here). 7.2.2.2.2 Human Readable UDEF Translation A translation of UDEF into a human readable language (default: English), which allows human consumption and captioning in a UI without contacting a UDEF translation service. 7.2.2.3 Access Information
The access information in the advertisement is used by the Information Consumer to connect to the Information Provider and request one or more pieces of information described in the advertisement. The access information is composed of three subsections: Method, Authentication and Authorization. 7.2.2.3.1 Connection This section captures the method used to connect to the Information Provider. An example could be a REST or SOAP based web service interface. 7.2.2.3.1.1 Method This tag states the method used for establishing the connection. 7.2.2.3.1.2 Endpoint This tag specifies the address of the endpoint of the Information Provider. 7.2.2.3.2 Authentication This section specifies any information required for authentication of the information consumer when he requests information from the information provider. It includes both a tag for the method as well as any needed details for the specified authentication method (varies depending on the method). 7.2.2.3.2.1 Method Method of authentication used (for example oAuth)
89
285541 31-Aug-13 PU
7.2.2.3.2.2 Details Any required details for the authentication, like for example: User, Password, Certificate, Key 7.2.2.3.3 Authorization In addition to authentication, some information providers may check if the authenticated user is authorized to receive the requested information. This section encapsulates all information required to inform the information consumer which authentication he must possess in order to successfully request the information. 7.2.2.4 Meta Data
This section of the Advertisement holds any useful metadata about the advertisement itself. Currently it consists of three separate sections, Publishing Information, Data Source Information and Publisher Information. 7.2.2.4.1 7.2.2.4.2 Publishing Information Data Source Information The Publishing Information consists of the data and time of the last update of the advertisement. Data source information is currently just a Data Source ID which is used to identify internal data source of a PREMANUS Gateway for more convenient retrieval once the information is requested. 7.2.2.4.3 Publisher Information The publisher information is a list of UDEF-ID value pairs which deliver information about the legal person publishing the advertisement. Examples of possible UDEF value pairs are: 7.2.3 Company Name Address Email Telephone Legal Contact Other Standards under consideration
In this chapter, other standards which could form the foundation of the QLM Information Network standard are described. 7.2.3.1 ATOM Syndication format
The ATOM Standard describes a way of publishing information in a list of entries called a feed. ATOM is REST and XML based and widely accepted for news aggregators and blogs. Additionally it forms the basis of the OData Web service standard. ATOM could be very advantageous for the advertisement standard as both a method of publishing and as a communication protocol (REST). If Atom was to be used, each Information Provider would publish an ATOM based feed, with each entry in the feed being one advertisement. Many of the required and optional elements of an ATOM entry can be mapped one to one to elements from the proposed advertisement standard, which reduces the complexity of the custom advertisement XML nested within the ATOM entry. The ATOM feed would then be registered with the Information Directory, which would reacquire the feed whenever it is updated and maintain the most current advertisements in its database. Potentially the direct query from the Information Consumer to the corresponding Information Provider could also happen by sending an ATOM entry to the Provider in order to request the contained information. However, it is much more likely that the QLM Messaging Interface will be designated for this tasks.
90
285541 31-Aug-13 PU
7.2.3.2
QLM Messaging Interface
The QLM Messaging Interface offers a communication protocol for data exchange, which is already part of the QLM Standard. Thus, it makes sense to reuse the Message Interface for the data exchange in the proposed Information Network standard. While the distribution and gathering of metadata for the Information Directory will most likely not use the Message Interface, the other two major processes in the Information Network (the query and the information retrieval process) will utilize the QLM Messaging Interface standard. 7.2.3.2.1 Information Query Process For the query process, the following functions of the QLM Messaging Interface could be used: Read Requests would be used as a query for information about a product instance. The payload of the read request would specify which item is being queried for and would optionally provide a callback method. As specified in the QLM MI standard, the Information Directory will either respond with the desired data or with an error message. For more details refer to Section 5.1 of the QLM Messaging Interface Base Reference Document. Subscription requests would allow an Information Consumer to request the creation of a subscription for a specific query. This request should provide a callback function, since the request will most likely be answered more than once as new information becomes available at the Information Directory. Alternatively, the Information Provider can request an update on the subscription by submitting another read request with the requestID, which is created when the subscription is initially created. For more details refer to Section 5.2 of the QLM Messaging Interface Base Reference Document. Along with the subscription request, the MI supports the cancel request, which can be used to cancel a standing subscription. As an alternative to the queries through the read request, the MI suggests a RESTful URL based mechanism for discovering Meta-Data in section 5.4 of the Base Reference Document. This format would work for simple queries which only include a product identifier but no further demands on the query (like for instance UDEFs for the type of desired information). It could be thought of as a function for retrieving an overview of all available information for a product instance or series and should be included in the new Information Network standard. 7.2.3.2.2 Information Retrieval Process Similar to the Information Query Process, the Information Retrieval can reuse the already defined and standardized functions of the QLM MI. The following request could be used: The read request would fulfill the basic functionality of requesting a certain piece of information from the Information Provider. Again the request can either be answered directly in the response or over a callback function. If the standard is going to include subscriptions directly with the Information Provider, the subscription and cancel request will be used in a similar fashion as in the Information Query Process. [An open question is how the QLM MI would interaction with authentication mechanisms or role base access systems.] 7.2.4 Security Considerations
With the exchange and use of lifecycle data over a large network, security becomes a concern in a number of ways. Some of the information traded over the network may be confidential and only accessible to select partners, which creates the need for encryption and authentication. Data integrity is another relevant concern for both confidential and none confidential information, since the
91
285541 31-Aug-13 PU
information retrieved over the network may be used for business critical decisions (as is the case with the PREMANUS BDSS) and therefore needs to be protected against modification. More complex systems like role based access control require authorization mechanisms, which determine not only who the user is (authentication) but also which rights he has relating to the requested information.
92
285541 31-Aug-13 PU
Conclusion
This document provided an overview of the current state of the PREMANUS architecture. The split of the architecture into the three main components, the client (Information Consumer), the information directory (Index and Search) and the gateway (Information Provider), was introduced and explained. Since it is a living document, it will be continuously updated to reflect any changes and improvements to the architecture. As part of the PREMANUS project a prototype based on the presented architecture will be implemented and tested in conjunction with the use case partners SKF and CRF. All three major components of the architecture will be implemented as part of the prototype. The implementation details will be documented in the deliverables of WP3, WP4, and WP5. Any changes in design or specifications that will occur during the implementation of the prototype will be amended in this document. Once the prototype is operational at the use case partners, the prototype and by extension the architecture detailed in this document will be validated. The conclusion of this validation will be document in D6.2, D6.3 and D6.5.
93

D2.4 v1.0 Out

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D2.4 v1.0 Out

Uploaded by

Copyright:

Available Formats

Programme Factories of the Future PPP Strategic Objective ICT-2011.7.

D2.4 - LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

PREMANUS CLIENT ................................................................................................................................ 67!

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

High-level Architecture Concept

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Basic Information Sharing Process

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Share and Index Overview

9.:/%()6/&/"(* ;%/'()$"*'".* 9--%/-'()$"

9.:/%()6/&/"(* <//.*<)=/ >/-)6(/%* 9.:/%()6/&/"(*<//.

!"#$%&'()$"* ?%$:)./%* 1'('@'6/

>/(%)/:/*'".* ?%$2/66* 9.:/%()6/&/"(*<//.

Figure 2 Information Sharing and Indexing Process Diagram

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Figure 4 Information Search Process Diagram

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Figure 5 Search and Find component diagram

PREMANUS Cloud Information Directory: -

Project No Date Classification

D2.4 LIVING ARCHITECTURE

D$()#6*89::*'E$=(* 1$&F.,(,/*/'('* 1$..,1()$"

7$&F=(,*H0!*($* )&F%$-,* +,&'"=#'1(=%)"3* 9,1)2)$"

Figure 6 Retrieve and Processing Process Diagram

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Figure 7 Retrieve and Process Component Diagram

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

Project No Date Classification

D2.4 LIVING ARCHITECTURE

D-47<)$121347 /29,7516:,2 !-@+:AB:23 =164>1< /264791;4

Figure 8 Overview of the detailed PREMANUS architecture

Project No Date Classification

D2.4 LIVING ARCHITECTURE

The last component of the architecture, the PREMANUS Cloud manages:

9.:/%()6/&/"(* ;%/'()$"'". 9--%/-'()$"

9.:/%()6/&/"(* <//.<)=/ >/-)6(/% 9.:/%()6/&/"(*<//.

>/(%)/:/'". ?%$2/66* 9.:/%()6/&/"(*<//.

D$()#689::'E$=(* 1$&F.,(,//'(' 1$..,1()$"

7$&F=(,H0!($* )&F%$-,* +,&'"=#'1(=%)"3* 9,1)2)$"