Cloud-based Rapid Elastic MAnufacturing · CREMA WP3 Public Technical Specification T3.3 - D3.3 -...

Cloud-based Rapid Elastic MAnufacturing

WP3 – Architecture, Functional & Technical Specification, Security & Privacy Concept, Integration

D3.3 Technical Specification

Deliverable Lead: ASC

Contributing Partners: DFKI, IKER, TUV, UBI, ICE, DNIT

Delivery Date: 12/2015

Dissemination Level: Public

Version 1.0

This document provides an in-depth technical definition of all CREMA software components and their subcomponents, including the technical specification of the provided interfaces. Furthermore, it documents the defined service data models as well as the technologies chosen as foundation for the implementations of the CREMA software components.

CREMA WP3 Public Technical Specification

T3.3 - D3.3 - T3.3 - D3.3 - Technical Specification - v1.00.docx.docx

Document Version: 1.0

Date: 2015-12-30 Status: For Approval Page:

2 / 227

http://www.crema-project.eu Copyright © CREMA Project Consortium. All Rights Reserved. Grant Agreement No.: 637066

Document Status

Deliverable Lead Danny Pape, ASC Tim Dellas, ASC

Internal Reviewer 1 Matthias Klusch, DFKI

Internal Reviewer 2 Dale Stone, DNIT

Type Deliverable

Work Package WP3: Architecture, Functional & Technical Specification, Security & Privacy Concept, Integration

ID D3.3: Technical Specification

Due Date 31.12.2015

Delivery Date 31.12.2015

Status For Approval

Note This deliverable is subject to final acceptance by the European Commission.

Disclaimer The views represented in this document only reflect the views of the authors and not the views of the European Union. The European Union is not liable for any use that may be made of the information contained in this document. Furthermore, the information is provided “as is” and no guarantee or warranty is given that the information is fit for any particular purpose. The user of the information uses it at its sole risk and liability.





3 / 227


Project Partners

Ascora GmbH, Germany

Dot NET IT, United Kingdom

Technische Universität Wien, Austria

Technology Application Network Limited,

United Kingdom

German Research Center for Artificial

Intelligence, Germany

IKERLAN S. Coop., Spain

Ubisense, United Kingdom

Tenneco-Walker (U.K.) Limited, United Kingdom

FAGOR ARRASATE S. Coop., Spain

Goizper, Spain

Information Catalyst, United Kingdom





4 / 227


Executive Summary Within this deliverable D3.3, the technical specification of the CREMA software components is documented. Together with the already existing Requirements Analysis and User Stories document (D2.9), the Global Architecture Definition (D3.1), the Functional Specification (D3.2), and the Holistic Security and Privacy Concept (D3.4), this deliverable provides the foundation for the research, technology, and development work to be conducted within WP4-WP6. The goals of this deliverable are:

• Define concrete, detailed interfaces making available the functionality identified in the Functional Specification.

• Document not only what needs to be provided by a component, but also what the component can expect from other component, interface-wise.

• Document formats and expected data schemas in form of examples, which clearly describes what outputs to expect and what is necessary as input to call an interface.

• Describe concrete base technologies for the components. • The ultimate goal was to advance the software engineering process and to

concretise communication between the project partners. • The document also should provide a technical contract and handbook for the use

and implementation of the component interfaces, which makes it an important document for the whole further implementation phase of the project as well as technical information for external stakeholders.

The outcome of this technical specification is an in-depth technical description of all CREMA software components. From a technical perspective, the most important choices defined within this deliverable are the selection of RESTful interfaces as a common communication basis for all components, except if streaming data is necessary. For this special case, a message queue middleware to provide streaming abilities to the CREMA system is employed. A one stop scalable storage solution is provided by the Cloud-based Information Infrastructure (CRI), while for instantiation of services in CREMA, OpenStack and Amazon EC2 can be used on a basis of lightweight virtualisation in the form of Docker service binaries, called Proxy Service Wrappers. The choice of interface specifications and example data structures was inspired by open source projects driven by Google, Facebook or Github, where the stable focus of software development is only defined on the interface and data format level. Examples and colours were used in the interface descriptions to make the document more useful for developers. In order to make this deliverable self-contained, it starts with a recapitulation of CREMA system. Afterwards, the common technical decisions of the CREMA system are explained. Amongst these are data storage, security and privacy, public interfaces, data-interchange format and semantic data. Subsequently, an in-depth discussion of the technical aspects of each component is provided. It starts for each component with a selection of technologies and reused software. In order to explain how to interact with the respective software component, the RESTful and, if applicable, Java interfaces provided are discussed in detail. The document concludes with a brief summarisation of the main outcomes.





5 / 227


Table of Contents 1 Introduction ................................................................................................................... 11

1.1 CREMA Project Overview .................................................................................... 111.2 Deliverable Purpose, Scope and Context ............................................................ 111.3 Document Status and Target Audience ............................................................... 121.4 Abbreviations and Glossary ................................................................................. 121.5 Document Structure ............................................................................................. 12

2 General Description of the Technical Specification ...................................................... 133 General Technology Selection ...................................................................................... 14

3.1 Data Storage ........................................................................................................ 143.2 Security and Privacy ............................................................................................ 143.3 Public Interfaces ................................................................................................... 153.4 Data-Interchange Format ..................................................................................... 153.5 Semantic Data ...................................................................................................... 153.6 Component-based Technical Specification .......................................................... 16

4 CREMA Manufacturing Virtualisation & Interoperability Components .......................... 174.1 Data Model, Model Library and Profiles ............................................................... 17

4.1.1 Technology Base & Reuse ....................................................................... 174.1.1.1 Standards for resource codification ........................................... 174.1.1.2 Standards for semantic data querying and reasoning ............... 174.1.1.3 Missing Elements and Implementation Needs .......................... 18

4.1.2 Component Structure Overview ................................................................ 184.1.3 Public Interfaces ....................................................................................... 19

4.1.3.1 RESTful Interfaces .................................................................... 194.1.4 Content Format ......................................................................................... 364.1.5 Authorisation Definition ............................................................................. 37

4.2 Data Harmonisation Services ............................................................................... 374.2.1 Technology Base & Reuse ....................................................................... 37

4.2.1.1 Selection for Maps Designer and Transformation Engine ......... 384.2.1.2 Missing Elements and Implementation Needs .......................... 38


4.2.3.1 RESTful Interfaces .................................................................... 424.2.4 Content Format ......................................................................................... 634.2.5 Authorisation Definition ............................................................................. 63

4.3 Cloud-based RAID Infrastructure ......................................................................... 644.3.1 Technology Base & Reuse ....................................................................... 64

4.3.1.1 Selection for Semi-Structured Data Storage ............................. 644.3.1.2 Selection for Semantic Data Storage ........................................ 654.3.1.3 Selection for Binary Data Storage ............................................. 654.3.1.4 Missing Elements and Implementation Needs .......................... 65


4.3.3.1 Common Return Codes ............................................................. 674.3.3.2 Method “Create Bucket” ............................................................ 684.3.3.3 Method “List Buckets” ................................................................ 694.3.3.4 Method “Describe Bucket” ......................................................... 694.3.3.5 Method “Delete Bucket” ............................................................. 70





6 / 227


4.3.3.6 Method “Create Object” ............................................................. 714.3.3.7 Method “Read Object” ............................................................... 724.3.3.8 Method “Update Object” ............................................................ 734.3.3.9 Method “Delete Object” ............................................................. 744.3.3.10 Method “Execute Generic Query” .............................................. 744.3.3.11 Method “Execute Delete Query” ................................................ 764.3.3.12 Method “Create Repository” ...................................................... 764.3.3.13 Method “Delete Repository” ...................................................... 774.3.3.14 Method “Create a new RDF Graph” .......................................... 784.3.3.15 Method “Query a RDF Graph” ................................................... 794.3.3.16 Method “Update a RDF Graph” ................................................. 804.3.3.17 Method “Delete a RDF Graph” .................................................. 81

4.3.4 Content Format ......................................................................................... 824.3.5 Authorisation Definition ............................................................................. 84

4.4 Cyber-Physical Systems, Sensor Abstraction and Virtualisation ......................... 854.4.1 Technology Base & Reuse ....................................................................... 854.4.2 Component Structure Overview ................................................................ 864.4.3 Public Interfaces ....................................................................................... 884.4.4 Content Format ....................................................................................... 1044.4.5 Authorisation Definition ........................................................................... 105

4.5 Service Virtualisation and Abstraction ................................................................ 1054.5.1 Technology Base & Reuse ..................................................................... 106

4.5.1.1 Selection of Semantic Annotation Means ................................ 1064.5.1.2 Selection of SVA UI Engine ..................................................... 1064.5.1.3 Missing Elements and Implementation needs ......................... 107

4.5.2 Component Structure Overview .............................................................. 1084.5.3 Public Interfaces ..................................................................................... 110

4.5.3.1 RESTful Interfaces .................................................................. 1104.5.4 Content Format ....................................................................................... 1114.5.5 Authorisation Definition ........................................................................... 114

5 CREMA Cloud Manufacturing Collaboration, Knowledge and Stakeholder Interaction Framework Components .................................................................................................. 115

5.1 Cloud Collaborative Process Design Time Environment ................................... 1155.1.1 Technology Base & Reuse ..................................................................... 115

5.1.1.1 Selection for BPMN Renderer and Modeller ........................... 1155.1.1.2 Missing Elements and Implementation Needs ........................ 116

5.1.2 Component Structure Overview .............................................................. 1165.1.3 Public Interfaces ..................................................................................... 1205.1.4 Content Format ....................................................................................... 120

5.1.4.1 BPMN2.0 XML ......................................................................... 1205.1.4.2 Process Definition ................................................................... 1205.1.4.3 Service XML Element .............................................................. 1215.1.4.4 Abstract Service XML Element Example ................................. 1215.1.4.5 Concrete Service XML Element Example ............................... 1225.1.4.6 Meta Data XML Element ......................................................... 1225.1.4.7 Constraints .............................................................................. 1225.1.4.8 Custom-Meta-Model ................................................................ 123

5.1.5 Authorisation Definition ........................................................................... 1245.2 Cloud Process and Messaging Runtime Environment ....................................... 124





7 / 227


5.2.1 Technology Base & Reuse ..................................................................... 1255.2.1.1 Selection of a Business Process Model Execution System .... 1255.2.1.2 Selection of a Message Bus .................................................... 1255.2.1.3 Missing Elements and Implementation Needs ........................ 126



5.3 On-Demand Service Leasing and Releasing ..................................................... 1345.3.1 Technology Base & Reuse ..................................................................... 134

5.3.1.1 Selection of Programming Language ...................................... 1345.3.1.2 Selection of Cloud Infrastructure ............................................. 1345.3.1.3 Selection of Service Container ................................................ 1355.3.1.4 Missing Elements and Implementation Needs ........................ 135



5.4 Design Time and Runtime Optimisation ............................................................. 1425.4.1 Technology Base & Reuse ..................................................................... 143

5.4.1.1 Semantic process service selection and planning ................... 1435.4.1.2 Dynamic process constraint optimisation ................................ 1435.4.1.3 Semantic Data Stream Processing ......................................... 1445.4.1.4 Missing Elements and Implementation Needs ........................ 144



6 CREMA Cloud Manufacturing Process and Optimisation Framework Component .... 1576.1 Marketplace and Monetisation ........................................................................... 157

6.1.1 Technology Base & Reuse ..................................................................... 1576.1.1.1 Monetisation Environment ....................................................... 1576.1.1.2 Monetisation Provider .............................................................. 1576.1.1.3 Marketplace Environment ........................................................ 1576.1.1.4 Resource Management ........................................................... 1586.1.1.5 REST Client ............................................................................. 1586.1.1.6 Missing Elements and Implementation Needs ........................ 158


6.1.3.1 Method “Get Service” .............................................................. 1616.1.3.2 Method “Get Services” ............................................................ 1626.1.3.3 Method “Create Service” ......................................................... 1646.1.3.4 Method “Update Service” ........................................................ 1656.1.3.5 Method “Delete Service” .......................................................... 1666.1.3.6 Method “Create Proxy Service Wrapper” ................................ 1666.1.3.7 Method “Lease Service” .......................................................... 167





8 / 227


6.1.3.8 Method “Release Service” ....................................................... 1686.1.3.9 Method “Delete Proxy Service Wrapper” ................................. 1696.1.3.10 Method “Get Service Schedule” .............................................. 1696.1.3.11 Method “Schedule Service” ..................................................... 1716.1.3.12 Method “Update Service Schedule” ........................................ 1716.1.3.13 Method “Delete Appointment from Service Schedule” ............ 1726.1.3.14 Method “Clear Service Schedule” ........................................... 173

6.1.1 Content Format ....................................................................................... 1746.1.2 Authorisation Definition ........................................................................... 175

6.2 Monitoring & Alerting .......................................................................................... 1766.2.1 Technology Base & Reuse ..................................................................... 176

6.2.1.1 Selection for Business Rule Definition Language ................... 1766.2.1.2 Selection for Rule Engine ........................................................ 1776.2.1.3 Selection for Business Rule and KPI Storage ......................... 1776.2.1.4 Selection for Monitoring and Alerting API Implementation ...... 1776.2.1.5 Selection for Rules UI (Integrated with DBA) .......................... 1776.2.1.6 Missing Elements and Implementation Needs ........................ 177



6.3 Manufacturing Big Data, Knowledge and Analytics ........................................... 1826.3.1 Technology Base & Reuse ..................................................................... 182

6.3.1.1 Selection of Base Platform ...................................................... 1836.3.1.2 Selection of Data Analytic Framework .................................... 1836.3.1.3 Selection of Data Storage ....................................................... 1836.3.1.4 Selection of Stream Processing Technology ........................... 1836.3.1.5 Selection of Visualisation ........................................................ 1846.3.1.6 Missing Elements and Implementation Needs ........................ 184


6.3.3.1 RESTful Interfaces .................................................................. 1866.3.3.2 Java Interfaces ........................................................................ 189


6.4 Agile Personal Collaboration Environment ......................................................... 1906.4.1 Technology Base & Reuse ..................................................................... 191

6.4.1.1 Data Exchange Infrastructure .................................................. 1916.4.1.2 Missing Elements and Implementation Needs ........................ 192


6.4.3.1 Method “Send Notification” ...................................................... 1956.4.3.2 Method “Upload Highlighting” .................................................. 1966.4.3.3 Method “Download Highlighting” ............................................. 1976.4.3.4 Method “Replace Highlighting” ................................................ 1986.4.3.5 Method “Delete Highlighting” ................................................... 199






9 / 227


6.5 Dashboard & Visualisation ................................................................................. 2016.5.1 Technology Base & Reuse ..................................................................... 201

6.5.1.1 Dashboard Content ................................................................. 2016.5.1.2 Corporate Design .................................................................... 2026.5.1.3 Dashboard Interaction ............................................................. 203


6.5.3.1 Method “Push Notification” ...................................................... 2066.5.4 Content Format ....................................................................................... 2076.5.5 Authorisation Definition ........................................................................... 208

7 Security and Privacy Component ............................................................................... 2107.1.1 Technology Base & Reuse ..................................................................... 210

7.1.1.1 Technical Solution to Authentication ....................................... 2107.1.1.2 Technical Solution to Authorisation ......................................... 2107.1.1.3 Technical Solution to Privacy .................................................. 210


7.1.3.1 Method “Create User” .............................................................. 2127.1.3.2 Method “Get User” ................................................................... 2127.1.3.3 Method “Get Users” ................................................................. 2137.1.3.4 Method “Update User” ............................................................. 2147.1.3.5 Method “Delete User” .............................................................. 2157.1.3.6 Method “Access User Data” .................................................... 2167.1.3.7 Method “User Login” ................................................................ 2167.1.3.8 Method “Authenticate Token” .................................................. 2177.1.3.9 Method “User Logout” ............................................................. 218

7.1.4 Content Format ....................................................................................... 2188 Transmitted Issues ...................................................................................................... 2209 Conclusion .................................................................................................................. 221





10 / 227


List of Figures, Tables and Listings Due the large number of figures, tables and listings in this deliverable, those lists are moved to Annex A.





11 / 227


1 Introduction

CREMA – Cloud-based Rapid Elastic MAnufacturing – is a project funded by the Horizon 2020 Programme of the European Commission under Grant Agreement No. 637066. Within this deliverable, an in-depth technical definition of all CREMA software components, including the selection of software and technologies that provide the foundation for the individual components, interface definitions, and a declaration of missing elements and implementation needs.

1.1 CREMA Project Overview

CREMA aims at simplifying the establishment, management, adaptation, and monitoring of dynamic, cross-organisational manufacturing processes following Cloud manufacturing principles. CREMA will also provide the means to integrate data from distributed locations as if the complete manufacturing was carried out on the same shop floor, by integrating extra- and inter-plant manufacturing assets and making them “mobile”. CREMA will be built upon concepts and methods from the fields of Virtual Factories, Service-oriented Computing, Ubiquitous Computing, Cyber-Physical Systems, the Internet of Things and the Internet of Services, and naturally and most importantly Cloud computing. To achieve its goals, the project will define tools and approaches in these areas:

• Manufacturing Virtualisation & Interoperability • Cloud Manufacturing Process and Optimisation Framework • Cloud Manufacturing Collaboration, Knowledge and Stakeholder Interaction

Framework Thus, to achieve its goals, CREMA conducts original research and applies technologies from the fields of full end-to-end integration of Cloud manufacturing, integration of manufacturing assets and corresponding data sources, the design and execution of manufacturing processes, to the end user support via collaboration and interaction tools. For more information, please refer to the project Website1.

1.2 Deliverable Purpose, Scope and Context

The purpose of this document is to provide the detailed technical specification of all CREMA software components. The technical specification is based on the software engineering activities of CREMA, which were previously presented within the Requirements Analysis (D2.9), the Global Architecture Definition (D3.1), and – most importantly – the Functional Specification (D3.2). Finally, the Holistic Security and Privacy Concept (deliverable D3.4) complements the document at hand by defining (amongst other things) security and privacy aspects to be regarded during the research, technology, and development work in WP4-6. For this purpose, this document defines the individual subcomponents on a deep technical level by discussing major design decisions, a selection of the technological foundation for the implementation efforts, a definition of missing elements and implementation needs, and an updated component structure. Very importantly, the interfaces offered to other software components are specified.

1 http://www.crema-project.eu/





12 / 227


1.3 Document Status and Target Audience

This document is listed in the Description of Action (DoA) as “public”, since it provides the technical specifications of the CREMA software components and can therefore be used by external parties in order to get according insights into the project activities. While the document primarily aims the project partners, this public deliverable can also be useful for the wider scientific and industrial community. This includes other publicly funded projects, which may be interested in collaboration activities.

1.4 Abbreviations and Glossary

A glossary of common terms and roles related to the realisation of CREMA as well as a list of abbreviations is provided as an online glossary2 / abbreviations list3.

1.5 Document Structure

This deliverable is broken down into the following sections:

• Section 1: Provides an introduction for this deliverable, including a general overview of the project, and outlines the purpose, scope, context, status, and target audience of this deliverable.

• Section 2: Recapitulates the global architecture of CREMA shortly, and introduces the expectations of this document.

• Section 3: Provides common technical decisions that influences all CREMA components and also introduces the structure of the component descriptions in Section 4-7.

• Section 4-7: Presents the technical specification of all components included in WP4, WP5, and WP6, and additionally the additional SPC component. For each component, the technology base is selected and reused software is presented that may be used as a foundation for the related component. Furthermore, an updated component structure overview is described and a detailed list of provided public interfaces. Finally, a content format is provided, which is used primarily for the related component.

• Section 8: Provides a list of remaining issues from the Functional Specification (D3.2) that are solved in this document.

• Section 9: Concludes the deliverable with a short summarisation of its findings. • References: Provides the details of the references mentioned in the document. • Annex A: List of Figures, Tables and Listings.

2 http://crema-project.eu/glossary 3 http://crema-project.eu/abbreviations





13 / 227


2 General Description of the Technical Specification

This deliverable is closely aligned with previous deliverables of the project, particularly specifying the user requirements (D2.9), system functionalities (D3.2) and the global architecture (D3.1). As specified in deliverable D3.1 Global Architecture Definition and shown in Figure 1, the functionalities of CREMA will be realised by 15 components. Since Figure 1 is a very abstract version of the CREMA architecture, not all connections are shown in this figure. All connections of the CREMA components can be seen in D3.1, Section 3.1, Figure 6. Additional information for the figure below, are in (D3.2 Functional Specification, Section 2, System Overview).

Figure 1: CREMA Global Architecture Diagram

This document describes, which technologies are used to realise the development of the CREMA system. During this stage of the System Engineering process, the selection of technologies, the definition of public interfaces and defining objects structures are significant to setup a Service Oriented Architecture (SOA). In the following course of this document, each component defines the before mentioned topics plus possible changes due new insights or additional requirements to finish the conceptualisation of CREMA.





14 / 227


3 General Technology Selection

This section describes the general decisions of the CREMA system that will be used by the various CREMA components.

3.1 Data Storage

Backing up data to an external hard drive only defers the risk of losing important files/data from the drive. Because hard drives are susceptible to be damaged or corrupted. Therefore saving a huge amount of data directly to external hard drives increase the need for maintaining a large number of hardware and software components. Thus, huge expenses and costs have to be invested to achieve a completely data integrity. Contrariwise, cloud storage concepts offer an easy to use solution to achieve the same goals as the traditional use of static hard drives. Using a cloud storage solution avoids most of the costs associated with the traditional saving and backup methods; it especially reduces the huge time spent on maintaining and processing the saving and back up processes. Above all, a big benefit is reached when combining the use of a cloud storage solution with the employment of a RAID-based system - with RAID (Redundant Array of Independent Discs) enabled on a cloud storage system two or more drives can be connected in the system to act as a big drive unity. Thus, backups and mirrors could be made automatically and instantaneously. The data protection mode allows a high level of data protection while splitting the storage capacity into two halves. One half is used to store data and the other half is for mirroring (duplicating) it. Saving data to a cloud also increases the security and privacy purposes. Data is encrypted while transferring and while at rest, so no unauthorized third party could access these data or read it along during the transmission. Cloud storage concepts also solve the biggest issue associated with manually backing up business data; it solves this tedious process by using automation. An additional feature of the cloud storage solution is dedicated to software developers. They don’t have to care about the type of data their applications want to save and which database this data should be saved to. Most of the cloud storage solutions support multiple data types (e.g. semi structured, binary or semantic data) and provide unified methods to handle with these different data base systems. Thus, software developers don’t have to struggle with different query syntaxes and programming languages.

3.2 Security and Privacy

Security is a major factor of success for the CREMA project because data, especially sensitive and private data, are consumed in a large quantity. Machines, components and people will use a big amount of data and business processes that need to be secured and meet the current demands. CREMA allows users and companies to benefit from a flexible react to demands and to be able to provide production capacities. For this benefit many systems and machines are consuming services provided with the help of the CREMA platform. Those engines and services may be bound to personal and secret user and company data that are particularly worthy of protection.





15 / 227


For example, a service that will make pay-per-use possible needs banking information about the customer to book the costs properly. To gain the acceptance of the users and industry, security and privacy should be respected, at least in a conceptual way. Because of the fact that CREMA is not a security project, a basic security concept with a prototypical implementation will be delivered. The consortium is convinced that a project cannot succeed in the market if it does not respect the privacy of its users. But it should be mentioned that no hundred percent secure platform should be expected at the end of the project lifetime. It can and should be expected though, that a concept is given, which can influence the design of each component to be secure aware and that minds privacy, or at least be extensible in a way that the overall security and privacy plans of CREMA can be implemented fully with additional effort after the projects lifetime.

3.3 Public Interfaces

REST (REpresentational State Transfer) is a lightweight alternative mechanism like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, etc.). In a nutshell, REST gives a coordinated set of constraints to the design of components in a distributed hypermedia system. This kind of RESTful systems, communicate over Hypertext Transfer Protocol (HTTP) with the same HTTP verbs (e.g., GET, POST, PUT, DELETE, etc.) offering simplicity, scalability and performance among other properties. Due to the nature of RESTful web-based services, it is quite easy to standardise a documentation, which can be used to invoke offered services by other systems/ components. Since CREMA is divided in a number of components, REST fits nicely to offer component connectivity and data exchange in an elegant and standardised way.

3.4 Data-Interchange Format

The Java Script Object Notation (JSON) is a widely used open standard format, which has been adopted by CREMA R&D activities for developing the interfaces between components. JSON is a lightweight data interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. This format uses human readable text to transmit data objects consisting of attribute value pairs. It is the primary data format used for asynchronous browser-server communication, largely replacing XML. Although originally derived from the JavaScript scripting language and based on a subset of the Java Script Programming Language, JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language. In conclusion JSON is ideal to use within CREMA as an easy and universally interchange data format.

3.5 Semantic Data

The development and sharing of a CREMA semantic data model enables semantic interoperability and management of service-based manufacturing processes and data in the CREMA use cases. Prominent W3C standard languages for semantic data modelling with formal semantics are OWL2 (Web Ontology Language) and RDFS (RDF Schema) for RDF (Resource Description Framework) data. Linked data sets in RDF can be included in





16 / 227


semantic data models in OWL2. The semantic annotation of process models and services with a formal CREMA semantic data model in OWL2 allows for an automated and optimal assignment of services to processes at design time and runtime. The optimal assignment relies on high-precision semantic selection and automated planning of services for the implementation of given annotated processes. Besides, streams of semantic annotated sensor data can be continuously processed in order in order to detect and diagnose machine conditions and related service-based process optimisation. For example, if the semantic data analysis indicates the onset of a machine fault with high probability, the process services of this machine may not be considered for an optimal assignment of services to processes. The shared CREMA semantic data model enables semantic interoperability of exchanged data, and semi-automated semantic data harmonisation in CREMA.

3.6 Component-based Technical Specification

The following list describes the template that is used for the technical description of each component in the CREMA architecture. The information for each of the components in the next sections is structured as follows:

• Technology Base & Reuse: This subsection describes selected technologies used for the implementation of each component. The identification of the selected technologies are based on defined functionalities in the functional specification (D3.2). The reasons why a particular technology has been selected or an existing software system has been reused are explained.

• Component Structure Overview: This subsection describes the current state of the component architecture. This updated architecture contains technology decisions and could differ from previous diagrams of the Global Architecture Definition (D3.1) and the Functional Specification (D3.2) in terms of restructuring for technology adjustments. If the architecture is changed, reasons for the changes are explained.

• Public Interfaces: In this subsection, the focus is on public interfaces to enable interactions between CREMA components. For this, all interactions which have been identified during the definition of the Global Architecture Definition (D3.1) and the Functional Specification (D3.2) are covered. In addition, new interactions that have been identified during the technical specification are also covered and according interfaces are provided.

• Content Format: This subsection defines the data models, which are used within the related components. Since for most of the CREMA software components JSON has been chosen as messaging format, in most cases this subsection states the defined JSON explained as exhaustive example snippets. In case the examples are not sufficient to explain the data structures, appropriate JSON schemas or class diagrams may be used.

• Authorisation Definition: Due the usage of a central Security and Privacy (SPC) component (Section 7), each of the CREMA components has to consider its own permission model for the private data part of the authorisation model of the SPC. It describes permissions that are needed to use functions and UI elements of the CREMA component for the respective user.





17 / 227


4 CREMA Manufacturing Virtualisation & Interoperability Components

4.1 Data Model, Model Library and Profiles

The Data Model, Model Library and Profiles (DLP) component maintains and provides other CREMA components with access to the semantic CREMA Data Model (CDM) library. The CDM library contains (a) the semantic CREMA data model, which is the public shared CREMA manufacturing domain ontology CDM-Core in OWL2, (b) user-specific CDM-Core profiles, and (c) CDM-Core metadata. The DLP component provides other CREMA components with functions for basic (CRUD) management, querying, and support of collaborative contributions to the CDM-Core ontology that is stored in the cloud. These functions are offered to the user through the user interface of the DHS component, and are implemented as RESTful services. The syntax chosen for data exchange is JSON, enclosed in specialised wrappers when required by the original format.

4.1.1 Technology Base & Reuse

Both lightweight linked RDF data sets and knowledge representations in more expressive heavyweight XML-RDF-encoded OWL2 are called ontologies in the context of the DLP component. Despite solutions for CRUD operations on ontologies already existing (e.g.: Protégé4 and its web-based version WebProtégé), no integrated solution to manage the three basic aspects of DLP (semantic data models, profiles and metadata) was found. For this reason, the component will be implemented from scratch. DLP will adopt standards to store, and interact with the knowledge graphs used for the CDM-Core ontologies. It will also make use of relational DBMS to locally save usage information and to provide overview of user modelling activities inside the component.

4.1.1.1 Standards for resource codification

The CDM-Core is defined in the standard W3C ontology language OWL2 encoded/serialized in standard XML-RDF syntax. The first prototype will be based on the SOH5 (SPARQL Over HTTP) offered by Apache Jena Fuseki26, that will rely on the Apache Jena7 TDB8 (Triple Database) for the actual storage in terms of named graphs. The cloud-based semantic data storage is in the CRI component, which is planned to offer a RESTful interface and a native interaction modality on the SPARQL level. The relational (meta-) data on the CDM-Core usage will be locally stored in an open-source MySQL database of the DLP.

4.1.1.2 Standards for semantic data querying and reasoning

In CREMA, semantic data is stored in a triple store with SPARQL1.1 endpoint and OWL2 reasoning support via OWL-API. The standard semantic query language SPARQL 1.1 also supports the basic CRUD operations required by DLP. Semantic reasoners for OWL2 and 4 http://protege.stanford.edu/ 5 http://jena.apache.org/documentation/serving_data/soh.html 6 https://jena.apache.org/documentation/fuseki2/index.html 7 http://jena.apache.org/index.html 8 http://jena.apache.org/documentation/tdb/index.html





18 / 227


RDF/S are used by the DLP. For relational data querying, the standard SQL is adopted. Combinations of relational and semantic data queries are handled by the internal query workflow processor of the DLP. This includes interpreting the combined queries given in a non-standard format, which is to be specified, resolving the underlying SPARQL and SQL queries as well as collecting and merging the returned data into structured responses.

4.1.1.3 Missing Elements and Implementation Needs

DLP will be able to store any RDF-encoded resource in its semantic TBD as a named graph. This approach also supports linked data sets, as they are also RDF-encoded. For this reasons DHL will not provide any specific functionality for treating linked data sets, differently from their view as lightweight ontologies. On top of the generic RDF triples9, the OWL2-DL layer with RDF materialisation (under OWL-Horst semantics [Horst05]) is added whenever the resource is a heavyweight ones. The missing basic elements that need implementation work are as follows:

• DLP library software API: The RESTful API needs to be implemented from scratch. It is planned to use a webserver (i.e. Apache HTTPD webserver10) equipped with a rewrite module11 to manage URL translation. The application logic will be developed with a server-side scripting language (e.g. PHP12)

• Semantic similarity measure(s): The set of semantic similarity measurements of the DLP has to be defined and implemented. These measurements are performed by the DLP in support of semantic data harmonisation carried out by the DHS component. Semantic similarity computation can rely on a weighted combination of text-based, ontology-based structural and logic-based semantic similarity measurement between given items.

• Specialised workflows for DHS component: Workflow definition and implementation for the DHS predefined queries is ongoing work. Final decisions will be taken later on, when the DHS development started in the second project year. The complex workflows will combine semantic, metadata and relational inputs such that specific requirements of DHS for data harmonisation are met.

4.1.2 Component Structure Overview

The DLP component is composed of the following three main modules (see Figure 2). The Data Model Framework API encapsulates the internal structure of the component in terms of a RESTful API, which exposes all the functions to other CREMA components. The Semantic Data Manager System is responsible for the semantic data management (CRUD) operations and execution of query processing workflows over the CDM-Core in the cloud storage layer (realised by the CRI component). It is supported by the Semantic Data Manipulation module with various kinds of predefined semantic data operations such as various semantic similarity computations for concepts and keywords. These predefined functions can be used by other CREMA components such as the DHS component for data

9 http://www.w3.org/TR/n-triples/#simple-triples 10 http://httpd.apache.org/ 11 http://httpd.apache.org/docs/current/mod/mod_rewrite.html 12 http://php.net/





19 / 227


harmonisation. The module provides access to the actual version of the public shared CDM-Core ontology, which is stored in the CRI component, based on native query interfaces.

Figure 2: DLP Architecture Diagram

4.1.3 Public Interfaces

The following tables provide the defined functions with a description, details about their external aspect (such as the method they use and the actual URL for calling them), the expected -Resource and HTTP- parameters, together with the returning HTTP status and payload for the DLP component. All functions are presented, in term of success criteria, in the deliverable D3.2 (Functional Specification).

4.1.3.1 RESTful Interfaces

In the following, whenever JSON-LD is used as parameter, there is no example provided because of space restrictions. The parameters will always be compliant to the JSON-LD specification13.

4.1.3.1.1 Method “Read CDM-Core Ontology”

“Read CDM-Core ontology” (Table 1) allows a user to search and read ontologies from the CDM-Core based on domain keyword(s). This operation also automatically creates a CDM-Core profile for the user or updates an existing one with the returned resources.

Table 1: DLP RESTful Interface – Read CDM-Core ontology

13 http://json-ld.org/

DataModel,ModelLibraryandProfiles(DLP)

CREMAComponentX

DataModelFrameworkAPI

SemanticDataManagerSystem

-Genericmanagement(CRUD)-Predefinedspecializedqueries

T4.2CREMADataHarmonisationServices(DHS)

CRUDexecutionrequest

query/commandexecution

response

query/results

response

predefinedquery

executionrequest

response

SemanticDataManipulation

request request

query/results

T4.3CREMACloud-basedRAID

Infrastructure(CRI)

Ontologies

LinkedData

Read CDM-Core ontology

Description This function allows the user to read the CDM-Core ontology, or parts (named graphs) of it for given domain(s). The reading of the complete CDM-Core ontology is a special case (all domains). A non-empty answer contains relevant named graphs such as





20 / 227


4.1.3.1.2 Method “Read Other Public CDM-Core Profile”

“Read other public CDM-Core profile” (Table 2) allows a user to select and read another users CDM-Core profile.

Table 2: DLP RESTful Interface – Read other public CDM-Core profile

relevant linked RDF data sets and/or representations in OWL2 from the master data space of the DLP in the cloud. The result is put into the CDM-Core profile of the user, if it exists, or creates it for completing the reading process of the user. The user-specific CDM-Core profiles are stored in user-specific working space sections of the DLP in the cloud.

Request

Request URL GET http://crema.eu/dlp/ontology?session=userToken

Resource Parameters

Name Description Example

userToken : string The userToken propagated through all requests.

User1234

HTTP Parameters

object : object An object representing one or all of the domains

{

“domain”: “manufacturing”

}

Combined Example

GET /dlp/ontology?session=user1234 HTTP/1.1 Host: crema.eu object={“domain” : “manufacturing”}

Response

HTTP Status Code

Value Description

200 Search correctly executed, result returned

204 Search correctly executed, no result returned

400 Returned if the combination of parameters generates an invalid request

401 Authorisation step failed with the provided UserToken

503 Storage layer not available

520 Impossible to store the profile for the object retrieved

JSON Attributes

Name Description

Result : ontologies (only HTTP/200 result)

An object representing JSON-LD serialisation format of the ontologies labelled with the requested domain(s).

Read other public CDM-Core profile

Description This function allows a user to retrieve a public CDM-Core profile of another user (not herself) from the working space. The answer is an ontology (named graph) representing the requested resource.





21 / 227


4.1.3.1.3 Method “Copy Other CDM-Core Profile”

“Copy other CDM-Core profile” (Table 3) is the operation that allows a user to substitute their own CDM-Core profile with the one of another user. The other profile is assumed to be already loaded using the previous operation in Method “Read Other Public CDM-Core Profile”.

Table 3: DLP RESTful Interface – Copy other CDM-Core profile

Request

Request URL GET http://crema.eu/dlp/profile/others?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the named graph of the profile to be read

{

“named_graph”:”uc_23”

}

Combined Example

GET /dlp/profile/others?session=user1234 HTTP/1.1 Host: crema.eu object={“named_graph” : “uc_23”}

Response

HTTP Status Code

Value Description



400 Named graph unknown



JSON Attributes

Name Description

Result : ontology (only HTTP/200 result)

An object representing JSON-LD serialisation format of the ontology identified by the named graph received

Copy other CDM-Core profile

Description This function allows a user to copy a CDM-Core profile of another user into her own working space section.

Request

Request URL POST http://crema.eu/dlp/profile/others?session=userToken

Resource Parameters



User1234





22 / 227


4.1.3.1.4 Method “Read my CDM-Core Profile”

“Read my CDM-Core profile” (Table 4) supports a user in multisession editing of its own profile, allowing to continue editing the profile in another session.

Table 4: DLP RESTful Interface – Read my CDM-Core profile

HTTP Parameters

object : object An object representing JSON-LD serialisation format of the profile to be stored.

Combined Example

POST /dlp/profile/others?session=user1234 HTTP/1.1 Host: crema.eu object=JSON-LD encode of the profile (named graph) to store

Response

HTTP Status Code

Value Description

201 Profile stored correctly


409 Profile not stored correctly


520 Impossible to copy the profile

Read my CDM-Core profile

Description This function allows a user to read its own CDM-Core profile from the working space. The answer is an ontology (named graph) representing the requested resource.

Request

Request URL GET http://crema.eu/dlp/profile/mine?session=userToken

Resource Parameters



User1234

Combined Example

GET /dlp/profile/mine?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

201 Profile read correctly


409 Profile does not exists


Name Description





23 / 227


4.1.3.1.5 Method “Refresh my CDM-Core Profile”

“Refresh my CDM-Core profile” (Table 5) updates an existing CDM-Core profile to the current content in the master dataspace. Any none committed modification made by the user is lost.

Table 5: DLP RESTful Interface – Refresh my CDM-Core profile

4.1.3.1.6 Method “Update my CDM-Core Profile”

“Update my CDM-Core profile” (Table 6) is the main function for a user to contribute to the CDM-Core. The function supports modification of user-specific CDM-Core profiles by means of adding, modifying or deleting concepts, relations, or individuals. These changes are valid only in the user-specific working space section of the DLP in the cloud. User-specific profile

JSON Attributes

Result : ontology (only HTTP/200 result)

An object representing JSON-LD serialisation format of the ontology identified by the named graph received

Refresh my CDM-Core profile

Description This function allows a user to refresh its CDM-Core profile with the relevant domain related CDM-Core parts. The CDM-Core profile of the user in its working space section is replaced with the current version of the corresponding part of the CDM-Core in the master dataspace in the cloud.

Request

Request URL PUT http://crema.eu/dlp/profile/mine?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing JSON-LD serialisation format of the updated profile to be stored.

Combined Example

PUT /dlp/profile/mine?session=user1234 HTTP/1.1 Host: crema.eu object=JSON-LD encode of the profile (named graph) to store

Response

HTTP Status Code

Value Description

202 Profile updated correctly


409 Profile does not exists


520 Impossible to update the profile





24 / 227


changes are not automatically committed to the shared CDM-Core in the master dataspace of the DLP in the cloud.

Table 6: DLP RESTful Interface – Update my CDM-Core profile

4.1.3.1.7 Method “Update Metadata of my CDM-Core Profile”

“Update metadata of my CDM-Core profile” (Table 7) is another way for a user to contribute to the CDM-Core by means of addition or changes of metadata. No automatic commit to CDM-Core master space is managed by this function.

Table 7: DLP RESTful Interface – Update metadata of my CDM-Core profile

Update my CDM-Core profile

Description This function allows a user to modify its CDM-Core profile in its working space section by means of adding, changing, or removing concepts, relations, and individuals. Examples are modification of concept definition in OWL, and adding of a linked data statement.

Request

Request URL POST http://crema.eu/dlp/profile/mine?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing JSON-LD serialisation format of the new profile to be stored.

Combined Example

POST /dlp/profile/mine?session=user1234 HTTP/1.1 Host: crema.eu object=JSON-LD encode of the profile (named graph) to store

Response

HTTP Status Code

Value Description

200 Updated profile correctly stored


409 Profile to update does not exist


520 Impossible to update the profile passed

Update metadata of my CDM-Core profile

Description This function allows a user to modify some of the metadata of its CDM-Core profile, which are properties of the respective named graph of the profile. Examples are modification of profile description, and adding of a new domain covered by the profile.





25 / 227


4.1.3.1.8 Method “Commit my CDM-Core Profile”

“Commit my CDM-Core profile” (Table 8) explicitly commits a CDM-Core profile in the working space to the public shared CDM-Core master dataspace. One then, the changes to a profile are available for others.

Table 8: DLP RESTful Interface – Commit my CDM-Core profile

Request

Request URL POST http://crema.eu/dlp/metadata/mine?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing JSON-LD serialization format of the new profile to be stored.

Combined Example

POST /dlp/metadata/mine/?session=user1234 HTTP/1.1 Host: crema.eu object=JSON-LD encode of the profile (named graph) to store

Response

HTTP Status Code

Value Description

200 Updated profile correctly stored


409 Profile to update does not exist


520 Impossible to update the profile metadata requested

Commit my CDM-Core profile

Description This function allows a user to commit its CDM-Core profile in the working space to the public shared CDM-Core in the master dataspace. The applied N-user commitment policy is kept mostly simple: the most recent commitment overwrites all previous changes, i.e. “dirty writes”. There is no further functionality of ontology transaction management such as for versioning, 2PL (two-phase-locking) protocol, and recovery.

Request

Request URL PUT http://crema.eu/dlp/profile/mine/commit?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing JSON-LD serialization





26 / 227


4.1.3.1.9 Method “Delete Ontology”

“Delete ontology” (Table 9) is used to remove a named graph from CDM-Core. It does not rely on the commit function as it works directly in the master dataspace.

Table 9: DLP RESTful Interface – Delete ontology

format of the profile to be stored.

Combined Example

PUT /dlp/profile/mine/commit?session=user1234 HTTP/1.1 Host: crema.eu

object=JSON-LD encode of the profile (named graph) to store

Response

HTTP Status Code

Value Description

202 Commit executed successfully


409 Commit failed


520 Impossible to execute the search requested

Delete ontology

Description This function allows a user to delete a specific ontology (named graph) from the CDM-Core in the master data space of the DLP in the cloud. Note: An ontology deleted can reappear as an effect of a user CDM-Core profile commit, if it was created before the current delete operation.

Request

Request URL DELETE http://crema.eu/dlp/ontology/?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the named graph of the ontology to be deleted

{“named_graph” : “uc_23”}

Combined Example

DELETE /dlp/ontology?session=user1234 HTTP/1.1 Host: crema.eu object={“named_graph” : “uc_23”}

Response

HTTP Status Code

Value Description

200 Ontology correctly deleted





27 / 227


4.1.3.1.10 Method “Add Ontology”

“Add ontology” (Table 10) adds a new named graph into CDM-Core. It does not rely on the commit function as it works directly in the master dataspace.

Table 10: DLP RESTful Interface – Add ontology


404 Ontology to delete does not exist


520 Impossible to execute the requested deletion operation

Add ontology

Description This function allows a user to add one ontology (which is not CDM-Core profile) to the CDM-Core in the master dataspace. Note: An ontology (named graph) that is labelled with domain X can disappear as an effect of a user CDM-Core profile commit, in case it included the X domain and it was created before the current delete operation.

Request

Request URL POST http://crema.eu/dlp/ontology?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the requested named graph and the JSON_LD serialization format of the ontology to store.

{

“named_graph”: “uc_23”,

“ont”: JSON-LD(ont)

}

Combined Example

POST /dlp/ontology?session=user1234 HTTP/1.1 Host: crema.eu object=name of the graph and JSON-LD encode of the ontology to store

Response

HTTP Status Code

Value Description

200 Ontology correctly inserted


404 Ontology to store already exists


520 Impossible to execute the requested insertion operation

Name Description





28 / 227


4.1.3.1.11 Method “Find similar Entities in CDM-Core”

“Find similar entities in CDM-Core” (Table 11) retrieves entities from CDM-Core or a CDM-Core profile, which are similar (i.e. relevant) to a given keyword. The result is a ranking of top-n entities, ordered by similarity according to a hybrid similarity measure.

Table 11: DLP RESTful Interface – Find similar entities in CDM-Core

JSON Attributes

Result : identifier given to the named graph (only HTTP/200 result)

----

Find similar entities in CDM-Core

Description This function returns for a given keyword a rank list of relevant entities in the CDM-Core or CDM-Core profile. The semantic relevance is computed with appropriate method(s) for hybrid semantic similarity computation. Hybrid semantic similarity computation refers to a possibly weighted combination of methods for logic-based semantic matching and non-logic-based semantic matching such as text-based similarity and structural ontology-based similarity. The size of the rank list can be limited to top-n results. The presentation of the relevant entities in the rank list is restricted to their definition in the CDM-Core by default.

Request

Request URL GET http://crema.eu/dlp/similarity/open?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the parameters searched

{"refString": "someValue", "weights": [30,25,45], "limiting_NR": 30}

Combined Example

GET /dlp/similarity/open?session=user1234 HTTP/1.1 Host: crema.eu object={"refString": "Machine", " weights": [30,25,45],"limiting_NR": 30}

Response

HTTP Status Code

Value Description




400 Concept not found



Name Description





29 / 227


4.1.3.1.12 Method “Determine Similarity of Two Entities”

“Determine similarity of two entities” (Table 12) computes the semantic similarity score of two entities from the CDM-Core or a CDM-Core profile using a hybrid similarity measure.

Table 12: DLP RESTful Interface – Determine similarity of two entities

JSON Attributes

Result : list of resources returned with their similarity measure (only HTTP/200 result)

{"NR": 30 , "results": [ {"URI1#Machine":87.50},{” URI1#Machine_Resource”:35.55}, {” URI1#Machine_Operator”:35.55}, {“ URI2#operative_Machine”:27}, … ] }

Determine similarity between two entities

Description This function computes the semantic similarity between two given entities of the CDM-Core or a CDM-Core profile. This semantic relevance is computed with appropriate method(s) for hybrid semantic similarity computation (see DLP_F110).

Request

Request URL GET http://crema.eu/dlp/similarity/closed/?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing JSON serialization format of the following parameters:

{Resource1: “CM:Machine” , Resource2 : “UC_23:Machinery” }

Resource1 : string The full URI of the first resource

http://crema-project.eu/DLP/ConditionalMonitoring.owl#Machine

Resource2 : string The full URI of the second resource

http://crema-project.eu/DLP/LDs/ XYZ_987654321#Machinery

Combined Example

GET /dlp/similarity/closed/?session=user1234 HTTP/1.1 Host: crema.eu object={Resource1: “ http://crema-project.eu/DLP/ConditionalMonitoring.owl#Machine”, Resource2: “http://crema-project.eu/DLP/LDs/ XYZ_987654321#Machinery” }

Response

HTTP Status Code

Value Description

200 Similarity computation correctly executed

204 Similarity computation correctly executed, no value returned






30 / 227


4.1.3.1.13 Method “Execute DHS Query”

“Execute DHS query” (Table 13) covers query-answering of DLP as required by the DHS. The set of specific query types for DHS remains to be defined in T4.2.

Table 13: DLP RESTful Interface – Execute DHS query

400 Concept(s) not found


520 Impossible to execute the research requested

JSON Attributes

Name Description

Result : decimal value of the similarity computed (only HTTP/200 result)

An object representing JSON-LD serialisation format of the local linked data identified by the received ID.

Execute DHS query

Description This function covers the query-answering capability of the DLP that is required by the DHS in addition to the functions in Tables 12 and 11. This set of specific queries to be issued by the DHS to the DLP remains to be defined in T4.2.

Request

Request URL GET http://crema.eu/dlp/query/DHS?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the parameters to be matched into the predefined query requested

{"QueryID": " QRY_4321", "par1": "someValue", "par2": "SomeValue2", "par3": 95 }

Combined Example

GET /dlp/query/DHS?session=userToken Host: crema.eu object={"QueryID": " QRY_4321", "par1": "someValue", "par2": "SomeValue2", "par3": 95 }

Response

HTTP Status Code

Value Description

200 Query correctly executed

204 Computation correctly executed, no value returned

400 Query ID not found or combination of parameters invalid



520 Impossible to execute the query requested





31 / 227


4.1.3.1.14 Method “List all CDM-Core Ontologies”

“List all CDM-Core ontologies” (Table 14) returns a list of ontology IDs plus corresponding metadata.

Table 14: DLP RESTful Interface – List all CDM-Core ontologies

4.1.3.1.15 Method “Retrieve a CDM-Core Ontology by ID”

“Retrieve a CDM-Core ontology by ID” (Table 15) returns a specific named graph containing the ontology specified as parameter by ID.

JSON Attributes

Name Description

Result : JSON object (only HTTP/200 result)

An object representing JSON serialisation format of the result provided by the query invoked

List all CDM-Core ontologies

Description This function returns a list of all ontologies (named graphs), which are part of the CDM-Core including their unique IDs and attached metadata. The result can be used for the invocation of function Table 15.

Request

Request URL GET http://crema.eu/dlp/ontology/list?session=userToken

Resource Parameters



User1234

Combined Example

GET /dlp/ontology/list?session=userToken Host: crema.eu

Response

HTTP Status Code

Value Description

200 Request of listing correctly executed

204 Request of listing correctly executed, no value returned



520 Impossible to execute the listing requested

JSON Attributes

Name Description

Result : JSON object containing the named graphs (only HTTP/200 result)

{ "results": [ “uc_23”, “uc_1”, “uc_3”, … ] }





32 / 227


Table 15: DLP RESTful Interface – Retrieve a CDM-Core ontology by ID

4.1.3.1.16 Method “Set Equivalence of Entities in CDM-Core”

“Set equivalence of entities in CDM-Core” (Table 16) is used to add semantic equivalence statements for two entities in the CDM-Core. It directly operates on the CDM-Core master dataspace.

Table 16: DLP RESTful Interface – Set equivalence of entities in CDM-Core

Retrieve a CDM-Core ontology by ID

Description This function returns the ontology (named graph) with matching given ID (see Table 14).

Request

Request URL GET http://crema.eu/dlp/ontology/byID?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the named graph of the ontology to be deleted

{“named_graph” : “uc_23”}

Combined Example

GET /dlp/ontology/byID?session=userToken Host: crema.eu object={“named_graph” : “uc_23”}

Response

HTTP Status Code

Value Description


204 Search correctly executed, no content returned

400 Named graph to retrieve not found



520 Impossible to retrieve the Ontology with the specified named graph

JSON Attributes

Name Description

Result : JSON-LD encoded object (only HTTP/200 result)

An object representing JSON-LD serialisation format of the ontology identified by the received ID.

Set equivalence of entities in CDM-Core

Description This function allows users to enter their semantic equivalence statements for two entities into the CDM-Core. These statements concern the level of individuals





33 / 227


4.1.3.1.17 Method “Find CDM-Core Entities by Mame”

The RESTful interface “Find CDM-Core entities by name” (Table 17) helps the user to find one or more instances of concepts or properties matching a given string.

(owl:sameAs) and concept level (owl:EquivalenceClass), as well as rdfs:seeAlso for informal statements of equivalence. The statements are added to the CDM-Core in the master dataspace directly under the same restrictions for commitment as stated in Table 8.

Request

Request URL POST http://crema.eu/dlp/ontology/equivalence?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing JSON serialization format of the following parameters:

{ “Concept1”: “CM:Machine”,

“Concept2”: “CM:Machine_Resource”,

“type”: “owl:EquivalenceClass”}

Concept1 : string The full URI of the first concept

http://crema.eu/DLP/ConditionalMonitoring.owl#Machine

Concept2 : string The full URI of the second concept

http://crema.eu/DLP/ConditionalMonitoring.owl#Machine_Resource

Type : string One of the foreseen linkage types

owl:EquivalenceClass

Combined Example

POST /dlp/ontology/equivalence?session=userToken Host: crema.eu object={ “Concept1”: “ http://crema.eu/DLP/ConditionalMonitoring.owl#Machine ”, “Concept2”: “ http://crema.eu/DLP/ConditionalMonitoring.owl#Machine_Resource”, “type”: “owl:EquivalenceClass”}

Response

HTTP Status Code

Value Description

200 statement correctly stored

400 Concept(s) not found


404 User profile not existing


520 Impossible to execute the similarity computation requested





34 / 227


Table 17: DLP RESTful Interface – Find CDM-Core entities by name

4.1.3.1.18 Method “Increase the Weight (Popularity) of an Entity”

Find CDM-Core entities by name

Description This function is devoted to support the users in searching one or more concepts and/or properties that match, at least partially, the given name.

Request

Request URL GET http://crema.eu/dlp/search?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An JSON object of the following parameters:

{ “searchkey”: “Machine”,

“entity”: “concept”,

“type”: “substring”}

type : string The type of matching requested (can be “exactly”, “substring” or “approximated”).

“type”: “substring”

entity : string The type of entity searched (can be “concept” or “relation”)

“entity”: “concept”

searchkey : string The string to use as search value

“searchkey”: “Machine”,

Combined Example

GET /dlp/ontology/search?session=userToken Host: crema.eu object={“searchkey”: “Machine”, “entity”: “concept”, “type”: “substring”}

Response

HTTP Status Code

Value Description

200 Search correctly executed, returned result(s)

204 Search correctly executed, no matching returned




JSON Attributes

Name Description


{ "results": [ {“ http://crema.eu/DLP/ConditionalMonitoring.owl#Machine”, 100}, {“ http://crema.eu/DLP/ConditionalMonitoring.owl#Machine_Resource”, 43.75}, … ] }





35 / 227


The RESTful interface “Increase the weight (popularity) of an entity” (Table 18) works to increase the absolute value used as popularity measure for a given entity. The concept of popularity is related to the entity usage for similarity assertion previously declared by users.

Table 18: DLP RESTful Interface – Increase the weight (popularity) of an entity

4.1.3.1.19 Method “Read the Weight (Popularity) of an Entity”

Increase the weight (popularity) of an entity

Description This function allows to increase the “popularity” of an entity. The concept of popularity adopted is the absolute number of entity usage for similarity declaration.

Request

Request URL POST http://crema.eu/dlp/popularity?session=userToken

Resource Parameters



User1234

HTTP Parameters


{ “entity”: “Administrative_Entity”,

“value”: 1}

entity : string The full URI of the first concept

http://crema.eu/DLP/MASON.owl#Administrative_Entity

value: string The amount (integer) to be added to the entity “popularity”

1

Combined Example

POST /dlp/popularity?session=userToken Host: crema.eu object={“entity”: “Administrative_Entity”, “value”: 1}

Response

HTTP Status Code

Value Description

200 weight correctly updated




520 Impossible to store weight values

JSON Attributes

Name Description


{ "results": [ {“ http://crema.eu/DLP/ConditionalMonitoring.owl#Machine”, 100}, {“ http://crema.eu/DLP/ConditionalMonitoring.owl#Machine_Resource”, 43.75}, … ] }





36 / 227


The RESTful interface “Read the weight (popularity) of an entity” (Table 19) can be used to support the restriction of selection of similar entities returned by a semantic search. In particular, this function will be used to limit and order descending the returned resultset, by means of analysis of each single candidate.

Table 19: DLP RESTful Interface – Read the weight (popularity) of an entity

4.1.4 Content Format

Content which is received or returned by some DLP function is encoded in JSON. The definition of each single message format has been presented above for each function.

Read the weight (popularity) of an entity

Description This function is devoted to retrieve the popularity value associated to an entity, by means of its usage for previous similarity declaration by users.

Request

Request URL GET http://crema.eu/dlp/popularity?session=userToken

Resource Parameters



User1234

HTTP Parameters


{“entity”: “Administrative_Entity”}

entity : string The full URI of the first concept

http://crema.eu/DLP/MASON.owl#Administrative_Entity

Combined Example

GET /dlp/popularity?session=userToken Host: crema.eu object={“entity”: “Administrative_Entity”}

Response

HTTP Status Code

Value Description

200 Search correctly executed, weight returned

204 Search correctly executed, no value of weight found



520 Impossible to execute the query

JSON Format Result : JSON object containing the weight of the entity (only HTTP/200 result)

{“ http://crema.eu/DLP/MASON.owl#Administrative_Entity”, 7}





37 / 227


4.1.5 Authorisation Definition

Due to the fact that the DLP component has no GUI foreseen in CREMA and those DLP functions are just used by CREMA components without restrictions, no authorisation definition is needed.

4.2 Data Harmonisation Services

The Data Harmonisation Services (DHS) component assists in mapping, transforming and integrating data from concrete existing data sources. For this, it uses existing tools or enhances/improves those, following the semantic CREMA data model CDM-Core that is maintained by the DLP component. The main functionality of the DHS is to help the user (business analyst) to develop so called manufacturing maps. These maps represent the semantic relationships between source schemas and target schemas. For this purpose, the DHS makes use of the CDM-Core maintained by the DLP in order to set the relations between given concepts (keywords) from the target and source schemas. Once created, these maps are stored in the Maps Store of the CRI for future usage. Furthermore, the relationships contained in the maps are also reported back to the DLP so they can be used to extend the CDM-Core as well as helping in the profile creation of the user contribution. To make use of the manufacturing maps, they need to be wrapped as services and, then published in the MPM. These wrapped services are annotated by following the same templates and procedures as other manufacturing services. Then, these wrapped services can be picked up by the user while designing processes with the PDE. Finally, as wrapped transformation services, these manufacturing maps can be called by the PRU when they are reached during the process execution. Alternatively, it is possible to call the DHS for executing additional transformations. These calls are placed by specific CPS gateways (composed of CVA and pilot specific components) and by the BDA. As a final major functionality, the DHS provides access to the semantic similarity computation (linked concepts) functionality offered by the DLP based on the CDM-Core. This way, the user would be able to request linked concepts information when generating the Manufacturing Maps (embedded in the Maps Designer of the DHS). In addition, other CREMA components would be able to call this linked concepts functionality via the REST API offered by the DHS (and DLP) when doing the following tasks: (i) analyse schemas when the user is designing queries (from the BDA), (ii) describe/annotate the manufacturing services to be used within the CREMA platform (from the SVA), and (iii) help when the user is mapping BPMN inputs, outputs (from the PDE). An example of these requests is the following: “Find me a definition for ‘pressure sensor’ in the CDM-Core, which I can use to specify my service output”.


The DHS has a three-fold purpose: (i) it allows the user (Business Analyst) to create manufacturing maps, (ii) it allows the execution of transformation services, i.e. running the manufacturing maps, and (iii) it allows the users of other CREMA components, such as BDA, PDE or SVA, to send requests and retrieve linked concepts when executing their activities.





38 / 227


For all these purposes, technology decisions have been taken and described in the following subsections.

4.2.1.1 Selection for Maps Designer and Transformation Engine

As already pointed out in several previous documents, the DHS will be based on Talend Open Studio for Data Integration14. This open-source tool already allows the generation of maps, and transformation between several types of data formats and schemas. However, this tool should be improved to deal with ontologies and other semantic formats on one hand, and with linked concepts and collaborative development of the semantic CREMA data model on the other hand to fully cover the expected functionality from the DHS. The Talend Open Studio for Data Integration is provided under the Apache License v2 agreement terms. The Apache license requires preservation of the copyright notice and disclaimer. Like other free software licenses, the license allows the user of the software the freedom to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software, under the terms of the license, without concern for royalties.


As the DHS is originated in two different fronts, the strategy is different for each of them. On one side, the Maps Designer and the Transformation Engine are being developed on top of Talend Open Studio for Data Integration (TOS), allowing its current version to generate syntactic maps and deploy them as JAR, WAR or OSGi bundles. On the other side, the linked concepts functionality is developed from scratch and is going to make use of appropriate REST interfaces and calls to the DLP. As such, the following features will be developed:

• Semantic support: Ontology-based formats are currently not supported within TOS. The DHS makes use of the DLP to facilitate the generation of the manufacturing maps and since the CREMA data model is in XML-RDF syntax of OWL2, this needs to be developed on top of TOS.

• Publish in CREMA MPM: The transformation services that are going to be developed by the user, as the final stage of the development of the manufacturing maps, need to be compliant with the services publication template as being defined by the CREMA MPM (see Section 4.5.4).

• Linked Concepts: As just mentioned, the linked concepts functionality is a collection of functions, together with an UI, making use of the services exposed by the DLP as REST Interfaces.


The diagram below shows the architecture of the DHS, which has been updated to reflect the technology selection and some other updates on the component’s architecture. In comparison to the Functional Specification (T3.2, D3.2), the subcomponents have slightly changed in order to reflect the technology selection and in order to better cope with the implementation planning described in previous sections:

14 http://www.talend.com/products/data-integration





39 / 227


• There are two aspects to be taken into consideration regarding security: one at design time, i.e. when the business analyst is creating the manufacturing maps, and a second one at runtime, i.e. when other CREMA components request the intervention of the DHS, either for its linked concepts functionality or for the execution of its transformation services. In the first case, the DHS gets the user token from the CREMA DBV and, if the interaction requested by the user involves the CRI, e.g. to retrieve a manufacturing map from the CRI, this is forwarded to the CRI itself for further filtering and authorising. In the latter case, the DHS gets the requests already filtered by the calling component.

• The publication of the transformation services is taken into consideration in a more explicit way. In the previous version of the diagram (see Section 4.2 of D3.1 deliverable), this was supposed to be published by the CRI. However, after several discussions between the responsible partner from the CREMA CRI, DHS and MPM, it was agreed that a similar approach to what is going to be implemented to publish the services virtualised under CREMA SVA should be followed. As such, a new UI will be developed within the DHS to allow the similar publication procedure.

• Also in the previous version of the diagram (see Section 4.2 of D3.1 deliverable), the final selection of computed semantic relations between keywords (concepts) by the user was not provided as an explicit feedback to the DLP. With the current update, the final user selection is sent to the DLP for taking it into account in future semantic similarity computations on request.

• Some labels are changed in terms of defining technologies to be used.





40 / 227


Figure 3: DHS Architecture Diagram

To achieve the functionalities described in the last subsection, the CREMA DHS provides the following subcomponents as depicted in the figure above.

• Maps Designer (Talend Open Studio for Data Integration): The Maps Designer subcomponent is the core for designing Manufacturing Maps. Talend Open Studio (TOS) will be taken and extended to include the necessary functionality to deal with semantic content.

InstantiatedProxyService

Wrapper(viaPRU)Service

concepts

T4.5(SVA)T5.1(PDE)

<userinterface>MappingUI

MapsDesigner[TalendOpenStudioforDataIntegration]

CREMADataHarmonisationServices(DHS)

<<interface>>Harmonisation

wrapper

DatatargetDatasource

ExternalObjects

store/retrieve

serialisedata

fetchdata

<<interface>>AccesstoCRI

ExternalDatasources

T4.1CREMADataModel,ModelLibraryandProfiles(DLP)

get/setsemantics maps

dataschema

<<interface>>AccesstoDLP

<<interface>>LinkedConcepts

API

getschema

execute

show

SpecificCPSGateway(CVA/WP7/WP8),T6.3CREMAManufacturingBigData,KnowledgeandAnalytics(BDA)

TransformationEngine

[Dockerservices]

mapsretrieve

<<interface>>Harmonisation

Services

exetransformation

exetransformation

data/datatransformed

exetransformation

<userinterface>T6.5CREMA

DashboardandVisualisation(DBV)

<<interface>>DataSourceConnectors

retrieveschema

retrieveschema

dataschema

dataschema

get/providelinked

conceptslinkedconcepts

T6.1CREMAMarketplaceand

Monetisation(MPM)

publish maps

data

data

data/transformeddata

<<interface>>SchemaAnalyser

analyse linkedconcepts analysed

linkedconcepts

T6.3CREMAManufacturingBigData,Knowledgeand

Analytics(BDA)

analysesemanticrelevantdata semanticrelevantdata/

analysedsemanticrelevantdata

<<interface>>ConceptProvider

API

provideconcepts

concepts

provideconcepts

conceptsget/provide

linkedconceptslinked

concepts

LinkedConceptsServicesandVisualiser[Ad-hoc]

get/providelinkedconcepts

linkedconcepts

LinkedConceptsAnalyser[Ad-hoc] data/

transformeddata

data


Infrastructure(CRI)

MapsStore

data/analyseddata

get/providelinkedconcepts linked

concepts

exetransformation

datatransformed

get

concepts

<userinterface>PublishinMPM

publishmap maps

store/retrieve

analyse

provideconcepts

linkedconcepts





41 / 227


• Transformation Engine (Docker-based services): The transformation services will be wrapped as Docker-based services, similarly to any manufacturing service that will be virtualised in the SVA. This way, the transformation services will be easily scalable when needed. The transformation engine will be embedded in the services themselves providing a better performance and executing times.

• Linked Concepts Services and Visualiser (Ad-hoc development): The Linked Concepts Services and Visualiser subcomponent makes use of the different computation functionalities of the DLP to calculate similar concepts to the one being passed as parameter.

• Linked Concepts Analyser (Ad-hoc development): This subcomponent has two main functionalities: firstly, it breaks down the schemas into concepts and secondly it analyses the broken down concepts by using the services from the previous subcomponent. These requests will come from the BDA component, when building BDA queries, and internal from the Maps Designer, when designing the Manufacturing Maps.

• Harmonisation Services: This subcomponent is in charge of routing the execution transformations requests coming from different actors: (i) from the Proxy Service Wrapper (via the Harmonisation Wrapper); (ii) directly from the specific CPS Gateways (composed of the CVA component plus the subcomponents from the Pilots activities), and; (iii) from the BDA component.

• Publish in MPM: This UI will take care of the annotation and publication of the Docker-based wrapped services into the MPM for their reuse by the PDE.

• Access to CRI: This subcomponent encapsulates the access to the CRI, where the Maps Store is located.

• Access to DLP: This subcomponent encapsulates the access to the DLP for retrieving the relevant semantics when generating the manufacturing maps. In addition, it will offer also the service of updating the CDM-Core metadata values such as popularity.

• Content Provider API: This subcomponent encapsulates access to the DLP for providing crowdsourcing concepts that will be proposed as part of the usage of the Maps Designer.

• Linked Concepts API: The access to the Linked Concepts Services and Visualiser subcomponent from the SVA and PDE components will be granted via this API to perform their internal tasks.

• Schema Analyser: This subcomponent grants access to requests for analysing schemas when building BDA queries or Manufacturing Maps.

• Data Source Connectors: The requests for transformation need to have a source and a target schema. This subcomponent communicates directly with the source and target systems to retrieve their schemas for executing the requested transformations.

• Harmonisation Wrapper: This subcomponent manages the actual access to the external data sources and the objects where the data is generated and/or stored.


The major design decision for the CREMA project is to use RESTful interfaces as a common communication base for the CREMA components. In order to follow this decision the features of the DHS are defined as RESTful interfaces.





42 / 227



In order to describe the RESTful interface, each provided service is described in a separate table. This table is followed with a listing showing an example for the JSON parameter (if applicable) as well as an example for the return value (if applicable). In the following subsection, the term “user” describes also components which will use this method/interface. In the following, whenever JSON-LD is used as parameter, there is no example provided because of space restrictions. The parameters will always be compliant to the JSON-LD specification15.

4.2.3.1.1 Method “Transform”

Given a prepared document (see Section 4.2.3.1.2), the RESTful interface “Transform” (Table 20) transforms its content, according to a transformation engine fetched from the CRI, and returns the resulting document, unless any exception occurs during the transformation. Input and output documents can follow schemas from CDM or from other external sources, based on common syntaxes like XML, JSON or DSV (delimiter separated values) or some more complex containers like XLS files.

Table 20: DHS RESTful Interface – Transform

15 http://json-ld.org/

Transform

Description This method allows a prepared document to be transformed using a concrete Transformation Engine.

Request

Request URL POST http://crema.eu/dhs/transform/engineId?session=userToken

Resource Parameters


engineId : string ID of the Map fromFagorClutch42

HTTP Parameters


P3L4CtoKn

object : object A serialised object to transform, embed in a wrapper

<transformation> <engineId>fromFagorClutch42</engineId> <engineVersion>1.4</engineVersion> <sourceFormat>CSV</sourceFormat> <targetFormat>XML</targetFormat> <dataIn><![CDATA[ name;temperature;pressure|\n| clutch1;63.1;600|\n| clutch2;61.7;586|\n| clutch3;59.7;614|\n| clutch4;64.1;603|\n| ]]></dataIn> </transformation>

Combined Example

POST /dhs/transform/fromFagorClutch42?session=P3L4CtoKn HTTP/1.1 Host: crema.eu object=<transformation><engineId>fromFagorClutch42</engineId><engineV





43 / 227


4.2.3.1.2 Method “Prepare Data”

The RESTful interface “Prepare Data” (Table 21) wraps a piece of data in any input format with a common envelope that indicates more information on which are the source and target

ersion>1.4</engineVersion><sourceFormat>CSV</sourceFormat><targetFormat>XML</targetFormat><dataIn><![CDATA[name;temperature;pressure|\n|clutch1;63.1;600|\n|clutch2;61.7;586|\n|clutch3;59.7;614|\n|clutch4;64.1;603|\n|]]></dataIn></transformation>

Response

HTTP Status Code

Value Description

200 Object transformed

401 Insufficient rights

404 Map not found

502 Invalid transformation

HTTP Entity <transformation> <engineId>fromFagorClutch42</engineId> <engineVersion>1.4</engineVersion> <sourceFormat>CSV</sourceFormat> <targetFormat>XML</targetFormat> <dataIn><![CDATA[ { "machine": "machine1", "company": "FAGOR", "measures": [ { "name": "clutch1", "temp": "63.1", "pres": "600" }, { "name": "clutch2", "temp": "61.7", "pres": "586" }, { "name": "clutch3", "temp": "59.7", "pres": "614" }, { "name": "clutch4", "temp": "64.1", "pres": "603" } ] } ]]></dataIn> </transformation>





44 / 227


formats, which transformation engine will be used, as well as the concrete version and any other necessary information needed in order to perform the data transformation.

Table 21: DHS RESTful Interface – Prepare Data

Prepare Data

Description This method allows to prepare a piece of data for the data transformation.

Request

Request URL POST http://crema.eu/dhs/preparedata/engineId?source=sourceFormat&target=targetFormat&version=version&session=userToken

Resource Parameters


engineId : string Id of the transformation engine

fromFagorClutch42

sourceFormat : string Format of the source data CSV

targetFormat : string Format of the target data XML

version : string Version of the transformation engine

1.4

HTTP Parameters


P3L4CtoKn

object : object An object representing an object of the specified data type.

name;temperature;pressure|\n| clutch1;63.1;600|\n| clutch2;61.7;586|\n| clutch3;59.7;614|\n| clutch4;64.1;603

Combined Example

POST /dhs/preparedata?/fromFagorClutch42?source=CSV&target=XML&version=1.4&session=P3L4CtoKn HTTP/1.1 Host: crema.eu object=name;temperature;pressure|\n|clutch1;63.1;600|\n|clutch2;61.7;586|\n|clutch3;59.7;614|\n|clutch4;64.1;603

Response

HTTP Status Code

Value Description

200 Schema analysed

204 Schema processed correctly but no result provided


409 Object with specific ID already exists in the Bucket

HTTP Entity <transformation> <engineId>fromFagorClutch42</engineId> <engineVersion>1.4</engineVersion> <sourceFormat>CSV</sourceFormat> <targetFormat>XML</targetFormat>





45 / 227


4.2.3.1.3 Method “Return Transformed Data”

The RESTful interface “Return Transformed Data” (Table 22) extracts the data in the target format from a transformation envelope.

Table 22: DHS RESTful Interface – Return Transformed Data

<dataIn><![CDATA[ name;temperature;pressure|\n| clutch1;63.1;600|\n| clutch2;61.7;586|\n| clutch3;59.7;614|\n| clutch4;64.1;603|\n| ]]></dataIn> </transformation>

Return Transformed Data

Description This method extracts the transformed data in the target format which was specified in the transformation.

Request

Request URL POST http://crema.eu/dhs/returntransformation/engineId?session=userToken

Resource Parameters


engineId : string Id of the transformation engine

transport

HTTP Parameters


P3L4CtoKn


<transformation> <engineId>fromFagorClutch42</engineId> <engineVersion>1.4</engineVersion> <sourceFormat>CSV</sourceFormat> <targetFormat>XML</targetFormat> <dataIn><![CDATA[ { "machine": "machine1", "company": "FAGOR", "measures": [ { "name": "clutch1", "temp": "63.1", "pres": "600"





46 / 227


}, { "name": "clutch2", "temp": "61.7", "pres": "586" }, { "name": "clutch3", "temp": "59.7", "pres": "614" }, { "name": "clutch4", "temp": "64.1", "pres": "603" } ] } ]]></dataIn> </transformation>

Combined Example

POST / dhs/returntransformation/fromFagorClutch42?session=P3L4CtoKn HTTP/1.1 Host: crema.eu object=[{"name":"temp1","value":"45.3"},{"name":"pressure1","value":"1.2"}]

Response

HTTP Status Code

Value Description

200 Schema analysed



409 Object with specific ID already exists in the Bucket

HTTP Entity { "machine": "machine1", "company": "FAGOR", "measures": [ { "name": "clutch1", "temp": "63.1", "pres": "600" }, { "name": "clutch2",





47 / 227


4.2.3.1.4 Method “Decompose Schema”

The RESTful interface “Decompose Schema” (Table 23) decomposes the input schema into a list of concepts to be analysed. A knowledge domain ID can be provided to help identifying the concept.

Table 23: DHS RESTful Interface – Decompose Schema

"temp": "61.7", "pres": "586" }, { "name": "clutch3", "temp": "59.7", "pres": "614" }, { "name": "clutch4", "temp": "64.1", "pres": "603" } ] }

Decompose Schema

Description This method allows the decomposition of a schema into a list of concepts.

Request

Request URL POST http://crema.eu/dhs/decomposeschema?domain=domainId&session=userToken

Resource Parameters


domainId : string? Optional domain transport

HTTP Parameters


P3L4CtoKn


[ { "name": "temp1", "value": "45.3" }, { "name": "press1", "value": "1.2" } ]

Combined Example

POST /dhs/decomposeschema?domain=transport&session=P3L4CtoKn HTTP/1.1 Host: crema.eu object=[{"name":"temp1","value":"45.3"},{"name":"pressure1","value":"1.2"}]

Response





48 / 227


4.2.3.1.5 Method “Analyse Concept”

The RESTful interface “Analyse Concept” (Table 24) receives a single concept, extracted from a schema, performs an analysis through the DLP services and returns a rank list of semantically similar concepts (linked concepts). In order to narrow the search, a knowledge domain ID can be provided.

Table 24: DHS RESTful Interface – Analyse Concept

HTTP Status Code

Value Description

200 Schema analysed



HTTP Entity [

{

"concept": "Temperature"

},{

"concept": "Pressure"

},{

"concept": "Time"

}

]

Analyse Concept

Description This method allows to analyse a single concept from a schema, making use of the DLP services and returning a rank list of semantically relevant concepts in the CDM-Core (linked concepts). A knowledge domain ID can be provided to help identifying the concept.

Request

Request URL POST http://crema.eu/dhs/analyseconcept?domain=domainId&session=userToken

Resource Parameters


domainId : string Optional domain transport

HTTP Parameters


P3L4CtoKn

object : object An object representing an object of the concept extracted from the schema.

{ "town": "Milano" }

Combined Example

POST /dhs/analyseconcept?session=P3L4CtoKn34 HTTP/1.1 Host: crema.eu object={"town":"Milano"}

Response





49 / 227


4.2.3.1.6 Method “Connect Data Source”

The RESTful interface “Connect Data Source” (Table 25) allows setting up the connection to a target or source schemas implemented by any data source that may be used afterwards during runtime.

Table 25: DHS RESTful Interface – Connect Data Source

4.2.3.1.7 Method “Is Linked”

HTTP Status Code

Value Description

200 Concept analysed

204 Concept processed correctly but no result provided


HTTP Entity An object representing JSON-LD serialisation format of the concept analysed by DLP

Connect Data Source

Description This method allows a connection to a data source.

Request

Request URL POST http://crema.eu/dhs/datasource?session=userToken

Resource Parameters

Name Description

userToken : string The token propagated through all requests

P3L4CtoKn

object : object Setup of the data source { "schemaUrl": "https:\/\/crema.eu\/schema\/sch001.dtd", "format": "DTD", "version": "1.0" }

Combined Example

POST /dhs/datasource?session=P3L4CtoKn34 HTTP/1.1 Host: crema.eu object={"schemaUrl": "https:\/\/crema.eu\/schema\/sch001.dtd", "format":"DTD", "version":"1.0"}

Response

HTTP Status Code

Value Description

200 Schema was successfully accessed

204 Not possible to access the schema with current setup


404 Schema not found





50 / 227


The RESTful interface “Is Linked” (Table 26) computes the semantic similarity between two given concepts in the CDM-Core, and returns the existing paths between them to certain depth.

Table 26: DHS RESTful Interface – Is Linked

4.2.3.1.8 Method “Create Map”

Is Linked

Description This method allows retrieving the paths between given concepts in the CDM-Core

Request

Request URL GET http://crema.eu/dhs/link/conceptId1/conceptId2?depth=maxDepth&session=userToken

Resource Parameters


conceptId1 : string ID of first concept 2b76

conceptId2 : string ID of second concept 3f8c

HTTP Parameters

maxDepth : integer Max number of levels to look for linked concepts

10

userToken : string The userToken propagated through all requests

P3L4CtoKn

Combined Example

GET /dhs/link/2b76/3f8c?depth=10&session=P3L4CtoKn HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Link found

204 No links found between concepts


404 Some of the concepts were not found

HTTP Entity List of paths that connect two concepts, expressed by their concept IDs. Example: [ [ "2b76", "e525", "bf13", "c9d9", "3f8c" ], [ "2b76", "0182", "8f16", "3f8c" ], [ "2b76", "c58e", "5628", "39f0", "3f8c" ]

]





51 / 227


The RESTful interface “Create Map” (Table 27) creates a new map making use of the CRI component.

Table 27: DHS RESTful Interface – CRUD-Operation Create Map

4.2.3.1.9 Method “Read Map”

The RESTful interface “Read Map” (Table 28), executes a read operation on an existing map making use of the CRI component.

Table 28: DHS RESTful Interface – CRUD-Operation Read Map

Create Map

Description This method allows to store a new map related to a particular knowledge domain of the CDM-Core.

Request

Request URL POST http://crema.eu/dhs/map?session=userToken

HTTP Parameters



P3L4CtoKn

file : file A file that contains the Manufacturing Map project created by TOS

(Binary content of the Manufacturing Map)

Combined Example

POST /dhs/map?session=P3L4CtoKn HTTP/1.1 Host: crema.eu object=(Binary content of the Manufacturing Map)

Response

HTTP Status Code

Value Description

201 Map created


404 Knowledge Domain not found

HTTP Entity ID of the Map created Example: 3f5b

Read Map

Description This method allows to get a specific Map object based on its object id.

Request

Request URL GET http://crema.eu/dhs/map/mapId?session=userToken

Resource Parameters

Name Description

mapId : string ID of the Map 3f5b





52 / 227


4.2.3.1.10 Method “Update Map”

The RESTful interface “Update Map” (Table 29), updates an existing map given its ID, making use of the CRI component.

Table 29: DHS RESTful Interface – CRUD-Operation Update Map

HTTP Parameters


P3L4CtoKn

Combined Example

GET /dhs/map/3f5b?session=P3L4CtoKn HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Map found

204 Map not found



HTTP Entity Result: (Binary stream, only if Status Code is 200)


Update Map

Description This method allows to update an existing Map.

Request

Request URL PUT http://crema.eu/dhs/map/mapId?session=userToken

Resource Parameters

Name Description



P3L4CtoKn

object : object An object representing an Map with the data to be updated


Combined Example

PUT /dhs/map/3f5b?session=P3L4CtoKn HTTP/1.1 Host: crema.eu object=(Binary content of the Manufacturing Map)

Response

HTTP Status Code

Value Description

200 Found Map updated

204 Map not found






53 / 227


4.2.3.1.11 Method “Delete Map”

The RESTful interface “Delete Map” (Table 30), deletes an existing map given its ID making use of the CRI component.

Table 30: DHS RESTful Interface – CRUD-Operation Delete Map

4.2.3.1.12 Method “Attach Transformer to Map”

The RESTful interface “Attach Transformer to Map” (Table 31) adds or replaces the JAR library that implements the corresponding transformation of a map, from some source data to a target data, specified by the map. Given the ID of an existing map, DHS makes use of the CRI to store the transformer.

Table 31: DHS RESTful Interface – Attach Transformer to Map


Delete Map

Description This method allows to delete an existing Map

Request

Request URL DELETE http://crema.eu/dhs/map/mapId?session=userToken

Resource Parameters

Name Description



P3L4CtoKn

Combined Example

DELETE /dhs/map/3f5b?session=P3L4CtoKn HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Map deleted

204 Map not found



Attach Transformer to Map

Description This method allows to attach a transformer to an existing map.

Request

Request URL PUT http://crema.eu/dhs/map/mapId/transformer?session=userToken

Name Description





54 / 227


4.2.3.1.13 Method “Retrieve Transformer from Map”

The RESTful interface “Retrieve Transformer from Map” (Table 32) retrieves the JAR library that will carry out the transformation of an existing map, given its ID and making use of the CRI component to store it.

Table 32: DHS RESTful Interface – Retrieve Transformer from Map

Resource Parameters

mapId : string ID of the map 3f5b


P3L4CtoKn

file : file A file that contains the JAR library that will carry out the transformation for the corresponding map

(binary content of the JAR)

Combined Example

PUT /dhs/map/3f5b/transformer?session=P3L4CtoKn HTTP/1.1 Host: crema.eu file=(binary content of the JAR)

Response

HTTP Status Code

Value Description

200 Transformation attached to map


404 Map not found

503 Unable to attach transformation to map

Retrieve Transformer from Map

Description This method allows to retrieve the transformer of an existing map.

Request

Request URL GET http://crema.eu/dhs/map/mapId/transformer?session=userToken

Resource Parameters

Name Description



P3L4CtoKn

Combined Example

GET /dhs/map/3f5b/transformer?session=P3L4CtoKn HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Transformation attached to map

204 Map found but no transformation was attached





55 / 227


4.2.3.1.14 Method “Deploy Map as Service”

The RESTful interface “Deploy Map as Service” (Table 33) allows generating a transformation service as a Docker container which encapsulates the transformation JAR. This container provides some more information as the main Java class that effectively performs the transformation.

Table 33: DHS RESTful Interface – Deploy Map as Service

4.2.3.1.15 Method “Annotate Service”

The RESTful interface “Annotate Service” (Table 34) allows adding metadata to a transformation service, such as the owner, a description of the service and keywords.

Table 34: DHS RESTful Interface – Annotate Service


404 Map not found

HTTP Binary stream with the content of the JAR library

Deploy Map as Service

Description This method allows to deploy the transformation JAR into a Docker container

Request

Request URL PUT http://crema.eu/dhs/map/mapId/deploy?session=userToken

Resource Parameters

Name Description



P3L4CtoKn

Combined Example

PUT /dhs/map/3f5b/publish?session=P3L4CtoKn HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

201 Map deployed


404 Map not found

412 Map exists but no transformer JAR was attached to it

Annotate Service

Description This method attaching some meta information to the transformation service of a map

Request





56 / 227


Request URL PUT http://crema.eu/dhs/map/mapId/annotate?session=userToken

Resource Parameters

Name Description



P3L4CtoKn

metadata : object JSON structure containing all the metadata associated to a Transformation Service

{ "mapId": "3f5b", "isDraft": "False", "mapName": "From Fagor clutch to CDM", "mapDescription": { "serviceVersion": "1.4", "description": "This Transformation Service converts sensor data from the Fagor clutch model XYZ346 to the CREMA Data Model.", "serviceOwner": "FAGOR", "activationDate": "24\/07\/2015", "notifications": "enabled", "accessGroups": "FAGOR" }, "keywords": [ "fagor", "clutch", "transformation", "clutchXYZ346" ] }

Combined Example


metadata={"mapId":"3f5b","isDraft":"False","mapName":"From Fagor clutch to CDM","mapDescription":{"serviceVersion":"1.4","description":"This Transformation Service converts sensor data from the Fagor clutch model XYZ346 to the CREMA Data Model.","serviceOwner":"FAGOR","activationDate":"24\/07\/2015","notifications":"enabled","accessGroups":"FAGOR"},"keywords":["fagor","clutch","transformation","clutchXYZ346"]}

Response

HTTP Status Code

Value Description

201 Map correctly annotated


404 Map not found





57 / 227


4.2.3.1.16 Method “Publish Map”

The RESTful interface “Publish Map” (Table 35) allows publishing a map on the MPM component.

Table 35: DHS RESTful Interface – Publish Map

4.2.3.1.17 Method “Create Concept”

The RESTful interface “Create Concept” (Table 36) creates a new concept, making use of the CRI component to store it.

Table 36: DHS RESTful Interface – CRUD-Operation Create Concept

412 Map exists but no deployment found

Publish to Map

Description This method allows to publish a map to the MPM.

Request

Request URL PUT http://crema.eu/dhs/map/mapId/publish?session=userToken

Resource Parameters

Name Description



P3L4CtoKn

Combined Example


Response

HTTP Status Code

Value Description

201 Map published


404 Map not found

412 Map exists but no transformer was attached to it

Create Concept

Description This method allows to store a new concept.

Request

Request URL POST http://crema.eu/dhs/concept?session=userToken

Resource Parameters






58 / 227


4.2.3.1.18 Method “Read Concept”

The RESTful interface “Read Concept” (Table 37), executes a read operation on an existing concept, making use of the CRI component.

Table 37: DHS RESTful Interface – CRUD-Operation Read Concept

HTTP Parameters


P3L4CtoKn

object : object An object representing a concept to be created

See JSON-LD specification

Combined Example

POST /dhs/map?session=P3L4CtoKn HTTP/1.1 Host: crema.eu object=JSON-LD encode of the concept to be created

Response

HTTP Status Code

Value Description

201 Concept created


HTTP Entity ID of the concept created (URL-encoded URI) Example: http://www.example.com/ontology.owl/MyConcept

Read Concept

Description This method allows to get a specific concept object based on its object id.

Request

Request URL GET http://crema.eu/dhs/concept/conceptId?session=userToken

Resource Parameters

Name Description

conceptId : string ID (URL-encoded URI) of the concept

http%3A%2F%2Fwww.example.com%2Fontology.owl%23MyConcept

HTTP Parameters


P3L4CtoKn

Combined Example

GET /dhs/map/http%3A%2F%2Fwww.example.com%2Fontology.owl%23MyConcept?session=P3L4CtoKn HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Concept found






59 / 227


4.2.3.1.19 Method “Update Concept”

The RESTful interface “Update Concept” (Table 38), updates an existing concept given its ID, making use of the CRI component.

Table 38: DHS RESTful Interface – CRUD-Operation Update Concept

4.2.3.1.20 Method “Delete Concept”

The RESTful interface “Delete Concept” (Table 39), deletes an existing concept given its ID, making use of the CRI component.


HTTP Entity Result : JSON-LD encoded object (only HTTP/200 result)

An object representing JSON-LD serialisation format of the ontology identified by the received ID

Update Concept

Description This method allows to update an existing concept.

Request

Request URL PUT http://crema.eu/dhs/concept/conceptId?session=userToken

Resource Parameters

Name Description

conceptId : string ID (URL-encoded URI) of the concept



P3L4CtoKn

object : object An object representing a concept with the data to be updated

An object representing JSON-LD serialisation format of the ontology identified by the received ID

Combined Example

PUT /dhs/concept/http%3A%2F%2Fwww.example.com%2Fontology.owl%23MyConcept?session=P3L4CtoKn HTTP/1.1 Host: crema.eu object= JSON-LD encode of the Concept to be updated

Response

HTTP Status Code

Value Description

200 Concept updated







60 / 227


Table 39: DHS RESTful Interface – CRUD-Operation Delete Concept

4.2.3.1.21 Method “Get Linked Concepts Simple”

The RESTful interface “Get Linked Concepts Simple” (Table 40) retrieves all the concepts that are linked to a given concept up to a certain depth.

Table 40: DHS RESTful Interface – Get Linked Concepts Simple

Delete Concept

Description This method allows to delete an existing concept

Request

Request URL DELETE http://crema.eu/dhs/concept/conceptId?session=userToken

Resource Parameters

Name Description

conceptId : string ID (URL-encoded URI) of the Concept



P3L4CtoKn

Combined Example

DELETE /dhs/concept/http%3A%2F%2Fwww.example.com%2Fontology.owl%23MyConcept?session=P3L4CtoKn HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Concept deleted



Is Linked

Description This method allows to retrieve a path of linked Concepts between two concepts.

Request

Request URL GET http://crema.eu/dhs/concept/conceptName/links? depth=maxDepth&session=userToken

Resource Parameters


conceptName : string Name of the concept city

HTTP Parameters

maxDepth : integer? Max number of levels to look for linked concepts

10


P3L4CtoKn





61 / 227


4.2.3.1.22 Method “Get Linked Concepts with Method”

The RESTful interface “Get Linked Concepts with Method” (Table 41) retrieves all the concepts that are linked to a given concept to a certain depth, and using some method like name similarity or description similarity.

Table 41: DHS RESTful Interface – Get Linked Concepts with Method

Combined Example

GET /dhs/concept/city/links?depth=10&session=P3L4CtoKn HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Link found

204 No Concepts related



HTTP Entity List of Concepts in JSON-LD format

Is Linked

Description This method allows to retrieve a path of linked concepts between two concepts.

Request

Request URL GET http://crema.eu/dhs/concept/conceptName/links? method=methodName&depth=maxDepth&session=userToken

Resource Parameters


conceptName : string Name of the concept city

HTTP Parameters

methodName : string Method used to get the related concepts (e.g. link, name similarity, description similarity)

namesimilarity

maxDepth : integer? Max number of levels to look for linked Concepts

10


P3L4CtoKn

Combined Example

GET /dhs/concept/city/links?method=namesimilarity&depth=10&session=P3L4CtoKn HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Link found





62 / 227


4.2.3.1.23 Method “Get Linked Concepts with Filter”

The RESTful interface “Get Linked Concepts with Filter” (Table 42) retrieves all the concepts that are linked to a given concept to a certain depth.

Table 42: DHS RESTful Interface – Get Linked Concepts with Filter





Is Linked

Description This method allows to retrieve a path of linked concepts between two concepts.

Request

Request URL GET http://crema.eu/dhs/concept/conceptName/links? filter=filterList&depth=maxDepth&session=userToken

Resource Parameters


conceptName : string Name of the Concept city

HTTP Parameters

filterList : string List of conditions Lan:EN;Domain:Geography

maxDepth : integer? Max number of levels to look for linked Concepts

10


P3L4CtoKn

Combined Example

GET /dhs/concept/city/links?filter=Lan:EN;Domain:Geography&depth=10&session=P3L4CtoKn HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Link found









63 / 227



This section shows an example of common data structure expected by DHS via RESTful interface. In order to get a piece of data transformed by DHS the data needs to be wrapped with an envelope, as shown in the Listing below. This envelope provides additional information about what is expected in the transformation such as the transformation engine, format in/out and the data in (see Section 4.2.3.1.2 to see an auxiliary method for this functionality).

Listing 1: Data in CSV wrapped with XML document to be transformed by DHS


At design time, the DHS manages three types of schemas depending on their origin: in-house schemas, partners’ schemas and the CREMA data model. During the design-time phase access to these types of schemas is required, therefore it is necessary to set permissions for in-house and partners’ schemas, since the access to the CREMA data model is granted as the maps designer will be executed as part of the CREMA platform software. The maps designer has access to in-house schemas and certain partners’ schemas depending on the authorisation credentials of the user who is doing the manufacturing maps. This access to the external objects and/or data sources is granted via the Data Source Connectors interface. Hence, different permission models are necessary. The following permission level restricts users for different kinds of tasks. So the following list contains the authorisation definitions for the DHS:

• Full Access: The user has unrestricted access to the data schemas that are accessible by the DHS. The user is able to view, load, update and delete data schemas falling under this category.

• Read Access: The user is able to load and view data schemas falling under this category.

• Write Access: This permission model inherits the permission from “Read Access” and extends it with update permission. A distinction is that data schemas cannot be deleted.

• Unauthorised: This level of authorisation prevents the data schemas falling under this category from being loaded or viewed.

The Listing below shows the example of how a response from the SPC component could be. It uses the predefined permission labels to set the rights for each user.

<transformation> <engineId>fromFagorClutch42</engineId> <formatIn>CSV</formatIn> <formatOut>XML</formatOut> <dataIn><![CDATA[ name;temperature;pressure|\n| clutch1;63.1;600|\n| clutch2;61.7;586|\n| clutch3;59.7;614|\n| clutch4;64.1;603 ]]></dataIn> </transformation>





64 / 227


Listing 2: DHS Example Authorisation Definition

4.3 Cloud-based RAID Infrastructure

The Cloud-based RAID16 Infrastructure (CRI) is the central storage of all data in the CREMA system, which has to be stored persistently and redundantly. This includes manufacturing-related domain ontologies, linked data, maps, service templates, process models, abstract and concrete services, business rules, KPIs etc. The CRI component is responsible for redundant storage backed by RAID technology to increase availability and guarantee permanent data access. The CRI provides a REST interface and several concrete implementations of API wrappers for different programming languages (Java, C#, PHP, JavaScript etc.). These different options help other developers to choose their preferred interface and simplify the common task to store or load data, while sustaining the benefits of redundant and highly available storage in the cloud.


The REST-API of the CRI accepts and stores structured JSON-Data as well as binary data. According to this, different bucket-types exist. Therefore, buckets with the same name but of different types are quite allowed for the same user. For these different storage options, technology decisions were taken and described in the following subsections. In addition to redundancies on database-level, which can be achieved by running several redundant database-instances on one server, there is RAID-support on hardware-level for each server as well. In addition, it is possible to increase data availability and security by means of a multi-server setup featuring several redundant nodes.

4.3.1.1 Selection for Semi-Structured Data Storage

MongoDB17 is selected as a semi-structured data storage, as it is an extremely stable and well performing data base management system. MongoDB is an open source solution and uses the GNU Affero General Public License (AGPL), a non-infecting license. It is available for Windows, Linux, OS X and Solaris and provides drivers for many programming languages. It has a very active community and updates are being published very frequently. MongoDB can be run on its own server, in its own private cloud or on Microsoft Azure as a public cloud. The database supports replication and sharing. Thus, synchronisation and scalability are fully integrated.

16 http://faculty.kfupm.edu.sa/ICS/sukairi/ics434(012)/RAID.pdf 17 https://www.mongodb.org/

{ "userId": "758920", "user”: "Higuain Hernandez", "company": "FAGOR", "authorisation": [ {"company": "FAGOR", "permission": "Full Access, Restricted Resources"}, {"company": "GOIZPER", "permission": "unauthorised"} ]; }





65 / 227


4.3.1.2 Selection for Semantic Data Storage

Sesame18, a standard database to store RDF-based data, was initially selected to store semantic data. The more flexible triple store Jena TDB with Fuseki2 will be added for its usage by the DLP. Both Sesame and Jena work with several relational DBMS and are platform independent. Sesames performance is reasonably good and it is also a very stable solution. It is open source and uses the GNU Lesser General Public License (LGPL), a non-infecting license. As the storage requests of semantic data differ clearly from the other data types, they are treated as a separate subcomponent within CRI. Availability can be increased by using a cluster of Galera MySQL databases.

4.3.1.3 Selection for Binary Data Storage

GridFS19 is selected as a binary storage for files and other binary data. It can be hosted on self-managed servers. GridFS is implemented in order to become more flexible and independent from Amazon S3, which could be attached as an alternative secondary storage. Nevertheless, integrating this service would increase complexity and costs without a clear advantage. GridFS offers high availability and scalability. Furthermore, its fast interaction allows a coupling between binary and structured metadata, which does not implicate requests to separate servers or databases.


As the CRI is used as a backend storage solution for several EU projects, it will be iteratively improved over time. CREMA is one step to improve and extend the CRI. The current version allows the management of backend databases, store data, and set ACL permissions. The existing features will be optimised and the following feature will be developed:

• Custom backups: CRI contains a backup schema for the entire server. The Management Web UI shall provide an extra option to activate or deactivate an additional backup functionality for each application and/or bucket of any given type.


The diagram below shows the structure that has been updated to reflect the technology selection. In comparison to the functional specification (D3.2), the subcomponents are restructured in order to reflect the technology selection and to focus on the storage functionality. Therefore the storage monitoring is removed and the semantic storage is outsourced from the semi-structured and binary storage with an own business logic inside the Semantic Storage Nexus. The below mentioned major changes are depicted in Figure 4:

• A security layer was added, which includes both authentication and authorisation processes. It was added to visualise the security aspect with the location where the authentication and authorisation take place. More details in Section 4.3.5

• Some labels are changed in terms of defining technologies to use. These technology defining labels concretise the architecture diagram that allows developers and users to see at a glance where that technology is used. More

18 http://www.sesamedatabase.com/ 19 https://docs.mongodb.org/v3.0/core/gridfs/





66 / 227


specifically the labels of database Backend, Storage Facade and the Storage API Client were updated

• The Storage Monitoring is removed, because of focusing on Storage and RAID functionality

• The semantic storage is outsourced to be more flexible in terms of extensibility and interchangeability

Figure 4: CRI Architecture Diagram

To achieve the functionalities described in the last subsection, the CRI provides the following subcomponents as depicted in Figure 4.

• Storage Backend: Those are external storage systems offering a concrete storage facility for a certain storage type. Following database types and systems are supported: Semi-structured (MongoDB), binary (GridFS) and semantic (Sesame + Jena).

• Storage Access: This subcomponent provides an abstraction layer around concrete storage implementations. This allows CREMA to replace one storage unit with another one if necessary. Hence, the flexibility of the storage system is increased.

• Storage Nexus: The Storage Nexus decouples the CRUD operations from management operations or advanced queries. It projects the incoming requests to the corresponding resources in the backend and prepares the responses.

• REST-API: The REST-API is the interface between the CRI and the remaining CREMA components (e.g. the marketplace) as well as the client SDKs. It provides the access to all query- and CRUD-operations.

• Client SDK: This subcomponent provides the functionalities of the REST API on a programming-language level. It provides access from within Java, C#, PHP, or JS





67 / 227


environment. As the signatures of those languages would not differ significantly, Java signatures are explained, but not for the other languages.

• Security Layer: This subcomponent takes care of users’ and components’ authentication and authorisation.


The major design decision for the CREMA project is to use RESTful interfaces as a common communication base for the CREMA components. In order to follow this decision the communication interfaces of the CRI are defined as RESTful interfaces. But also APIs are provided for several programming languages.

4.3.3.1 Common Return Codes

Since the most HTTP status codes are the same for the following RESTful interfaces, the table below describes those status codes for the CRI in general, which are referred in the affected interface.

Table 43: CRI RESTful Interface – Common Return Codes

Value Description

200 Success

201 Created successfully

204 Success (no further detail/content is provided)

304 No change (The client should keep/use its current/cached version. No payload is included for efficiency)

400 The server was unable to parse the request

401 Authorization credentials are required, but not provided. Try again after logging in

403 The current user is not authorized

404 Page not found (Given by server)

Bucket not found

Document not found

405 Method not supported (Given by server)

409 Specific details about the submitted request have been rejected by the server. Modifying the request could yet result in a successful operation

412 The supplied ETag value is no longer valid

415 Unsupported Media Type. (Check the Content-Type header)

423 Document has been locked. See the “Retry-After” for the expected expiration.

500 Internal Server Error





68 / 227


4.3.3.2 Method “Create Bucket”

The RESTful interface “Create Bucket” (Table 44), creates a new bucket for the specified owner. A bucket is unique in the context of the owner and type.

Table 44: CRI RESTful Interface – Create Bucket

501 This current server instance does not support this command. (It is not implemented, has been disabled within this context, etc.)

502 Database (or other supporting resource) is not available

503 The server is overloaded. Try again later. (Given by Server)

Create Bucket

Description Creates a new bucket

Request

Request URL POST /version/crema/cri/owner/type/core

Resource Parameters Name : Type Description Example

version : Designator Version of the REST-API 1.0

owner : OwnerName Name of the owner johndoe

type : BucketType Datatype of resource(s) semistructured

JSON Body Parameters application/json

bucket_name :

BucketName Name of the bucket to be created

products

user_icons

acl : AclDef? Create bucket with special ACL

Response

HTTP Status Codes Value Description

201 Bucket has been created

409 Bucket already exists

… See Table 43 for miscellaneous codes

HTTP Headers Name Description of value

Location? URL to the just created bucket, if successful

HTTP Body Contains either a bucket description, payload or a message





69 / 227


4.3.3.3 Method “List Buckets”

The RESTful Interface “List Buckets” (Table 45), provides a list of bucket IDs for the given owner and type.

Table 45: CRI RESTful Interface – Delete Bucket

4.3.3.4 Method “Describe Bucket”

The RESTful Interface “Describe Bucket” (Table 46) provides meta-data associated with the bucket, but not directly contained by the bucket.

Table 46: CRI RESTful Interface – Describe Bucket

List Buckets

Description Retrieves a list of buckets for a type

Request

Request URL GET /version/crema/cri/owner/type/info





Response


200 Success


HTTP Body Delivers general bucket information and an array of bucket IDs

Describe Bucket

Description Returns information about the bucket

Request

Request URL GET /version/crema/cri/owner/type/core/bucket_name








70 / 227


4.3.3.5 Method “Delete Bucket”

The RESTful Interface “Delete Bucket” (Table 47), deletes the specific bucket for the specified owner. This will also delete all data stored in the bucket. Normally only for the owner of the bucket.

Table 47: CRI RESTful Interface – Delete Bucket


bucket_name : BucketName

Name of the bucket customers

Response

HTTP Status Code Value Description

200 Success

404 Bucket not found


HTTP Body Contains a bucket description object

Delete Bucket

Description Deletes a bucket based on its name

Request

Method / URL DELETE /version/crema/cri/owner/type/core/bucket_name


version : Designator Version of the REST-API v1.0

owner : UserName Name of the user johndoe

type : BucketType Datatype bin


Name of the bucket customers

Response


200 Bucket has been deleted






71 / 227


4.3.3.6 Method “Create Object”

The RESTful interface “Create Data Object” (Table 48), executes a create operation on an existing bucket. This stores the data of the transferred data object. The storage details are based on the data type of the transferred data object. For semi-structured (document based) collections, an array containing one or more JSON objects is expected. For binary collections, either a JSON array of binary data objects20 or a single binary stream is expected. The single binary stream is used to create a single binary object with default values and is provided for environments with limited control, such as within a web browser.

Listing 3: String Example "mydata with UTF-8 encoding"

The response for a request with an array of objects may contain an array of describing objects, which can provide status, location, and other information about the created objects. The order of the array corresponds to the input array.

Table 48: CRI RESTful Interface – CRUD Operation Create

20 https://docs.mongodb.org/manual/reference/mongodb-extended-json/#binary

… See Table 43 for miscellaneous codes.

Create Object(s)

Description Creates one or more new objects in a specific bucket for a specific user

Request

Request URL POST /version/crema/cri/owner/type/core/bucket_name



owner : UserName Name of the owner johndoe



Name of the bucket where the object shall be stored

customers

JSON Body Parameters application/json

rawdata : JSONobject[]

An array of 1..n objects

acl : AclDef? Create object(s) with special ACL

Binary application/octet-stream

Applicable only for Binary Buckets. This creates a single binary object with the default ACL.

{"rawdata": [{"$binary": "bXlkYXRh", "type":"\x02"}]}





72 / 227


4.3.3.7 Method “Read Object”

The RESTful interface “Read Object” (Table 49), executes a read operation on an existing bucket. This retrieves all data objects of a specific type matching the query object. The matching criteria are based on the data type.

Table 49: CRI RESTful Interface – Read Object

Response


201 Object(s) created



HTTP Headers Name Description of value

Location: URL? URL to the created object. For single object only.

HTTP Body Contains either an array mapping an object descriptions or messages per object requested.

Update Object

Description Updates an object in a specific bucket for a specific user

Request

Method / URL PUT /version/crema/cri/owner/type/core/bucket_name/id



owner : UserName Optional name of the user johndoe



Name of the corresponding bucket

customers

id : ObjectId Id of the object to be updated 1a2b3c

JSON Body Parameters

acl : AclDef? Updates the ACL of the object

rawdata : JSONobject An array with 1 object

Response





73 / 227


4.3.3.8 Method “Update Object”

The RESTful interface “Update Object” (Table 50) performs an update operation on an existing object.

Table 50: CRI RESTful Interface – Update Object


200 Object updated

404 Object not found


HTTP Body Contains either an object, no payload or a message

Update Object

Description Updates an object in a specific bucket for a specific user

Request

Method / URL PUT /version/crema/cri/owner/type/core/bucket_name/id






Name of the corresponding bucket

customers

id : ObjectId Id of the object to be updated 1a2b3c

JSON Body Parameters

acl : AclDef? Updates the ACL of the object

rawdata : JSONobject An array with 1 object

Response


200 Object updated







74 / 227


4.3.3.9 Method “Delete Object”

The RESTful interface “Delete Object” (Table 51) deletes an object in a bucket. Table 51: CRI RESTful Interface – Delete Object

4.3.3.10 Method “Execute Generic Query”

The RESTful Interface “Execute Generic Query” (Table 52) executes a generic query on an existing bucket.

Table 52: CRI RESTful Interface – Generic Query

HTTP Body Contains either an object, no payload or a message

Delete Object

Description Deletes an object in a specific bucket for a specific user

Request

Request URL DELETE /version/crema/cri/owner/type/core/bucket_name/id






Name of the bucket containing the object

customers

id : ObjectId Id of the object to be deleted 1a2b3c

JSON Body Parameters acl : AclDef Create object with special ACL

Response


200 Object deleted

404 Bucket or object not found


Query Read

Description Retrieve a filtered result from CRI. A paging mechanism is used to prevent the response from being too large





75 / 227


Request

Method / URL POST /version/crema/cri/owner/type/core/bucket_name




type : BucketType Datatype semistructured


Name of the bucket to be queried customers

HTTP Body (JSON) last_id : JSON? The value given by the last page read, or Null for the first read request issued.

12345

limit : int? Maximum number of records to return

10

query : JSONObject?

MongoDB query to execute. Default query is to match everything.

orderBy : object? Sorting order

find_one : boolean (Not for paging, this is a single read)

Response


200 Success


HTTP Body (JSON) Name : Type Description Example

last_id : JSON To be given on the next page read, or Null if there is no further content.

12345

num_read : int Number of records returned 10

Values : ReadInfo[]





76 / 227


4.3.3.11 Method “Execute Delete Query”

The Restful interface, which is presented in Table 53 performs a mass deletion of documents that match a query.

Table 53: CRI RESTful Interface – Generic Query

4.3.3.12 Method “Create Repository”

The RESTful interface “Create Repository” (Table 54), provides the functionality to create a repository on a semantic databases to store RDF graphs.

Query Read

Description Retrieve a filtered result from CRI. A paging mechanism is used to prevent the response from being too large

Request

Method / URL POST /version/crema/cri/owner/type/query/bucket_name




type : BucketType Datatype semistructured


Name of the bucket to be queried customers

HTTP Body (JSON) query : JSONObject? MongoDB query to execute. Default query is to match everything

find_one : boolean (Not for paging, this is a single read)

false

Response


200 Success


HTTP Body (JSON) Name : Type Description Example

num_deleted : int Number of records deleted 10





77 / 227


Table 54: RESTful Interface Description – Create Repository

4.3.3.13 Method “Delete Repository”

The RESTful interface “Delete Repository” (Table 55), provides the functionality to delete a repository on semantic database.

Table 55: RESTful Interface Description – Delete Repository

Create a Repository

Description Creates a new repository.

Request

Request URL POST http://crema.eu/cri/semantic?session=userToken

Resource Parameters


userToken : string? The user token propagated through all requests.

User1234

HTTP Parameters

object : object An object that holds the repository information. The values for “id” and “name” are mandatory.

{ “id”:”repoId”, “title”:”repoTitle”, }

Combined Example

POST /cri/semantic/?session=user1234 HTTP/1.1 Host: crema.eu

object={"id":"repoId","title":"repoTitle"}

Response

HTTP Status Code

Value Description

201 Repository created


409 Repository exists already

502 Database error

Delete a Repository

Description Deletes a specific repository.

Request

Request URL DELETE http://crema.eu/cri/semantic/repositoryId?session=userToken

Resource Parameters


repositoryId : string ID of the Bucket repostory123


User1234





78 / 227


4.3.3.14 Method “Create a new RDF Graph”

The RESTful interface “Create a new RDF Graph” (Table 59), provides the functionality to create a new graph in an existing RDF ready repository.

Table 56: RESTful Interface Description – Create a new Graph

Combined Example

DELETE /cri/semantic/repository123?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Repository deleted


404 Repository not found

Create a Data Entry

Description Creates a new RDF graph in an existing RDF ready repository.

Request

Request URL POST http://crema.eu/cri/semantic/repositoryId?session=userToken

Resource Parameters


repositoryId : string ID of the Bucket repository123

userToken : string? The userToken propagated through all requests.

User1234

HTTP Parameters

object : object A full CREATE graph management operation in SPARQL 1.1 Update format.

{ “create”:”CREATE GRAPH <http://crema/graph>“ }

Combined Example

POST /cri/semantic/repository123?session=user1234 HTTP/1.1 Host: crema.eu Content-Type: application/x-www-form-urlencoded

object={"create": "CREATE GRAPH <http://cream/graph>"}

Response

HTTP Status Code

Value Description

201 RDF Graph created



409 RDF Graph exists already

502 Database error





79 / 227


4.3.3.15 Method “Query a RDF Graph”

The RESTful interface “Query a RDF Graph” (Table 57), provides the functionality to execute a generic SPARQL 1.1 query on an available RDF ready repository. The method returns the result of the query in a JSON-LD format.

Table 57: RESTful Interface Description – Query a RDF Graph

Query a RDF Graph

Description Queries a specific repository. The query has to be formulated in SPARQL 1.1.

Request

Request URL POST http://crema.eu/cri/semantic/repositoryId/query?session=userToken

Resource Parameters


repositoryId : string Name of the Bucket repository123


User1234

HTTP Parameters

object : object An object that holds a SPARQL 1.1 query.

{"query": "

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

PREFIX ns: <http://crema.eu/ns#/>

SELECT * {?s ?p ?o}"}

Combined Example

POST /cri/semantic/repositoryIdquery?session=user1234 HTTP/1.1 Host: crema.eu Content-Type: application/x-www-form-urlencoded

object={"query": "PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

PREFIX ns: <http://crema.eu/ns#>

SELECT * {?s ?p ?o}"}}

Response

HTTP Status Code

Value Description

201 OK



409 Query not in SPARQL 1.1 format

502 Database error

JSON Attributes

list

A list of data entries, in JSON-LD format, matching the query. Example: {





80 / 227


4.3.3.16 Method “Update a RDF Graph”

The RESTful interface “Update a RDF Graph” (Table 58), provides the functionality to update a RDF dataset. The query has to be in a SPARQL 1.1 Update format.

Table 58: RESTful Interface Description – Update a RDF Graph

"@context": "http://crema.eu/cps.jsonld", "@id": " http://crema.eu/ ", "key1": "valu1", "key2": "value2" }

Update a RDF Graph

Description Updates an RDF dataset. The query has to be formulated in SPARQL 1.1 Update string.

Request

Request URL PUT http://crema.eu/cri/semantic/repositoryId?session=userToken

Resource Parameters




User1234

HTTP Parameters

object : object An object representing a SPARQL 1.1 Update string.

{ "update": "PREFIX ns: <http://crema.eu/ns#> INSERT DATA { GRAPH <http://crema/graph> { <http://crema/entry1> ns:price 42 } “}" }

Combined Example

PUT /cri/semantic/repository123?session=user1234 HTTP/1.1 Host: crema.eu Content-Type: application/x-www-form-urlencoded

object={"update": "PREFIX ns: <http://crema.eu/ns#>

INSERT DATA { GRAPH <http://crema/graph> { <http://crema/entry1> ns:price 42 } "}

Response

HTTP Status Code

Value Description

201 OK







81 / 227


4.3.3.17 Method “Delete a RDF Graph”

The RESTful interface “Delete a RDF Graph” (Table 59), provides the functionality to delete a RDF graph. If the graph is not empty, it will be first cleared and then deleted.

Table 59: RESTful Interface Description – Delete a RDF Graph

409 Update operation not in SPARQL 1.1 Update format

502 Database error

JSON Attributes

Optional Update result

An optional result of the update operation. Can also include an exception message.

Delete a RDF Graph

Description Deletes all data entries of a graph.

Request

Request URL DELETE http://crema.eu/cri/semantic/repositoryName?session=userToken

Resource Parameters




User1234

HTTP Parameters

object : object A full DROP graph management operation in SPARQL 1.1 Update format.

{

"delete":"DROP GRAPH <http://crema/graph>" }

Combined Example

DELETE /cri/semantic/repository123?session=user1234 HTTP/1.1 Host: crema.eu Content-Type: application/x-www-form-urlencoded object={"delete":"DROP GRAPH <http://crema/graph>"}

Response

HTTP Status Code

Value Description

201 Graph deleted



409 RDF Graph not found

502 Database error





82 / 227



This section lists JSON examples which shows the structure of the common CRI objects for the communication with other components via the RESTful and Java interfaces.

Listing 4: Create Information

Listing 5: Read Information

Listing 6: Query Response

Table 60: Message Description

Name Description

typeName A string with the value “CRIMessage”. This is to assist in proper type casting

currentUser Specifies the current user

targetUser Specifies the target user

stackTrace Provides debug information. Only provided conditionally

status Value to indicate the success or failure of the operation

description Long form text of what happened. (This should address the “why”)

title Short form text of what happened. (This should address the “what”)

timestamp Date/time of the incident

origin (Sub)system where the problem/message originated

version Cloud Storage version identifier. (The server application’s version)

apiVersion The API version being used

{ "_typeName": "CreateInfo", //(This object type) "id": "012345-123-1234567890", //Document ID "etag": "\"0123456789012345\"" //Document revision }

{ "_typeName": "ReadInfo", //(This object type) "id": "012345-123-1234567890", //Document ID "etag": "\"0123456789012345\"", //Document revision "value": { … } //Document value }

{ "_typeName": "QueryResponse", "lastId": "012345-123-1234567890", "numRead": 10, "values":[ … /* Read Info */ ] }





83 / 227


Listing 7: Sample report message for parsing error fault

Listing 8: Sample report message for an access denied response

Listing 9: Sample report message for an unspecified error response

{ "_typeName”: "CRIMessage", "currentUser": "johndoe", "targetUser": "johndoe", "stackTrace": null, "status": false, "description": "There is a syntax error at line 4, column 12. Expected ':', found '='", "title": = "Unable to process request", "timestamp": "2015.11.25 13:14:05 UST", "origin": "REST API Facade", "version": "1.0.1.42", "apiVersion": "v1.0", }

{ "_typeName”: "CRIMessage", "currentUser": "johndoe", "targetUser": "janedoe", "stackTrace": null, "status": false, "description": "User 'johndoe' does not have access to janedoe:data:sales", "title": = "Access denied", "timestamp": "2015.11.25 13:15:07 UST", "origin": "Security Check", "version": "1.0.1.42", "apiVersion": "v1.0", }

"{ "_typeName”: "CRIMessage", "currentUser": "johndoe", "targetUser": "johndoe ", "stackTrace": "IOException: Operation timed out\r\n de.ascora.cri.Class(Class.java:50)…", "status": false, "description": "Unhandled error: IOException: Operation timed out", "title": = "Unhandled internal error", "timestamp": "2015.11.25 13:17:55 UST", "origin": "REST API Facade", "version": "1.0.1.42", "apiVersion": "v1.0", }





84 / 227


Listing 10: Bucket Description Object

Listing 11: Bucket List


The Access Control List (ACL) of the bucket is defining authorisation levels to manage the access to the CRI. The SPC component delivers decoded permissions within an API key. This API key will be transmitted if the user wants to interact with the CRI via the DBV. The SPC also provides the opportunity to set group policies for each user. Thereby, a user can join groups, managed by the SPC to ease passing permissions. These group policies are adjusted to the authorisation level and scope of the CRI. Since the CRI hosts a huge amount of data from different CREMA components, the CRI has a special role regarding authorisation. As other components may not provide an authorisation model definition, the CRI is responsible to authorise the requesting communication partner and provide only authorised data based on the CRI permission level.

{ "_typeName" : "bucketDescription", "name" : "products", "owner" : "u12345678", "type" : "data", "itemCount" : "325", "aclForDocuments" : { "comment: " : "missing attribute means default acl" }, "userPermissions" : { "canCreateDocs" : ["u23456","g200"], "canReadDocs" : ["u23456","g200"], "canUpdateDocs" : ["u23456","g200"], "canDeleteDocs" : ["u23456","g200"], "canDeleteBucket" : [] }, "currentUserEffectivePermissisons" : { "canCreateDocs" : true, "canReadDocs" : true, "canUpdateDocs" : true, "canDeleteDocs" : false, "canDeleteBucket" : false, "canCreateBuckets" : false } }

{ "_typeName" : "bucketList", "itemCount" : "325" "bucketList" : [ { "id" : "5459d6c482e88c8c0b000029", "name" : "pdf_file_23", "type" : "binary" }, {…} ] }





85 / 227


The access can be managed up to a high level of detail (entity id). The following list contains the basic authorisation roles for the CRI, that can be set aside of the detailed entity ids.

• Full: The user has full access to all data in the CRI and to all interaction options. The CRI Management Web UI has absolutely no restrictions.

• ReadOnly: The user has strongly limited access to the data in the CRI. The access is restricted to read the database configuration, but the user is not able to perform any write operations.

The following Listing shows an example of how a response from the SPC component could be. It uses the predefined permission levels to set appropriate rights for each user. Additionally, a scope is defined, which ensures a detailed accessibility. High level scopes can be “CREMA” to access the whole system, or “company” to access data associated to the given company in the public area of the response. A more detailed approach (Listing 12) is to restrict the access for defined objects referring to an id. Therefore, the scope contains further information for accessing a bucket and the underlying data objects. For this, clearly defined Ids must be known from the SPC to allocate permission to the appropriate data.

Listing 12: CRI Example Authorisation Definition

4.4 Cyber-Physical Systems, Sensor Abstraction and Virtualisation

This section outlines the specification details for T4.4 of component CVA. Besides describing the main technologies used, it lists the RESTful web service methods to be delivered by this task.


The CVA component uses the technology of Apache Active Message Queue (MQ)21 for streaming CPS data. Apache Active MQ is a popular and powerful open source messaging and integration pattern server. It is fast, supports many cross language clients and protocols

21 http://activemq.apache.org/

{ "userId":"19929", "user": "Brian Branston", "company ": "Tenneco", "authorisation": { "permission": { "level": ”ReadOnly", "scope": [{ "bucketid":"5498", "dataObjectIds":["129864","321","4783",…] },{ "bucketid":"2486", "dataObjectIds":["4682","123","3874",…] }] } } }





86 / 227


such as Java, C, C++, C#, Ruby, Perl, Python, and PHP comes with easy to use enterprise integration patterns and many advanced features while fully supporting JMS and J2EE. Since the CVA component has to communicate with shop floor sensors, the following existing software platforms and tools are deployed: SMART FACTORY (SF)22, INDUSTREWEB23, DATA LOGGER and RASPBERRYPI. These systems already have the appropriate interface for communicating with shop floor sensors and CPS. INDUSTREWEB, DATA LOGGER and RASPBERRYPI provide sensor data from the machines or PLC they are connected to. SMART FACTORY is interfacing with real time location sensors and provides the position of each asset within the shop floor. The map explorer is a SMART FACTORY feature that is used to gather all assets from all other systems within one common map for the user. This offers the visibility of the shop floor, which furthermore contributes to the transparency of the production process. The benefits from using Smart Factory platform are:

• Central modelling of all shop floor assets, objects and humans within an interactive visible user map.

• Capability of a real time position monitoring of tagged asset, objects and humans. • Capability to quickly search and find assets in the area. • Functionality of notifying and alerting any network element upon any location events

or any change in asset property (e.g. location or other sensor values). Smart Factory Platform has two software components; a configuration UI and a user web interface. While the configuration client enables to design the virtual environment in terms of map, types, objects, properties, spatial zones and rules, the user web interface offers the user a mean to visualise, search and find objects based on any property, e.g. type ID, object ID or property ID. The Smart Factory works in conjunction with a location platform, which computes a 3D real time location of active transponders fixed on assets based on real time measurements from fixed passive inter-synchronised Ultra-Wideband sensors. Similarly to Smart Factory, the INDUSTREWEB and DATA LOGGER are systems connected to shop floor equipment (robots, machines, tools, etc.) via Programmable Language Controllers (PLC), which enable to collect and control various sensor data. These systems provide RESTful web services for their CPS (described in the use case deliverables from WP7 and WP8) in order to access sensor data and request sensor data streams.


The following Figure 5 depicts the updated architecture showing the technologies used. All communication goes through the Virtual Service Wrapper Layer (VSWL). The CPS shop floor represents the cyber physical systems. These are wrapped by custom services in the Service Layer, represented by the concrete systems Location Platform, Raspberry Pi, IndustreWeb and Fagor Data Logger. In the first phase, during a first implementation of CREMA in a factory, there are some manual steps necessary. The first and most important work is the manual provisioning of the web service in a virtualisable container, so that it can be uploaded to the Service Registry in the MPM component and later on be run on virtual hardware by the OSL component.

22 http://ubisense.net/de/products/smart-factory 23 http://www.industreweb.co.uk





87 / 227


Figure 5: CVA Architecture Diagram

To be able to use these services within CREMA, they are manually described in a semantic manner using a web UI provided by the SVA Component. Using a translator, this semantic description can be imported in the Smart Factory dataset, which itself publishes services to access its functions and makes querying easier, can enrich data with a location mapping infrastructure and provides a visualisation of the factory shop-floor, displaying all CPS, human workers and other manufacturing assets. Another manual task is the wrapping of each web service in a virtualisable container, which provides the correct configuration for a runtime environment for the service and enables an on-demand instantiation of this service at runtime. The VSWL is represented by the wrapped service binaries, created within the CVA Component and instantiated by the OSL Component. The services are extracted as a binary from the MPM Service Repository which can communicate with the concrete services and its instantiation enables the PRU Component to call the contained service. The VSWL dashed box in Figure 5 represents these instantiated services, and this layer is green, as it is callable from the outside as soon as the services are instantiated. The concrete services are shown in Figure 5 in red, this means the services of the Smart Factory, IndustreWeb, the Fagor Data Logger, etc. are callable during their instantiation from the outside. All unlabelled black arrows between T5.2/T5.4/T5.5 are unspecified calls because they represent a specified call to the concrete instance of the service. The T5.3 arrow to the VSWL is the instantiation of the service binary, which is found in the T6.1 Marketplace Repository as a virtualisable binary. The metadata about a specific service is generated using the UI in the SVA Component and is stored in the MPM Service Registry. This metadata is translated by the Translator subcomponent to the representation of the data format in the Smart Factory database. Thus, a type and its properties are created in the Smart Factory so that a CPS represented by a service can be registered in the Smart Factory, and its properties can be made available





88 / 227


through the unified abstracted representation of services of the Smart Factory, which means that the same kind of access can be used for all registered services and CPS, so that the Smart Factory’s data schema is an access point to all the services / CPS registered with that instance. The active queue message bus implemented within the PRU Component is used to stream CPS data to any interested subscribers. For this, the services provide an interface to start and to stop the streaming of data to a topic name defined in process-scope, and interested components like the BDA, MON or ODERU components can directly attach to the topic names and get the data as soon as it is produced and published.


The CVA uses RESTful methods to let other external CREMA components access and read CPS sensor data. In the tables below, the RESTful service methods from the CVA component are listed. The methods provided by INDUSTREWEB and DATALOGGER are presented in the use case deliverables of WP7 and WP8 (D7.1 and D8.1)

4.4.3.1.1 Method “Create Type”

The RESTful interface “Create Type” (Table 61), creates a new type of a virtual object. A type is unique in the context of Smart Factory (SF).

Table 61: CVA RESTful Interface – Create Type

Create Type

Description Every virtual object in Smart Factory (SF) has to be of a certain type. There are different types in Smart Factory, such as robots of automotive use case (connected to INDUSTREWEB) or the machines from the maintenance use case (connected to DATA LOGGER). The types are created whenever a new set of objects (with common properties) is to be modelled in the explorer of the Smart Factory.

Request

Request URL POST http://crema.eu/cva/sf/type

HTTP Parameters


type: object an object representing a type in SF

{

"typeId": "Person",

"properties": [{

"id": "name",

"type": "String",

"flag": "name"

}, {

"id": "function",

"type": "String"

}, {

"id": "age",





89 / 227


4.4.3.1.2 Method “Delete Type”

The RESTful interface “Delete Type” (Table 62), deletes an existing type. A type is unique in the context of SF. Deleting a type is to be treated with high care since this delete all objects instances of that type.

Table 62: CVA RESTful Interface – Create Type

4.4.3.1.3 Method “Get Type”

"type": "Int"

}]

}

Combined Example

POST /cva/sf HTTP/1.1 Host: crema.eu

Content-type: application/json type = {“typeId”: “Person”,”propertyArray”:[{“propertyId”: “name”, “type”: ”String”, “flag”: ”name”},{“propertyId”: “function”, “type”: ”String”},{“propertyId”: “age”, “type”: ”Int”} ]}

Response

HTTP Status Code

Value Description

201 Type created

409 Type exists already

Delete Type

Description This method deletes an existing type in SF.

Request

Request URL DELETE http://crema.eu/cva/sf/typeId

Resource Parameters


typeId : string Name of the type Person

Combined Example

DELETE /cva/sf/Person HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Type deleted

404 Type does not exist

JSON Attributes

None None





90 / 227


The RESTful interface “Get Type” (), executes a read operation of a defined type within the SMART FACTORY dataset based on a type name. This retrieve all properties (attributes) related to the specified type.

Table 63: CVA RESTful Interface – Get Type

4.4.3.1.4 Method “Get Types”

The RESTful interface “Get Types” (Table 64), executes a read operation of all existing types within the SMART FACTORY dataset. This retrieves all properties (attributes) related to the specified type. The matching criteria are based on the data type.

Table 64: CVA RESTful Interface – Get Types

Get Type

Description This method gets all properties of a type available in SF

Request

Request URL GET http://crema.eu/cva/sf/typeId

Resource Parameter


typeId : string Name of the Type Person

Combined Example

GET /cva/sf/Person HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

201 Type has been found

404 Type not found

JSON Attributes

List Optional list

A list of all type Ids and their properties { "typeId": "Person", "propertyArray": [{ "propertyId": "name", "flag": "name", "type": "String" }, { "propertyId": "function", "type": "String" }, { "propertyId": "age", "type": "Int" }]

}

Get Types

Description This method gets the list of types available in SF, each with a list of its available simple properties.





91 / 227


4.4.3.1.5 Method “Create Object”

The RESTful interface “Create Object” (Table 65), executes a create operation on an existing Type. This stores the data of the created object. The storage details are based on the data type of the created object.

Table 65: CVA RESTful Interface – Create Object

Request

Request URL GET http://crema.eu/cva/sf/types

Combined Example

GET /cva/sf/ HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

201 At least one type found in list, list is output

404 Type not found

JSON Attributes

List Optional list

A list of all type Ids and their properties [{ "typeId": "Person", "properyArray": [{ "propertyId": "name", "flag": "name", "type": "String" }, { "propertyId": "function", "type": "String" }, { "propertyId": "age", "type": "Int" }] }, { "typeId": "Machine", "properyArray": [{ "propertyId": "name", "flag": "name", "type": "String" }, { "propertyId": "model", "type": "String" }, { "propertyId": "production date", "type": "Time" }] } … ]

Create Object





92 / 227


4.4.3.1.6 Method “Delete Object”

The RESTful interface “Delete Object” (Table 66), executes a delete operation on an existing objects removing also all properties values of that object.

Table 66: CVA RESTful Interface – Delete Object

Description This method creates a new object of a given Type and stores property values to this object.

Request

Request URL POST http://crema.eu/cva/sf/typeId/Objects

Resource Parameters


typeId : string Name of the type Person

HTTP Parameters

object : object Object of a given type

{

“name”: ”Danny”, “function”: “Engineer”, “age”: “31” }

Combined Example

POST /cva/sf/Person/Objects HTTP/1.1 Host: crema.eu

Content-type: application/json object = {“name”: ”Danny”, “function”: “Engineer”, “age”: “31”}

Response

HTTP Status Code

Value Description

201 Object created Returns some data with the response. The data should contain the underlying unique id of the object (different to the name – unique but can be changed at any time). {_id: “04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]PERSON”}

404 Type not found

501 Object with specific ID already exists with the Type

JSON Attributes

none none

Delete Object

Description This method deletes the instance of an object of a given type and all its property values.

Request





93 / 227


4.4.3.1.7 Method “Get Object”

The RESTful interface “Get Object” (Table 67), executes a read operation on an existing object of a given type. This retrieves all properties’ values of that specific object matching the query.

Table 67: CVA RESTful Interface – Get Object

Request URL DELETE http://crema.eu/cva/sf/typeId/Objects

Resource Parameters


typeId : string ID of the type Person

HTTP Parameters/

object: String Id of the object to delete {

“objectId: ” “04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person” }

Combined Example

DELETE /cva/sf/Person/Objects/ HTTP/1.1 Host: crema.eu object = { “objectId”: ”04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person” }

Response

HTTP Status Code

Value Description

200 Object deleted


404 Type not found

JSON Attributes

None None

Get Object

Description This method gets all object property values of an Object.

Request

Request URL GET http://crema.eu/cva/sf/typeId/Objects/

Resource Parameters

Name Description

typeId : string ID of the Type Person

HTTP Parameters/

objectId: String Id of the requested Object {

“objectId: ” “04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person”





94 / 227


4.4.3.1.8 Method “Get Objects”

The RESTful interface “Get Objects” (Table 68), executes a read operation on an all objects of an existing type. This retrieves all properties’ values of all objects of a particular type matching the query. All objects of the specified types will be returned with their full representation.

Table 68: CVA RESTful Interface – Get Objects

}

Combined Example

GET /cva/sf/Person/Objects/ HTTP/1.1 Host: crema.eu object = {

“objectId”: ”04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person”

}

Response

HTTP Status Code

Value Description

201 Object found


404 Type not found

JSON Attributes

list Optional list

A list of properties of an object with their values. Example: {"_id" : "04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person", "name": "Danny", "function": "Engineer", "age": "31" }

Get Objects

Description This method gets a list of all objects of a given type with all their properties’ values.

Request

Request URL GET http://crema.eu/cva/sf/typeId/Objects

Resource Parameters

Name Description


Combined Example

GET /cva/sf/Person/Objects/ HTTP/1.1 Host: crema.eu

Response

Value Description





95 / 227


4.4.3.1.9 Method “Create Simple Property”

The RESTful interface “Create Simple Property” (Table 69), executes a create operation on an existing Type. This stores the data of the created property. The storage details are based on the data type of the transferred data object.

Table 69: CVA RESTful Interface – Create Simple Property

HTTP Status Code

201 Object found


404 Type not found

JSON Attributes

List Optional list

A list of all object IDs and their properties of the given type Example: [ { “_id”: “04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person”, “name”: "Danny", “function”: "Engineer", “age”: “31” }, { “_id”:”04007zLyLmG4B1s0000A4W0002V:UserDataModel:

:[Custom]Person”, “name”: "Tim", “function”: "Team Leader", “age”: “37” } ]

Create Simple Property

Description This method creates a new non existing property for a given type. If objects of that type are already existing, they will get this new property that can have a value.

Request

Request URL POST http://crema.eu/cva/sf/typeId/objects/simplePropertyList

Resource Parameters



HTTP Parameters

property : string Those properties describe a type

{

“propertyId”:“country”,

“type”:”string”

}

Combined Example

POST /sf/Person/ HTTP/1.1 Host: crema.eu





96 / 227


4.4.3.1.10 Method “Delete Simple Property”

The RESTful interface “Delete Simple Property” (Table 70), executes a delete operation on an existing property of a particular type. This will delete the data of that property

Table 70: CVA RESTful Interface – Delete Simple Property

4.4.3.1.11 Method “Create Complex Property”

The RESTful interface “Create Complex Property” (Table 71), executes a create operation on an existing Type by adding a complex property.

Content-Type: application/json property = {“propertyId”: “country”, “type”: ”String”}

Response

HTTP Status Code

Value Description

201 Property created

404 Type not found

400 Property with specific ID already exists for the type

JSON Attributes

None None

Delete Simple Property

Description This method allows deleting a property for a given Type. If objects of that type are already existing the values or the properties will be deleted.

Request

Request URL DELETE http://crema.eu/cva/sf/typeId/objects/simplePropertyList

Resource Parameters



propertyId : string ID of the type property. Unique in the context of an object.

Country

Combined Example

DELETE /sf/Person/country HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Property deleted

404 Property not found

404 Type not found





97 / 227


Table 71: CVA RESTful Interface – Create Complex Property

4.4.3.1.12 Method “Delete Complex Property”

The RESTful interface “Delete Complex Property” (Table 72), executes a delete operation on an existing Type by removing a complex property.

Table 72: CVA RESTful Interface – Delete Complex Property

Create Complex Property

Description This method allows to create a new non existing complex property.

Request

Request URL POST http://crema.eu/cva/sf/typeId/objects/complexPropertyList

Resource Parameter



HTTP Parameter

object : Object JSON defining new property. Syntax of “propertyId” is important to ensure property is correctly created in SF

{

“propertyId”: “__<Product>is_in__<Process Area>”,

“type”: “Bool” }

Combined Example

POST /sf/ComplexPropertylist/ HTTP/1.1 Host: crema.eu

Content-Type: application/json object = {“propertyId”:”__<Product>is_in__<Process Area>”,”type”: “Bool”}

Response

HTTP Status Code

Value Description

201 Property created

404 Type not found

404 Property with specific ID already exists for the type

Delete Type Property

Description This method deletes a complex property of a given Type.

Request

Request URL DELETE http://crema.eu/cva/sf/typeId/objects/complexPropertyList

Resource Parameters


typeId : string ID of the type property. Unique in the context of an object.

Person





98 / 227


4.4.3.1.13 Method “Get Object Property”

The RESTful method “Get Object Property” (Table 73), executes a read operation on an existing object by getting its property value.

Table 73: CVA RESTful Interface – Read Data Object

HTTP Parameter

object : Object JSON defining the target complex property

{

“propertyId”: “__<Product>is_in__<Process Area>”,

“type”: “Bool” }

Combined Example

DELETE /cva/sf/Person/objects/complexPropertyList

HTTP/1.1 Host: crema.eu

Content-Type: application/json

object = {“propertyId”:”__<Product>is_in__<Process Area>”,”type”: “Bool”}

Response

HTTP Status Code

Value Description

200 Property deleted


Get Object Property Value

Description This method gets a particular object property value of an Object.

Request

Request URL GET http://crema.eu/cva/sf/typeId/objects/propertyId

Resource Parameters



propertyId : string ID of the property to be read age

HTTP Parameters/ Request Body JSON

object: object ID of the data object. Unique in the context of the Type

{

“objectId: ” “04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person”, “type”: “Bool” }

Combined Example

GET /sf/Person/objects/age





99 / 227


4.4.3.1.14 Method “Set Object Property Value”

The RESTful interface “Set Object Property Value” (Table 74), executes an update operation on an existing object of a given type by setting a value for one of its properties.

Table 74: CVA RESTful Interface – Update Data Object


Content-Type: application/json object = {“propertyId”: “__<Product>is_in__<Process Area>”,”type”: “Bool”}

Response

HTTP Status Code

Value Description

201 Object found


404 Type not found

JSON Attributes

list Optional list

The result of the property value requested Example: { “value”: 31 }

Set Object Property Value

Description This method updates an existing property value of an object of a given type.

Request

Request URL PUT http://crema.eu/cva/sf/typeId/objects/propertyId

Resource Parameters

Name Description

typeId: string ID of the Type Person

propertyId : string

ID of the property of the object of the type

location


objectId: string

ID of the data object. Unique in the context of the Type

{

“objectId”: “04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person”, “value”: "Test Area" }

Combined Example

PUT /sf/Person/Objects/age


Content-Type: application/json





100 / 227


4.4.3.1.15 Method “Start Object Property Value Stream”

The RESTful interface “Start Object Property Value Stream” (Table 75), starts a stream of data based on chained ids represented in the table below. Subscribers are than able to get the data of this stream.

Table 75: CVA RESTful Interface – Start Object Property Value Stream

{“objectId”: “04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person”,”value”: "Test Area"}

Response

HTTP Status Code

Value Description

200 Found objects updated


404 Type not found

Start Object Property Value Stream

Description This method starts a property value stream of a given Object based on its Id.

Request

Request URL PUT http://crema.eu/cva/sf/typeId/objectList/propertyId/targetId/stream

Resource Parameters



propertyId : string ID of the property of the object of the type

location

targetId: string ID of the stream receiver components

PCE


object: string ID of the data object. Unique in the context of the Type

{

“objectId”: “04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person” }

Combined Example

PUT /sf/Person/objectList/location/PCE/stream HTTP/1.1 Host: crema.eu

object = {“objectId”: ”04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person”}

Response

HTTP Status Code

Value Description

200 Property found and streaming started





101 / 227


4.4.3.1.16 Method “Stop Object Property Value Stream”

The RESTful method “Stop Property Stream” (Table 76), executes a stop operation on an existing type. This stops the stream and ends to provide data to subscribers.

Table 76: CVA RESTful Interface – Stop Object Property Value Stream



404 Type not found

Stop Object Property Value Stream

Description This method stops a property value stream of a given Object based on its Id.

Request

Request URL DELETE http://crema.eu/cva/sf/typeId/objects/propertyId/targetId/stream

Resource Parameters

Name Description


propertyId : string ID of the property of the object of the type

location

targetId : string ID of the stream receiver components

PCE


object: string ID of the data object. Unique in the context of the Type

{

“objectId: “04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person” }

Combined Example

DELETE /sf/Person/objects/location/PCE/stream HTTP/1.1 Host: crema.eu

Object = “objectId”: “04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Custom]Person” }

Response

HTTP Status Code

Value Description

200 Property found and streaming stopped



404 Type not found





102 / 227


4.4.3.1.17 Method “Get Complex Property Value”

The RESTful interface “Get Complex Property Value” (Table 77), executes a read operation on an existing type by getting the value of its complex property.


4.4.3.1.18 Method “Get Complex Property Values”

The RESTful interface “Get Complex Property Values” (Table 78), executes a read operation on an existing object of a certain type by getting all values of its complex property.


Get Complex Property Value

Description This method gets the value of a particular complex property given a particular set of keys.

Request

Request URL GET http://crema.eu/cva/sf/complexPropertyList

HTTP Parameters


Object : Object Represents a complex type of property

{ “propertyId”: “__<Product>is_in__<Process Area>”, “keys”: [“10001”, ”Rework Area”] }

Combined Example

GET /sf/complexPropertyList

Host: crema.eu

Object = {“propertyId”: “__<Product>is_in__<Process Area>”, “keys”: [“10001”, ”Rework Area”]}

Response

HTTP Status Code

Value Description

201 Property row found

404 Property row not found

JSON Attributes

List Optional list

The result of the property value requested Example: { “value”: true }

Get Complex Property Values

Description This method gets all the rows for a particular complex property.





103 / 227


4.4.3.1.19 Method “Set Complex Property”

The RESTful interface “Set Complex Property” (Table 79), executes an update operation on an existing object of a given type by updating its complex property.

Table 79: CVA RESTful Interface – Set Complex Property

Request

Request URL GET http://crema.eu/cva/sf/ComplexPropertylist

HTTP Parameters


property : string ID of the complex property for which all rows have to be read

__<Product>is_in__<Process Area>

Combined Example

GET /cva/sf/ComplexPropertylist HTTP/1.1 Host: crema.eu

property = {”key”:”Rework Area” }

Response

HTTP Status Code

Value Description

201 Property row found

404 Property row not found

JSON Attributes

List Optional list

All property values Example: [ { keys: [“10001”, ”Rework Area”], value: true }, { keys: [“10002”, ”Rework Area”], value: true }, … ]

Set Complex Object Property Value

Description This method allows to update an existing property value of an object of a given type.

Request

Request URL PUT http://crema.eu/cva/sf/ComplexPropertylist

HTTP/Parameters


Property : object represents a complex object property value

“{

propertyId: “__<Product>is_in__<Process Area>”





104 / 227



The use of Smart Factory enables CREMA developers to flexibly create any new types necessary to define the application data model. User defined types are augmented with appropriate properties, which can be any of the basic numeric or string types as well as user-defined types already defined in the data model. Additionally, Smart Factory fully supports the object oriented concept of inheritance, where a derived type (the child) can inherit all the properties of a parent type. In this way a child type is both an instance of the parent and the derived type. Within the CREMA context, a type refers to as the cluster of modelled assets or objects having common characteristics or features such as INDUSTREWEB, DATA LOGGER, RASPBERRY-PI and PERSONS. Every type needs two elements to be defined: a name and an ID. For instance for every human a type called “PERSON” is defined. Every person of type PERSON has a set of properties, for instance Name, Function and Age. The Name is the ID of the Type, which has to be defined. For creating a new property of a type, three parameters have to be specified. These are

• Property Id: this is the string showing how the property will be called, e.g. “Name”, “Temperature” or “Creation Date”.

• Property Flag showing the nature of the property, whether it is unique or a name of the type.

Property Type: depending on the type of property, this parameter can be a string or an int. With simple properties it is possible to cover one-to-one and many-to-one relations between objects. In addition to this basic type and property modelling it is also possible to define complex relations between types through the concept of a complex property. Complex

}

Combined Example

PUT http://crema.eu/cva/sf/ComplexPropertylist Host: crema.eu

Content-Type: application/json Property = {

propertyId: __<Product>is_in__<Process Area>

keys: [“10001”, “Rework Area”],

value: false

}

Response

HTTP Status Code

Value Description

200 Property set


404 Type not found





105 / 227


properties enable the inclusion of joins between types so that it becomes possible to define one-to-many or even many-to-many relations. This is really valuable when it becomes necessary to store or operate on sets of data. Hence, a complex property can easily be used to maintain lists of objects of one type that have some association to another (single) object instance. This is obviously not possible with a simple property and therefore highlights the value of the complex property construct. Furthermore, it is sometimes necessary to maintain the state of a many-to-many relation. A simple example might be the need to maintain a list of all the zones that some group of objects are located in. The difference here compared to the one-to-many example is that there is no uniqueness across the relation – many instances of the type can be located within the same instances of the second type zone.


The Smart Factory UI maintains a combination of role-based search constructs, which determine what information any user is allowed to access and additionally what they can see and do. A search is assigned to one or many roles. This represents the authorisation for visualisation at UI level of CPS and sensor data. It determines what properties are displayed to users viewing the results of a search. Users are allocated to roles which can be either of

• named users with domain authenticated usernames. • anyone that can authenticate on the server.

The following Listing shows an example of how a response from the SPC component can be defined. It uses the predefined permission labels to set the rights for each user.

Listing 13: CVA Example Authorisation Definition

4.5 Service Virtualisation and Abstraction

The SVA component is a design time component that provides means to virtualise services. Virtualisation involves profiling of the services, i.e., adding definition information, semantic annotation, data schemas, and an executable container with an actual software service. The definition of services is used in MPM to expose to the potential users the description of services. Keywords of the service are the linked concepts added by means of the DHS component to facilitate search over services within the Marketplace. Semantic annotations of services is an essential part of the process designer (see Section 3.5), it is needed for the optimisation component ODERU when a substitute for a not working service is needed, e.g., when an abstract service needs to be substituted by a concrete service, or a set of concrete services.

{ "userId": "597134" "user": "Charles", "company": "CREMA", "authorisation": { "permission": "IT Access" } }





106 / 227



To implement SVA functionality the next directions were considered: means to provide functionalities to the user – managing templates and services, and means to semantically annotate services and get linked concepts. For all these groups of functionalities, technology decisions were taken and described in the following subsections.

4.5.1.1 Selection of Semantic Annotation Means

On the market there are few products that offer attractive tools for annotating web services: the annotation of WSDL24 into WSDL-S25 and SAWSDL26 via an ontology using extensibility elements of the WSDL is the main idea of the Radiant27 tool. WSMO Studio28 is an open source set of tools developed during several European projects. The main goal there was to provide a holistic environment to model ontologies, annotate services with semantics, specify web service composition on a semantic basis, and provide an ontology viewer and editor for convenient annotation. The operating principle of the WSMO lays in the combination of WSDL and OWLS-S to perform annotations. Another similar tool is SOWER29. It is a visual tool to perform the same WSDL-OWL-S transformation, and performs WSDL-SAWSDL transformation using representations of trees of ontologies. Iridescent30 is a research prototype allowing the same WSDL-SAWSDL mapping. These tools have similar goals and features, however, they provide a heavy-weight ontology matching embedding this into the web service descriptions, and it was requested that semantic descriptions stay separated from the actual services. The CREMA platform is intended to be used by the manufacturers, i.e., the audience are the technical and business people not acquainted with advanced techniques of communicating and understanding of ontologies and heavy semantic transformations. The SVA component provides a simple but holistic UI. This UI lets the users add descriptions of services, manage keywords, i.e., linked concepts, and easily upload data schemas and executable files. Light UI Semantic Annotation Manager allows the reading of the shared CREMA manufacturing ontology CDM-Core (via DHS and DLP) and to perform semantic annotations of services with it. As the main architectural decision in CREMA is to use RESTful web services, the entities “service” that are created by means of SVA are represented as light-weight JSON objects to ease the data transfer to the MPM component.

4.5.1.2 Selection of SVA UI Engine

To implement UIs to support these functionalities, the decision was made towards using Thymeleaf31. This technology is a Java template engine that supports several template

24 http://www.w3.org/TR/wsdl 25 http://www.w3.org/Submission/WSDL-S/ 26 http://www.w3.org/TR/sawsdl/ 27 http://lsdis.cs.uga.edu/projects/meteor-s/downloads/index.php?page=1 28 http://www.wsmostudio.org/ 29 http://technologies.kmi.open.ac.uk/soa4all-studio/provisioning-platform/sower/ 30 http://challenge.semanticweb.org/2012/submissions/swc2012_submission_6.pdf 31 http://www.thymeleaf.org/





107 / 227


models: XML32, HTML533, and XHTML1.034 and 1.135. The SpringStandard36 dialect of Thymeleaf allows creation of powerful templates correctly displayed by all major browsers and therefore also works as static prototypes. The use of Thymeleaf along with Spring Boot37 facilitates bootstrapping of a web application simplifying development, as with several steps a fully working self-contained web application is set up.

4.5.1.3 Missing Elements and Implementation needs

As the main goal of SVA is service virtualisation, two major directions of implementation should be considered: the management of the templates to ease the service creation, and the management of services. The main implementation needs are in the following areas:

• Service Virtualisation Control and Management UI: Means to describe, annotate, and send objects of abstract services and concrete services described in a JSON data structure to the MPM component to let the service metadata be saved in the service registry. The description and annotation is performed by means of predefined templates taken from the Template Registry. During the description of the services, monitoring events like availability or failure are specified. In case of concrete services, the user adds the Proxy Service Wrapper (see Figure 7) and internal binaries, and along with the description, annotation and a data schema, the service is put into a JSON object and sent to MPM. These Proxy Service Wrappers enable service integration within the CREMA platform. The abstract as well as concrete services are used within the PDE component to create activities in the process models. Linked data information comes directly from DHS to UI to add keywords to services, and semantic model for annotation from the simple UI Semantic Annotation Manager that communicates with the Linked Data API of the DHS components, and therefore with the DLP component implicitly.

• Template Control and Management UI: Means to create and manage templates and save them in the Template Repository in CRI. These templates are used to build an abstract or a concrete service. Each template contains a number of similar properties, which describe the set of services.

• Security Layer: SVA has to be adapted to fulfil the special authorisation role, which was indicated within the Section 4.5.6 of deliverable D3.2. A security layer is added, which includes both the authentication and the authorisation level. It was added to visualise the security aspect with the location where the authentication and authorisation takes place. In contrast to the unilateral authentication, the authorisation is bilateral.

• Semantic Annotation Manager. Means to annotate templates and services with semantic data. A UI is needed to support this functionality. The user enters the concept to annotate with, and the UI calls an interface of DHS to get the URI of a concept from an ontology from DLP if it exists. First order logical expressions to annotate services are supported. Therefore, the interaction with the DLP component is implicit, and is performed through the DHS Linked Data API.

32 http://www.w3.org/XML/ 33 http://www.w3.org/TR/html5/ 34 http://www.w3.org/TR/xhtml1/ 35 http://www.w3.org/TR/xhtml11/ 36 http://www.thymeleaf.org/doc/tutorials/2.1/thymeleafspring.html 37 http://projects.spring.io/spring-boot/





108 / 227



The SVA component is a design time component, which consumes information coming from other components: DHS, DLP, CVA to perform its main task – service virtualisation, and it reacts on the calls of MPM and DBV.

Figure 6: SVA Architecture Diagram

The CREMA SVA component is composed of the following subcomponents:

• Service Virtualisation Control: This subcomponent provides means to create a JSON object of abstract services or concrete services from the data filled in by the users within the UI Service Virtualisation Manager to the MPM component to save services in a Service Registry.

• Service Virtualisation Manager: This is a user interface for the Service Virtualisation Control. It is integrated in DBV. This interaction allows displaying services, perform editing of templates and services, uploading data schemas and proxy service wrappers.

• Security Layer: This subcomponent includes both the authentication and the authorisation level.


Monetisation(MPM)

CREMAServiceVirtualisationandAbstraction(SVA)

ServiceVirtualisation

Control

Technicalusers

T4.4CREMACPS,SensorAbstractionand

Virtualisation(CVA)

CPS/sensorDataSensorwrappers

servicedescription,semanticannotation

binary/REST

<userinterface>T6.5CREMADashboardandVisualisation(DBV)

<userinterface>ServiceVirtualisation

Manager

TemplateControl

callforwrapper

Technicalusers


<userinterface>TemplateManager

callaccess templates

data

T4.3CREMACloud-baSedRAIDInfrastructure(CRI)

TemplateRepository

ServiceRepository

templatesrequest

servicerequest

servicesdata

templatesdata

templatesdata

templatesrequest

T4.2CREMADataHarmonisationServices

(DHS)

linkedconcepts

getlinkedconcepts

getlinkedconcepts

linkedconcepts

getsemantics

semantics

getsemantics

semantics

callaccess

SecurityLayer

fwdfwd fwd fwd

<userinterface>SemanticAnnotationManager

getlinkedconcepts

linkedconcepts





109 / 227


• Semantic Annotation Manager: This is a simple UI component needed to annotate services and templates with semantics.

• Template Control: This subcomponent provides means to manage templates and save them in the Template Repository.

• Template Manager: This is a user interface for the Template Control. It is integrated in DBV. This interaction allows displaying and managing templates, perform CRUD operations with templates.

• Template Repository: This repository acts as a data client to store the templates. The Template Repository will be a separate bucket in the CREMA CRI, maintained by the SVA.

The major element that is needed to be specified here is a Proxy Service Wrapper (Figure 7). Manufacturing services and corresponding sensor data are rather heterogeneous, a homogeneous access method has to be provided to represent such sensors as Data-as-a-Service in the Cloud environment. A Proxy Service Wrapper is intended to provide that integrative access to services and ease integration efforts. It is a construct of an entity “service” that is a result of SVA component workflow and it provides a functionality to wrap all interactions of internal, external, and CPS services and the CREMA platform. Each virtualised service implements the Service Start Interface, represented by one method Start Service in order to start an execution of a service (called by PRU), and the Service Availability Interface, represented by a method Get Availability that responds on the call from the OSL component about the availability state of a service. The notification service is a dedicated subcomponent of a Proxy service wrapper. A notification service sends messages to PRU when the service has a failure or is finished.

Figure 7: Proxy Service Wrapper Architecture Diagram

<<interface>>GetAvailability

<<interface>>StartService

startservice

ProxyServiceWrapper

getavailability

T5.2CREMACloudProcessandMessagingRuntimeEnvironment

(PRU)

checkavailability

Service

NotificationService

monitoring/endofserviceexectution

events

<<interface>>ServiceMonitoringAPI

CREMACloudProcessandMessagingRuntimeEnvironment(PRU)

BPMSserviceexecution

request

Container


events

serviceavailability





110 / 227



The major design decision for the CREMA project is to use REST interfaces as a common communication base for the CREMA components. The SVA will consume the functionalities of the CRI component to store data about templates, of the DHS and DLP components to get linked concepts and semantic data, of CVA component to get executable part of CPS services, and of the MPM component to send data to its Service Repository.


Two main interfaces identified here are the service start interface, represented by the method Start Service that is called by PRU to start execution of a service, and the service availability interface, represented by the method Get Availability that responds on the call from the OSL component about the availability state of a service.

4.5.3.1.1 Method “Start Service”

The method “Start Service” (Table 80) is triggered by PRU to start an execution of a service. Table 80: SVA RESTful Interface – Start Service

Start Service

Description This method reacts on the call from PRU to start an execution of a service, i.e. create new instance of a service. The response is sent to PRU indicating the result of instantiation.

Request

Request URL POST http://<serviceIP>/resources/

Resource Parameters


serviceIP : string IP and Port of the Service serviceIP=10.10.10.10:1234

HTTP Parameters

object: object An object representing an object of the URL to the monitoring service and input parameters to start an execution of the service

{ "monServiceURL": "10.10.10.10:5678",

"inputparams": {"key1":"value1", "key2":"value2"} }

POST http://<serviceIP>/resources/ HTTP/1.1 Host: serviceHost

object = { "monServiceURL": "10.10.10.10:5678", "inputparams": {"key1":"value1", "key2":"value2"} }

Response

HTTP Status Code

Value Description

201 Success. Request fulfilled.

424 Unknown error occurred.





111 / 227


4.5.3.1.2 Method “Get Availability”

The method “Get Availability” (Table 81) of a service is queried by OSL to evaluate if the service is actually available.

Table 81: SVA RESTful Interface – Get Availability


This section lists JSON examples that shows the structure of a service to send to the MPM component. The listing below shows general features of the example service, its linked data as keywords, semantic annotations, a data schema and an executable part. A serviceID indicates a service inside the Service Registry of the MPM. If the user is editing the description, but needs to postpone editing before finishing the description, the flag isDraft indicates that service is under construction. The distinction between concrete and abstract service is made by means of concreteServiceID and abstractServiceID. If for a concrete

JSON Attributes

Result: object

Response 1: { "started": "true" } Response 2: { "started": "false", }

Get Availability

Description This method receives a query from OSL to get the availability state of a service. The response is sent to OSL with status “available” if the service is free for use, and “blocked” if the service is in use.

Request

Request URL GET http://<serviceIP>/getAvailability/

Resource Parameters

Name Description

serviceIP : string ID of the Service serviceIP=10.10.10.10:1234

Response

HTTP Status Code

Value Description

200 Success. Response received.

424 Unknown error occurred.

JSON Attributes

Result: object

Response 1: { "state": "available" } Response 2: { "state": "blocked" }





112 / 227


service there is no corresponding abstract service, the value of abstractServiceID is null, serviceName, serviceDescription, serviceOwner are seen in the dashboard of the users in the MPM component (see Listing 14).

Listing 14: General Information of a Service

A separate subject semanticAnnotation is generated as soon as the user adds semantics by means of calling the DHS and DLP components. The intent is to use all basic first order logic inside the annotation expressions. There are four keys for this object: inputs, outputs, preconditions, and effects. These are semantic annotations. In essence, the UI calls the Linked Data API of DHS to get semantics from ontologies from DLP (see Listing 15). To consider logical operations, three sub-object keys are used: and, or, and not along with lists of values to be covered by those logic operators (see Listing 15).

"serviceID": "Service_0m5fx1g", "isDraft":"False", "concreteServiceID":"Service_0m5fx1g", "abstractServiceID":"null", "serviceName": "machining:Turning", "serviceDescription": { "serviceVersion": "2.0" "description": " This real-life manufacturing process allows to create a manufactured part to its needed geometric dimensions by removing of excess material from a work piece by means of a certain material removal tool. The combination of various machining operations allow to manufacture complex parts. Turning is a form of machining used to create rotational parts by cutting away unwanted material. It requires a turning machine or lathe, workpiece, fixture, and cutting tool. A piece of pre-shaped material is a workpiece. It is secured to the fixture. The fixture is attached to the turning machine and is allowed to rotate a workpiece at high speeds. Generally, a single-point cutting tool – cutter – is needed and it is also secured in the machine. Some operations make use of multi-point tools. In order to create the needed shape, the fixture rotates the workpiece, the cutting tool feeds into the rotating workpiece and cuts away material in the form of small chips to create the desired shape.", "serviceOwner": "TCO", 0activationDate": "24/07/2015", "notifications": "enabled", "accessGroups": "TCO" },





113 / 227


Listing 15: Semantic Annotation of a Service

The third set of key-value JSON pairs are reflected in Listing 16. Linked concepts serve as keywords for a service to enable effective search within MPM. linkedConcepts are received by means of communicating with DHS component via its UI returning a list of concepts. Optionally, if the user adds an XML schema of a service, it is stored in a value of a key serviceSchema. Executable part is put under a key serviceSoftware. In order to indicate an availability of a service state key is used with two possible values “available” and “blocked”. Inside the MPM the sub-objects payment and serviceSchedule are set and maintained.

"semanticAnnotation": { "inputs": { "or": [ {"and": [ "http: //127.0.0.1: 8080/CREMA/Ontologies/ProductOntology.owl# Machine: e", "http: //127.0.0.1: 8080/CREMA/Ontologies/ProductOntology.owl#Metal: m", "http: //127.0.0.1: 8080/CREMA/Ontologies/ProcessOntology.owl# Cylindrical: c" ] }, {"and": [ "http: //127.0.0.1: 8080/CREMA/Ontologies/ProductOntology.owl# Tool: t", "http: //127.0.0.1: 8080/CREMA/Ontologies/ProductOntology.owl# Material: ma", "http: //127.0.0.1: 8080/CREMA/Ontologies/ProcessOntology.owl# Round: r" ] } ] }, "outputs": { "and": [ "http: //127.0.0.1: 8080/CREMA/Ontologies/ProductOntology.owl# Part: p", "http: //127.0.0.1: 8080/CREMA/Ontologies/ProductOntology.owl#Shape: s", ] }, "preconditions": { "and": [ "http: //127.0.0.1: 8080/CREMA/Ontologies/ProductOntology.owl# isValidated(t)", "http: //127.0.0.1: 8080/CREMA/Ontologies/ProductOntology.owl# isInstalled(t)", ] }, "effects": { "and": [ "http: //127.0.0.1: 8080/CREMA/Ontologies/ProductOntology.owl# isUsed(p)", ] }, },





114 / 227


Listing 16: Linked Concepts, Executable Part and Service Schedule


The creation of templates and services, and their maintenance is available to the technical users: Service Providers (limited customised functionality) and SVA Administrator (administration functionality). To execute an action, the user must have a corresponding role that permits the user to execute the intended action. The following table contains the authorisation definitions for the SVA component.

• SVA Administrator Access: The user has full access to all functionalities and entities of the SVA.

• Service Provider Access: The user has a strong limited access to the data in the SVA. The access is restricted to read and write operations with entities that are created by this user.

The following Listing shows an example of how a response from the SPC component could be. It uses the predefined permission labels to set the rights for each user.

Listing 17: SVA Example Authorisation Definition

"linkedConcepts": [ "Turning Machine, Solid", "Cylindrical", "Computer Numerical Control", "Metal" ], "serviceSchema":"../serviceSchema.xml", "serviceSoftware":"../Service_0m5fx1g.war", "payment":{ "usagetime": "600000", "costs": "100", "payper": "time", "currency": "euro", }, "state":"blocked" "serviceSchedule": [ { "client": "”FAGOR", "appointment": {"start": "17/04/2015", "end": "17/09/2015"} }, { "client": "FAGOR", "appointment": {"start": "01/01/2016", "end": "01/03/2016"} }]

{ "userId": "597134" "user": "Charles", "company": "CREMA", "authorisation": {

"permission": "service provider", "templates": "Tenneco",

"services": "Tenneco" } }





115 / 227


5 CREMA Cloud Manufacturing Collaboration, Knowledge and Stakeholder Interaction Framework Components

5.1 Cloud Collaborative Process Design Time Environment

The Cloud Collaborative Process Design Time Environment (PDE) is a central component in the CREMA platform, which allows BPMN2.0 manufacturing processes to be designed. The PDE is responsible for the modelling and rendering of BPMN2.0 processes to be displayed in modern web browsers. The PDE has the function of allowing a process manager to select an abstract or concrete service within PDE. It allows additional attributes to be added on a BPMN task, such as service definitions, inputs, outputs, preconditions and effects. This semantic annotation of process tasks allows the ODERU component to find an optimal assignment of individual or composed services for them. The aim of the PDE is to design a BPMN2.0 diagram of a process model with annotations so that ODERU can be called to create an optimal process service plan for it that can be executed by the PRU.


The PDE supports the designing of BPMN2.0 process models. There are many BPMN process designers to choose from, based on this technology decisions were taken and are described in the following subsections.

5.1.1.1 Selection for BPMN Renderer and Modeller

BPMN.IO is selected as the renderer and modeller for BPMN2.0 as it is an open source library that is a BPMN2.0 rendering toolkit and a web modeller. It allows creating, embedding, and extending BPMN2.0 diagrams, it runs in modern browsers (Internet Explorer 10 and later versions, Chrome, Firefox). It can be used standalone or integrated in applications. It is built as part of Camunda BPM38. Other beneficial reasons are that the basis of the BPMN.IO 39is HTML5 40and it is built with NodeJS41, therefore it is very modular and has access to further node modules from Node Package Manager (NPM42). It uses Grunt43, which is a task runner that handles all the repetitive tasks such as compilation, unit testing etc. by using Grunt it allows automation of development tasks thus increasing productivity. The BPMN design canvas is touch enabled and is rendered in SVG. There are numerous examples on GitHub and the BPMN.IO forums with examples on how to extend and modify certain aspects of the library. It is worth mentioning that the PRU component uses Camunda BPM, which is another benefit to use the BPMN.IO as it is created by the same company.

38 https://camunda.org/ 39 http://bpmn.io/ 40 http://www.w3.org/TR/html5/ 41 https://nodejs.org/en/ 42 https://www.npmjs.com/ 43 http://gruntjs.com/





116 / 227



As PDE is built on the foundation of the BPMN.IO toolkit described above it needs to be extended to the requirements of the CREMA platform. The following features will need to be developed in order to achieve this:

• Cloud Storage: It is a requirement in the CREMA platform that the BPMN2.0 process model needs to be stored in CRI. A PDE module implements CRUD access to the CRI REST API in order to provide this functionality.

• BPMN2.0 Process Model Optimisation: A way to call the ODERU REST API from the PDE to associate a BPMN2.0 process model with an optimal process service plan (PSP) needs to be implemented. For calling the functional optimisation by ODERU, the required semantic annotation of BPMN2.0 process steps or tasks with concepts from the shared CDM-Core has to be realized. For the non-functional optimisation of a PSP for a process model, the respective KPI-driven constrained optimisation problem (COP) to be solved has to be specified. This is done by the process manager and encoded in the set of (default) constraints stored in the CRI. If an optimised PSP is found by ODERU for the PDE on request, then a notification is sent to the DBV so that it can either be accepted or rejected.

• A custom-meta-model needs to be created to validate the additional elements that CREMA needs in a BPMN2.0 process model. This is used to validate the XML when designing and opening a BPMN2.0 process model.

• BPMN2.0 Process Model Execution: A way to call the PRU REST API from the PDE needs to be implemented as this allows the ability to test the execution of the optimal PSP returned by ODERU to the PDE for a BPMN2.0 process model and COP. A request with the process ID is sent to the PRU and it returns a response of the outcome, e.g., success or failure.

• BPMN2.0 Process Model Linked Data: The ability for the PDE to manually annotate the metadata for a BPMN service task, such as the service inputs, outputs, preconditions and effects. It will need to communicate with the DHS Linked Data API to gain access to the ontologies. It must be stated that this is lower priority and may not be fully implemented at the end of the CREMA project.

• Security Layer: A way to authenticate the user using PDE needs to be implemented. This is achieved by implementing a way for the PDE component to access the REST API of the SPC component. This allows validating of a user token, redirecting the user to login or denying access.

• Service Repository: A way to access the MPM Service Registry needs to be implemented. It will allow the PDE to get a list of available abstract or concrete services that the PDE can use in the design of a BPMN2.0 process. The services are displayed in the properties panel within the PDE when a service task is selected and an implementation type is chosen (e.g. abstract or concrete). An abstract service are services without an executable service and concrete services are services which are grounded in an executable service (e.g. REST, WSDL).


The component structure has been updated in comparison to the Functional Specification (T3.2, D3.2) to reflect the technology selection and offer a more modularity to the component (Figure 8). This change is in order to cope with the implementation of CREMA functionality.





117 / 227


The following subcomponents that have been effected by this are CRI, MPM Service Registry, DHS Linked Data, PRU Execution, ODERU Optimisation and SPC authentication. It must also be noted that the module for the Toolbox Service has been completely removed and is replaced with the Service Repository module. The updated component diagram can be seen in the figure below.

Figure 8: PDE Architecture Diagram

The BPMN.IO open source library is the core of the PDE component. The description of the major modules that it is made up of are outlined below.

• Bpmn-moddle-js: This module offers read and write support for BPMN2.0 XML in the web browser. It uses the BPMN2.0 meta-model to validate the input and produce correct BPMN2.0 XML.

• Diagram-js: A toolbox for helping and extending the functionality in the rendering and modelling of a BPMN2.0 diagram.

• Bpmn-js: This is the core BPMN 2.0 diagram modelling and rendering toolkit. It renders the BPMN2.0 XML into a HTML5 canvas.

• Bpmn-js-properties-panel-js: The properties panel module allows access to the BPMN properties behind certain diagram elements.

The CREMA Modules are what needs to be developed and added to the open source library to meet the CREMA platform requirements. The CREMA Modules are as follows:

• Cloud Storage: PDE uses the CRI component in two ways. The first is to offer the ability for CRUD operations on a BPMN2.0 diagram. The second is for storing the optimisation constraints that can be set on a BPMN2.0 process. It is worth noting that versioning of the BPMN2.0 diagram is implemented, this is to allow a historical record of the diagram, composition and optimisations that have occurred on a PSP.





118 / 227


• Service Registry: PDE uses the MPM Service Registry to get service information for abstract and concrete services when designing a process. The Service Repository provides service definitions and semantic annotations such as preconditions, inputs, outputs and effects. These are used to annotate the BPMN2.0 diagram so that it can be sent to the ODERU which composes a PSP.

• Linked Data: PDE utilises the DHS Linked Data API to help in suggesting the semantic annotations of a BPMN2.0 diagram task inputs, outputs, preconditions, and effects. It must be stated that this is lower priority than the other functionality and thus may not be implemented. This functionality will be implemented inside as a dedicated part of the SVA components, and PDE may reuse the results of that task.

• Execution: Once a BPMN2.0 diagram has been composed into a process service plan and stored in CRI with an assigned process ID it is possible to send a test execution to PRU by providing the process ID of the process which should be tested.

• Optimisation: PDE uses ODERU to obtain an optimal PSP for a BPMN2.0 process model. For this purpose, PDE allows the process manager to semantically annotate a process model. If required, this annotation also includes the KPI-driven COP to be solved, which concerns KPIs like execution cost, time, and original equipment efficiency (OEE). The COP is stored as set of constraints in the CRI with only the PDE and ODERU having access to it. In particular, these constraints are placed at the root of the BPMN2.0 process along with the model, instance and PSP versions. To compose a PSP the ODERU inspects the annotated process tasks of the model (also called abstract services defined in the process) and tries to create a PSP that is optimal with respect to functional and non-functional aspects. A PSP is functionally optimal with respect to satisfaction of requested process model semantics with best matching services and minimal plan length. A PSP is non-functionally optimal with respect to given COP to solve. If an optimised PSP is found the user can either accept or reject it which overwrites the existing PSP, if there is one.

• Authentication: This has the simple responsibility for authenticating if the user has access to the PDE. It checks whether the user has a token and either allow or deny access. The PDE communicates with the SPC REST API for this functionality.

The PDE has a rich User Interface for the design of a BPMN2.0 diagram. The descriptions of each of the UI’s is detailed below. Palette: The palette on the left side of Figure 9 contains the following BPMN2.0 elements start event, intermediate throw event, end event, exclusive gateway, task, sub process collapsed, sub process expanded, pool, and participant. It is worth mentioning that the palette can be extended so custom elements can be added. Design Canvas: The design surface for the design of a BPMN2.0 process is where elements can be dragged and dropped from the palette and placed on the right side of the palette.





119 / 227


Figure 9: PDE Design Canvas

Properties Panel: The properties panel is a way to get access to the underlying attributes that can be set on a BPMN2.0 diagram (see Figure 10). This is extended so when an implementation type (e.g. abstract or concrete) is chosen it shows a list of services from the MPM Service Registry that the user can choose. Upon choosing a service it updates the design canvas and BPMN2.0 diagram.

Figure 10: Properties Panel

Toolbox: A menu that allows actions to be performed on a BPMN2.0 diagram (Figure 10).

Figure 11: Toolbox Menu

Starting Figure 11 from left the following actions are supported: open BPMN diagram from local file system, open BPMN diagram from cloud storage, download BPMN diagram to local system, upload BPMN diagram to cloud storage, download BPMN diagram as SVG image and finally compose/optimise BPMN diagram into a process service plan.





120 / 227


Process Model Store: The open BPMN diagram from cloud storage from the tool box opens the process model store (Figure 12). This allows the user to view BPMN2.0 diagrams that are stored in the CRI. When a BPMN2.0 diagram is selected it is loaded into the design canvas.

Figure 12: Process Model Store

Component backend: The PDE backend is based on NodeJS. This means that it runs on the server.


As PDE is a design time component, no public interfaces have been requested from any other component owners or collaborators.


5.1.4.1 BPMN2.0 XML

The PDE produces and consumes BPMN2.0 XML. It is compliant with the BPMN2.0 specification. The BPMN2.0 requires an <bpmn:extensionElements> to be added to the BPMN2.0 process to meet the CREMA needs in storing the process definition and service definitions. The <bpmn:extensionElements> element is used to extend BPMN2.0. It allows the storing of additional information for a process. It must be stated that only one <bpmn:extensionElements> element can be defined in each BPMN2.0 element, e.g., <bpmn:serviceTask>.

5.1.4.2 Process Definition

The <crema:processDefinition> element is used to store additional information about the process, e.g., versioning. The process definition is defined in the root of the BPMN2.0 process. It contains the following elements in the <crema:version> element, the model version <crema:modelVersion>, process instance version <crema:instanceVersion>, and PSP version <crema:servicePlanVersion>. The crema version element has a validated attribute that can be set to true or false. This shows whether the optimised process has been validated by the user. After the process has been optimised by the ODERU it is set to false, an alert is then





121 / 227


sent to the DBV asking the user to accept or reject this optimised process, if it is accepted the validated attribute is set to true. Below (Listing 18) is an example of the <crema:processDefinition> element.

Listing 18: Process Definition Example

5.1.4.3 Service XML Element

The <crema:service> element contains further elements to store the information on abstract and concrete services (Listing 19 and Listing 20). The elements that can be defined are <crema:abstractServiceID> and <crema:concreteServiceID>. These elements contain the ID of the service. The <crema:concreteServiceID> element may be decorated with an optional origin attribute that specifies the entity that populated the concrete service. The current proposed values for this attribute are user, optimisation, and optimisation validated. PDE is only responsible for setting the origin attribute to user. The ODERU component is responsible for setting the origin attribute to the value of optimisation or optimisation validated. A BPMN2.0 Process Model is deemed valid if all composite child tasks within the process are in a valid state.

5.1.4.4 Abstract Service XML Element Example

An abstract service is a semantic description of a service which might have no concrete implementation in terms of an executable service program defined. This abstract service has been manually assigned to a process task by the process designer to represent the task semantics. This needs to be checked for optimisation by ODERU. The ODERU can only change abstract services within a BPMN2.0 process. This is done by looking at the semantic description of the process task in terms of the given abstract service and by composing an optimal PSP for it with concrete service, meaning executable service(s).

Listing 19: Abstract Service XML Element Example

<bpmn:process> ... <bpmn:extensionElements> <crema:processdefinition> <crema:version validated="false"> <crema:modelVersion>pm1</crema:modelVersion> <crema:instanceVersion>pi1</crema:instanceVersion> <crema:servicePlanVersion>psp1</crema:servicePlanVersion> </crema:version> </crema:processdefinition> <! -- constraints --> </bpmn:extensionElements> ... </bpmn:process>

<crema:service> <crema:abstractServiceID>5023282A-298F-4713-A037-BE528998F2C5</crema:abstractServiceID> <crema:concreteServiceID/> </crema:service>





122 / 227


5.1.4.5 Concrete Service XML Element Example

A concrete service is a service which has its implementation defined and cannot be changed or optimised by the ODERU.

Listing 20: Concrete Service XML Element Example

5.1.4.6 Meta Data XML Element

The <crema:metaData> element stores further service details that define semantic annotations such as inputs, output, preconditions, and effects associated with the BPMN service task.

5.1.4.7 Constraints

For non-functional optimisation of a PSP, the ODERU requires the respective objective function (min/max) with a set of constraints on its variables like cost, time, OEE. The way this is achieved is by storing a dictionary of constraints in the CRI, these will then be manually set in the PDE via the properties panel. The end user is not permitted to add new constraints into CRI.

5.1.4.7.1 Constraints Dictionary

The constraints dictionary is stored as JSON data in the CRI. At the time of writing three items exist in the dictionary, Time, Cost and Original Equipment Efficiency. An example of what the constraints dictionary looks like is defined below in JSON (Listing 21), the Constraint ID is a GUID to identify the constraint, the Description is human readable text to identify the constraint and the Concept ID is a URI that identifies where in the ontology this constraint exists.

Listing 21: Constraints Dictionary

<crema:service> <crema:abstractServiceID>5023282A-298F-4713-A037-BE528998F2C5 </crema:abstractServiceID>

<crema:concreteServiceID origin="user">BE3B7136-B020-4B01-B28F- 08FA3E177F08 </crema:concreteServiceID> </crema:service>

[{ "constraintId": "38ECE9E8-2795-41EE-BFC8-F4D806BC26B6", "description": "Time", "conceptId": "http: //127.0.0.1: 8080/CREMA/Ontologies/ConstraintOntology.owl#Time" },{ "constraintId": "FF79C00A-2CC1-41A3-8E46-D589E8A01ACB", "description": "Cost", "conceptId": "http: //127.0.0.1: 8080/CREMA/Ontologies/ConstraintOntology.owl#Cost" },{ "constraintId": "F7DA29EF-96FE-4C42-A308-769D70D91D52", "description": "Original Equipment Efficiency", "conceptId":"http://127.0.0.1:8080/CREMA/Ontologies/ConstraintOntology.owl#Original_Equipment_Efficiency" }]





123 / 227


5.1.4.7.2 Constraint XML Element

The <crema:constraints> element is used to facilitate the input of constraint information for a process. The constraints that can be set, which are currently defined are time, cost and original equipment efficiency. The element contains the expression (and, or) and the ID of the constraint. This is used by the ODERU when trying to optimise the BPMN2.0 process.

5.1.4.7.3 Constraint XML Element Example

The constraints element is defined in the root of the BPMN2.0 process. The example (see Listing 22) shows how to set the optimise constraints of a BPMN2.0 process by time and original equipment efficiency. When an optimised BPMN2.0 request is sent to the ODERU it utilises these constraints when trying to compose an optimised process service plan.

Listing 22: Constraint XML Element Example

5.1.4.8 Custom-Meta-Model

A custom-meta-model is created for the BPMN.io library to support additional elements that the CREMA platform needs. This allows the BPMN.io viewer / modeller instance to read, create and write domain specific data from and to BPMN2.0 diagrams.

<bpmn:process> ... <bpmn:extensionElements> <! – process definition --> <crema:constraints> <crema:expr type="and"> <crema:constraint>38ECE9E8-2795-41EE-BFC8-F4D806BC26B6</crema:constraint> <crema:constraint>FF79C00A-2CC1-41A3-8E46-D589E8A01ACB</crema:constraint> </crema:expr> </crema:constraints> </bpmn:extensionElements> ... </bpmn:process>

{ "name": "CREMA", "uri": "http://crema/schema/bpmn/crema", "prefix": "crema", "xml": { "tagAlias": "lowerCase" }, "types": [ { "name": "ProcessDefinition", "superClass": [ "Element" ], "properties": [ { "name": "version", "type": "Version" } ] }, ...





124 / 227



To interact with a process model the user must have a corresponding role that permits the user to execute the intended action. The following list contains the authorisation definitions of the PDE component

• Full Access: The user has full access to all functionalities and entities of the PDE. This means that the user can access and update process models.

• Read Access: The user can only view the process model. The following Listing shows an example of how a response from CREMA SPC component could be. It uses predefined permission labels to set the rights for each user. This may be extended in the future to contain more granular permissions.

Listing 23: PDE Example Authorisation Definition

5.2 Cloud Process and Messaging Runtime Environment

The CREMA Cloud Process and Messaging Runtime Environment (PRU) component is responsible for the execution of a workflow that is defined in a business process model that uses the BPMN 2.0 standard. A process model describes the workflow of a process in terms of process tasks and the interaction between them. A process task can be an abstract service, without grounding and not executable, or a concrete services, which is a full-fledged service with grounding and executable. To be able to execute the workflow, which is defined by a process model, this process model has to be fully implemented, which means that each abstract service has to be replaced with a concrete service. If a process model is fully implemented it is called a process service plan. To start the execution of a workflow defined by a process model the PRU component loads the process model, which was defined with the help of the PDE, from the CRI. If the process model only includes concrete service it is called a process service plan and can be executed. If it contains abstract services without any defined concrete service, the PRU interacts with the ODERU to request a process service plan. For each execution request, the component starts a separate execution instance that is then responsible to spawn a new process instance in order to execute a process service plan. The usage of separate execution instances allows the component to rapidly and elastically scale up or down in order to execute and monitor numerous process instances. Before the execution of the process instances starts, the PRU interacts with the OSL to reserve all required services. During the execution of a process service plan the PRU interacts with the OSL in an ad-hoc manner to lease the services as soon as they are needed, respectively, release them again if they are not needed anymore. Additionally, the ODERU is used to perform exception handling in terms of an optimal replacement of process services that became unavailable during the execution of the process service plan.


"permission": "Read Access" } }





125 / 227


Finally, the PRU component contains a Message-Oriented Middleware (MOM) that is used to buffer streaming data from services, e.g., temperature information of a sensor. This buffered information is then processed from other CREMA components like the BDA or the MON component. This has two benefits. On the one hand, the buffered streaming data can be retrieved and used from several components at the same time. On the other hand, by buffering the data it can be ensured that all listening components receive the data without any data loss.


The PRU is responsible for the execution of the workflows that are defined by the process models and the provision of a message bus. While the message bus can be used without any changes, the software for the execution of the defined process workflows has to be extended to fit our specific needs.

5.2.1.1 Selection of a Business Process Model Execution System

For the Business Process Model System (BPMS) Camunda BPM44 is chosen. Camunda BPM is an open source platform for workflow and business process automation written in Java that is capable of executing BPMN 2.0 models. Besides the possibility to run Camunda BPM as a container service in a Webserver, such as Tomcat or JBoss, it is also possible to use it as a light-weight Java library. It is designed out of several different components, among them the Process Engine and the Cockpit, which are the two most important ones for CREMA. The Process Engine is responsible for the execution of the process service plans and the Cockpit can be used to start the execution and to monitor the execution. All components offer REST interfaces that can be used to interact with them. In addition to the REST interface, the Process Engine can also be used as a Java library. Therefore it can be used and extended in an easy way. Further benefits of Camunda BPM are an active community and the collaboration with BPMN.io, which is used by the PDE and developed by the same company as Camunda BPM.

5.2.1.2 Selection of a Message Bus

Regarding the message bus Apache ActiveMQ45 was chosen. Apache ActiveMQ is a widely used, open source, and powerful MOM. It is written in Java and among the full support of the JMS 1.1 protocol, Apache ActiveMQ is also compatible with several cross language clients and protocols. The most important supported languages for CREMA are Java and C# and the most important protocol is AMQP 1.046. AMQP is an OASIS standard for a MOM that does not specify a programming language. Furthermore, ActiveMQ offers a REST API to publish and consume messages. The decision of using ActiveMQ as a message bus gives us therefore the freedom of choosing different programming languages to interact with the message bus. Furthermore, the performance of ActiveMQ is very good, among other reasons, such as the clustering and scalability options. For the message transfer ActiveMQ offers point-to-point communication as well as Publish-Subscribe communication. In a Publish-Subscribe

44 https://camunda.org 45 http://activemq.apache.org 46 https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=amqp





126 / 227


paradigm, there are publishers and subscribers involved. A publisher can publish messages to specific topics and several clients (subscriber) can subscribe and listen to those topics. If a new message is on the message bus and correlated to a topic all listening subscribers receive this message.


As mentioned in the introduction of this chapter, the message bus can be used as it is. However, Camunda BPM has to be extended to be able to provide the defined functionalities of the PRU.

• Process Execution Manager: The Process Execution Manager is the central subcomponent that processes the requests that are sent to the PRU. It will be implemented in Java. Furthermore, it implements the interfaces “Process Execution API”, “Request Process Log API” and “Optimised process API” from the defined architecture in Figure 13.

• Process Instance Infrastructure Controller: This component is responsible for the management of the Process Instance Executers. This component is also implemented in Java.

• BPMS: For this component Camunda BPM is used and extended. It is used as a Java library. Nevertheless, Camunda BPM does not fully support all functionalities that are required in CREMA and therefore Camunda BPM has to be extended. All the extensions are done in Java. The extensions are as follows: • Before the execution of the process service plan starts: The process model has

to be loaded from the CRI before the execution can be started. After the process model has been loaded it has to be checked if it is an executable process service plan, which means that all process steps are concrete service. If it is not a process service plan, the ODERU has to be contacted to receive a process service plan. Before the execution starts, all required services have to be reserved via the OSL.

• During the execution of the process service plan: Each time a new process step is reached and this process step includes a Proxy Service Wrapper, the OSL has to be called to lease the service. After the Proxy Service Wrapper is instantiated the URL of the Instantiated Proxy Service Wrapper is received from the OSL. After that, the service has to be started by using the corresponding “Service Start Interface” on the Proxy Service Wrapper and the “Service Monitoring API” has to be initialised. Subsequently, the process service plan execution waits for a termination or failure event via the “Service Monitoring API”. If a failure event occurs the execution of the process service plan is halted, this functionality is provided by Camunda BPM, and an optimisation by ODERU in terms of optimal replacement of the failed service is requested. If the service terminates, the OSL component is called to release the service again.

• After an optimised process service plan is received: If this happens the optimised process service plan has to be loaded from the CRI and again parsed. Subsequent to those steps the execution has to be continued at the process step where the execution failed. During this step the execution variables have to be saved and passed to the new execution.

• Security Layer: The PRU has to be adapted to fulfil the authentication and authorisation roles (Described in deliverable D3.2, Section 5.3.6). The security layer





127 / 227


is required to check whether the request on behalf of a user is already authenticated before they are able to perform any activity in the PRU.


The diagram below shows the structure that has been updated to reflect the technology selection. In comparison to the functional specification, the subcomponents have slightly changed in order to reflect the technology selection and in order to better cope with the implementation planning described in Figure 13:

• A Security Layer is added, which includes both the authentication and the authorisation level. It is added to visualise the security aspect with the location where the authentication and authorisation takes place. In contrast to the unilateral authentication, the authorisation is bilaterally

• Due to the selection of Camunda BPM, as the underlying BPMS, the BPMN Parser subcomponent, which was introduced in the Global Architecture Document (D3.1), is now merged into the BPMS subcomponent. This is because Camunda BPM already includes the technologies to parse the process model

• The Resource Manager is now included in the Camunda BPM, because the operations that are performed from this subcomponent are now done directly in the BPMS subcomponent

• Due to changes in the behaviour of the MON component, the MON component is now able to start an execution of a process service plan to react to a monitoring event. As a further result the Monitor Alert API is now obsolete.

• The last change, is the interaction between the PRU and an Instantiated Proxy Service Wrapper. In the final version the request data is directly transferred to the Service via the Service Start Interface and the response data is transferred back to PRU via the Monitor Service





128 / 227


Figure 13: PRU Architecture Diagram

To achieve the functionalities described in the last subsection, the PRU provides the following subcomponents as depicted in Figure 13.

• Process Execution Manager: This subcomponent is the central subcomponent in the PRU. It processes the incoming execution requests from the PDE and MON. If a new execution of a workflow defined by a process model request is received this component requests a new Process Instance Executer that is then used to spawn a new process instance, which then executes the process service plan. Furthermore, this subcomponent is able to terminate a running execution of a process service plan, return the status of a current execution, or inform a Process Instance Executer

requestprocessinstance

ProcessInstanceExecuter

T5.3CREMAOn-demandServiceLeasingand

Releasing(OSL)

releaseservice

requestoptimisation

optimizedprocess

ProcessExecutionManager

controlprocess_execution

ProcessInstance

InfrastructureController

<userinterface>T6.5DashboardandVisualisation(DBV)

controlprocessinstance

T5.1CREMACloudCollaborativeProcess

DesignTimeEnvironment(PDE)

processexecutionrequest


Infrastructure(CRI)

requestprocess_log

process_log

saveprocess_logProcessLogStore

ProcessModelStore process_modelrequest

process_model

requestprocess_log

process_log

BPMS

T5.5CREMADesignTimeand

RuntimeOptimisation(ODERU)

T6.2CREMAMonitoringandAlerting(MON)

processexecution_request

<<interface>>RequestProcessLog

API

requestprocesslog

processlog

<<interface>>OptimizedprocessAPI

CREMACloudProcessandMessagingRuntimeEnvironment(PRU)

use


reserveservices

leaseserviceserviceURI

responsetouserrequest


processterminationrequest

processstatusrequest

<<interface>>ProcessExecution

API

<userinterface>Start/

Terminate/StatusProcessExecution

optimizedprocess

SecurityLayer

<<interface>>Service

MonitoringAPI

requestprocesslog

processlog

InstantiatedProxyServiceWrapper

ServiceStartInterface

NotificationService

MessageBus

T6.3CREMAManufacturing

BigData,KnowledgeandAnalytics

(BDA)

streamingdata

streamingdata

Service

streamingdata


events

serviceexecutionrequest





129 / 227


that an updated version of a process service plan is available. If the MON or the ODERU requests a process log of a current running process instance this subcomponent contacts the Process Instance Executer that is executing this specific process instance and forwards the request for the process log to this Process Instance Executer.

• Process Instance Infrastructure Controller: This subcomponent is responsible for managing the different Process Instance Executers. If it is needed this subcomponent can start a new Process Instance Executer or terminate one if it is not used anymore.

• BPMS: This subcomponent is responsible for the actual execution of the process service plan. This subcomponent uses the Camunda BPM, which will be extended to fit the needs of CREMA, as underlying BPMS. In the first step, this subcomponent loads the process service plan from the CRI and reserves all services that are required to execute the process service plan. After all services are reserved, the actual execution is started. During the execution this subcomponent interacts with the OSL to lease and release the required Proxy Service Wrapper. Furthermore, this subcomponent is able to request an optimisation of the current process service plan if the execution of a service fails.

• Security Layer: This subcomponent takes care of authentication and authorisation for user respectively other CREMA components. It allows to perform actions and get data the user is authorised for

• Process Execution API: This interface provides the possibility to start an execution of a workflow defined by a process model without the use of the UI. The call has to include the ID of the process model and, if needed, starting values that are then passed to the first executed service.

• Request Process Log API: This interface can be used to receive a Process Log of a current running execution.

• Optimised Process API: This interface provides the possibility to inform the PRU about an optimised process service plan.

• Service Monitoring API: This API is used by an Instantiated Proxy Service Wrapper to inform the BPMS about monitoring events like the termination of a service or about a failure during the execution of a service

• Message Bus This subcomponent is a Message-Oriented Middleware that is used to buffer streaming data from services, e.g., temperature information of a sensor that is then processed by other CREMA components, e.g., BDA



In order to describe the RESTful interface, each provided service is described in a separate table. This table is followed with a listing showing an example for the JSON parameter (if applicable) as well as an example for the return value (if applicable). In the following subsection the term “user” describes also components which will use this method/interface.

5.2.3.1.1 Method “Start a Process Model Execution”

The RESTful interface “Start a process model execution” (Table 82), is called to start the execution of a workflow defined by a process model. Besides the ID of the process model





130 / 227


that defines the workflow that has to be executed, this interface also can receive a JSON object. This JSON object is passed to the executing process instance at the start of the process service plan execution and includes values that are then passed to the first executed service.

Table 82: PRU RESTful Interface – Start a Process Model Execution

5.2.3.1.2 Method “Optimised Process Service Plan Available”

The RESTful interface “Optimised process service plan available” (Table 83), is called by the ODERU component to inform the PRU that an updated version of a process service plan is available.

Table 83: PRU RESTful Interface – Optimised Process Model Available

Start a Process Model Execution

Description This method starts the execution of a predefined process model.

Request

Request URL POST http://crema.eu/pru/pminstances?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object JSON object that holds the ID of the process model. Furthermore, it has the optional values for the process service plan execution. Those values are passed to the executing process instance at the beginning.

{

"processmodel" :

"model123",

"input": [

{"key1" : "value1"},

{"key2" : "value2"}

]}

Combined Example

POST /pru/pminstaces?session=user1234 HTTP/1.1 Host: crema.eu

object={"processmodel":"model123", "input": [{"key1":"value1","key2":"value2"}]}

Response

HTTP Status Code

Value Description

200 Execution started


404 Process model not found

Optimised Process Model Available

Description This method is called if an optimised process service plan is available.

Request





131 / 227


5.2.3.1.3 Method “Request Process Log”

The RESTful interface “Request Process Log” (Table 84), can be used to request a process log of a currently executed process instance.

Table 84: PRU RESTful Interface – Request Process Log

Request URL PUT http://crema.eu/pru/pminstances/instanceId?session=userToken

Resource Parameters


isntanceId : string The ID of the process instance that should use the optimised process service plan.

Instance1234


User1234

HTTP Parameters

object : object JSON object holding the ID of the instance that had to be optimised and the ID of the optimised process service plan.

{ "newModel":

"model123"

}

Combined Example

PUT /pru/pminstances/instanceId?session=user1234 HTTP/1.1 Host: crema.eu

object={“newModelId”:”model123”}

Response

HTTP Status Code

Value Description

200 Execution continued


404 Process instance not found

409 Process model not found

Request Process Log

Description This method is used to request a process log of an execution for a process instance.

Request

Request URL GET http://crema.eu/pru/pminstances/instanceId/logs?session=userToken

Resource Parameters


instanceId : string The identifier of a running process instance

instance123


User1234

Combined Example

GET /pru/pminstances/instance123/logs?session=user1234 HTTP/1.1 Host: crema.eu





132 / 227


5.2.3.1.4 Method “Service Monitoring Event”

The RESTful interface “Service monitoring event” (Table 85) is called by an Instantiated Proxy Service Wrapper to inform the BPMS about a regular termination of a service execution or about the failure of a service execution.

Table 85: PRU RESTful Interface – Service Monitoring Event

Response

HTTP Status Code

Value Description

200 Log for Process Instance found


404 Log for Process Instance not found

JSON Attributes

Name Description

Result : object Camunda BPM Process Log

Service Monitoring Event

Description This method is called from an Instantiated Proxy Service Wrapper to inform the PRU about the termination of the execution of a service or the failure of one.

Request

Request URL POST http://crema.eu/pru/pminstances/instanceId/service/processStepId

Resource Parameters


instanceId : string ID of the process instance. testId

processStepId : string ID of process step. testStepId

HTTP Parameters

object : object JSON object representing an exception (type=exception) or the end of the execution (type=finished)

Response 1: { "serviceId": "1234", "type":

"termination", "response" : [ {"key1": "value1"}, {"key2": "value2"}, {"keyn": "valuen"} ] } Response 2: { "serviceId": "1234", "type": "failure", "reason":

"Errormessage"

}





133 / 227



The PRU is able to execute workflows defined by a process model in BPM2.0 XML format that are created with the PDE component. Beside the general BPMN2.0 elements the PRU relies on the CREMA specific <bpmn:extensionElements> that are filled by the PDE and ODERU components. A detailed explanation of the element can be found in Section 5.1.4. For the PRU the service definition elements are the most important.


To start or terminate an execution of a process model the user must have a corresponding role that permits the user to execute the intended action. The following list contains the authorisation definitions of the PRU component.

• Full Access: The user has full access to all functionalities and entities of the PRU. This means that the user can start and terminate any execution of a process model. The user can also terminate executions that he did not start.

• Regular Access: The user can start any available execution of a process model but they can only terminate those they actually started.

• Execution Access: The user can only start an execution of a process model but not terminate it.

• Restricted resources: Depending on the current user, this user is just able to start and terminate executions of process models that are available in his company.


Listing 24: PRU Example Authorisation Definition

Combined Example

POST /pru/pminstances/testID/service/testStepId HTTP/1.1 Host: crema.eu

object={“serviceId”: “1234”, “type”:”failure”, “reason”:”Errormessage”}

Response

HTTP Status Code

Value Description

200 OK

404 Process Instance or Process step not found

409 Process Step not found

{ "userId": "597134" "user": "Charles", "company": "CREMA", "authorisation": { "permission": ["ExecutionrAccess", "RestrictedResources"], } }





134 / 227


5.3 On-Demand Service Leasing and Releasing

The On-Demand Service Leasing and Releasing (OSL) component allows the leasing of services on demand in an ad-hoc manner whenever they are requested by the PRU. These services are represented by Proxy Service Wrappers which provide an interface to either access real world assets, i.e. manufacturing services or the functionality of software services. As soon as the services execution is terminated, either when the service is finished or failed, the PRU requests its termination and the OSL releases the instantiated Service Wrapper again. These leasing and releasing operations are exposed by RESTful interfaces to be accessed by the PRU. Further, the OSL also provides the functionality to reserve a list of services for future usage on the MPM component as well as to obtain a list of all currently instantiated Proxy Service Wrappers for administrational purposes. Finally, the OSL also exposes a REST interface to obtain the current availability of a specific service which is required by the ODERU to create appropriate optimisations of service-based process models.


The OSL supports two different Cloud platforms, i.e. Openstack47 and Amazon EC248, which are used to allocate computational resources for the instantiation of Proxy Service Wrappers. In order to ease the deployment and handling among the different components, the CREMA platform relies on a containerised approach for the services. The following sections provide the rationale behind the technology decisions and a discussion about the technology stack of the subcomponents of the OSL which are going to be implemented as well.

5.3.1.1 Selection of Programming Language

The OSL component will be implemented using the Java programming language49 and the component will run on the Oracle Java Virtual Machine50. The Java programming language was used since it is free of charge and the code can be executed on different platforms due to the Java Virtual Machine architecture. Furthermore the ecosystem of Java is large and has numerous mature libraries which are suitable for the implementation of this component.

5.3.1.2 Selection of Cloud Infrastructure

Amazon EC2 and the Openstack platform were chosen to be used as a cloud infrastructure. Since Amazon EC2 represents a mature platform with a high availability and a large set of features in terms of configurability, it was selected as one of the two platforms to obtain the computational resources. Besides offering standardised interfaces to lease and release computational resources, which are provided as Virtual Machines (VMs), Amazon EC2 also provides a strong ecosystem to monitor and configure these VMs. The accounting on these VMs is performed in a pay per use manner and thus there are no up-front costs for the initial hardware purchases. Due to the managed infrastructure the costs for maintaining the

47 https://www.openstack.org 48 https://aws.amazon.com/es/ec2/ 49 https://docs.oracle.com/javase/specs/ 50 https://www.java.com/





135 / 227


infrastructure are very low and it is feasible to obtain virtually unlimited computational resources. Besides Amazon EC2, the OpenStack platform was chosen since it represents the most mature solution to provide a private cloud environment. The OpenStack platform enables companies to maintain a private cloud instance. Although this private cloud requires upfront hardware investments and higher efforts regarding the infrastructure maintenance, it often may be the only option to build a cloud infrastructure, e.g. due to legal or privacy restrictions. Nevertheless, the OpenStack platform also allows to optimise, i.e. minimise, the resource usage within a company due to resource pooling.

5.3.1.3 Selection of Service Container

In order to maintain a flexible, i.e. support different runtime environments for Proxy Service Wrappers but also keep a standardised approach in terms of deploying Proxy Service Wrappers, a containerised approach is taken. This means that each Proxy Service Wrapper maintains its own runtime environment and required configuration within a container and the OSL is able to instantiate these containerised services by instantiating the container images. Docker51 was chosen as the concrete container format, since it is widely adopted and provides an extensive and vivid ecosystem and mature toolchain. The Docker platform provides mature facilities to manage Docker images, i.e., Docker Repository, host images, i.e., Docker Host and to bundle computational resources, i.e., Docker Swarm.


The OSL represents a new component, which is developed from scratch. Nevertheless, this component is going to rely on mature frameworks if available and to pursue an architecture built on state of the art concepts. The following features are going to be developed:

• Cloud Resource Management: The Cloud Resource Management obtains the required computational resources which are required to run Proxy Service Wrappers. In order to minimise the operational costs of CREMA, the Cloud Resource Management optimises the allocation of computational resources, i.e. it will provide an optimisation algorithm which considers the pricing policies as well as the leasing policies of Amazon EC 2 and OpenStack based clouds. This component will be implemented as a Spring Boot52 based service and the connection to the computational cloud resources will be realised by the AWS SDK53 for Amazon EC2 and jClouds54 for the OpenStack environments.

• Service Manager: The Service Manager is the central component of the OSL which dispatches all requests by other CREMA components and triggers the required operations to obtain service containers from the MPM component, obtain cloud resources, deploy and delete services on cloud resources as well as checking the current availability of services. The Service Manager will be implemented as a Spring Boot55 based service and the deployment of the Docker container will be

51 https://www.docker.com 52 http://projects.spring.io/spring-boot/ 53 https://aws.amazon.com/sdk-for-java/ 54 https://jclouds.apache.org 55 http://projects.spring.io/spring-boot/





136 / 227


realised by means of a Java based Docker client library56. The single services will be deployed on a set of Docker Hosts, which are managed by Docker Swarm.

• Service Organiser: The Service Organiser represents a GUI, which is intended for organisational aspects, like analysing the current usage of cloud resources and the currently running Proxy Service Wrappers as well as the ability to release any instantiated Proxy Service Wrappers. The latter component is only intended to be used during the Development Phase. This Component will be realised as a Spring Boot Service whereas the GUI will be realised by Thymeleaf57.

• Security Layer: The OSL has to be adapted to fulfil the authentication and authorisation roles (Described in the Functional Specification, T3.2, D3.2, and Section 5.3.6). The security layer is required to check whether the request on behalf of a user is already authenticated before they are able to perform any activity in the OSL.


The diagram below shows the structure that has been updated to reflect the technology selection. In comparison to the Functional specification (T3.2, D3.2) the subcomponents have slightly changed to fulfil the Authentication and Authorisation Operations. Notably the Security Layer is added which includes both the Authentication and the Authorisation Level.

56 https://github.com/spotify/docker-client 57 http://www.thymeleaf.org





137 / 227


Figure 14: OSL Architecture Diagram


The major design decision for the CREMA project is to use RESTful interfaces as a common communication base for the CREMA components. In order to follow this decision, the communication interfaces of the OSL are defined as RESTful interfaces.


In order to describe the RESTful interfaces, each provided service is described in a separate table. This table includes an example for the JSON parameter (if applicable) as well as an example for the return value (if applicable). In the following subsection the term “user” describes also components which will use this method/interface.

5.3.3.1.1 Method “Lease Service”

The RESTful interface “Lease Service” (Table 86) describes the functionality to lease a new service by instantiating a new Proxy Service Wrapper.

Table 86: OSL RESTful Interface – Lease Service

T5.2CREMACloudProcessandMessagingRuntimeEnvironment(PRU)


Monetisation(MPM)ServiceManager

CloudResource

Management

T5.4CREMADesigntimeandRuntime

Optimisation(ODERU)

CloudResources


AvailabilityInterfaceService


AvailabilityInterfaceService

requestservicedefinitionservicedefinition

cloudresourceURI

reportservicerelease

CREMAOn-DemandServiceLeasingandReleasing(OSL) serviceURI

serviceleasability

serviceURIcheck

availability

checkservice

leasability

leasenewservice

deploy/terminateservice

<<interface>>Serviceleasability

API

<<interface>>ServiceleasingAPI

reserveservices

reserveservices

requestcloudresources

serviceleasability

checkservice

leasability

serviceURIlease

newservicereserveservices

<userinterface>Organisational

WebUI

getinstantiatedservices


releaseservice

releaseservice

instantiatedservices

getinstantiatedservices

cloudresourceallocation

cloudresourceURI

serviceavailability

Lease Service





138 / 227


5.3.3.1.2 Method “Release Service”

The RESTful interface “Release Service” (Table 87), describes the functionality to release a specific Proxy Service Wrapper instance.

Table 87: OSL RESTful Interface – Release Service

Description This method leases a new service by instantiating a new Proxy Service Wrapper.

Request

Request URL POST http://crema.eu/osl/service/processID/serviceID?session=userToken

Resource Parameters


processID : string ID of the process Process1

serviceID : string ID of the service Service1v123


User1234

Combined Example

POST /osl/service/Process1/Service1v123?session=User1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

201 Service created


404 Service not found

409 Service is not available

JSON Attributes Result: object {“serviceURI” : “http://10.10.10.10:1234”,

“serviceInstanceID” : “Service1v123i1337” }

Release Service

Description This method releases a specific Proxy Service Wrapper instance.

Request

Request URL DELETE http://crema.eu/osl/service/serviceInstanceID?session=userToken

Resource Parameters


serviceInstanceID : string

ID of the Proxy Service Wrapper instance

Service1v123i1337


User1234





139 / 227


5.3.3.1.3 Method “Leaseability Check”

The RESTful interface “Leaseability Check” (Table 88), describes the functionality to check the leaseability of a specific service for the current time.

Table 88: OSL RESTful Interface – Leaseability Check

5.3.3.1.4 Method “Reserve Services”

The RESTful interface “Reserve Services” (Table 89), describes the functionality to reserve a list of services for future usage for a specific process.

Combined Example

DELETE /osl/service/Service1v123i1337?session=User1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Proxy Service Wrapper deleted


404 Proxy Service Wrapper not found

Leaseability Check

Description This method checks the leaseability of a specific service

Request

Request URL GET http://crema.eu/osl/serviceLeaseability/serviceID?session=userToken

Resource Parameters


serviceID : string ID of the service Service1v123


User1234

Combined Example

GET /osl/serviceLeaseability/Service1v123?session=User1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Service is leaseable



409 Service is not leasabile

JSON Attributes

Result: object {“service” : “service1”, “leaseability” : “true” } {“service” : “service2”, “leaseability” : “false” }





140 / 227


Table 89: OSL RESTful Interface – Reserve Services

Reserve Services

Description This method reserves a list of services for future usage for a specific process.

Request

Request URL POST http://crema.eu/osl/reserveServices/processID?session=userToken

Resource Parameters


processID : string ID of the process Process123


User1234

HTTP Parameters

serviceList : object A JSON object, which lists the required services including their timeslots for a process.

{ “services” : [

{“service” : “serviceID”,

“start” : “startTimeInUTC”,

“end” : “EndTimeInUTC” }

]

}

Combined Example

POST /osl/reserveServices/Process123?session=User1234 HTTP/1.1 Host: crema.eu

serviceList = { “services” : [

{“service” : “Service1”,

“start” : “2015-10-25T22:34:51Z”,

“end” : “2015-10-25T23:55:22Z” },


“start” : “2015-10-25T23:55:22Z”,

“end” : “2015-10-26T00:55:22Z” },


“start” : “2015-10-26T00:55:22Z”,

“end” : “2015-10-26T05:55:22Z” }

]}

Response

HTTP Status Code

Value Description

200 Services reserved



409 Service is not available





141 / 227


5.3.3.1.5 Method “List all Instantiated Proxy Service Wrappers”

The RESTful interface “List all Instantiated Proxy Service Wrappers” (Table 90), describes the functionality to list all currently instantiated Proxy Service Wrappers or just those of a specific process.

Table 90: OSL RESTful Interface – List all Instantiated Proxy Wrappers

JSON Attributes Result: object {“services” : [“service1” : ok”, “service2” : “failed”, “service3”: “failed”] }

List all Instantiated Proxy Service Wrappers

Description This method gets a list of all instantiated Proxy Service Wrappers or just those of a specific process.

Request

Request URL GET http://crema.eu/osl/instantiatedServices/processID?session=userToken

Resource Parameters


processID : string? ID of the process Process123


User1234

Combined Example

GET /osl/instantiatedServices/Process123?session=User1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Service list is available


JSON Attributes Result: object {“services” : [

{ “process” : “Process123”,

“serviceID” : “service1v123”,

“serviceURI” : “http://10.10.10.10:1234”,

“serviceInstanceID” : “Service1v123i1337” }, { “process” : “Process122”,


“serviceURI” : “http://10.10.10.10:12”,

“serviceInstanceID” : “Service2v1i666” }, {





142 / 227



The instantiated Proxy Service Wrappers are represented and identified by an URI to external CREMA components. As the URI scheme the URL concept is chosen, which acts as a unique identifier for a specific instantiated Proxy Service Wrapper and can also be used to access the functionality provided by this Proxy Service Wrapper.


To lease as well as release a service on the OSL, the OSL must be provided a suitable authentication token, which can be used to obtain the appropriate authorisation definitions. This token is provided by the PRU and checked within the OSL against the SPC. The token is also forwarded in all interactions with other services; for example to obtain the service definitions on the MPM.

• Administrator Access: The user has full access to organisational functionalities and entities of the OSL. This means that the user can access the UI which lists all instantiated Proxy Service Wrappers and release services, even if their execution is not terminated yet.

• Regular Access: The PRU can lease services on behalf of a specific user that are assigned to the specific process instance, but cannot release any software services before their execution is terminated.

• Availability Access: The ODERU can query the leasability for all allowed services. The following Listing shows an example of how a response from the SPC component could be structured. It uses the predefined permission labels to set the rights for each user.

Listing 25: OSL Example Authorisation Definition

5.4 Design Time and Runtime Optimisation

In CREMA, the ODERU component provides means for optimising service-based manufacturing processes at design time and runtime. An optimal implementation of BPMN process models with services can be realised with respect to functional and non-functional

“process” : “Process1111”,


“serviceURI” : “http://10.10.10.10:1111”,

“serviceInstanceID” : “Service3v111i42” }, ] }


"permission": "regular", "services": ["service1", "service11", "service111"]

} }





143 / 227


aspects. Functional optimisation of a given annotated process model is performed with means of high-precision semantic selection and planning of services. Non-functional optimisation of process models concerns the process KPI-driven optimisation of their service plan with respect to a given objective function (min/max) and constraints on its (KPI) variables like cost, time, and OEE. This is performed with means of dynamic constrained optimisation problem solving in the cloud, taking into account historic and live data. The main research challenge is the efficient and effective integration of means for both kinds of optimisation in one integrated approach for process optimisation by ODERU. The ODERU can assist the process designer (PDE) in the optimal implementation of BPMN process models with services at design time. In addition, ODERU supports the process execution environment PRU by trying to find an optimal replacement of services when execution failed.


Research and development of the integrated ODERU component is performed in Tasks 5.4 and 5.5; the functional characteristics of this component are described in D3.2. The process optimisation by ODERU partly bases on state of the art approaches for semantic service selection and planning, dynamic constraint optimisation problem solving, and RDF stream processing.

5.4.1.1 Semantic process service selection and planning

Functional optimisation of processes by ODERU at design time and runtime is based on means for high-precision semantic selection and automated composition planning of available services. Semantic selection of services encompasses (a) the pairwise semantic matching of the given annotated process with each annotated service that is registered in the service directory of the MPM component, and (b) the semantic relevance ranking of these services for the process. Means for optimal semantic selection by ODERU can partly rely on state of the art in this field [KKSLB15], in particular the tool iSeM developed by DFKI. If an optimal semantic selection of available services fails, the ODERU can try to compose an optimal composite service by means of semantic service planning. During planning, service execution is simulated on an abstract level based on their semantic descriptions. Means for process service planning by ODERU can partly rely on the state of the art in this field, in particular the state-based dynamic OWL-S service planning tool OWLS-XPlan2 developed by DFKI.

5.4.1.2 Dynamic process constraint optimisation

Non-functional optimisation of processes by ODERU at design time and runtime is based on means for dynamic constrained optimisation problem (DCOP) solving and forecasting. In this regard, an individual or composite process service can be optimised with respect to a given objective (min/max) function and set of (in-) equality constraints on its parameters like quality of service, resource consumption, execution costs, and other process service KPIs. In dynamic environments, the objective function, the constraints, and the parameter values can dynamically change even during the computation of an optimal solution of the original problem. Examples are the dynamic change of the process optimisation constraints and/or the objective function by the process manager, as well as the dynamic changes of relevant





144 / 227


process KPI values. Means for dynamic constrained optimisation problem (DCOP) solving by ODERU can partly rely on state of the art in high-performance DCOP and distributed COP solving. State of the art means for the forecasting of objective function parameter values and risk of process service failure analysis based on history and actual data are available in the tool suite MATLAB. For implementation of cloud-based DCOP solving by ODERU, the Apache EC2 and Apache Flink streaming frameworks are considered.

5.4.1.3 Semantic Data Stream Processing

Process optimisation at runtime takes into account relevant live data on monitored process KPIs and machine conditions. For this purpose, ODERU annotates and analyses the in part streamed data it receives from the CPS, CVA and PRU. The semantic analysis is performed with means for RDF stream processing (RSP) in support of detecting dynamic changes of the actual DCOPs for process models. Means for RSP by ODERU can rely on state of the art in this field, in particular the tools C-SPARQL and SPARQL-Stream with Apache Flink.


Research and development of the ODERU component are carried out in Tasks 5.4 and 5.5. As mentioned above, the innovative integration of functional and non-functional process optimisation at runtime and design time remains to be investigated, and then implemented almost from scratch. This concerns, in particular, the following elements:

• Dynamic distributed constrained optimisation solver for the cloud, as well as its integration with the selected RSP engine and methods for forecasting and risk of failure analysis.

• Integrated non-functional and functional process service selector. This element can be implemented with a major revision and extension of the high-precision semantic service selector iSeM.

• Dynamic process service planner with functional and non-functional optimisation aspects for its simulation-based planning. This element will be implemented with either a major revision of the planner OWLS-XPlan2, or a whole new service planner if required in practice of CREMA use cases.


Based on what has been already described in the architecture deliverable D3.1 and in the requirements elicitation step, the ODERU component plays a twofold role:

• The ODE (design time) component support is able to enhance the Process Designer activity by finding the optimal service-based implementation of a (semantically) annotated process model.

• The ORU (runtime) component support is foreseen to provide optimisation of running service-based process model instances.

Figure 15 shows the modular architecture of the ODERU component. The set of provided APIs covers both aspects of ODERU: runtime and design time optimisation. The central module of ODERU is the “Optimisation Workflow Handling” module. It decides which information is required, handles all possible interactions with external components, and prepares the results to be returned to the calling component.





145 / 227


Figure 15: ODERU Architecture Diagram

As mentioned above, ODERU performs process optimisation with respect to functional and non-functional aspects, taking historic and live data into account. The available process models and services are taken from the components CRI and MPM, and the leasable process services are checked with the OSL component. Runtime optimisation of service-based processes is performed by ODERU on request of the PRU component. Design time optimisation is done on request of the PDE component. The ODERU module “Service Selection and Planning” performs a high-precision selection and automated planning of functionally optimal services for a given process model. The module “Simulation-based Service Plan Optimisation” performs (dynamic) KPI-driven constrained optimisation problem solving for process service plans. The included forecasting of objective function parameter values like process service KPI values is based on historic and streamed live data. This data is provided by the components MON, BDA, and PRU, and the module “Data Stream Processing”. The latter module supports the dynamic COP (DCOP) solving based on semantic processing of live streamed data taken from the component CVA.


The major design decision for the CREMA project is to use RESTful interfaces as a common communication base for the CREMA components. In order to follow this decision, the communication interfaces of the ODERU are defined as RESTful interfaces.

T6.1MarketplaceandMonetisation(MPM)

ServiceRepository


T5.1CREMACloudCollaborativeProcessDesignTimeEnvironment(PDE)


Analytics(BDA)

T4.4CREMACPS,SensorAbstractionandVirtualisation(CVA)

T6.2CREMAMonitoringandAlerting(MON)

CREMADesignTime&RuntimeOptimisation(ODE/ORU)

DataStreamProcessing

ServiceSelectionandPlanning

datastreamsregistertodatastreams

Simulation-basedServicePlanOptimisation

<<interface>>ORUAPI

<<interface>>ODEAPI

OptimisationWorkflowHandling

datastreams

serviceplans

optimisedserviceplan

monitoredevents

historicserviceKPI

actualserviceKPI


optimisedprocessinstance



getservices/requestupdates

functional(re-)planning

request

non-functionaloptimisationrequest

requesteventchannel

getactualserviceKPI

datastreamrequest

optimiseprocessinstance

optimiseprocessinstance

getoptimalserviceplan

getoptimalserviceplan

requestprocesslogs

gethistoricserviceKPI getprocess

model

serviceleasibility

T5.3CREMAOn-demandServiceLeasingandReleasing(OSL)

checkserviceleasibility

useracceptanceanswer

processlogs

availableservices/updates

<userinterface>Optimisation

UIuse


presentprocessinstanceandcheckforuseracceptance


Infrastructure(CRI)

processmodels


processmodel


storeoptimisations





146 / 227



In order to describe the RESTful interfaces, each provided service is described in a separate table. This table includes an example for the JSON parameter (if applicable) as well as an example for the return value (if applicable). In the following subsection the term “user” describes also components which uses this method/interface.

5.4.3.1.1 Method “Compose Process Service Plan for Process Model at Design Time”

The RESTful interface “Compose process service plan for process model at design time” (Table 91) provides a process service plan at design time. Service composition planning is based on the functional specification of process steps of a given process model and available services in terms of their Inputs, Outputs, Preconditions and Effects (IOPE). Planning simulates state transitions for process service executions. It is functionally optimal with respect to the creation of a service plan, if it exists, that it satisfies the requested functionality with best matching services and minimal plan length plan.

Table 91: ODERU RESTful Interface – Compose Design Time Process Service Plans

Compose process service plan for process model at design time

Description This function computes a process service plan, if it exists, for a given process model. The plan is functionally optimal with respect to the satisfaction of requested functionality with the best matching services and minimal plan length. The service planning relies on the semantic IOPE annotations of process tasks and available services. If an objective function is provided in the request, the planner can also take non-functional parameters of individual services but only for its non-functionally optimal service selection during the planning process into account; it is not a global optimisation of the process service plan.

Request

Request URL PUT http://crema.eu/oderu/PM/Compose?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the composition (optimisation) problem

{

"ProcessModel ID": "ID1",

"ObjectiveFunction": [{

"Dim1": {"type": "MIN","parameter": "@X1"},

"Dim2": {"type": "MIN","parameter": "(@X2 + @X3)/@Y"},

"Dim3": {"type": "MAX","parameter": "AVG(@Z)"}}],





147 / 227


5.4.3.1.2 Method “Optimise Non-Functional Properties of Process Model at Design Time

The RESTful interface “Optimise non-functional properties of process model at design time” (Table 86) takes a process service plan and tries to optimise it with respect to a given KPI-based constrained optimisation (COP) problem. If required, the original process service plan is replaced with a functional equivalent plan that satisfies the given COP, taking into account historic and forecasted KPI data.

"deadline": "2015-11-04T14:00:00"

}

Combined Example

PUT /oderu/PM/Compose/?session=user1234 HTTP/1.1 Host: crema.eu object={“ProcessModel ID": "PM1", "ObjectiveFunction": [{ "Dim1": { "type": "MIN", "parameter ": "@global_cost"}, "Dim2": {"type ": "MIN ", "parameter ": "(@direct_cost + @indirect_cost) / @financial_impact "}, "Dim3": {"type": "MAX", "parameter": "AVG(@ROI)" }}]}

Response

HTTP Status Code

Value Description

200 Composition correctly executed, result returned

204 Composition finished, no possible process service plan available for the given process model

400 Error due to deadline in the past.

401 Authorization step failed with the provided UserToken

404 Error due to Process Model ID not existing in the CRI

422 Error due to invalid Objective function

503 Storage layer not available, not possible to retrieve the Process Model from the ID or to store back the resulting Process Service Plan.

504 Timeout reached. The returned process service plan, if any, could be not optimized.

520 Impossible to execute the composition requested.

JSON Attributes

Name Description

Result : identifier of the PSP (concatenation of the PMID and the PSP version) and the optimisation value achieved (only HTTP/200 result)

{"ProcessServicePlanID":”PM1_PSP1”,

“OptimisationValue”:87.50}





148 / 227


Table 92: ODERU RESTful Interface – Optimise Design Time Process Models

Optimise non-functional properties of process model at design time

Description This function takes a process service plan of a process model and tries to optimise this plan (thereby the model) with respect to a given KPI-based constrained optimisation (COP) problem. The COP is obtained from the CRI as set of constraints with objective function for this process model. If required, the original process service plan is replaced with a functional equivalent service plan that satisfies the COP. This non-functional optimisation of the process service plan takes abstract QoS values in service descriptions into account, as well as historic and forecasted KPI data from the BDA, and actual KPI data from the PRU, if available.

Request

Request URL PUT http://crema.eu/oderu/PM/Optimise?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the optimisation problem

{

"ProcessServicePlanID":”PM1_PSP1",

"Contraints":

[“Var1<k1”,”Var2>=k2”],


"Dim1": {{"type": “MIN","parameter": "@X1"}}], "deadline": "2015-11-04T14:00:00"

}

Combined Example

PUT /oderu/PM/Optimise?session=user1234 HTTP/1.1 Host: crema.eu object={“ProcessServicePlanID": "PM1_PSP1", "Contraints": ["@lenght<120","@ROI>=2.345"],"ObjectiveFunction": [{ "Dim1": { "type": "MIN", "parameter ": "@global_cost"}}]}

Response

HTTP Status Code

Value Description

200 Optimisation correctly executed, result returned

204 Optimisation finished, no possible process service plan available for the given process model with these constraints









149 / 227


5.4.3.1.3 Method “Approve Optimised Process Service Plan”

The RESTful interface “Approve optimised process service plan” (Table 93) is designed to support the approval of a newly optimised process service plan by the process designer.

Table 93: ODERU RESTful Interface – Approve optimised process service plan

503 Storage layer not available, not possible to retrieve the Process Model from the ID or to store back the resulting Process Service Plan.


520 Impossible to execute the Optimisation requested.

JSON Attributes

Name Description

Result : identifier of the PSP (concatenation of the PMID and the PSP version), the constraint set used and the optimisation value achieved (only HTTP/200 result)

{"ProcessServicePlanID":”PM1_PSP2”,

"Contraints": ["@lenght<120","@ROI>=2.345"],


Approve optimised process service plan

Description Approve an optimised process service plan

Request

Request URL PUT http://crema.eu/oderu/PSP/Approve?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An JSON object representing the PSPID and the user decision about the current version acceptance

{

"ProcessServicePlanID": "PM1_PSP1",

"acceptance": TRUE|FALSE

}

Combined Example

PUT oderu/PSP/Approve?session=user1234 HTTP/1.1 Host: crema.eu object={"ProcessServicePlanID": "PM1_PSP1", "acceptance": TRUE}

Response

HTTP Status Code

Value Description

202 Acceptance flag modified to TRUE

205 Acceptance flag modified to FALSE






150 / 227


5.4.3.1.4 Method “Compose Process Service Plan for Process Instance at Runtime”

The RESTful interface “Compose process service plan for process instance at runtime” (Table 95) is designed to provide a functionally optimal process service planning for a given process instance at runtime.

Table 94: ODERU RESTful Interface – Compose Runtime Process Service Plan

404 Process Model ID not existing in the CRI

409 PSP version received does not exist


520 Impossible to modify the acceptance flag

Compose process service plan for process instance at runtime

Description The function computes a functionally optimal process service plan for a given process model instance at runtime. For this purpose, it focuses on available and leasable services (OSL).

Request

Request URL PUT http://crema.eu/oderu/PI/Compose/?session=userToken

Resource Parameters



User1234

HTTP Parameters


{

"ProcessInstanceID": "PM1_PI1",

"ObjectiveFunction": [{ "Dim1": {{"type": “MAX","parameter": "@X1"}}],

"deadline": "2015-11-04T14:00:00"

}

Combined Example

PUT /oderu/PI/Compose/?session=user1234 HTTP/1.1 Host: crema.eu object={"ProcessInstanceID": "PM1_PI1", "ObjectiveFunction": [{ "Dim1": { "type": "MIN", "parameter ": "@global_cost"}, "Dim2": {"type ": "MIN ", "parameter ": "(@direct_cost + @indirect_cost) / @financial_impact "}, "Dim3": {"type": "MAX", "parameter": "AVG(@ROI)" }}],"deadline": "2015-11-04T14:00:00"}

Response

HTTP Status Code

Value Description

200 Composition correctly executed, result returned





151 / 227


5.4.3.1.5 Method “Optimise Non-Functional Properties of Process Instance at Runtime”

The RESTful interface “Optimise non-functional properties of process instance at runtime” (Table 95) computes, in near-realtime, a functionally equivalent plan satisfying the KPI constraints set provided for a given process instance. It starts from a process service plan currently executed and considers data coming from sensors, services execution layer, services availability and leasability. It takes into account also updates in the data sources while being executed, implementing a dynamic constrained optimisation.

Table 95: ODERU RESTful Interface – Optimise Runtime Process Instances

204 Composition finished, no possible process service plan available for the given process instance





503 Storage layer not available, not possible to retrieve the Process Instance from the ID or to store back the resulting Process Service Plan.


520 Impossible to execute the composition requested.

JSON Attributes

Name Description

Result : identifier of the PSP (concatenation of the PIID and the PSP version) and the optimization value achieved (only HTTP/200 result)

{"ProcessServicePlanID":”PM1_PI1_PSP1”;

“OptimizationValue”:87.50}

Optimise non-functional properties of process model at runtime

Description This function takes a process model instance and tries to optimise its process service plan (thereby the model instance) with respect to a given KPI-based constrained optimisation (COP) problem. As at design time, the COP is obtained from the CRI as set of constraints with objective function for this process model. If required, the original process service plan is replaced with a functional equivalent service plan that satisfies the COP. This non-functional optimisation of the process service plan takes abstract QoS values in service descriptions into account, as well as historic and forecasted KPI data from the BDA, and actual KPI data from the PRU, if available. In addition, the COP solving is dynamic (DCOP) since it takes dynamic changes of KPI data (derived from live streamed sensor data by the “Data Stream Processing” module) into account.

Request





152 / 227


Request URL PUT http://crema.eu/oderu/PI/Optimise/?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the optimisation problem

{

"ProcessInstanceID": "PM1_PI1",

"Contraints":[“Var1<K1”, ”Var2<=K2”, ”Var2>K3”],

"ObjectiveFunction": [{ "Dim1": {{"type": “MAX","parameter": "@X1"}}], "deadline": "2015-11-04T14:00:00"

}

Combined Example

PUT /oderu/PI/Optimise/?session=user1234 HTTP/1.1 Host: crema.eu object={"ProcessInstanceID": "PM1_PI1", "Contraints": ["@length<19","@used_energy<=155","@used_ energy>59"], "ObjectiveFunction": [{"Dim1": {"type": "MIN","parameter": "@cost"}}],"deadline": "2015-11-04T14:00:00"}

Response

HTTP Status Code

Value Description

200 Optimisation correctly executed, result returned

204 Optimisation finished, no possible process service plan available for the given process instance with these constraints

400 Error due to deadline in the past


404 Error due to Process Instance ID not existing in the CRI

409 Error due to invalid constraints set


503 Storage layer not available, not possible to retrieve the Process Instance from the ID or to store back the resulting Process Service Plan.

504 Timeout reached. The returned process service plan, if any, could be not optimised.

520 Impossible to execute the Optimisation requested.

JSON Attributes

Name Description

Result : identifier of the PSP (concatenation of

{"ProcessServicePlanID":”PM1_PI1_PSP1”,





153 / 227


5.4.3.1.6 Method “Find Matching Services for Process Step”

The RESTful interface “Find matching services for process step” (Table 96) provides a top-k ranked list of functionally optimal, i.e. semantically most relevant services that are available to implement a given process step. The semantic relevance computation is based on the hybrid semantic comparison of the sematic IOPE descriptions of process step and available services. Additionally, non-functional properties such as historical execution data can be considered.

Table 96: ODERU RESTful Interface – Find matching services for process step

the PMID and the PSP version) and the optimisation value achieved (only HTTP/200 result)

"Contraints": ["@length<19", "@used_energy<=155", "@used_ energy>59"],


Find matching services for process step

Description This function provides a search for candidate services to implement a specific process step. It returns a list of length k, ordered by descending fitness of IOPE annotation.

Request

Request URL GET http://crema.eu/oderu/Service/Matching/?session=userToken

Resource Parameters



User1234

HTTP Parameters


{

"ProcessServiceID": "PM1",

"ProcessTaksID": "PT1",


"Dim1": {"type": "MIN","parameter": "@X1"},

"Dim2": {"type": "MAX","parameter": "AVG(@Z)"}}],

"candidates_nr: "6",

"RequiredLevel": 65

}

Combined Example

GET /oderu/PI/Compose/?session=user1234 HTTP/1.1 Host: crema.eu object={"ProcessServiceID": "PM1", "ProcessTaksID": "PT1", "ObjectiveFunction": [{"Dim1": {"type": "MIN","parameter": "@X1"}, "Dim2": {"type": "MAX","parameter": "AVG(@Z)"}}], "candidates_nr: "6", "RequiredLevel": 65}





154 / 227


5.4.3.1.7 Method “Retrieve Service Plans for Process Model at Design Time”

The RESTful interface “Retrieve service plans for process model at design time” (Table 97) is devoted to return already computed optimal process service plans with their value of the objective function for a given process model ID.

Table 97: ODERU RESTful Interface – Retrieve Design Time Service Plans

Response

HTTP Status Code

Value Description

200 Matching found correctly executed, result(s) returned

204 Matching finished unsuccessfully, no possible process task available for the given process instance at the required level

400 Error due to deadline in the past



409 Error due to invalid Process Task ID


503 Storage layer not available, not possible to retrieve the Process Model from the ID.

520 Impossible to run the service matching requested.

JSON Attributes

Name Description

Result set: array of process service IDs with matching level

{"Result" : [{"ServiceID":"S1",

"fitness":87.50}, {"ServiceID":"S9",

"fitness":71}, …]}

Retrieve service plans for process model at design time

Description The function returns a top-k ranked list of existing process service plans for a given process model that were automatically or manually stored in the past in the CRI. The ranking bases on the optimisation criteria (functional, non-functional COPs). This function can be used to avoid unnecessary optimisation calls by the PDE.

Request

Request URL GET http://crema.eu/oderu/PM/Retrieve/?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the Process Model identification

{

"ProcessModel ID": "PM1"





155 / 227


5.4.3.1.8 Method “Retrieve Service Plans for Process Instance at Runtime”

The RESTful interface “Retrieve service plans for process instance at runtime” (Table 98) is devoted to return previous computed optimal service plans with their value of the objective function for a given process instance ID. This can be useful to support rapid consideration of already existing and pre-optimized plan.

Table 98: ODERU RESTful Interface – Retrieve Runtime Service Plans

}

Combined Example

GET /oderu/PM/Optimise/?session=user1234 HTTP/1.1 Host: crema.eu object={"ProcessModelID": "PM1"}

Response

HTTP Status Code

Value Description

200 Process Service Plans correctly retrieved, result returned

204 Retrieval finished, no previously optimised process service plan available for the given process model



503 Storage layer not available or not possible to retrieve the Process Model from the ID

520 Impossible to retrieve the requested Process Service Plans.

JSON Attributes

Name Description

Result set : array of PSPIDs (only HTTP/200 result)

{"Result" : [{"ProcessServicePlanID": "PM1_PSP1", "OptimisationValue":87.50}, {"ProcessServicePlanID":"PM1_PSP3", "OptimisationValue":79.335}, …]}

Retrieve service plans for process instance at runtime

Description The function returns a top-k ranked list of existing process service plans for a given process model instance that were automatically or manually stored in the past in the CRI. The ranking bases on the (functional, non-functional DCOPs). This function can be internally used to avoid unnecessary activities in optimisation (e.g. re-computing rank list of functionally optimal services, if service set did not change).

Request

Request URL GET http://crema.eu/oderu/PI/Retrieve/?session=userToken

Resource Parameters



User1234





156 / 227



For exchanging information and data, ODERU makes use of the JSON syntax, as for the rest of CREMA components. The definition of each single message format envisioned was already presented in the function using it. If necessary, the internal organisation of the fields included will be adapted in cooperation with the other interacting components before starting the development, and refined iteratively during the software implementation.


Due to the fact that the DLP component has no GUI foreseen in CREMA and those DLP functions are just used by CREMA components without restrictions, no authorisation definition is needed.

HTTP Parameters

object : object An object representing the Process Model identification

{

"ProcessInstanceID": "PM1_PI1"

}

Combined Example

GET /oderu/PI/Optimise/?session=user1234 HTTP/1.1 Host: crema.eu object={"ProcessInstanceID": "PM1_PI5"}

Response

HTTP Status Code

Value Description

200 Process Service Plans correctly retrieved, result returned

204 Retrieval finished, no previously optimised process service plan available for the given process instance



503 Storage layer not available or not possible to retrieve the Process Instance from the ID

520 Impossible to retrieve the requested Process Service Plan.

JSON Attributes

Name Description

Result set : array of PSPIDs (only HTTP/200 result)

{"Result" : [{"ProcessServicePlanID": "PM1_PSP1", "OptimisationValue":87.50}, {"ProcessServicePlanID":"PM1_PSP3", "OptimisationValue":79.335}, …]}





157 / 227


6 CREMA Cloud Manufacturing Process and Optimisation Framework Component

6.1 Marketplace and Monetisation

The MPM consists of two different tasks, which are represented in the architecture diagram shown in Figure 16. The marketplace is the central component to manage service related data. It provides access to the Service Registry that contains all metadata of the services, and additionally the Service Repository that contains the binaries to execute services. The monetisation part takes over the payment process after releasing services. It calculates the costs based on the information provided by the OSL component. To store all MPM related data, the CRI is used as a resource management system.


Since the MPM component is split into two different major parts, the technologies used in each part are encapsulated and described in own subsections.

6.1.1.1 Monetisation Environment

For the Monetisation part, the payment system FIPS is reused in this project. FIPS was originally developed by Ascora to handle customer payments in the field of end customer software products. Currently, it handles more than 2.3 million different user accounts and runs stable and reliable. FIPS is written in HTML, PHP and JavaScript and will be improved within the CREMA project.

6.1.1.2 Monetisation Provider

To have access to as much external payment providers as possible the Payone API58 is used to support different well-known payment providers. Among them are VISA59, MasterCard60, and Paypal61. Payone can be integrated as a Software-as-a-Service and is certified as a Payment Card Industry Data Security Standard. Besides the provision of security, Payone is flexible and configurable and always up-to-date, due to the fast and consistent development. Payone is already in use in FIPS (Section 6.1.1.1) and was always reliable.

6.1.1.3 Marketplace Environment

The Marketplace, which hosts the Service Repository and the Service Registry uses C# as the programming language. C# is an object-oriented programming language invented by Microsoft. It is intended to develop software components in distributed environments and is largely compatible with the CREMA goals to have multiple independent software components. Mostly C# is connected to windows-based programming. But since the

58 https://www.payone.de/en/ 59 https://www.visa.co.uk/ 60 http://www.mastercard.co.uk/index.html 61 https://www.paypal.com/uk/webapps/mpp/home





158 / 227


deployment server is Linux-based, Mono62 is used as a framework, which includes a .NET Framework-compatible set of tools. In contrast to the .NET Framework, Mono is able to run .NET applications cross-platform and is a free and open source project, which is currently led by Xamarin63 under the LGPLv2 License. The latest version of Mono supports the functionalities of the .NET4.5 framework, except the Windows Presentation Framework, which is for the Front-End and the Windows Communication Foundation, which allows to perform actions in the windows system environment. Both exceptions are not needed for this component, so the partial incompatibility does not impair the implementation of the MPM.

6.1.1.4 Resource Management

The MPM acts as a mediator to use services inside of the CREMA System. It hosts the Service Repository, Service Registry and the functionalities to execute CRUD operations on the services inside. The Service Registry hosts all service Meta data and is stored in a semi-structured database in the CRI. For leasing purposes the MPM refers to the location of the Proxy Service Wrapper in the binary storage of the CRI, called Service Repository. Since the CRI is chosen as a common storage in the CREMA system (defined in Section 0), the Service Repository and Service Registry are hosted in the CRI. As an emergency solution Docker Hub64 is used if the performance of the CRI is not sufficient. This must be decided in an early stage and therefore it is foreseen to make a Proof-of-Concept as soon as possible. Since Docker (see also Section 4.5 and 5.3.1.3) is also used in the project (CVA, SVA, OSL and PRU), Docker Hub represents a Service Registry to pull and push Docker images and enables the access via a RESTful interface.

6.1.1.5 REST Client

In order to enable a communication with RESTful interfaces, RestSharp65 is used for the Marketplace. RestSharp is a simple REST and HTTP API Client, which is compatible with the Mono environment and allows serialising and deserialising of XML and JSON automatically. If needed, it also handles custom serialisation via an ISerialiser and IDeserialiser interface. All standard HTTP methods, such as GET, POST, PUT, DELETE, HEAD, and OPTIONS are supported and other non-standard HTTP methods as well.


The MPM is able to reuse some elements from the FIPS system of Ascora. This means that the Monetisation part of the MPM is partially already existing and has to be updated for CREMA purposes. In contrast to the Monetisation, the Marketplace has to be built from scratch.

6.1.1.6.1 Calculation of costs

After a service is released by the OSL component, the usage information has to be evaluated to calculate the actual costs. Therefore the general service payment information must be

62 http://www.mono-project.com/ 63 https://xamarin.com/licensing 64 https://docs.docker.com/docker-hub/ 65 http://restsharp.org/





159 / 227


considered (see Listing 27). The calculation result must then be forwarded to the Monetisation of the MPM to proceed with the accounting.

6.1.1.6.2 Request Mediator

The Marketplace manages all accesses to any Service and Proxy Service Wrapper and forwards these requests to the CRI component. For this, the mediator has all information and permissions to perform CRUD operations in the CRI. Therefore flexibility and Scalability is a goal to be achieved. The performance of the mediator must stand a huge amount of requests and should therefore pass a stress test.

6.1.1.6.3 Internal Payment REST interface

The internal communication between the Marketplace part and the Monetisation part should be performed by using a RESTful interface. This RESTful interface is just used by the Marketplace part of the MPM and therefore not published for other CREMA components. This Internal Payment REST interface also encapsulates the business logic of the payment.


The architecture of the MPM has slightly changed in contrast to D3.1 and D3.2. One major change is the differentiation between the service description and the Proxy Service Wrapper. The service description (described in Section 4.5.4) is stored in the Service Registry and the Proxy Service Wrapper are stored in the Service Repository. Both are hosted in the CRI component. Service descriptions are retrieved directly from the Service Registry, but Proxy Service Wrapper requests respond with a reference to the accompanying Proxy Service Wrapper in the Service Repository. Furthermore the Service Controller was taken out, because the RESTful interface Service Repository API is requested instead, since it would have provided the same functionalities. The Configuration Storage was added to provide the marketplace with all access details to the CRI to request service definitions or Proxy Service Wrappers. Also the separation of the MPM into marketplace and monetisation parts are visualised more concretely in Figure 16. Both parts use different technologies and programming languages. Therefore the monetisation component gets an additional private RESTful interface, which is just intended to be used by the marketplace part of the MPM component.





160 / 227


Figure 16: MPM Architecture Diagram

To achieve the functionalities described in the last subsection, the MPM provide the following subcomponents as depicted in Figure 16.

• Marketplace UI: This UI is integrated into the DBV component and enables the user to discover and edit services. Estimated UIs can be viewed in (D3.2, Section 6.1.4).

• Configuration Storage: This subcomponent holds information to access the CRI to request data from the Service Repository and Service Registry

• Service Manager: This subcomponent provides the business logic to access and manage the Service Repository and Service Registry.

• Service API: This RESTful interface provides executing functionalities of the MPM to other CREMA components (SVA, PDE, OSL, ODERU and PCE).

• Trading Manager: This subcomponent calculates the costs by means after the information of the releasing request has arrived. It also calls the MPM internal RESTful interface of the monetisation part and transmits the necessary data to start the payment process.

• Payment API: This MPM internal RESTful interface enables the Trading Manager to transmit all relevant information to start the payment process.





161 / 227


• Payment Manager: This subcomponent is responsible for the payment and calls the external Monetisation Provider via the PayOne66 API and forwards accounting details to the Accounting subcomponent.

• Accounting: This subcomponent handles all paid processes and stores the accounting details in the CRI. Those details can also be requested to have an overview about consumed services.


One of the major design decisions of the CREMA project is to use RESTful interfaces as a common communication base between the CREMA components. In order to fit this decision the interface functions of the MPM are defined as RESTful interfaces. In order to describe the RESTful interfaces, each provided service is described in a separate table. This table is followed with a listing showing an example for the JSON parameter (if applicable) as well as an example for the return value (if applicable). In the following the term “user” indicates also components which will use this method/interface.

6.1.3.1 Method “Get Service”

The RESTful interface “Get Service” (Table 99), executes a get operation on an existing service. This method retrieves service of a specific service matching the query id.

Table 99: MPM RESTful Interface – CRUD-Operation Create

66 https://www.payone.de/en/platform-integration/interfaces/

Get Service by Id

Description This method retrieves a service based on an id from the Service Registry.

Request

Request URL GET http://crema.eu/mpm/services/serviceId?session=userToken

Resource Parameters


serviceId : string ID of the service 2983749AC234DF


User1234

Combined Example

GET /mpm/services/137?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Object retrieved successfully



JSON Attributes Service : Object A service object matching the query.





162 / 227


6.1.3.2 Method “Get Services”

The RESTful interface “Get Services” (Table 100) executes a get operation on all existing services. This method requests all existing services provided by the MPM and provides additionally a pagination functionality.

Table 100: MPM RESTful Interface – Get Services

Example: "Service": { "serviceID": "2983749AC234DF", "isDraft": "False", "concreteServiceID": "Service_0m5fx1g", "abstractServiceID": "null", "serviceName": "machining:Turning", "serviceDescription": {...}, "semanticAnnotation": {...}, "linkedConcepts":{...}, "serviceSchema":"../serviceSchema.xml", "serviceSoftware":"../2983749AC234DF.war", "payment":{...}, "schedule":{...}, "state": "blocked" }

Get Services

Description This method gets a list of all services from the Service Registry

Request

Request URL GET http://crema.eu/mpm/services?serviceType=serviceType& page=page&limit=limit&session=userToken

Resource Parameters

serviceType : String? Type of the service (concrete or abstract

concrete

page : int? Enables the user to use pagination

3

limit : int? Request a limited number of entities

50


User1234

Combined Example

GET /mpm/services?serviceType=concrete&page=3&limit=50&session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Services retrieved





163 / 227



JSON Attributes

Service : List A list of service objects. Example: { "metadata": { "page": 3, "limit": 50, "Links": [ { "previous":

/mpm/services?serviceType=concrete&page=2&limit=50&session=user1234",

"next": /mpm/services?serviceType=concrete&page=4&limit=50&session=user1234",

} ], "Services": [ { "serviceID": "2983749AC234DF", "isDraft": "False", "concreteServiceID": "Service_0m5fx1g", "abstractServiceID": "null", "serviceName": "machining:Turning", "serviceDescription": {...}, "semanticAnnotation": {...}, "linkedConcepts":{...}, "serviceSchema":"../serviceSchema.xml", "serviceSoftware":"../2983749AC234DF.war", "payment":{...}, "schedule":{...}, "state": "blocked" }, {…}, { "serviceID": "309485AC456DF", "isDraft": "false", "concreteServiceID": "Service_0m52rg9", "abstractServiceID": "null", "serviceName": "machining:Lifting", "serviceDescription": {...}, "semanticAnnotation": {...}, "linkedConcepts":{...}, "serviceSchema":"../serviceSchema.xml", "serviceSoftware":"../309485AC456DF.war", "payment":{...}, "schedule":{...}, "state": "available" }]





164 / 227


6.1.3.3 Method “Create Service”

The RESTful interface “Create Service” (Table 101) creates a new service in the Service Registry.

Table 101: MPM RESTful Interface – Create Service

Create Service

Description Creates a new service in the MPM.

Request

Request URL POST http://crema.eu/mpm/services?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing an object of the specified service

{ "serviceID":

"309485AC456DF", "isDraft": "false", "concreteServiceID":

"Service_0m52rg9", "abstractServiceID":

"null", "serviceName":

"machining:Lifting" "serviceDescription":

{...}, "semanticAnnotation":

{...}, "linkedConcepts":{...

}, "serviceSchema":"../s

erviceSchema.xml", "serviceSoftware":"..

/309485AC456DF.war", "payment":{...},

"schedule":{...}, "state": "available" }

Combined Example

POST /mpm/services?session=user1234 HTTP/1.1 Host: crema.eu object={"serviceID":"309485AC456DF", "isDraft":"false", "concreteServiceID":"Service_0m52rg9", "abstractServiceID":"null",

"serviceName":"machining:Lifting", "serviceDescription": {...}, "semanticAnnotation": {...}, "linkedConcepts":{...},

"serviceSchema":"../serviceSchema.xml", "serviceSoftware":"../309485AC456DF.war", "payment":{...}, "schedule":{...}, "state": "available"}

Response

HTTP Status Code

Value Description

201 Service created





165 / 227


6.1.3.4 Method “Update Service”

The RESTful interface “Update Service” (Table 102) executes an update operation on an existing service. This method updates the found service with the query object.

Table 102: MPM RESTful Interface – Update Service

402 HTTP Body contains errors

409 Service with this Id exists already

502 Service is not created

Update Service

Description This method updates an existing service inside of the Service Registry. A specific data object can be chosen by providing a service id as a parameter.

Request

Request URL PUT http://crema.eu/mpm/services/serviceId?session=userToken

Resource Parameters


serviceId : string ID of the service 132


User1234

HTTP Parameters

object : object An object representing an object of the specified data type with attributes set, which will be updated in the data objects found with the query.

{ "serviceID":

"309485AC456DF", "isDraft": "false", "concreteServiceID":

"Service_0m52rg9", "abstractServiceID":

"null", "serviceName":

"machining:Lifting" "serviceDescription":

{...}, "semanticAnnotation":

{...}, "linkedConcepts":{...

}, "serviceSchema":"../s

erviceSchema.xml", "serviceSoftware":"..

/309485AC456DF.war", "payment":{...},

"schedule":{...}, "state": "available"

}

Combined Example

PUT /mpm/services/132?session=User1234 HTTP/1.1 Host: crema.eu object= {"serviceID":"309485AC456DF", "isDraft":"false", "concreteServiceID":"Service_0m52rg9", "abstractServiceID":"null",





166 / 227


6.1.3.5 Method “Delete Service”

The RESTful Interface “Delete Service” (Table 103) deletes a specific service from the Service Registry.

Table 103: MPM RESTful Interface – Delete Service

6.1.3.6 Method “Create Proxy Service Wrapper”

The RESTful interface “Create Proxy Service Wrapper” (depicted in Table 104) executes a create operation to upload an existing Docker image of a service into the Service Repository.

"serviceName":"machining:Lifting", "serviceDescription":{...}, "semanticAnnotation":{...}, "linkedConcepts":{...}, "serviceSchema":"../serviceSchema.xml", "serviceSoftware":"../309485AC456DF.war", "payment":{...}, "schedule":{...}, "state":"available"}

Response

HTTP Status Code

Value Description

201 Service is updated

400 Request could not be understood



Delete Service

Description Deletes a specific Service from the Service Repository.

Request

Request URL DELETE http://crema.eu/mpm/services/serviceId?session=userToken

Resource Parameters

Name / Type Description Example

serviceId : string ID of the Service testID2

userToken : string The user token propagated through all requests.

User1234

Combined Example

DELETE /mpm/services/testID2?session=User1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Service deleted







167 / 227


Table 104: MPM RESTful Interface – Create Proxy Service Wrapper

6.1.3.7 Method “Lease Service”

The RESTful interface “Lease Service” (Table 105) executes a get operation on an existing Proxy Service Wrapper object. This object contains metadata about the Proxy Service Wrapper, which includes all necessary information to get the executable binary directly from the CRI to execute it afterwards.

Table 105: MPM RESTful Interface – Lease Services

Create Proxy Service Wrapper

Description This method uploads a Docker image into the Service Registry

Request

Request URL POST http://crema.eu/mpm/proxyservicewrapper?session=userToken

Request Parameters


User1234

HTTP Parameters

Object : object The file to be uploaded to the Service Registry

{

“ServiceRefId”:”1284”, "filepath":”../test.exe", "mime_type":"application/octet-stream"

}

Combined Example

POST /mpm/proxyservicewrapper?session=user1234 HTTP/1.1 Host: crema.eu

object = {“ServiceRefId”:”1284”, "filepath":”../test.exe", "mime_type":"application/octet-stream"}

Response

HTTP Status Code

Value Description

201 Proxy Service Wrapper created


402 Payload is missing / not applicable

Lease Services

Description This method gets Proxy Service Wrapper meta information based on a service Id from the Service Repository.

Request

Request URL GET http://crema.eu/mpm/proxyservicewrapper/serviceId?session=userToken






168 / 227


6.1.3.8 Method “Release Service”

The RESTful interface “Release Service” (Table 1060) executes a post operation to release a leased service, which continues to start the payment process.

Table 106: MPM RESTful Interface – Release Services

Resource Parameters


User1234

Combined Example

GET /mpm/proxyservicewrapper/137?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Proxy Service Wrapper has been retrieved



JSON Attributes

Service : List A list of service objects. Example: { "MetaProxyServiceWrapper": { "ServiceId": "137", "ServiceRef": "mpm/services/137?session=user1234", "BucketRefId": 3, "objectId": 50, "ServiceProxyWrapperRef":

"/cri/bucket/3/50?session=userToken" } }

Release Services

Description This method gets release Proxy Service Wrapper meta information based on a service Id from the Service Repository.

Request

Request URL POST http://crema.eu/mpm/services/serviceId/released?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : Object The service to be released including payment information

{

“UserId”:”2083749837”, “processId”:”283ASD28”, “usagetime”:”5”





169 / 227


6.1.3.9 Method “Delete Proxy Service Wrapper”

The RESTful interface “Delete Proxy Service Wrapper” (Table 107) executes a delete operation to remove a Proxy Service Wrapper binary from the Service Repository.

Table 107: MPM RESTful Interface – Delete Proxy Service Wrapper

6.1.3.10 Method “Get Service Schedule”

The RESTful interface “Get Service Schedule” (Table 108) executes a get operation on an existing service schedule. This method retrieves a complete schedule from a specified service matching the query id.

}

Combined Example

POST /mpm/services/137/released?session=user1234 HTTP/1.1 Host: crema.eu object={“UserId”:”2083749837”, “processId”:”283ASD28”, “usagetime”:”5”}

Response

HTTP Status Code

Value Description

201 Release Information created



Delete Proxy Service Wrapper

Description This method deletes a specific Docker image from the Service Repository.

Request

Request URL DELETE http://crema.eu/mpm/proxyservicewrapper/wrapperId?session=userToken

Resource Parameters

wrapperId : string ID of the Proxy Service Wrapper

8238


User1234

Combined Example

DELETE /mpm/proxyservicewrapper/8238?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 File successful deleted







170 / 227


Table 108: MPM RESTful Interface – Get Service Schedule

Get Service Schedule

Description This method gets a service schedule based on a Service Id. By using the parameter “uid” it is possible to filter schedules for a defined schedule owner. The uid represents either a component, which scheduled a service or a process to which the service belongs.

Request

Request URL GET http://crema.eu/mpm/services/serviceId/schedule?uid=uid&session=userToken

Resource Parameters



uid : string? ID of the schedule entry owner (CREMA Component / Process)

19400


User1234

Combined Example

GET /mpm/services/137/schedule?uid=19400&session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Service schedule retrieved successfully



JSON Attributes Service Schedule : Object

A service object matching the query. Example: "ServiceSchedule": [ { "uid": "19400", "appointment": {"start": " 1446628200000", "end": " 1446631800000"} },{…} { "uid": "19400", "appointment": {"start": "1446562800000", "end": "1446564600000"} }] ]





171 / 227


6.1.3.11 Method “Schedule Service”

The RESTful interface “Schedule Service” (Table 109) executes a post operation on an existing service to add an appointment to the service schedule.

Table 109: MPM RESTful Interface – Create Service Schedule

6.1.3.12 Method “Update Service Schedule”

The RESTful interface “Update Service Schedule” (Table 110) executes a put operation on an existing service to update an appointment on its service schedule.

Create Service Schedule

Description This method creates an appointment on a service schedule based on a service Id.

Request

Request URL POST http://crema.eu/mpm/services/serviceId/schedule?session=userToken

Resource Parameters




User1234

HTTP Parameters

object : Object The Appointment to be added to the Service Schedule

{

"appointmentId": "28937", "processId":"19400", appointment": {appointmentId:"start": "1446628200000", "end": "1446631800000" }

Combined Example

POST /mpm/services/137/schedule?session=user1234 HTTP/1.1 Host: crema.eu object= {"appointmentId": "28937","processId":"19400", appointment": {"start": "1446628200000", "end": "1446631800000"}

Response

HTTP Status Code

Value Description

201 Appointment created successfully


402 Post Object is missing or not complete






172 / 227


Table 110: MPM RESTful Interface – Update Service Schedule

6.1.3.13 Method “Delete Appointment from Service Schedule”

The RESTful interface “Delete Appointment from Service” (Table 111) executes a delete operation on an existing appointment in the service schedule.

Table 111: MPM RESTful Interface – Delete Appointment from Service Schedule

Update Service Schedule

Description This method updates an appointment on the service schedule based on a service Id from the Service Registry. By using the request parameter “uid” it is possible to update schedules for a defined schedule owner. The uid represents either a component, which scheduled a service or a process which the service belongs to.

Request

Request URL PUT http://crema.eu/mpm/services/serviceId/schedule/scheduleEntryId?session=userToken

Resource Parameters



uid : string ID of the schedule owner 19400


User1234

HTTP Parameters

object : Object The Appointment to be added to the Service Schedule

{"appointmentId":"2892", "processId": "29", appointment": {"start": "…", "end": "…"}

Combined Example

PUT /mpm/services/137/schedule/29?session=user1234 HTTP/1.1 Host: crema.eu object= {"appointmentId":"2892", "processId": "19400",

appointment":{"start":"1446628200000", "end":"1446630000000"}

Response

HTTP Status Code

Value Description

201 Appointment updated successfully


404 Service or Schedule not found

Delete Service Schedule

Description This method deletes an appointment from a service schedule based on a service Id from the Service Registry.

Request





173 / 227


6.1.3.14 Method “Clear Service Schedule”

The RESTful interface “Clear Service Schedule” (Table 112) executes a delete operation on a service’s schedule.

Table 112: MPM RESTful Interface – Clear Service Schedule

Request URL DELETE http://crema.eu/mpm/services/serviceId/schedule/appointmentId?session=userToken

Resource Parameters



appointmentId : string ID of an appointment in the schedule

29


User1234

Combined Example

DELETE /mpm/services/137/schedule/29?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Appointment deleted successfully


404 Service or Schedule not found

Clear Service Schedule

Description This method deletes all appointments on a service schedule.

Request

Request URL DELETE http://crema.eu/mpm/services/serviceId/schedule?session=userToken

Resource Parameters




User1234

Combined Example

DELETE /mpm/services/137/schedule?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Schedule cleared successfully





174 / 227



The service itself is depicted in Section 4.5.4, but some parts of the service scheme are MPM relevant for calculation of costs and collision detection for scheduling services. For scheduling services, every service includes its own schedule scheme, which contains appointments with the following attributes:

• AppointmentId: Identifies the entry inside of a schedule • ProcessId: Identifies the scheduling consumer; where a consumer is a process • Start: The starting time for the service reservation • End: The ending time for the service reservation

The Listing below shows an example of the complete service schedule scheme, which is integrated into the service scheme.

Listing 26: Service Schedule Scheme Example

For the monetisation part of the MPM, a payment scheme is added to the service scheme which contains pre-defined information, such as costs, currency and the payment type, but also the “usage” attribute which has to be filled out by the OSL component in order to calculate the actual costs of the leasing process. After executing this process, the monetisation part is able to create accountings and notify the consumer about the payment for the service usage. The payment scheme is composed of the following attributes:

• consumerId: The responsible user which have leased and released the service • payPer: Defines the accounting interval for the payment. e.g. pay per use, pay per

hour or another thinkable intervals • costs: the defined costs of each accounting interval • currency: The currency of the money, such as euro, pound or dollar • usage: the amount of accounting intervals to calculate the actual costs of the

leasing process The Listing 30 shows an example of the complete service payment scheme, which is integrated into the service scheme.



416 Schedule was already empty

{ "appointmentId": "178", "processId": "29834", "start":"110792384729347", "end":"110792384730347” }





175 / 227


Listing 27: Service Payment information Example


The MPM manages service metadata and Proxy Service Wrappers in the Service Registry and Repositories, whose data is hosted by the CRI. Therefore, the CRI is in charge of the data restriction of each user. But the MPM is in charge for authorising operation execution for users. The following permissions describe the abilities, which the user is able to perform.

• Read Access: CREMA components and users are granted to retrieve service metadata and their related Proxy Service Wrapper from the Service Repository and Registry. Also the accounting data can be requested with this permission level.

• Write Access: This permission model inherits the permission from “Read Access” and extends it with permission concerning the update, creation and deletion of services. Accounting data are not affected with this permission level, because those are just readable.

The following Listing shows an example of how a response from the SPC component could be. It uses the predefined permission models to set the rights for each user. Additionally, a scope is defined, which ensures a detailed accessibility. Possible scopes can be CREMA to access the whole system, or company to access data associated to the given company, or a more detailed approach is to restrict the access for defined objects referring to an id.

Listing 28: MPM Example Authorisation Definition

{ "consumerId": "29834", "payPer":"use", "costs": "250”, “currency”: “euro”, “usage”: “1” }

{ "userId": "597134" "user": "Charles", "company": "CREMA", "authorisation": { "services": { "level": "User", "scope": "Company" }, "schedules": { "level": "User", "scope": "Company" }, "invoices": { "level": "User", "scope": "Company" } } }





176 / 227


6.2 Monitoring & Alerting

The Monitoring and Alerting (MON) is the key component to manage and monitor business rules and KPIs according to running process instances. These business rules may combine historic and streamed live process data (e.g. what is gathered from CPS services), user-introduced KPIs, forecasted KPIs by the BDA component and process instance-related data from PRU (e.g. process instance ID, process instance status, or current running task). Therefore, the MON component takes over the supervision of the user-defined business rules and the generation of alarms in case of KPI deviation from pre-defined target values. To support these functionalities, the MON provides a Rules UI and Rule Engine in order to enable developers defining different business rules, attaching them to process instances and then monitoring their status. Hence, if a KPI threshold is exceeded, the MON alerts the user about such event and notifies the PRU component to start the process instance optimisation if necessary.


In MON, a business rule should contain rule's conditions that must be evaluated to trigger a particular rule and actions that should be performed when rule's conditions are satisfied. To satisfy these expectations, the following technical decisions are taken.

6.2.1.1 Selection for Business Rule Definition Language

Business rules definition are UI-guided, so the user is able to graphically define business rules within the Rules UI. Such definitions map to a general-purpose specification that are managed by the Monitoring and Alerting API and interpreted by the Rule Engine. A business rule definition contains two main parts: an evaluate section, which encapsulates conditions that must evaluate to TRUE to trigger the rule, and an execute method, which encapsulates actions that should be performed when rule's conditions are satisfied (see code snippet below).

Listing 29: Business Rule Definition Interface and Example

public interface Rule { /** * This method encapsulates the rule's conditions. * @return true if the rule should be applied, false else */ boolean evaluate(); /** * This method encapsulates the rule's actions. * @throws Exception thrown if an exception occurs * during actions performing */ void execute() throws Exception; }





177 / 227


6.2.1.2 Selection for Rule Engine

A Java-based rule engine, called EasyRules67, was selected to execute and hold rules. It boasts the following key features:

• It is a lightweight library and has an easy to learn API.

• It offers a POJO based development with an annotation-based programming model, abstractions to define business rules, composite rules support, and a dynamic rule configuration support at runtime.

EasyRules is an extensible and configurable engine (e.g. it can be integrated with the Spring Framework68), which will be customised for CREMA functionalities, i.e., during the rule conditions definition CREMA could include stream data or even consider historic data.

6.2.1.3 Selection for Business Rule and KPI Storage

The CRI component is used to store business rules and KPIs. To enable interactions with the MON component, the CRI provides REST interfaces. JSON is used as a content type for input and output of different buckets, which is used to store business rules and KPIs.

6.2.1.4 Selection for Monitoring and Alerting API Implementation

The MON component offers an internal API, including necessary methods for business rules and KPI creation and management, alarm querying and process instance status checking. MON exposes this API as a RESTful API with the associated API documentation. The decision behind RESTful is that it is an architectural style for network hypermedia applications that has turned as a de-facto standard for web applications interoperability. Beyond SOAP services, it is primarily used to build web services that are lightweight, maintainable, and scalable.

6.2.1.5 Selection for Rules UI (Integrated with DBA)

Rules UI is integrated with the dashboard component so it is offered as a part of the dashboard itself. The web technologies HTML/CSS/JavaScript were selected in order to develop the Rules UI from scratch. It makes use of the Monitoring and Alerting API to access and manage business rules and KPIs, but also to present generated alarms and process instance status for different users.


Although MON is based on EasyRules, the existing features are optimised to meet the implementation needs in CREMA and the following features will be developed:

• A custom business rule definition language: It is envisioned to create a custom business rule definition language based on forward-chaining rules (e.g., production/inference rules) that is interpreted by the EasyRules engine. The most basic element of a business rule is the language used to express it. This business rules definition language allows to define a business rule considering the following

67 http://www.easyrules.org/ 68 http://spring.io/





178 / 227


information: stream data (via PRU) where the user is able to select which stream and variables should be included within the business rule definition, historic data from the CRI component, precalculated KPIs querying BDA component, user-defined KPIs and process instance status data via PRU

• Wrappers to connect PRU, CRI, BDA, and PRU: The MON may need access to all these CREMA components within business rule definition, so these wrappers are developed to integrate public interfaces. If a particular wrapper is down for a given time, the user is not able to select this wrapper so it discriminates associated data. For example, if PRU wrapper is down the user is not able to select stream data and variables within business rule definition

• Alarms categorisation: Considering user partners’ needs, process instance alarm categorisation, classification and prioritisation should be defined including for instance: alarm type, category, priority, scope, etc. Using such categorisation makes it possible to create different types of alarms for different use cases in MON


The diagram in Figure 17 shows the structure that has been updated to reflect the technology selection. In comparison to the Functional Specification (T3.2, D3.2) the subcomponents have slightly changed in order to fit the technology selection and show the implementation details.

• Since MON is integrated within Dashboard, the arrow from Dashboard to MON was removed. This means that the Rule Engine stores alarms in the CRI component and notifies the Rules UI in parallel.

• Some labels are changed in terms of defining technologies to be used. These technology-defining labels concretise the architecture diagram that allows developers and users to see at a glance where that technology is used.





179 / 227


<<interface>>Monitoring and

Alerting API

Data Service



<userinterface>RulesUI

use


requestexecprocess

instanceoptimisationnotifyalarm

gethistoricaldata

getprocessdata


Analytics(BDA)

CREMAMonitoringandAlerting(MON)

calculateKPI

<<interface>>Access to

Process Data

<<interface>>Access to KPIs

pushprocessdata

calculateKPI

<<interface>>Optimisation API

<<interface>>Dashboard API

execoptimisation

notifyalarm


Historical Data

gethistoricaldata

getprocessdata

getKPI

CRUDrules

CRUDrules/KPI

requestprocessdata/KPIinfo processdata/KPIs

processdata KPI

KPI

historicaldatahistoricaldata

ackack

ack

rules/KPI

processdata KPI

rules/KPIuse

processdata


Infrastructure(CRI)

HistoricData

Rules&KPIs

rules/KPI


Rules and KPIsCRUDrules/KPI

rules/KPI

Rule Engine Service

(EasyRules)

Figure 17: MON Architecture Diagram To achieve the functionalities described in the last subsection, the MON provides the following subcomponents as depicted in the figure above.

• Monitoring and Alerting API (RESTful): This subcomponent offers the business rule CRUD interfaces and alarm interfaces (as REST API). The latter is offered as a public interface in order to allow external components to create and query different alarms, if required. This API acts as a gateway API for the Rules UI to access MON backend resources and data

• Process Data/KPI Access (Data Service): This subcomponent provides the interface between the MON and external components like PRU and CRI. This includes access for all queries and CRUD operations. In addition, it enables MON-BDA interaction in order to enable MON running queries on BDA component

• Business Rule and Alarm Monitoring (Rule Engine Service): This subcomponent supervises active business rules. It is the actual programming code that enforces the rules. It interprets all business rule conditions and trigger actions when the KPI thresholds are exceeded

• Business Rule Editor and Alarm Management (Rules UI): This subcomponent offers a UI so different users can define and manage business rules and check for alarms. Through this user interface, CREMA users are able to define, design, document and edit business rules. Moreover, Rules UI enables users to activate/deactivate concrete business rules and trigger process optimisation. The





180 / 227


latter is done via the "Alarms" tab where users can check alarms and click for process instantiation


The MON component offers two public interfaces and includes other private interfaces following RESTful principles and Functional Specification document to connect Rules UI.


In order to describe the RESTful interface, each provided service is described in a separate table. This table is followed with a listing showing an example for the JSON parameter (if applicable) as well as an example for the return value (if applicable).

6.2.3.1.1 Method “Create Alarm”

The RESTful interface “Create Alarm” (Table 113), creates a new Alarm for the process instance in MON. This public interface can be invoked via PRU to indicate process instance-specific alarms.

Table 113: MON RESTful Interface – Create Alarm

Create Alarm

Description Creates a new Alarm for the process instance.

Request

Request URL POST http://crema.eu/mon/alarms?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : Object The alarm request body which l includes a number of attributes.

{ "name": "My Alarm", "priority": "High", "category": "Cat_A", process_instance_id": "12300" }

Combined Example

POST /mon/alarms?session=user1234 HTTP/1.1 Host: crema.eu

object = {"name": "My Alarm","priority": "High","category": "Cat_A", process_instance_id": "12300"}

Response

HTTP Status Code

Value Description

201 Alarm created

409 Alarm exists already





181 / 227


6.2.3.1.2 Method “List all Alarms”

The RESTful interface “List all Alarms” (Table 114), retrieves all alarms for a process instance. A process instance is unique in the context of the PRU, which created it.

Table 114: MON RESTful Interface – List all Alarms


JSON is used as the structure of the common MON internal API objects for the communication with Rules UI via the RESTful interfaces.

5xx MON backend error

List all Alarms

Description Gets a list of all alarms for a specific process instance.

Request

Request URL GET http://crema.eu/mon/alarms/p_instance_id?session=userToken

Resource Parameters


p_instance_id : string ID of the process instance. 12300


User1234

Combined Example

GET /mon/alarms/12300?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 OK

404 Not found

5xx MON backend error

JSON Attributes

AlarmList : List<Object> {"Alarms": [ {

"name": "My Alarm", "priority": "High", "category": "Cat_A", process_instance_id": "12300" },{ "name": "My Alarm 2", "priority": "High", "category": "Cat_B", process_instance_id": "12300" }]}





182 / 227



The MON component has a "Monitoring and Alerting API" which exposes different resources (business rules, alarms, KPIs and process data). Therefore, it is necessary to set permissions for different API resources, so not only the Rules UI users but also third-party applications may access MON. The Rules UI lists all business rules from the CRI component and enables users to CRUD them. Different permission models limit the visibility of Rules UI resources and interactions options. To execute an action, the user needs to have a corresponding role. The following roles and token-based authentication restrict users for different kinds of tasks in the Rules UI. The following list contains the roles and authorisation mechanisms for MON:

• ROLE_USER: Users can only query existing business rules and generated alarms by the Rule Service (Engine).

• ROLE_ADMIN: Apart from user operations, administrators can create, update and remove business rules.

All API resources are authenticated by the SPC component. Therefore, each API request must include an authentication header, including an access token. An Example of a SPC response is shown below.

Listing 30: MON Example Authorisation Definition

6.3 Manufacturing Big Data, Knowledge and Analytics

The Manufacturing Big Data, Knowledge and Analytics (BDA) component enables the extraction of hidden values and business intelligence from the process and sensor data gathered in the manufacturing domain. The BDA component stores data from heterogeneous sources (such as manufacturing processes, CPS and sensor data) to allow users (human and CREMA components) to perform different types of analytic operations on the stored data. The BDA serves two types of users using a set of dedicated interfaces; the human users can submit queries and get their results by virtue of a UI embedded in the DBV, whereas other CREMA components can request analytics information from the BDA using dedicated REST interfaces. The information extracted from BDA can help better redesign or optimise the processes and take operational decisions that can improve the efficiency of processes in the manufacturing domain.


The BDA provides simultaneous access to different CREMA components and offers predefined analytic functionalities to satisfy the requirements of CREMA use-cases. For all these access details analytic options and technology decisions are described in the following sections.

{ "userId": "597134" "user": "Charles", "company": "CREMA", "authorisation": { "permission": "ROLE_ADMIN" } }





183 / 227


6.3.1.1 Selection of Base Platform

The base of the BDA component is the Talend Open Studio for Big Data69, an open source platform that enables combining big data technologies into a unified open source environment. The embedded UI and toolset in Talend Open Studio for Big Data simplifies the loading, extraction, transformation and processing of large and diverse data sets, thus enabling users to make timely decisions based on the available data. In essence, Talend Open Studio for Big Data operates as a code generator, allowing users to perform complex data operations using an intuitive interface and producing underlying programs and functions in Java that can be integrated with other Java modules in a seamless fashion. The selection of Talend platform not only aims to reuse open source technologies, it also allows for more efforts to be invested in the extension of the technology and development of specific functionalities that can address the user needs in the CREMA project.

6.3.1.2 Selection of Data Analytic Framework

The BDA provides different types of ETL (Extract, Transform and Load) and data analytics functionalities to address the varying needs of CREMA use cases. These functionalities range from simple (query style) data extraction to extracting the insight from multi-dimensional datasets (or OLAP operations). In BDA the general functionality for data extraction and processing will be implemented in Java. Spark SQL70 will be used for stream processing. It allows querying structured data inside Spark programs, using the familiar SQL syntax. More sophisticated OLAP operations will be realised by employing Jedox Palo MOLAP Server71, an open source memory resident multidimensional OLAP database server and business intelligence tool. Palo can be used within Talend Open Studio, which offers a set of components to manage Palo cubes (multi-dimensional dataset) and perform complex ETL processing. The integration of Palo in Talend Open Studio makes possible complex data integration procedures to build reliable Palo OLAP cubes within Talend Open Studio that can be stored as Java methods. Such methods can be exported as components, allowing for their reuse and integration with other components.

6.3.1.3 Selection of Data Storage

An important subcomponent of BDA is the data warehouse (DWH) subcomponent. For the implementation of the DWH, MongoDB72 has been selected as semi-structured data storage. The selection of MongoDB will ease the interoperability and data handling issues that may arise during BDA and CRI interactions, since MongoDB is also selected as data storage solution for CRI.

6.3.1.4 Selection of Stream Processing Technology

An important functionality envisioned from BDA component is to store and process data from running processes and sensors. BDA uses Apache ActiveMQ73 message broker to access data streams from PRU and employs Apache Spark Streaming API to processing 69 http://www.talend.com/download/talend-open-studio 70 http://spark.apache.org/ 71 http://sourceforge.net/projects/palo/ 72 https://www.mongodb.org/ 73 http://activemq.apache.org/





184 / 227


streaming data. Apache Spark Streaming74 is a free and open source distributed real-time computing framework enabling reliable processing of unbounded streams of data. Spark Streaming can be used with many programming languages (e.g. Java, Scala and Python) and enables real-time analytics, online machine learning, continuous computation and distributed ETL as well. Spark Streaming is easy to set up and can be integrated with available databases and information processing technologies.

6.3.1.5 Selection of Visualisation

To address the need for visualising the outcomes of data analytics, particularly for the human users, the BDA component offers the Visualisation subcomponent that transforms the data analytic results to user friendly visualisations. The Visualisation subcomponent uses a combination of Java and JFreeChart75 API to display high quality charts incorporated within CREMA dashboard. JFreeChart is a free chart library that supports flexible design and a wide range of chart types. The output of JFreeChart API include Swing, JavaFX components, image files (e.g. PNG, JPEG) and vector graphics formats (e.g. PDF, EPS and SVG).


As the BDA interacts with other CREMA components, it needs to implement the security framework provided by the SPC. In this aspect, the following features will be developed to conform to the security principles adopted in CREMA:

• Security Layer: The BDA has to be adapted to fulfil the special authorisation role (described in D3.2, Section 4.3.6). The first security level is to check if the user (CREMA component or human user) is already authenticated before they are able to perform any query building and execution operation. The second security level is performed after the request is executed and the results are prepared to be returned. At that level, the users’ authorisation to access the retrieved data (or results of the submitted request) gets checked and data entries which the user is not authorised to read are filtered from the response items.


The BDA component contains a number of subcomponents that deliver specific functionalities and interact with each other as described in deliverable D3.2. The figure below shows the technologies that have been selected to realise the functionalities envisioned in the functional specifications.

74 http://spark.apache.org/streaming/ 75 http://www.jfree.org/jfreechart/





185 / 227


Figure 18: BDA Architecture Diagram





186 / 227



Based on the design decision (for the CREMA project) to use RESTful interfaces as a common communication base for the CREMA components, the following features of the BDA are defined as RESTful interfaces.


This section describes each BDA RESTful interface in a separate table. This table is followed with a listing showing an example for the JSON parameter (if applicable) as well as an example for the return value (if applicable). In the following subsections the term “user” is referred to CREMA components that uses this method/interface.

6.3.3.1.1 Method “Invoke Built Query”

This RESTful interface “Invoke Built Query” (Table 115) requests BDA to execute a specific built query, identified by a ‘queryId’. Upon receiving the request, BDA will retrieve the query from CRI and execute it. The successful query execution will result in the data extraction and analytic operations on a particular dataset. The result of the query execution will be returned as a response.

Table 115: BDA RESTful Interface – Invoke Built Query

Invoke Built Query

Description This method invokes a predefined built query based on a queryId

Request

Request URL GET http://crema.eu/bda/invoke/queryId?session=userToken

Resource Parameters


queryId : string ID of the Query queryId=averagePressureSensorTemp


User1234

Response

HTTP Status Code

Value Description

200 OK, Query found


502 Database error

JSON Attributes

Result set Sample Result of the query execution [ { "sensor": "PressureSensor", "averageTemperature": "TestValyue” }





187 / 227


6.3.3.1.2 Method “Start Listening to Streaming Data”

The RESTful interface “Start Listening to Streaming Process Data” (Table 116), informs BDA that process data is now available for streaming.

Table 116: BDA RESTful Interface – Start Listening to Streaming Data

6.3.3.1.3 Method “Stop Listening to Streaming Data”

The RESTful interface “Stop Listening to Streaming Process Data” (Table 117), informs BDA that process data is no longer available for streaming, hence the stream is being terminated.

Table 117: BDA RESTful Interface – Stop Streaming Data

]

Start Listening to Streaming Process Data

Description This method notifies the BDA that PRU is ready to push streaming data about a specific topic from a certain port/IP-address. The topic and source address (e.g. IP or Port) allows BDA to identify the nature of data and relevant operations that should be performed on the data.

Request

Request URL PUT http://crema.eu/bda/streaming/start/streamId?session=userToken

Resource Parameters

Name Description

streamId : string ID of the incoming streaming

streamId=stream1234

userToken : string

The token propagated through all requests

User1234

HTTP Parameters

object : object An object representing the topic of the streaming data and the address/IP of the data source

{"topic": "myTopic",

"port" : "http://195.235.97.154"}

Example PUT /bda/streaming/start/stream1234?session=userToken HTTP/1.1 Host: crema.eu object {“topic”:”myTopic”, "port":"http://195.235.97.154"}

Response

HTTP Status Code

Value Description

200 OK, BDA status updated

204 BDA status not updated


Stop Listening to Streaming Process Data





188 / 227


6.3.3.1.4 Method “Push Process Data”

The RESTful interface “Push Process Data” (Table 118), informs BDA that a specific dataset containing process data needs to be stored in the DWH.

Table 118: BDA RESTful Interface – Push Process Data

Description This method notifies the BDA that PRU is terminating streaming data about a specific topic from a certain port/IP-address. The topic and source address (e.g. IP or Port) allows BDA to identify the data stream.

Request

Request URL PUT http://crema.eu/bda/streaming/stop/streamId?session=userToken

Resource Parameters

Name Description

streamId : string ID of the incoming streaming streamId=stream1234

userToken : string

The token propagated through all requests

User1234

Example PUT /bda/streaming/start/stream1234?session=userToken HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description




Access to Process Data: Push Process Data from PRU

Description This method notifies the BDA that PRU is pushing data about a specific process and that data should be stored in the DWH.

Request

Request URL PUT http://crema.eu/bda/process/?session=userToken

Resource Parameters

Name Description


User1234

HTTP Parameter

object : object JSon object representing the process data

{

"pid": "19400", “status": {"start": "1446628200000", "end": "1446631800000" }





189 / 227


6.3.3.2 Java Interfaces

The Java interfaces act as wrappers for the RESTful interfaces and also enable BDA to interact with other CREMA components.

6.3.3.2.1 Java Method “Invoke Built Query”

For invoking a built query, the BDA API provides the method “invokeQuery”. This method has a predefined ID that uniquely identifies a specific Query in the CRI. The following listing shows the signature of the method along with an example for its usage.

Listing 31: API Method Signature for Invoking a Built Query

The example usage of the method at the bottom of Listing 22 executes a built query represented by ‘query’ String, which has been previously retrieved from the CRI based on constant ‘queryId’. If the API call is successful a resulting object will be returned.


This section lists JSON examples which shows the structure of the common BDA objects for the communication with other components via the RESTful interfaces. The Listing below shows an example for invoking a built query. If a user wants to execute a built query, the user has to use the “Invoke Built Query” method either from the RESTful interface (Section 6.3.3.1.1) or the Java API (Section 6.3.3.2.1). As an example a result can be seen in the Listing below. It shows the queryId which is automatically given when the user designs the query and stores it in the CRI.

Example PUT /bda/streaming/stop?session=userToken HTTP/1.1 Host: crema.eu object {"pid": "19400", “status": {"start": "1446628200000", "end": "1446631800000”}

Response

HTTP Status Code

Value Description




/** * @param queryId, a predefined ID for a specific query stored in CRI. * @return resultset */ public invokeQuery(String queryId) //Retrieves a built query from a specific bucket in CRI String query = api.executeQuery (BUCKET_TEST_ID, queryId); //Execute a predefined built query with the id Query_ID ArrayList result = new ArrayList(); result = BDA.invokeQuery(Query_STRING, query);





190 / 227


Listing 32: JSON Example – Invoke Query


The analytics functionality of the BDA is used by CREMA components as well as users. Therefore, special authorisation roles are defined to manage the access for different types of users of the BDA. The BDA component delivers decoded permissions within an API key. This API key will be transmitted if CREMA component or users wants to interact with the BDA via the DBV. The BDA utilises DBV to offer two types of UI. First, the Data Sourcing UI for managing the transformation of incoming data (from PRU and CRI), and second the Graphic UI where users can submit their queries. Different roles limit the accessibility of the two UI elements or interaction options. To access a specific UI the user must have a corresponding role that permits the user to execute the intended action. The following list contains the authorisation definitions for the BDA.

• Full Access: The user has full access to design and submit new built queries as well as manage interaction (e.g. data transformation operations) with the DHS. The BDA Data Sourcing and Graphic UIs have no restrictions.

• Read Access: CREMA components and users have access to execute built queries using the Analytic API Client and Graphic UI respectively. The read access is restricted to fetching and submitting predefined built queries. The users are not able to design new queries.

• Write Access: This permission model inherits the permission from “Read Access” and extends it with permission concerning the design of built queries. The user can design and store new queries as well as execute the queries using the Graphic UI.

• Restricted resources: This permission model applies on the CREMA components or users that do not have adequate access rights or permissions to interact with the BDA.


Listing 33: BDA Example Authorisation Definition

6.4 Agile Personal Collaboration Environment

The PCE is split in three different tasks, which are represented in the updated Multi-Tier 3 architecture diagram, shown in Figure 19. The PCE Web Service provides the functionalities

{ "queryId": "QueryId" }

{ "userId": "597134" "user": "Charles", "company": "CREMA", "authorisation": { "permission": "Write Access" } }





191 / 227


to gather context-based data about locations and services. It also provides options to upload image highlighting and send notifications to the mobile device. The mobile device’s primary task is to consume and visualise information from the web service about the actual context of the surrounding environment. The only requirement to get agile context-based information is to be in the CREMA network. The agile approach means to be flexible and to have an unrestricted access to the mobile dashboard including context-based information. The secondary task is to stream the output of the mobile device’s camera to the PCE UI inside the DBV. Finally, the PCE UI, which is integrated in the DBV, is responsible to add collaboration activities from the instructor perspective. There it is possible to consume a stream from the mobile device and to send back notifications to it.


The PCE component uses different technologies. Since the transport of the data is an important aspect in this component, the focus lies on the communication aspect. It is therefore required to describe how the data is intended to flow and which technologies are used. Furthermore, the different parts of the PCE are described.

6.4.1.1 Data Exchange Infrastructure

Different network communication paradigms are needed to fulfil the requirements for this component. Push-Notifications are needed to send notifications from the web service to the mobile device. These notifications provide the ability to inform a worker about the current process and which next step has to be done manually. Furthermore, a RESTful interface is needed to handle highlighting commands during a running stream process from the DBV. Finally, a video stream and download of images must be handled to allow a live collaboration between an instructor and a worker.

6.4.1.1.1 Push-Notifications

Push-Notifications are messages, which are received by client apps. For this, the Google Cloud Messaging76 is used to enable both communication channels from client apps to server as upstream messages and from server to client apps as downstream messages. The technology behind is based on HTTP, which is also used in REST communication standards. During transmission of information from the server to the client app a GCM Connection Server is interposed. This GCM Connection Server receives the message and forwards it to the intended mobile device.

6.4.1.1.2 REST

On the mobile device client, Volley77 is used as a RESTful API Client to consume the PCE RESTful interface. It is developed by Google as a HTTP library for Android. It allows communication via HTTP such as the PCE web service. Besides other useful features, Volley supports asynchronous requests, automatic scheduling of network requests, multiple concurrent network connections and a cancellation request API to cancel pending requests. Unfortunately, it is not suitable for large download or streaming operations. Therefore, the Android internal Download Manager is used to download images because it handles long- 76 https://developers.google.com/cloud-messaging/gcm 77 https://android.googlesource.com/platform/frameworks/volley





192 / 227


running HTTP downloads very well. On the web service side, Jersey78 in its latest stable version is used. Jersey is a framework to provide and consume RESTful interfaces. All standard HTTP methods, such as GET, POST, PUT, DELETE, HEAD and OPTIONS are already provided and other non-standard HTTP methods are supported as well.

6.4.1.1.3 Streaming

Streaming data is a resource intensive process and therefore Kickflip79 is used to stream a video from the mobile device’s camera to a receiving web browser. Kickflip provides different mobile SDKs for live video broadcasting. For this implementation the Android SDK of Kickflip is used. Through their global cloud infrastructure an instant scalability is guaranteed and it is fully Open Source. Kickflip is also compatible with Google Glass and enables live video broadcasting via this device. With this knowledge, the streaming platform can also be migrated to the Smart Glasses approach.


The PCE component is split into 3 different parts that need implementation work. These three parts must be developed from scratch with the above mentioned technologies to guarantee the data transport. In the following subsections, the responsibilities of these PCE parts are described, which have to be implemented.

6.4.1.2.1 PCE Web Service

The PCE Web Service provides a RESTful interface as a mediator between the PCE UI from the DBV and the mobile device. The web service receives requests from both, the PCE UI, and the mobile device. The requests from the PCE UI are processed and forwarded as notifications to the mobile device. Requests from the mobile device are processed and context-based data is gathered from the CVA and MPM.

6.4.1.2.2 Mobile Device Platform

The mobile device will be developed in native code for Android. Android is developed by the “Open Handset Alliance” under the lead of Google Inc., and it is a mobile operating system based on the Linux Kernel. It’s designed primarily for smartphones and tablets. However, user interfaces for cars, televisions and watches are currently being developed or already available. Android is licensed under the Apache 2.0 license and written in Java. With the mobile device, users are able to get context-based information from the PCE Web Service and receive notifications from the DBV. Furthermore, it enables connection to the PCE UI to stream the camera output of the mobile device.

6.4.1.2.3 PCE UI

This part of the PCE has to consume a multimedia data stream and is able to view the stream in a good quality to guide the communication partner via voice transmission. The UI also enables an instructor to highlight objects in the video stream which then can be extracted as an image. After this, the image is uploaded using the PCE web service to the 78 https://jersey.java.net/ 79 https://kickflip.io/





193 / 227


CRI. An additional feature is to notify a mobile device user via a notification. There, the message is sent to the PCE web service, which than pushes the notification via the Google Cloud Messaging to the mobile device.


The architecture of the PCE has changed, because of separating web service functionalities from mobile device functionalities in terms of additional added requirements and changing the focus work in this component. The new architecture is shown in the following figure and is separated into 3 parts. Those three parts have the following responsibilities.

• PCE UI: The UI, which is integrated into the DBV component. This UI takes care of sending messages to the mobile device, receiving the stream from the mobile device, and also uploading images in order to highlight objects from the stream

• Web Service: This part receives and processes all requests of the PCE. It provides a RESTful interface which enables users and components to gather context-based data from the CVA, MPM and CRI. The context data relates to services or location-based information. One special feature is the Push-Notification functionality to the mobile device (described in Section 6.4.1.1.1), which can be sent from the PCE UI

• Mobile Device: The primary task of the mobile device is to consume context-based information to display these on the mobile dashboard. All the information that can be requested is handled by the Collaboration Manager. Push-Notifications are received by the Mobile Notification manager, which are forwarded to the Android Operating System to display these notifications in the upper Notification bar. Another task is to stream the camera output of the mobile device to the DBV to collaborate with an instructor at the DBV level

Push-Notifications and the streaming ability of the component require external services for an appropriate implementation effort. These external services use their own cloud-based infrastructure to handle the data inside.





194 / 227


ExternalNotificationService

SendNotification

PushNotification

NotificationContent

NotificationContent

ExternalStreamingInfrastructure

PCEWebService

PCEMobileDevice

T6.5CREMADashboardandVisualisation(DBV)

Requestlocation-basedInformation

StreamVideo GetContext

SendNotification

RequestService

Description

Getlocationinformation

GetServiceInformation

SendNotificationSendHighlighting

UploadImage

NotifyUploadConfirmation

ForwardUploadInformation

ImageData

MetaData

LocationInformation

ServiceInformation

ServiceInformation

ServiceInformation

ContextInformation

ImageDataService

DescriptionManager

Location-basedInformationManager

HighlightManager

T4.3Cloud-basedRAIDInfrastructure

(CRI)

T4.4CREMACPS,SensorAbstractionandVirtualisation

(CVA)


Monetisation(MPM)

NotificationManagerCollaborationAPI

<userinterface>PCEUI

CollaborationManagerStreamManager

DownloadManager

<userinterface>CollaborationUI

T4.3Cloud-basedRAIDInfrastructure

(CRI)

Asset

DownloadAssetSendDownload

Command

Asset ShowNotificationNotification

ContextGetContext

StreamingData

StartStream

StreamVideo

StreamingData

StreamingData

MobileNotificationManager

Figure 19: PCE Architecture Diagram To achieve the functionalities described in the last subsection, the PCE provide the following subcomponents from the PCE Web Service as depicted in Figure 19.

• Service Description Manager: This subcomponent uses the latest stable version of Jersey to consume the RESTful interface of the MPM component. It requests context-based information of services requested by the PCE mobile device.

• Location-based Information Manager: This subcomponent uses the latest stable version of Jersey to consume the RESTful interface of the CVA component. It requests context-based information of locations requested by the PCE mobile device.

• Highlight Manager: This subcomponent uploads images to the CRI via the RESTful client Jersey. It also sends a message to the Notification Manager to inform the user about a new uploaded image including the URI to this file.

• Notification Manager: This subcomponent uses the Google Cloud Messaging infrastructure to send Push-Notifications to the mobile device.

• Collaboration API: This subcomponent represents the RESTful interface for this component. Context-based data can be requested and Notification can be sent through this interface.





195 / 227


The subcomponents of the mobile device part of the PCE (depicted in Figure 19) are described as follows:

• Stream Manager: The Stream Manager streams multimedia content (audio and video) from the camera output of the mobile device with help of Kickflip (see Section 6.4.1.1.3) to the PCE UI.

• Collaboration Manager: This subcomponent requests context-based data from the PCE Web Service. Context-based data is composed of location-based information and service descriptions. To consume RESTful services Volley is used as a REST Client for Android.

• Download Manager: After a notification has arrived with information about downloadable content, this subcomponent is able to download this content even if it is a long-term download.

• Mobile Notification Manager: This subcomponent listens for new Notifications. As soon as a Notification has been arrived, the Mobile Notification Manager shows it on the Notification bar of Android.

• Collaboration UI: This subcomponent shows context-based Notification on the mobile dashboard to the user. Furthermore, after a Notification was chosen by the User from the Android Notification Bar, it is visualised also in the Collaboration UI.


The major design decision for the CREMA project is to use RESTful interfaces as a common communication base for the CREMA components. In order to follow this decision, the features of the PCE are defined as RESTful interfaces. Each provided service is described in a separate table. This table is followed with a listing showing an example for the JSON parameter (if applicable) as well as an example for the return value (if applicable). In the following, the term “user” describes also components which will use this method/interface.

6.4.3.1 Method “Send Notification”

The RESTful interface “Send Notification” (Table 119), creates a new Notification and forwards the message as a Push-Notification to the mobile device.

Table 119: PCE RESTful Interface – Send Notification

Send Notification

Description Creates a Notification and transforms it as a Push-Notification to redirect the message to the mobile device.

Request

Request URL POST http://crema.eu/pce/notifications?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing an object of the specified service

{

"sender":"user_72982", "recipient":"user_323",





196 / 227


6.4.3.2 Method “Upload Highlighting”

The RESTful interface “Upload Highlighting” (Table 114), creates a new highlighted image and stores it in the CRI and sends a Push-Notification to the mobile device, to inform about a new image which is ready to be downloaded.

Table 120: PCE RESTful Interface – Create Highlighting

"message":"test msg", "timestamp":"2015-10-25T23:55:22Z"

}

Combined Example

POST /pce/notifications?session=user1234 HTTP/1.1 Host: cream.eu object={"sender":"user_72982", "recipient":"user_323", "message":"test msg", "timestamp":"2015-10-25T23:55:22Z"}

Response

HTTP Status Code

Value Description

201 Notification has been created successfully forwarded as a Push-Notification


502 Notification cannot be forwarded as a Push-Notification

Upload Highlighting

Description Uploads a highlighted image as a Base64 format and informs the mobile device about new download options via a Push-Notification including the new generated id.

Request

Request URL POST http://crema.eu/pce/highlighting?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing the specified highlighted image

{

"sender":"user_72982", "recipient":"user_323", "title":"Test", "description":"this is a test", "base64Image":"jA0EAwMCxamDRMfOGV5gyZPn…yX1BBPOQAE4BHbh7PfTDIn"

}

Combined Example

POST /pce/highlighting?session=user1234 HTTP/1.1 Host: crema.eu object={"sender":"user_72982", "recipient":"user_323", "title":"Test", "description":"this is a test",





197 / 227


6.4.3.3 Method “Download Highlighting”

The RESTful interface “Download Highlighting” (Table 115), enables the user to download a highlighted image from the CRI.

Table 121: PCE RESTful Interface – Download Highlighting

"base64Image":"jA0EAwMCxamDRMfOGV5gyZPn…yX1BBPOQAE4BHbh7PfTDIn"}

Response

HTTP Status Code

Value Description

201 Highlighted image created and Push-Notification has been forwarded


502 Highlighted image has not been created and/or Push-Notification has not been forwarded

Download Highlighting

Description Retrieves a stored highlighted image from the CRI.

Request

Request URL GET http://crema.eu/pce/highlighting/imageId?session=userToken

Resource Parameters


imageId : string The id of the image to be downloaded

Image_1209


User1234

Combined Example

GET /pce/highlighting/Image_1209?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Request was successful


404 Image not found

JSON Attributes

Image : Object An image object matching the query. Example: "Highlighting": { "sender": "user_72982", "recipient": " user_323", "title": "Test", "description": "this is a test",





198 / 227


6.4.3.4 Method “Replace Highlighting”

The RESTful interface “Replace Highlighting” (Table 116), replaces an existing highlighted image and stores it in the CRI and sends a Push-Notification to the mobile device, to inform about a new image which is ready to be downloaded.

Table 122: PCE RESTful Interface – Replace Highlighting

"base64Image": "jA0EAwMCxamDRMfOGV5gyZPn…yX1BBPOQAE4BHbh7PfTDIn"

}

Replace Highlighting

Description Replaces an existing highlighted image in the CRI and notifies the mobile device via a Push-Notification.

Request

Request URL PUT http://crema.eu/pce/highlighting/imageId?session=userToken

Resource Parameters


imageId : string The id of the image to be replaced

Image_1209


User1234

HTTP Parameters

object : object An object representing the specified highlighted image

{

"sender":"user_72982", "recipient":"user_323", "title":"Test2", "description":"this is another test", "base64Image":" yX1BBPOQAE4BHbh7PfTDIn…jA0EAwMCxamDRMfOGV5gyZPn"

}

Combined Example

PUT /pce/highlighting/Image_1209?session=user1234 HTTP/1.1 Host: crema.eu object = {"sender":"user_72982", "recipient":"user_323", "title":"Test2", "description":"this is another test", "base64Image":" yX1BBPOQAE4BHbh7PfTDIn…jA0EAwMCxamDRMfOGV5gyZPn"}

Response

HTTP Status Code

Value Description

200 Request was successful


404 Image not found





199 / 227


6.4.3.5 Method “Delete Highlighting”

The RESTful interface “Delete Highlighting” (Table 117), deletes an existing highlighted image if it is not needed anymore.

Table 123: PCE RESTful Interface – Delete Highlighting


Notifications enable a worker to be informed remotely via the DBV, or directly from a process. Therefore, the PCE web service enables via a RESTful interface to send notifications directly to the worker’s mobile device. The following attributes are set:

• sender: identifies from whom the notification is sent • recipient: Identifies the addressee of the notification • message: Includes the information, which should be displayed on the mobile device • timestamp: Shows when the notification was sent

The Listing below shows the format of the notification, which can be sent to the mobile device.

Listing 34: PCE Content Format "Notification"

Delete Highlighting

Description Deletes an existing highlighted image in the CRI If it is not needed anymore.

Request

Request URL DELETE http://crema.eu/pce/highlighting/imageId?session=userToken

Resource Parameters


imageId : string The id of the image to be deleted

Image_1209


User1234

Combined Example

DELETE /pce/highlighting/Image_1209?session=user1234 HTTP/1.1

Host: crema.eu

Response

HTTP Status Code

Value Description

200 Deletion was successful


404 Image not found





200 / 227


An additional feature to improve collaboration is to forward highlighted images from the DBV or processes to the mobile device. Therefore the following schema is described to handle an upload of a highlighted image.

• sender: identifies from whom the image is sent • recipient: identifies the addressee of the image transmission • title: identifies the topic about the image • description: a small description, which guides the mobile device user additionally • base64Image: the content of the image

The Listing below shows the format of a highlighted image, which can be extracted from the video stream.

Listing 35: PCE Content Format "Highlighted Image"


The PCE requests data from the MPM, which are originally hosted in the CRI. Therefore, the CRI is in charge of the data restriction of each user for service related information. But the PCE is in charge for authorising the user for location-based information and receiving notifications. The following list describe the abilities, which the user is able to perform, if the user has the permission to use the PCE mobile device.

• Location-based information: This ability allows a user to fetch location-based information for the surrounding environment.

• Notification: This ability describes if a user can receive notification on the mobile device or not.

The Listing below shows an example of the authorisation model. The permission true means, that both abilities, which are described above, are accessible.

{ "sender": "user_72982", "recipient": "user_323", "message": "test msg", "timestamp": "2015-10-25T23:55:22Z" }

{ "sender": "user_72982", "recipient": "user_323", "title": "Test", "description": "This is a test", "base64Image": "yX1BBPOQAE4BHbh7PfTDIn…jA0EAwMCxamDRMfOGV5gyZPn" }

{ "userId": "597134" "user": "Charles", "company": "CREMA", "authorisation": { "permission": "true" } }





201 / 227


6.5 Dashboard & Visualisation

The CREMA Dashboard and Visualisation (DBV) component provides the main GUI with integrated user interfaces from CREMA components to users. Each component can be developed separately and thus be integrated and represented on the DBV by an appropriate View Container (called UI Component View Container) as depicted in Figure 20. This UI Component View Container is bound to the DBV with help of a component controller and can therefore communicate with the remaining components only through this controller unit, so that each bound component on the DBV is isolated from the other components and from the DBV itself (sandboxed). The DBV customises the visualisation of the hosted components according to the respective user access rights provided from the SPC. Thus, the DBV helps users to see the most useful information for them about the manufacturing processes according to their access rights.


As mentioned above the DBV component is implemented as a web application based on well-known web technologies such as HTML5, CSS3 and JavaScript for the client side and PHP for the server side. The reasons for taking these decisions are explained as follows.

6.5.1.1 Dashboard Content

HTML580 is used to create the content of the dashboard. HTML5 is the fifth revision of the HTML Standard being released in October 28th 2014. It provides web developers a wide range of syntactic features, like easily embedding multimedia contents without requiring proprietary plugins and APIs. Furthermore, HTML5 provides some new structuring elements which could help web developers to better construct HTML pages to enable a clearly arranged navigation on the web pages. Another valuable feature that HTML5 provides is the new local storage feature. It is a combination of the traditional cookies and a client-side database. Though, it is better than cookies as it allows storage across multiple windows. Additionally, security and performance have been increased and the stored data does not disappear, as well as when working with cookies, even though the application window is closed. This feature allows developers to: cache data, store user information and store and load application states. Moreover, HTML5 is supported by most mobile devices since its release.

6.5.1.1.1 UI Component Container

Inline Frames81 (IFrames) are used to embed user interfaces from other CREMA components into the dashboard. An IFrame is an HTML Document Object Model (DOM) element, which enables embedding HTML documents inside an existing HTML document on a website. It is often used to insert and display content from foreign sources into a webpage without having the source code of the content. An interesting feature of IFrames is that they can be treated as all other DOM elements but still have their own navigation elements, such as scrollbars, independent from the hosting webpage. By using

80 http://www.w3.org/TR/html5/ 81 http://www.w3.org/TR/html401/present/frames.html#h-16.5





202 / 227


Asynchrounous Javascript and XML (Ajax), the content of an IFrame can be changed or reloaded without requiring a reload of the entire webpage as depicted in Listing 3.

Listing 3: Source Code Example - Periodically reload of an Iframe content.

Listing 4 shows a method, which enables a dynamic change of the content of a specific IFrame. Both, the IFrame ID and the intended page URL are passed to the method as parameters. With help of this method the web developer could use an IFrame to display multiple pages successively. This method is helpful, for example, for users who want to show different contents without having multiple IFrames on the web page.

Listing 4: Source Code Example - Exchange of sources in an IFrame

6.5.1.2 Corporate Design

Cascading Style Sheets 382 (CSS3) are used to enable a corporate design throughout all integrated user interfaces of the dashboard. It is the third revision of the CSS Standard. The concept of CSS3 allows web developers and designers to work separately and thus more productively by separating the structure of a website from its presentation. As a positive consequence, developers do not need to care about the style in every integrated user interface, but can concentrate on the business logic of the related component. Currently the CSS3 standard is supported by nearly all current web browsers, and together with HTML5 websites are becoming more flexible and platform independent.

82 http://www.w3schools.com/cssref/css3_browsersupport.asp

/*** * @param iFrameName, the name of the iFrame to be reloaded * @param timeInterval, the time in milliseconds after which the reload method will be periodically executed */ <script> setInterval("reloadIFrame();", timeInterval); function reloadIFrame(iFrameName) { document.frames[iFrameName].location.reload(); } </script>

/*** * @param iFrameId, the id of the iFrame to be refreshed * @param pageUrl, the URL of the website to be shown */ <script> function changeIFrameSource (iFrameId, pageUrl) { $(“#”+iFrameId").src = pageUrl; } </script>





203 / 227


6.5.1.3 Dashboard Interaction

The interaction between components and their related user interfaces, minimally complex calculations and further interaction possibilities in the DBV component are handled via JavaScript83, JQuery and PHP.

6.5.1.3.1 JavaScript

JavaScript is one of the most simple, versatile and effective languages used to enhance and extend functionality on websites. It offers the use of a wide range of screen visual effects, related to a fast processing and calculating of data as well as an extended functionality to websites using third party scripts and libraries. As the JavaScript code is executed on the user’s computer, processing is completed almost instantaneously depending on the task as it does not need to be processed on the server side. Thus, saving bandwidth and strain on the server and saving time in order to make it easier for users is one of the big advantages of using JavaScript.

6.5.1.3.2 JQuery

JQuery84 is a wrapper library for JavaScript and supplements the advantages of JavaScript by offering additional features. JQuery handles cross browser issues by wrapping different JavaScript implementations, thus web developers can create code once for different web browsers. An additional feature of JQuery is its syntax simplicity making it easier to select DOM elements to be changed and then chain actions and effects in order to make the code more efficient and better readable. Furthermore, JQuery uses the CSS3 selector mechanism for selecting elements from the DOM, so web developers do not have to learn a different selection syntax to work with JQuery selection.

6.5.1.3.3 PHP

PHP85 is a scripting language especially suited for developing web pages on the server side. Its design-clarity, well-structured modules and the upkeep of multiple technologies make it one of the most used scripting languages nowadays. PHP is also open source, which means that it’s readily available and free to use. Moreover, it supports several platforms, so it can be executed on LINUX/UNIX and Windows systems the same manner. PHP can also be easily embedded into HTML. Usually PHP supporting web servers come with a ready to use configuration, so that web developers don’t have to struggle with non-obvious configuration files. Additionally for its technical features, PHP provides a huge community where developers can share ideas, offer expertise and open discussions in order to fix a bug or improve the functionality of a specific module.

83 http://www.w3schools.com/js/ 84 http://jquery.com/ 85 http://php.net/





204 / 227



To reflect the technologies mentioned above and fulfil the functionalities that are described below, the architecture of the DBV component has been slightly changed as depicted in Figure 18. Additional Log and Notification Controller, which are respectively responsible for displaying logs and notifications of CREMA Components as well as a RESTful Interface to pass notifications through the DBV are among the main changes.

CREMADashboardandVisualisation(DBV)

CREMAComponentX

UIConfigurationUIComponentController

AuthenticationController

loginRequestpermission

token

T3.4HolisticSecurityandPrivacyConcept

(SPC)

authenticate/authoriseuser

token/user

UIComponentViewContainer

userinteraction

componentresponse

<includeUI>

Browser

view/interactinformation

data

view/interactionrequest

response request

configureUI

updatedUI

<userinterface>DashboardUI

UserManagement

updateuser

userdata

manageuseruser

Interact

DBVNotificationAPI

pushnotifications

shownotifications


Infrastructure(CRI)

processmodels

NotificationController

passnotifications

getnotifications

getnotifications

returnnotifications

savenotifications LogController

getlogs

getlogs

returnlogs

showlogs

Figure 20: DBV Architecture Diagram

To achieve the functionalities described in the last subsection, the DBV provides the following subcomponents as depicted in the figure above.

• Dashboard UI: this subcomponent is the primary interface with which users have to interact. It provides a main login area where users can enter their credentials and get authenticated and authorised from the SPC component. On this main user interface all available UI Component Views could be displayed and operated. This UI will be developed as a website implemented with the technologies listed above (HTML5, CSS3 and JavaScript). Thus, it will be accessible from the most popular web browsers and could be also viewed on mobile devices.

• Authentication Controller: this subcomponent is responsible for managing the user login on the Dashboard UI. After putting the user credentials into the appropriate fields, the Dashboard UI subcomponent sends a request to the Authentication Controller in order to get access permission to the Dashboard functionalities. The Authentication Controller then establishes a connection to the SPC component with the received user credentials. The SPC component delivers then a response containing an access token with access rights assigned to this user which enables the user to further communicate to the Dashboard and its components. Since the Authentication Controller subcomponent runs on the server side, it is implemented with the PHP scripting language in order to provide an easy





205 / 227


communication to the RESTful service which offers the access to the SPC component.

• Notification Controller: this subcomponent takes care of the notification traffic between the DBV and the remaining CREMA components. This notification flow is unidirectional to the DBV; it means the Dashboard acts only as a notification receiver in order to display incoming notifications and will not send notifications back to the CREMA components. The Notification Controller is accessible from outside through the DBV Notification API depicted in Figure 20; a RESTful interface which will be called from the CREMA components to push their notifications. Each incoming notification should be passed as a JSON object in order to meet a unified data format. After receiving the notification object the Notification Controller wraps its content into a HTML view element and shows it on the Dashboard UI page. Each passed notification will be stored to the CRI Component as well in order to allow a notification tracking at a later stage. The Notification Controller is accessible directly from the Dashboard UI subcomponent as well in order to request stored notifications from the CRI Component. In this case, users can request all notifications reported for each represented CREMA component on the DBV and show them in a log window. The Notification Controller will be implemented in PHP because of the selected technologies in section 6.5.1.

• Log Controller: this controller unit is the connective link between the CREMA Components represented on the DBV and the Logs entity on the CRI Component. It allows requesting logs for each Component on the Dashboard and display it on the Dashboard UI subcomponent. Thus, each CREMA Component allowing logs should be able to access its logs track through a separate UI (e.g. Tab) on the Dashboard UI. This Logs-Tab provides the user to select the component name, a time interval and eventually a process name for which the logs have to be viewed. The Log Controller subcomponent then addresses the CRI and gets the logs for the appropriate component/process which were registered during the given time interval and displays the result on the Logs-Tab embedded on the Dashboard UI. In this way users could better get knowledge about specific process progress or failure reasons.

• UI Component View Container: this subcomponent is responsible for representing the content of the CREMA components on the Dashboard UI. It’s a part of the Dashboard UI and could be configured through the UI Configuration subcomponent. CREMA components which aim to have a UI component should provide their inputs in form of a URL, e.g. a web page which could be called in a web browser. For every CREMA component to be viewed on the Dashboard UI an UI Component View Container e.g. IFrame will be created and the corresponding URL of this CREMA component will be passed to as a parameter. This URL is then called and its content is displayed within this IFrame. At the end of this process, the user will get a collection of multiple IFrames on the Dashboard UI representing the CREMA components which are authorised for his access token. The user could then interact with these IFrames and treat them independently from the Dashboard UI page, such as reloading contents, making some requests, etc.

• UI Component Controller: this subcomponent takes care of the logic of the UI Component View Container subcomponent. Each UI Component View Container uses this subcomponent to interact with its own CREMA Component through its RESTful interfaces, so that the whole communication between a CREMA component and its UI Component View Controller on the Dashboard should be





206 / 227


handled via this controller component. As the Figure 4 shows, every user interaction on a UI Component View Container which needs a response from the correspondent CREMA component should be passed through the UI Component Controller subcomponent. The UI Component Controller will accordingly call the appropriate RESTful interface of this CREMA Component and pass the request parameters through. Afterwards it gets a response as a result of the interface request call and handles it in order to properly display it on the UI Component View Container. Each UI Component View Container and its UI Component Controller together make up a unit which represents the corresponding CREMA component on the Dashboard. Because of technology selection in 6.5.1 JavaScript is used as programming language and the JQuery library as an advanced library as well.

• UI Configuration: this subcomponent is used to configure the UI Component View Container. Possible deployment scenarios are e.g. the ability to set the visibility of a specific UI Component View Container as well as preventing its notifications. To better interact with the UI Component View Containers it’s advisable to use JavaScript as well as the JQuery library in order to reach a better performance on all platforms including mobile devices’ web browsers.

• User Management: this subcomponent is available only for users with administrative rights allowing them to make CRUD operations on the subordinated user accounts. It is directly connected to the Authentication Controller subcomponent in order to bind it with the SPC Component. The User Management provides a special UI, which is only visible and accessible for a user with necessary rights and enables them to show available subordinated users and to make operations (CRUD) e.g. get information about user, create, update or delete user account. Each operation on a user bucket will notify the SPC Component in order to arrange possible permission impairments for the CREMA system. According to the technologies selection in 6.5.1 the UI will be implemented with HTML5, CSS3 and JavaScript (JQuery). All CRUD operations calls will be passed through the Authentication Controller subcomponent and forwarded to the SPC Component.


The DBV has only one public interface called the DBV Notification API. This interface is accessible from all CREMA Components, which could post notifications to the Dashboard. Its only method “Push Notification” is described as follows.

6.5.3.1 Method “Push Notification”

The method “Push Notification” (Table 124) pushes a new notification from a CREMA component, which is represented on the DBV through its UI Component View Container to the Notification Controller subcomponent in order to report about a specific event or happening during the execution, e.g. process completion to the user.

Table 124: DBV RESTful Interface – Push Notification

Push Notification

Description Pushes a new notification to the Notification Controller.

Request





207 / 227



This section lists JSON examples, which shows on the one side the structure of the JSON object, used to push notifications to the Notification Controller and store it in the CRI as well. On the other side it shows the JSON object used to retrieve the notifications reported by a specific CREMA component. Listing 36 shows an exemplary JSON object representing a notification, which is sent from a “Component X” to the Notification Controller in order to report the current user of the DBV about the successful end of a “Process Y” running on this component at the time “2011-01-27T11:40:52.280Z”. The content of the JSON object above is shown on the Dashboard UI in a special field. This JSON object is saved also in the CREMA CRI to allow an easy tracking of notifications reported during the entire deployment time.

Listing 36: JSON Example – Push Notification

Request URL POST http://crema.eu/dbv/notifications?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object An object representing an object of the specified notification

{

"Sender":"PRU", "Topic":"Process finished", "Message":"Process X has been completed successfully", "TimeStamp": "2015-12-12 13:37:12"

}

Combined Example

POST /dbv/notifications?session=user1234 HTTP/1.1 Host: crema.eu object={"Sender": "Component X","Topic": "Process finished", "NotificationContent": "Process X has been successfully completed", "TimeStamp": "2015-12-12 13:37:12"}

Response

HTTP Status Code

Value Description

201 Notification created

403 Unauthorized user/component

502 Database error

{ "Sender": "Component X", "Topic": "Process finished", "Message": "Process Y of the CREMA Component X has been successfully completed", "TimeStamp": "2011-01-27T11:40:52.280Z" }





208 / 227


The Notification Controller provides also a method called “getNotifications”, which allows Dashboard users to retrieve all notifications being reported by a component name. By passing the component name as a parameter the method “getNotifications” collects all notifications from the CRI, which have been reported by this component returning them as an array of JSON objects. The Listingbelow demonstrates the signature of the “getNotifications” method.

Listing 37: Function Example – Signature of the method “getNotifications”

The Listing belowshows how the notifications reported by the CREMA Components are saved on the CRI. The “notifications” object below is a JSON array object holding all the notifications objects which have being reported by the CREMA Components and displayed on the Dashboard UI. Note that only notifications from the same source (sender component) could be returned by a single call of the “getNotifications” method.

Listing 38: JSON Example – Result of the method Get Notifications


The DBV manages all integrated user interfaces of the CREMA components. However, each component is responsible for its own content and authorisation model definition. To access the user management interface the DBV also requires elevated user permissions. Therefore only administrators are able to see the User Management UI to manage registered user accounts. Authorisation models which define views and permissions are granted to user roles. The following list provides a general description of such roles:

/*** * @param componentName, the name of the component for which all notifications have to be returned * @param accessToken, user access token */ <script> function getNotifications(componentname,accessToken){ // request the notifications from the CRI return notifications; } </script>

"notifications": [ { "Sender": "Component X", "Topic": "Process finished", "Message": "Process A of the CREMA Component X has been successfully completed", "TimeStamp": "2016-05-27T11:40:52.280Z" }, { "Sender": "Component X", "Topic": "Process interrupted", "Message": "Process B of the CREMA Component X has been interrupted by Process C of the CREMA Component Y", "TimeStamp": "2016-05-27T12:40:50.280Z" }, {…} ]





209 / 227


• Shopfloor Access: The user has access to the analytics, the collaboration features and the CRI UIs.

• Manager Access: The user has access to all integrated UIs. • Admin Access: The user inherits the Manager Access permission and in addition

the user is able to manage user accounts through the user management. The example below in the following Listing describes the CREMA user authorisation model.

Listing 39: DBV Example Authorisation Definition

{ "userId": "597134" "user": "Charles", "company": "CREMA", "authorisation": { "level": "Write Access" "scope": ["OSL","MPM","PRU",…] } }





210 / 227


7 Security and Privacy Component


In the following sections procedures are described to guarantee Security and Privacy.

7.1.1.1 Technical Solution to Authentication

The authentication will be realised with the help of a dashboard where the user can login and logout. Every client has an API-key that needs to be checked. If the API-key is authenticated the client will get an access token from the SPC. The client has to add the key to its API if it wants to use the CREMA system. If the client is authorised it gets some basic user information (e.g. userID, name, company, etc.) from CREMA. There will be a two-factor authentication that increases the security of CREMA. Additional information on the technical solution to authentication can be found in the Holistic Security and Privacy Concept (D3.4).

7.1.1.2 Technical Solution to Authorisation

Basicylly, every CREMA component has to implement an authorisation module that interacts with the SPC. After a client has been authorized by the authentication module, the SPC sends a response with private information that contains user rights and authorisation rules. The component that receives the additional information can check whether the needed rights, roles or associations for the users are met. If the user has the appropriate rights, the request may be authorised. There is a difference between module authorisation and data authorisation. Modules are clients that want to interact with CREMA and needs to be authorized to use functions and processes. Data authorisation has more focus on privacy and the data that should be accessed and consumed. More information on the technical solution to authorisation can be found in the Holistic Security and Privacy Concept (D3.4).

7.1.1.3 Technical Solution to Privacy

Privacy focuses on how sensible data can be saved against unauthorised data access. For CREMA, there will be a theoretical concept that makes use of a group hierarchy. It will be possible to define groups and link data and directories that should be accessible by users with the appropriate group assignments. A group will be described by a specific string which is similar to the concept of name spacing. A user will only see data that is accessible by his group assignments or even public data from higher group levels. The technical solution to privacy has a big overlapping with the technical solution to authorisation because a user (or component) has to be authorised to access data with his given group strings. More information on the technical solution to privacy can be found in the Holistic Security and Privacy Concept (D3.4).


The component structure as can be seen the architecture below has not been changed since it was described in the functional specification.





211 / 227


Figure 21: Architecture of the SPC component

For the server side, CREMA uses the JavaScript executing server Node.js to provide web services. Node.js is an event driven programming language that executes JavaScript on the server side. Because of the non-blocking event driven architecture, Node.js is very performant even in handling multiple requests. Another advantage in the use of Node.js is that no additional programming language is required on the server side. CREMA uses the development method test-driven development which gives the effort to be very agile. A benefit in using the method is that CREMA is a very sensitive project and with the test-driven development it will be secured to develop very stable and robust software. There will be client libraries (first in Java) that provide a programmatic way to work with the CREMA service. It will be possible to add external components that use the SPC to obtain user data. There will be an API interface that is generic. The first client library will be in Java as stated above but more will follow. With the SPC it is possible to host multiple projects within the same instance. There are functions relating to the privacy aspects as stated in the Technical Solution to Privacy. An important feature the SPC focuses on is to provide reusability. An easy way to host more mandates in one instance decreases the management and service costs of the infrastructure. Every mandate has its own, autonomous data pool that only clients with the appropriate rights can access. It is not possible to gain access to other data than those to which the requesting client has the rights. As being displayed in the figure above, there will be a user interface where a user can login via a browser. Every component will be integrated with the help of an Iframe that uses SSL security. In this Iframe that is part of the Component Plugin Framework, the component specific data are displayed to the user.

HolisticSecurityandPrivacyConcept(SPC)

SecurityAPI

getpermission

accesstoken

CoreLogic

ExternalAuthentication

Providers

externalAPIresponseexternal

APIcall

permission

authorise

accesstoken/usercredentials

accesstoken

CREMAComponentX

Libraries

CREMAComponentY

Libraries

accesstoken/APIkey

accesstoken/APIkey

usermetadata

usermetadata

<userinterface>LoginUI(viaDBV)

authentication

accesstoken

accesstoken

usercredentials

CredentialsTokenAPIkeys

permissiontemplate

<userinterface>ManagementUI

UserManagementTokenConfiguration

ComponentPluginFramework

Browser





212 / 227



The major design decision for the CREMA project is to use RESTful interfaces as a common communication base for the CREMA components. In order to follow this decision, the features of the SPC are defined as RESTful interfaces. In order to describe the RESTful interface, each provided service is described in a separate table. This table is followed with a listing showing an example for the JSON parameter (if applicable) as well as an example for the return value (if applicable). In the following the term “user” describes also components which will use this method/interface.

7.1.3.1 Method “Create User”

The RESTful interface “Create Users” (Table 125), creates a new user for the SPC component.

Table 125: SPC RESTful Interface – Create User

7.1.3.2 Method “Get User”

The RESTful interface “Get User” (Table 126), gets an existing user in the SPC component based on an ID.

Create User

Description Creates a new user in the SPC component.

Request

Request URL POST http://crema.eu/spc/users?session=userToken

Resource Parameters



User1234

HTTP Parameters

object : object A user object representing an object of the created user

{ "user": "…",

"company": "…", "authorisation": {…}

}

Combined Example

POST /spc/users?session=user1234 HTTP/1.1 Host: crema.eu object{"user":"…","company": "…","authorisation":{…}}

Response

HTTP Status Code

Value Description

201 User created

409 User exists already

502 Database error





213 / 227


Table 126: SPC RESTful Interface – Get User

7.1.3.3 Method “Get Users”

The RESTful interface “Get Users” (Table 127), gets all existing users in the SPC component.

Table 127: SPC RESTful Interface – Get Users

Get User

Description Retrieves a user from the SPC component based on a user Id.

Request

Request URL GET http://crema.eu/spc/users/userId?session=userToken

Resource Parameters


userId : string Id of the user 1024


User1234

Combined Example

GET /spc/users/1024?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 User retrieved

404 User not found

502 Database error

JSON Attributes

User : Object { "userId": "1024", "user": "…", "company": "…", "authorisation":{…} }

Get Users

Description Retrieves a list of all registered users in the SPC component.

Request

Request URL GET http://crema.eu/spc/users?session=userToken&page=page&limit=limit

Resource Parameters



User1234

page : int? Enables the user to use pagination

3





214 / 227


7.1.3.4 Method “Update User”

The RESTful interface “Update User” (Table 128), updates an existing user in the SPC component based on an ID.

Table 128: SPC RESTful Interface – Update User

limit : int? Request a limited number of entities

50

Combined Example

GET /spc/users?session=user1234&page=3&limit=50 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

201 Userlist retrieved

502 Database error

JSON Attributes

User : Object "metadata": { "page": 3, "limit": 50, "Links": [ { "previous":

"/spc/users?session=user1234&page=2&limit=50",

"next": "/spc/users?session=user1234&page=4&limit=50",

} ], "Users": [ { "userId": "1024", "user": "…", "company": "…", "authorisation":{…} },{…}, { "userId": "1074", "user": "…", "company": "…", "authorisation":{…} } ]

Update User

Description Updates a user in the SPC component based on a user Id.

Request





215 / 227


7.1.3.5 Method “Delete User”

The RESTful interface “Delete User” (Table 129), deletes an existing user in the SPC component based on an ID.

Table 129: SPC RESTful Interface – Delete User

Request URL PUT http://crema.eu/spc/users/userId?session=userToken

Resource Parameters




User1234

HTTP Parameters

object : object A user object representing an object of the created user

{ "user": "…",

"company": "…", "authorisation": {…}

}

Combined Example

PUT /spc/users/1024?session=user1234 HTTP/1.1 Host: crema.eu object{"userId":"1024", "user":"…","company": "…","authorisation":{…}}

Response

HTTP Status Code

Value Description

200 User updated

400 Bad Request

404 User not found

502 Database error

Delete User

Description Deletes a user in the SPC component based on a user Id.

Request

Request URL DELETE http://crema.eu/spc/users/userId?session=userToken

Resource Parameters




User1234

Combined Example

DELETE /spc/users/1024?session=user1234 HTTP/1.1 Host: crema.eu

Response

Value Description





216 / 227


7.1.3.6 Method “Access User Data”

The RESTful interface “Access User Data” (Table 130), gets the public profile of an existing user in the SPC component based on an ID.

Table 130: SPC RESTful Interface – Access User Data

7.1.3.7 Method “User Login”

The RESTful interface “User Login” (Table 131), enables the user to login to the CREMA System provided by the SPC (e.g. DBV). Therefore the user has to transmit both username and password.

Table 131: SPC RESTful Interface – User Login

HTTP Status Code

200 User Deleted

404 User not found

502 Database error

Access User Data

Description Retrieves the public profile of a user in the SPC component based on a user Id.

Request

Request URL GET http://crema.eu/spc/users/userId/profile?session=userToken

Resource Parameters


userId : string Id of the User 1024


User1234

Combined Example

GET /spc/users/1024/profile?session=user1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 User retrieved

404 User not found

502 Database error

JSON Attributes

User : Object { "userId": "1024", "user": "…", "company": "…" }

User Login





217 / 227


7.1.3.8 Method “Authenticate Token”

The RESTful interface “Authenticate Token” (Table 132), enables CREMA components to check if a user is already logged in or not.

Table 132: SPC RESTful Interface – User Login

Description Enables the user to login to the CREMA System via username and password

Request

Request URL POST http://crema.eu/spc/session?username=username&password=password

Resource Parameters


username : string username of the user test

password : string password of the user pw_test

Combined Example

POST /spc/session?username=test&password=pw_test HTTP/1.1 Host: crema.eu1

Response

HTTP Status Code

Value Description

201 Session created

401 Username or password are wrong

JSON Attributes

user_accesstoken : Object

{"user_accesstoken":"aSioZoif828290cDACeio2F"}

Authenticate Token

Description Enables CREMA components to check if a user is logged in or not.

Request

Request URL GET http://crema.eu/spc/session/userToken

Resource Parameters



User1234

Combined Example

GET /spc/session/User1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Session exists

404 Session not found

JSON Attributes

User : Object { "userId": "1024", "user": "…",





218 / 227


7.1.3.9 Method “User Logout”

The RESTful interface “User Logout” (Table 133), enables the user to logout from the CREMA system.

Table 133: SPC RESTful Interface – User Logout


This section illustrates JSON examples, which shows the structure of the JSON object, used by a component to communicate with the SPC. Additionally, it shows the JSON object used to retrieve the group to authorise data and process access. The Listing belowshows an exemplary JSON object that represents a response to a client’s authorisation request, which is sent from SPC. The two group strings identify two exclusive groups in CREMA. If a component has these two groups associated it can access data and processes that are available to the group.

Listing 40: Response from the SPC to an authorisation request

There will be API Keys and Access Token that need to be unique. These keys and tokens will be random generated unique strings, for example Globally Unique Identifier (GUID). A GUID is a global unique number with 128 bit that is used as unique token in a distributed

"company": "…" }

User Logout

Description Enables the user to logout from the CREMA System.

Request

Request URL DELETE http://crema.eu/spc/session?username=username&password=password

Resource Parameters



User1234

Combined Example

DELETE /spc/session?userToken=User1234 HTTP/1.1 Host: crema.eu

Response

HTTP Status Code

Value Description

200 Session deleted

404 Session not found

{ "userId": "1234", "groups":[ {“groupName” : "CREMA_manufacturerA_factoryAa_internal"}, {“groupName” : "CREMA_manufacturerA_factoryAa_marketing"}, ] }





219 / 227


system. An example content format would be fd8c703a-e855-4e6e-a37a-c4c649f87a47. It would be possible to let different information’s have an influence on how the unique identifier looks like, for example the UserID. This would give the benefit to identify defined information’s from users back.





220 / 227


8 Transmitted Issues

The last open issues transmitted from the Functional Specification (D3.2) and introduced in the Global Architecture Definition (D3.1) are solved. The related solutions to each issue are provided in the table below.

Table 134: Solved Issues

Issue Description Solution

Data transfer Data for the BDA (T6.3) and MON (T6.2) component shall be solely routed via the process execution engine PRU (T5.2) and thus instructions for this will be via the process designer PDE (T5.1). This means that PDE must have the facility to indicate this – e.g. specific intrinsic steps, additional properties on process steps – and PRU must execute such instructions.

It is agreed that the data transfer is done via internal services. These services are used by the PDE, which enables the user to drag those services to configure a process

Monitoring UI MON UI could be also integrated with the PDE component.

MON will be integrated with DBV but not with the PDE, since PDE is based on BPMN.IO tool and will be used for process modelling

Monitoring running scope

Is monitoring (MON - T6.2) functioning all the time or only in connection with a running process (PRU - T5.2). Current thinking is only when related to a process such that data reading are routed by a process to the monitoring.

It is decided that a business rule is always related to a process instance

Influence of alerts from MON

The Alert component (MON - T6.2) may alert the user via DBV but also influence the process runtime (PRU - T5.2) – for example to halt or terminate a process

The PRU offers an interface that can be used by the MON to inform about an event

CPS and Sensors’ Data for Analysis

The way the Data is stored/described between the CVA (T4.4)/SVA (T4.5) end points, the CRI (T4.3) and the BDA (T6.3) is still being developed, particularly knowing ideally the Query the user of the BDA would like to deal with semantically rich data to build queries rather than just technically, unannotated data

This process is described in Section 4.4 and 4.5





221 / 227


9 Conclusion

This deliverable defines the detailed Technical Specification CREMA with regard to individual software components and their interfaces. Based on the Requirements Analysis and User Stories (deliverable D2.9), the Global Architecture Definition (D3.1), and – most importantly – the Functional Specification (D3.2), the Technical Specification provides the foundation for the Research, Technology, and Development (RTD) work to be carried out in CREMA. Each of the CREMA components is analysed with respect to these aspects:

• Technology Base & Reuse: Contains the technology selection for the functionalities and describes those technologies. Also already used technologies are involved and described.

• Component Structure Overview: An update of the components’ structure from the Functional Specification (deliverable D3.2.1). The update reflects the continuation in the software engineering process.

• Public Interfaces: Based on the used programming languages, all software components provide RESTful interfaces. For each interface, the necessary input and provided output is defined. Furthermore, example request and response JSON messages for the interaction with RESTful interfaces are provided.

• Content Format: Includes the definition of models used by the related component for interaction with the respective interfaces (in contrast to the examples provided as part of the interface descriptions).

As a result, for all software components in CREMA, it is clearly defined which functionalities to expect and how to access the provided functionalities. Throughout the technical specification of the individual software components, the CREMA consortium has been able to identify previously existing inconsistencies between the components and remodel the internal and external structure of software components, wherever necessary. Nevertheless, naturally, during the course of this research innovation action, certain aspects of the software architecture may be changed for technical reasons, currently unavailable research results, and due to other unforeseen issues. Nevertheless, this Technical Specification provides a stable and reliable foundation for the currently ongoing and upcoming software development tasks within CREMA. While not leading to additional deliverables of the CREMA project, changes to the Technical Specification will necessarily lead to an update of the document at hand. However, no major changes regarding the defined functionalities are foreseen.





222 / 227


References • [KKSLB15] M. Klusch, P. Kapahnke, S. Schulte, F. Lecue, A. Bernstein (2016)

“Semantic Web Service Search: A Brief Survey”. In: Kuenstliche Intelligenz, 2/16, Springer.





223 / 227


Annex A

Figures Figure 1: CREMA Global Architecture Diagram ................................................................. 13Figure 2: DLP Architecture Diagram .................................................................................. 19Figure 3: DHS Architecture Diagram .................................................................................. 40Figure 4: CRI Architecture Diagram ................................................................................... 66Figure 5: CVA Architecture Diagram .................................................................................. 87Figure 6: SVA Architecture Diagram ................................................................................ 108Figure 7: Proxy Service Wrapper Architecture Diagram .................................................. 109Figure 8: PDE Architecture Diagram. ............................................................................... 117Figure 9: PDE Design Canvas ......................................................................................... 119Figure 10: Properties Panel .............................................................................................. 119Figure 11: Toolbox Menu ................................................................................................. 119Figure 12: Process Model Store ....................................................................................... 120Figure 13: PRU Architecture Diagram .............................................................................. 128Figure 14: OSL Architecture Diagram .............................................................................. 137Figure 15: ODERU Architecture Diagram ........................................................................ 145Figure 16: MPM Architecture Diagram ............................................................................. 160Figure 17: MON Architecture Diagram ............................................................................. 179Figure 18: BDA Architecture Diagram .............................................................................. 185Figure 19: PCE Architecture Diagram .............................................................................. 194Figure 20: DBV Architecture Diagram .............................................................................. 204Figure 21: Architecture of the SPC component ................................................................ 211

Tables Table 1: DLP RESTful Interface – Read CDM-Core ontology ............................................ 19Table 2: DLP RESTful Interface – Read other public CDM-Core profile ............................ 20Table 3: DLP RESTful Interface – Copy other CDM-Core profile ...................................... 21Table 4: DLP RESTful Interface – Read my CDM-Core profile .......................................... 22Table 5: DLP RESTful Interface – Refresh my CDM-Core profile ...................................... 23Table 6: DLP RESTful Interface – Update my CDM-Core profile ....................................... 24Table 7: DLP RESTful Interface – Update metadata of my CDM-Core profile ................... 24Table 8: DLP RESTful Interface – Commit my CDM-Core profile ...................................... 25Table 9: DLP RESTful Interface – Delete ontology ............................................................ 26Table 10: DLP RESTful Interface – Add ontology .............................................................. 27Table 11: DLP RESTful Interface – Find similar entities in CDM-Core .............................. 28Table 12: DLP RESTful Interface – Determine similarity of two entities ............................ 29Table 13: DLP RESTful Interface – Execute DHS query ................................................... 30Table 14: DLP RESTful Interface – List all CDM-Core ontologies ..................................... 31Table 15: DLP RESTful Interface – Retrieve a CDM-Core ontology by ID ........................ 32Table 16: DLP RESTful Interface – Set equivalence of entities in CDM-Core ................... 32Table 17: DLP RESTful Interface – Find CDM-Core entities by name ............................... 34Table 18: DLP RESTful Interface – Increase the weight (popularity) of an entity .............. 35Table 19: DLP RESTful Interface – Read the weight (popularity) of an entity ................... 36Table 20: DHS RESTful Interface – Transform .................................................................. 42





224 / 227


Table 21: DHS RESTful Interface – Prepare Data ............................................................. 44Table 22: DHS RESTful Interface – Return Transformed Data .......................................... 45Table 23: DHS RESTful Interface – Decompose Schema ................................................. 47Table 24: DHS RESTful Interface – Analyse Concept ....................................................... 48Table 25: DHS RESTful Interface – Connect Data Source ................................................ 49Table 26: DHS RESTful Interface – Is Linked .................................................................... 50Table 27: DHS RESTful Interface – CRUD-Operation Create Map ................................... 51Table 28: DHS RESTful Interface – CRUD-Operation Read Map ..................................... 51Table 29: DHS RESTful Interface – CRUD-Operation Update Map .................................. 52Table 30: DHS RESTful Interface – CRUD-Operation Delete Map .................................... 53Table 31: DHS RESTful Interface – Attach Transformer to Map ........................................ 53Table 32: DHS RESTful Interface – Retrieve Transformer from Map ................................ 54Table 33: DHS RESTful Interface – Deploy Map as Service ............................................. 55Table 34: DHS RESTful Interface – Annotate Service ....................................................... 55Table 35: DHS RESTful Interface – Publish Map ............................................................... 57Table 36: DHS RESTful Interface – CRUD-Operation Create Concept ............................. 57Table 37: DHS RESTful Interface – CRUD-Operation Read Concept ............................... 58Table 38: DHS RESTful Interface – CRUD-Operation Update Concept ............................ 59Table 39: DHS RESTful Interface – CRUD-Operation Delete Concept ............................. 60Table 40: DHS RESTful Interface – Get Linked Concepts Simple ..................................... 60Table 41: DHS RESTful Interface – Get Linked Concepts with Method ............................ 61Table 42: DHS RESTful Interface – Get Linked Concepts with Filter ................................ 62Table 43: CRI RESTful Interface – Common Return Codes .............................................. 67Table 44: CRI RESTful Interface – Create Bucket ............................................................. 68Table 45: CRI RESTful Interface – Delete Bucket ............................................................. 69Table 46: CRI RESTful Interface – Describe Bucket .......................................................... 69Table 47: CRI RESTful Interface – Delete Bucket ............................................................. 70Table 48: CRI RESTful Interface – CRUD Operation Create ............................................. 71Table 49: CRI RESTful Interface – Read Object ................................................................ 72Table 50: CRI RESTful Interface – Update Object ............................................................. 73Table 51: CRI RESTful Interface – Delete Object .............................................................. 74Table 52: CRI RESTful Interface – Generic Query ............................................................ 74Table 53: CRI RESTful Interface – Generic Query ............................................................ 76Table 54: RESTful Interface Description – Create Repository ........................................... 77Table 55: RESTful Interface Description – Delete Repository ........................................... 77Table 56: RESTful Interface Description – Create a new Graph ........................................ 78Table 57: RESTful Interface Description – Query a RDF Graph ........................................ 79Table 58: RESTful Interface Description – Update a RDF Graph ...................................... 80Table 59: RESTful Interface Description – Delete a RDF Graph ....................................... 81Table 60: Message Description .......................................................................................... 82Table 61: CVA RESTful Interface – Create Type ............................................................... 88Table 62: CVA RESTful Interface – Create Type ............................................................... 89Table 63: CVA RESTful Interface – Get Type .................................................................... 90Table 64: CVA RESTful Interface – Get Types .................................................................. 90Table 65: CVA RESTful Interface – Create Object ............................................................ 91Table 66: CVA RESTful Interface – Delete Object ............................................................. 92Table 67: CVA RESTful Interface – Get Object ................................................................. 93Table 68: CVA RESTful Interface – Get Objects ................................................................ 94Table 69: CVA RESTful Interface – Create Simple Property ............................................. 95





225 / 227


Table 70: CVA RESTful Interface – Delete Simple Property .............................................. 96Table 71: CVA RESTful Interface – Create Complex Property .......................................... 97Table 72: CVA RESTful Interface – Delete Complex Property .......................................... 97Table 73: CVA RESTful Interface – Read Data Object ...................................................... 98Table 74: CVA RESTful Interface – Update Data Object ................................................... 99Table 75: CVA RESTful Interface – Start Object Property Value Stream ........................ 100Table 76: CVA RESTful Interface – Stop Object Property Value Stream ........................ 101Table 77: CVA RESTful Interface – Read Data Object .................................................... 102Table 78: CVA RESTful Interface – Read Data Object .................................................... 102Table 79: CVA RESTful Interface – Set Complex Property ............................................. 103Table 80: SVA RESTful Interface – Start Service ............................................................ 110Table 81: SVA RESTful Interface – Get Availability ......................................................... 111Table 82: PRU RESTful Interface – Start a Process Model Execution ............................ 130Table 83: PRU RESTful Interface – Optimised Process Model Available ........................ 130Table 84: PRU RESTful Interface – Request Process Log .............................................. 131Table 85: PRU RESTful Interface – Service Monitoring Event ........................................ 132Table 86: OSL RESTful Interface – Lease Service .......................................................... 137Table 87: OSL RESTful Interface – Release Service ....................................................... 138Table 88: OSL RESTful Interface – Leaseability Check ................................................... 139Table 89: OSL RESTful Interface – Reserve Services ..................................................... 140Table 90: OSL RESTful Interface – List all Instantiated Proxy Wrappers ........................ 141Table 91: ODERU RESTful Interface – Compose Design Time Process Service Plans . 146Table 92: ODERU RESTful Interface – Optimise Design Time Process Models ............. 148Table 93: ODERU RESTful Interface – Approve optimised process service plan ........... 149Table 94: ODERU RESTful Interface – Compose Runtime Process Service Plan .......... 150Table 95: ODERU RESTful Interface – Optimise Runtime Process Instances ................ 151Table 96: ODERU RESTful Interface – Find matching services for process step ............ 153Table 97: ODERU RESTful Interface – Retrieve Design Time Service Plans ................. 154Table 98: ODERU RESTful Interface – Retrieve Runtime Service Plans ........................ 155Table 99: MPM RESTful Interface – CRUD-Operation Create ........................................ 161Table 100: MPM RESTful Interface – Get Services ......................................................... 162Table 101: MPM RESTful Interface – Create Service ...................................................... 164Table 102: MPM RESTful Interface – Update Service ..................................................... 165Table 103: MPM RESTful Interface – Delete Service ...................................................... 166Table 104: MPM RESTful Interface – Create Proxy Service Wrapper ............................. 167Table 105: MPM RESTful Interface – Lease Services ..................................................... 167Table 106: MPM RESTful Interface – Release Services .................................................. 168Table 107: MPM RESTful Interface – Delete Proxy Service Wrapper ............................. 169Table 108: MPM RESTful Interface – Get Service Schedule ........................................... 170Table 109: MPM RESTful Interface – Create Service Schedule ...................................... 171Table 110: MPM RESTful Interface – Update Service Schedule ..................................... 172Table 111: MPM RESTful Interface – Delete Appointment from Service Schedule ......... 172Table 112: MPM RESTful Interface – Clear Service Schedule ........................................ 173Table 113: MON RESTful Interface – Create Alarm ........................................................ 180Table 114: MON RESTful Interface – List all Alarms ....................................................... 181Table 115: BDA RESTful Interface – Invoke Built Query ................................................. 186Table 116: BDA RESTful Interface – Start Listening to Streaming Data .......................... 187Table 117: BDA RESTful Interface – Stop Streaming Data ............................................. 187Table 118: BDA RESTful Interface – Push Process Data ................................................ 188





226 / 227


Table 119: PCE RESTful Interface – Send Notification ................................................... 195Table 120: PCE RESTful Interface – Create Highlighting ................................................ 196Table 121: PCE RESTful Interface – Download Highlighting ........................................... 197Table 122: PCE RESTful Interface – Replace Highlighting .............................................. 198Table 123: PCE RESTful Interface – Delete Highlighting ................................................ 199Table 124: DBV RESTful Interface – Push Notification .................................................... 206Table 125: SPC RESTful Interface – Create User ........................................................... 212Table 126: SPC RESTful Interface – Get User ................................................................ 213Table 127: SPC RESTful Interface – Get Users .............................................................. 213Table 128: SPC RESTful Interface – Update User .......................................................... 214Table 129: SPC RESTful Interface – Delete User ............................................................ 215Table 130: SPC RESTful Interface – Access User Data .................................................. 216Table 131: SPC RESTful Interface – User Login ............................................................. 216Table 132: SPC RESTful Interface – User Login ............................................................. 217Table 133: SPC RESTful Interface – User Logout ........................................................... 218Table 134: Solved Issues ................................................................................................. 220

Listings Listing 1: Data in CSV wrapped with XML document to be transformed by DHS .............. 63Listing 2: DHS Example Authorisation Definition ............................................................... 64Listing 3: String Example "mydata with UTF-8 encoding" .................................................. 71Listing 4: Create Information .............................................................................................. 82Listing 5: Read Information ................................................................................................ 82Listing 6: Query Response ................................................................................................. 82Listing 7: Sample report message for parsing error fault ................................................... 83Listing 8: Sample report message for an access denied response .................................... 83Listing 9: Sample report message for an unspecified error response ................................ 83Listing 10: Bucket Description Object ................................................................................. 84Listing 11: Bucket List ........................................................................................................ 84Listing 12: CRI Example Authorisation Definition ............................................................... 85Listing 13: CVA Example Authorisation Definition ............................................................ 105Listing 14: General Information of a Service .................................................................... 112Listing 15: Semantic Annotation of a Service ................................................................... 113Listing 16: Linked Concepts, Executable Part and Service Schedule .............................. 114Listing 17: SVA Example Authorisation Definition ............................................................ 114Listing 18: Process Definition Example ............................................................................ 121Listing 19: Abstract Service XML Element Example ........................................................ 121Listing 20: Concrete Service XML Element Example ....................................................... 122Listing 21: Constraints Dictionary ..................................................................................... 122Listing 22: Constraint XML Element Example .................................................................. 123Listing 23: PDE Example Authorisation Definition ............................................................ 124Listing 24: PRU Example Authorisation Definition ........................................................... 133Listing 25: OSL Example Authorisation Definition ............................................................ 142Listing 26: Service Schedule Scheme Example ............................................................... 174Listing 27: Service Payment information Example ........................................................... 175Listing 28: MPM Example Authorisation Definition ........................................................... 175Listing 29: Business Rule Definition Interface and Example ............................................ 176Listing 30: MON Example Authorisation Definition ........................................................... 182





227 / 227


Listing 31: API Method Signature for Invoking a Built Query ........................................... 189Listing 32: JSON Example – Invoke Query ...................................................................... 190Listing 33: BDA Example Authorisation Definition ............................................................ 190Listing 34: PCE Content Format "Notification" ................................................................. 199Listing 35: PCE Content Format "Highlighted Image" ...................................................... 200Listing 36: JSON Example – Push Notification ................................................................ 207Listing 37: Function Example – Signature of the method “getNotifications” ..................... 208Listing 38: JSON Example – Result of the method Get Notifications ............................... 208Listing 39: DBV Example Authorisation Definition ............................................................ 209Listing 40: Response from the SPC to an authorisation request ...................................... 218

Cloud-based Rapid Elastic MAnufacturing · CREMA WP3 Public Technical Specification T3.3 - D3.3 -...

Documents

Transcript of Cloud-based Rapid Elastic MAnufacturing · CREMA WP3 Public Technical Specification T3.3 - D3.3 -...