t33 d33 Technical Specification v100 PDF

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
Document Status
Danny Pape, ASC

Deliverable Lead
Tim Dellas, ASC
Internal Reviewer 1 Matthias Klusch, DFKI
Internal Reviewer 2 Dale Stone, DNIT
Type Deliverable
WP3: Architecture, Functional & Technical Specification, Security & Privacy

Work Package
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.
T3.3 - D3.3 - T3.3 - D3.3 - Technical Specification - Document Date: Page:

Status: For Approval
v1.00.docx.docx Version: 1.0 2015-12-30 2 / 227
http://www.crema-project.eu Copyright © CREMA Project Consortium. All Rights Reserved. Grant Agreement No.: 637066
Project Partners
Ascora GmbH, Germany Dot NET IT, United Kingdom
Technology Application Network Limited,

Technische Universität Wien, Austria United Kingdom
German Research Center for Artificial IKERLAN S. Coop., Spain

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

Kingdom
Goizper, Spain
FAGOR ARRASATE S. Coop., Spain
Information Catalyst, United Kingdom

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.

Table of Contents
1 Introduction ................................................................................................................... 11
1.1 CREMA Project Overview .................................................................................... 11
1.2 Deliverable Purpose, Scope and Context ............................................................ 11
1.3 Document Status and Target Audience ............................................................... 12
1.4 Abbreviations and Glossary ................................................................................. 12
1.5 Document Structure ............................................................................................. 12
2 General Description of the Technical Specification ...................................................... 13
3 General Technology Selection ...................................................................................... 14
3.1 Data Storage ........................................................................................................ 14
3.2 Security and Privacy ............................................................................................ 14
3.3 Public Interfaces ................................................................................................... 15
3.4 Data-Interchange Format ..................................................................................... 15
3.5 Semantic Data ...................................................................................................... 15
3.6 Component-based Technical Specification .......................................................... 16
4 CREMA Manufacturing Virtualisation & Interoperability Components .......................... 17
4.1 Data Model, Model Library and Profiles ............................................................... 17
4.1.1 Technology Base & Reuse ....................................................................... 17
4.1.1.1 Standards for resource codification ........................................... 17
4.1.1.2 Standards for semantic data querying and reasoning ............... 17
4.1.1.3 Missing Elements and Implementation Needs .......................... 18
4.1.2 Component Structure Overview ................................................................ 18
4.1.3 Public Interfaces ....................................................................................... 19
4.1.3.1 RESTful Interfaces .................................................................... 19
4.1.4 Content Format ......................................................................................... 36
4.1.5 Authorisation Definition ............................................................................. 37
4.2 Data Harmonisation Services ............................................................................... 37
4.2.1.1 Selection for Maps Designer and Transformation Engine ......... 38
4.2.3.1 RESTful Interfaces .................................................................... 42
4.2.4 Content Format ......................................................................................... 63
4.3 Cloud-based RAID Infrastructure ......................................................................... 64
4.3.1.1 Selection for Semi-Structured Data Storage ............................. 64
4.3.1.2 Selection for Semantic Data Storage ........................................ 65
4.3.1.3 Selection for Binary Data Storage ............................................. 65
4.3.3.1 Common Return Codes............................................................. 67
4.3.3.2 Method “Create Bucket” ............................................................ 68
4.3.3.3 Method “List Buckets”................................................................ 69
4.3.3.4 Method “Describe Bucket” ......................................................... 69
4.3.3.5 Method “Delete Bucket”............................................................. 70
4.3.3.6 Method “Create Object” ............................................................. 71

4.3.3.7 Method “Read Object” ............................................................... 72
4.3.3.8 Method “Update Object” ............................................................ 73
4.3.3.9 Method “Delete Object” ............................................................. 74
4.3.3.10 Method “Execute Generic Query”.............................................. 74
4.3.3.11 Method “Execute Delete Query” ................................................ 76
4.3.3.12 Method “Create Repository” ...................................................... 76
4.3.3.13 Method “Delete Repository” ...................................................... 77
4.3.3.14 Method “Create a new RDF Graph” .......................................... 78
4.3.3.15 Method “Query a RDF Graph” ................................................... 79
4.3.3.16 Method “Update a RDF Graph” ................................................. 80
4.3.3.17 Method “Delete a RDF Graph” .................................................. 81
4.3.4 Content Format ......................................................................................... 82
4.4 Cyber-Physical Systems, Sensor Abstraction and Virtualisation ......................... 85
4.4.4 Content Format ....................................................................................... 104
4.4.5 Authorisation Definition ........................................................................... 105
4.5 Service Virtualisation and Abstraction ................................................................ 105
4.5.1 Technology Base & Reuse ..................................................................... 106
4.5.1.1 Selection of Semantic Annotation Means................................ 106
4.5.1.2 Selection of SVA UI Engine..................................................... 106
4.5.1.3 Missing Elements and Implementation needs ......................... 107
4.5.2 Component Structure Overview .............................................................. 108
4.5.3 Public Interfaces ..................................................................................... 110
4.5.3.1 RESTful Interfaces .................................................................. 110
4.5.4 Content Format ....................................................................................... 111
5 CREMA Cloud Manufacturing Collaboration, Knowledge and Stakeholder Interaction
Framework Components .................................................................................................. 115
5.1 Cloud Collaborative Process Design Time Environment ................................... 115
5.1.1.1 Selection for BPMN Renderer and Modeller ........................... 115
5.1.1.2 Missing Elements and Implementation Needs ........................ 116
5.1.4 Content Format ....................................................................................... 120
5.1.4.1 BPMN2.0 XML......................................................................... 120
5.1.4.2 Process Definition ................................................................... 120
5.1.4.3 Service XML Element .............................................................. 121
5.1.4.4 Abstract Service XML Element Example................................. 121
5.1.4.5 Concrete Service XML Element Example ............................... 122
5.1.4.6 Meta Data XML Element ......................................................... 122
5.1.4.7 Constraints .............................................................................. 122
5.1.4.8 Custom-Meta-Model ................................................................ 123
5.2 Cloud Process and Messaging Runtime Environment ....................................... 124

5.2.1.1 Selection of a Business Process Model Execution System .... 125
5.2.1.2 Selection of a Message Bus .................................................... 125
5.2.4 Content Format ....................................................................................... 133
5.3 On-Demand Service Leasing and Releasing ..................................................... 134
5.3.1.1 Selection of Programming Language ...................................... 134
5.3.1.2 Selection of Cloud Infrastructure ............................................. 134
5.3.1.3 Selection of Service Container ................................................ 135
5.3.4 Content Format ....................................................................................... 142
5.4 Design Time and Runtime Optimisation ............................................................. 142
5.4.1.1 Semantic process service selection and planning................... 143
5.4.1.2 Dynamic process constraint optimisation ................................ 143
5.4.1.3 Semantic Data Stream Processing ......................................... 144
5.4.4 Content Format ....................................................................................... 156
6 CREMA Cloud Manufacturing Process and Optimisation Framework Component .... 157
6.1 Marketplace and Monetisation ........................................................................... 157
6.1.1.1 Monetisation Environment ....................................................... 157
6.1.1.2 Monetisation Provider.............................................................. 157
6.1.1.3 Marketplace Environment........................................................ 157
6.1.1.4 Resource Management ........................................................... 158
6.1.1.5 REST Client............................................................................. 158
6.1.3.1 Method “Get Service” .............................................................. 161
6.1.3.2 Method “Get Services” ............................................................ 162
6.1.3.3 Method “Create Service” ......................................................... 164
6.1.3.4 Method “Update Service” ........................................................ 165
6.1.3.5 Method “Delete Service”.......................................................... 166
6.1.3.6 Method “Create Proxy Service Wrapper” ................................ 166
6.1.3.7 Method “Lease Service” .......................................................... 167
6.1.3.8 Method “Release Service” ....................................................... 168

6.1.3.9 Method “Delete Proxy Service Wrapper”................................. 169
6.1.3.10 Method “Get Service Schedule” .............................................. 169
6.1.3.11 Method “Schedule Service” ..................................................... 171
6.1.3.12 Method “Update Service Schedule” ........................................ 171
6.1.3.13 Method “Delete Appointment from Service Schedule” ............ 172
6.1.3.14 Method “Clear Service Schedule” ........................................... 173
6.1.1 Content Format ....................................................................................... 174
6.2 Monitoring & Alerting .......................................................................................... 176
6.2.1.1 Selection for Business Rule Definition Language ................... 176
6.2.1.2 Selection for Rule Engine ........................................................ 177
6.2.1.3 Selection for Business Rule and KPI Storage ......................... 177
6.2.1.4 Selection for Monitoring and Alerting API Implementation ...... 177
6.2.1.5 Selection for Rules UI (Integrated with DBA) .......................... 177
6.2.4 Content Format ....................................................................................... 181
6.3 Manufacturing Big Data, Knowledge and Analytics ........................................... 182
6.3.1.1 Selection of Base Platform ...................................................... 183
6.3.1.2 Selection of Data Analytic Framework .................................... 183
6.3.1.3 Selection of Data Storage ....................................................... 183
6.3.1.4 Selection of Stream Processing Technology........................... 183
6.3.1.5 Selection of Visualisation ........................................................ 184
6.3.3.2 Java Interfaces ........................................................................ 189
6.3.4 Content Format ....................................................................................... 189
6.4 Agile Personal Collaboration Environment ......................................................... 190
6.4.1.1 Data Exchange Infrastructure.................................................. 191
6.4.3.1 Method “Send Notification” ...................................................... 195
6.4.3.2 Method “Upload Highlighting” .................................................. 196
6.4.3.3 Method “Download Highlighting” ............................................. 197
6.4.3.4 Method “Replace Highlighting” ................................................ 198
6.4.3.5 Method “Delete Highlighting” ................................................... 199
6.4.4 Content Format ....................................................................................... 199
6.5 Dashboard & Visualisation ................................................................................. 201

6.5.1.1 Dashboard Content ................................................................. 201
6.5.1.2 Corporate Design .................................................................... 202
6.5.1.3 Dashboard Interaction ............................................................. 203
6.5.3.1 Method “Push Notification” ...................................................... 206
6.5.4 Content Format ....................................................................................... 207
7 Security and Privacy Component ............................................................................... 210
7.1.1.1 Technical Solution to Authentication ....................................... 210
7.1.1.2 Technical Solution to Authorisation ......................................... 210
7.1.1.3 Technical Solution to Privacy .................................................. 210
7.1.3.1 Method “Create User”.............................................................. 212
7.1.3.2 Method “Get User”................................................................... 212
7.1.3.3 Method “Get Users” ................................................................. 213
7.1.3.4 Method “Update User” ............................................................. 214
7.1.3.5 Method “Delete User” .............................................................. 215
7.1.3.6 Method “Access User Data” .................................................... 216
7.1.3.7 Method “User Login”................................................................ 216
7.1.3.8 Method “Authenticate Token” .................................................. 217
7.1.3.9 Method “User Logout” ............................................................. 218
7.1.4 Content Format ....................................................................................... 218
8 Transmitted Issues...................................................................................................... 220
9 Conclusion .................................................................................................................. 221

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.

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

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.

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

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
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/
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.
Data Model, Model Library

and Profiles (DLP)
T4.3 CREMA Cloud-
Semantic Data Manager System request request based RAID
Semantic Data
Infrastructure (CRI)
- Generic management (CRUD) Manipulation
- Predefined specialized queries query/ query/
results results
Ontologies
query/command response
execution
Data Model Framework API Linked

Data
CRUD predefined
execution response query response
request execution
request
T4.2 CREMA Data

CREMA
Harmonisation
Component X
Services (DHS)
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
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
13
http://json-ld.org/
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 Name Description Example

Parameters
userToken : string The userToken propagated User1234
through all requests.
HTTP object : object An object representing one {

Parameters or all of the domains “domain”:
“manufacturing”
}
Combined GET /dlp/ontology?session=user1234 HTTP/1.1

Example Host: crema.eu
object={“domain” : “manufacturing”}
Response
HTTP Status Value Description

Code
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 Name Description

Attributes
Result : ontologies (only An object representing JSON-LD serialisation format of the
HTTP/200 result) ontologies labelled with the requested domain(s).
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
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.

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

Parameters
HTTP object : object An object representing the {

Parameters named graph of the profile “named_graph”:”uc_23”
to be read
}
Combined GET /dlp/profile/others?session=user1234 HTTP/1.1

object={“named_graph” : “uc_23”}
Response

Code
400 Named graph unknown

Attributes
Result : ontology (only An object representing JSON-LD serialisation format of the
HTTP/200 result) ontology identified by the named graph received
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
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

Parameters

HTTP object : object An object representing

Parameters JSON-LD serialisation
format of the profile to be
stored.
Combined POST /dlp/profile/others?session=user1234 HTTP/1.1

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

Code
201 Profile stored correctly
409 Profile not stored correctly
520 Impossible to copy the profile
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
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

Parameters
Combined GET /dlp/profile/mine?session=user1234 HTTP/1.1

Response

Code
201 Profile read correctly
409 Profile does not exists
Name Description
JSON Result : ontology (only An object representing JSON-LD serialisation format of the
Attributes HTTP/200 result) ontology identified by the named graph received
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
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

Parameters

format of the updated
profile to be stored.
Combined PUT /dlp/profile/mine?session=user1234 HTTP/1.1

Response

Code
202 Profile updated correctly
409 Profile does not exists
520 Impossible to update the 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

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

Parameters

format of the new profile to
be stored.
Combined POST /dlp/profile/mine?session=user1234 HTTP/1.1

Response

Code
200 Updated profile correctly stored
409 Profile to update does not exist
520 Impossible to update the profile passed
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 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.

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

Parameters

Parameters JSON-LD serialization
format of the new profile to
be stored.
Combined POST /dlp/metadata/mine/?session=user1234 HTTP/1.1

Response

Code
200 Updated profile correctly stored
409 Profile to update does not exist
520 Impossible to update the profile metadata requested
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
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

Parameters

Parameters JSON-LD serialization

format of the profile to be

stored.
Combined PUT /dlp/profile/mine/commit?session=user1234 HTTP/1.1

Response

Code
202 Commit executed successfully
409 Commit failed
520 Impossible to execute the search requested
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
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

Parameters
HTTP object : object An object representing the {“named_graph” :

Parameters named graph of the “uc_23”}
ontology to be deleted
Combined DELETE /dlp/ontology?session=user1234 HTTP/1.1

Response

Code
200 Ontology correctly deleted

404 Ontology to delete does not exist
520 Impossible to execute the requested deletion operation
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
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

Parameters

Parameters requested named graph “named_graph”: “uc_23”,
and the JSON_LD
serialization format of the “ont”: JSON-LD(ont)
ontology to store. }
Combined POST /dlp/ontology?session=user1234 HTTP/1.1

object=name of the graph and JSON-LD encode of the ontology to store
Response

Code
200 Ontology correctly inserted
404 Ontology to store already exists
520 Impossible to execute the requested insertion operation
Name Description

JSON Result : identifier given to ----

Attributes the named graph (only
HTTP/200 result)
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
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

Parameters
HTTP object : object An object representing the {"refString": "someValue",

"weights": [30,25,45],
Parameters parameters searched
"limiting_NR": 30}
Combined GET /dlp/similarity/open?session=user1234 HTTP/1.1

object={"refString": "Machine", " weights": [30,25,45],"limiting_NR":
30}
Response

Code
400 Concept not found
Name Description

JSON Result : list of resources {"NR": 30 , "results": [

Attributes returned with their {"URI1#Machine":87.50},{”
similarity measure (only URI1#Machine_Resource”:35.55}, {”
HTTP/200 result) URI1#Machine_Operator”:35.55}, {“
URI2#operative_Machine”:27}, … ] }
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
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

Parameters
HTTP object : object An object representing {Resource1:

Parameters JSON serialization format “CM:Machine” ,
of the following parameters: Resource2 :
“UC_23:Machinery” }
Resource1 : string The full URI of the first http://crema-

resource project.eu/DLP/Conditio
nalMonitoring.owl#Machi
ne
Resource2 : string The full URI of the second http://crema-

resource project.eu/DLP/LDs/
XYZ_987654321#Machinery
Combined GET /dlp/similarity/closed/?session=user1234 HTTP/1.1

object={Resource1: “ http://crema-
project.eu/DLP/ConditionalMonitoring.owl#Machine”, Resource2:
“http://crema-project.eu/DLP/LDs/ XYZ_987654321#Machinery” }
Response

Code
200 Similarity computation correctly executed
204 Similarity computation correctly executed, no value returned

400 Concept(s) not found
520 Impossible to execute the research requested

Attributes
Result : decimal value of An object representing JSON-LD serialisation format of the
the similarity computed local linked data identified by the received ID.
(only HTTP/200 result)
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
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

Parameters
HTTP object : object An object representing the {"QueryID": " QRY_4321",

"par1": "someValue", "par2":
Parameters parameters to be matched
"SomeValue2", "par3": 95 }
into the predefined query
requested
Combined GET /dlp/query/DHS?session=userToken

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

Code
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


Attributes
Result : JSON object An object representing JSON serialisation format of the
(only HTTP/200 result) result provided by the query invoked
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
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

Parameters
Combined GET /dlp/ontology/list?session=userToken

Response

Code
200 Request of listing correctly executed
204 Request of listing correctly executed, no value returned
520 Impossible to execute the listing requested

Attributes
Result : JSON object { "results": [ “uc_23”, “uc_1”, “uc_3”, … ] }
containing the named
graphs (only HTTP/200
result)
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.

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

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

Parameters
HTTP object : object An object representing the {“named_graph” : “uc_23”}

Parameters named graph of the
ontology to be deleted
Combined GET /dlp/ontology/byID?session=userToken

Response

Code
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

Attributes
Result : JSON-LD An object representing JSON-LD serialisation format of the
encoded object (only ontology identified by the received ID.
HTTP/200 result)
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
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

(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

Parameters
HTTP object : object An object representing { “Concept1”: “CM:Machine”,

Parameters JSON serialization format “Concept2”:
of the following parameters: “CM:Machine_Resource”,
“type”:
“owl:EquivalenceClass”}
Concept1 : string The full URI of the first http://crema.eu/DLP/Condition

alMonitoring.owl#Machine
concept
Concept2 : string The full URI of the second http://crema.eu/DLP/Condition

concept alMonitoring.owl#Machine_Reso
urce
Type : string One of the foreseen linkage owl:EquivalenceClass

types
Combined POST /dlp/ontology/equivalence?session=userToken

object={ “Concept1”: “
http://crema.eu/DLP/ConditionalMonitoring.owl#Machine ”, “Concept2”: “
http://crema.eu/DLP/ConditionalMonitoring.owl#Machine_Resource”,
“type”: “owl:EquivalenceClass”}
Response

Code
200 statement correctly stored
400 Concept(s) not found
404 User profile not existing
520 Impossible to execute the similarity computation requested
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.

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

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

Parameters
HTTP object : object An JSON object of the { “searchkey”: “Machine”,

Parameters following parameters: “entity”: “concept”,
“type”: “substring”}
type : string The type of matching “type”: “substring”

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

(can be “concept” or
“relation”)
searchkey : string The string to use as search “searchkey”: “Machine”,

value
Combined GET /dlp/ontology/search?session=userToken

object={“searchkey”: “Machine”, “entity”: “concept”, “type”:
“substring”}
Response

Code
200 Search correctly executed, returned result(s)
204 Search correctly executed, no matching returned

Attributes
Result : JSON object { "results": [ {“
containing the named http://crema.eu/DLP/ConditionalMonitoring.owl#Ma
graphs (only HTTP/200 chine”, 100}, {“
result) http://crema.eu/DLP/ConditionalMonitoring.owl#Ma
chine_Resource”, 43.75}, … ] }
4.1.3.1.18 Method “Increase the Weight (Popularity) of an Entity”

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

Parameters
HTTP object : object An JSON object of the { “entity”:

“Administrative_Entity”,
Parameters following parameters:
“value”: 1}
entity : string The full URI of the first http://crema.eu/DLP/MASON.owl

#Administrative_Entity
concept
value: string The amount (integer) to be 1

added to the entity
“popularity”
Combined POST /dlp/popularity?session=userToken

object={“entity”: “Administrative_Entity”, “value”: 1}
Response

Code
200 weight correctly updated
520 Impossible to store weight values

Attributes
Result : JSON object { "results": [ {“
containing the named http://crema.eu/DLP/ConditionalMonitoring.owl#Ma
graphs (only HTTP/200 chine”, 100}, {“
result) http://crema.eu/DLP/ConditionalMonitoring.owl#Ma
chine_Resource”, 43.75}, … ] }
4.1.3.1.19 Method “Read the Weight (Popularity) of an Entity”

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

Parameters
HTTP object : object An JSON object of the {“entity”:

“Administrative_Entity”}
Parameters following parameters:
entity : string The full URI of the first http://crema.eu/DLP/MASON.owl

#Administrative_Entity
concept
Combined GET /dlp/popularity?session=userToken

object={“entity”: “Administrative_Entity”}
Response

Code
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 http://crema.eu/DLP/MASON.owl#Administrative_Ent
the entity (only ity”, 7}
HTTP/200 result)
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.

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.

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

Instantiated
Service Proxy Service
Wrapper (via PRU)
Data source exe Data target

transformation
T6.3 CREMA Manufacturing External Objects External Datasources
Big Data, Knowledge and
Analytics (BDA)
analyse fetch data

semantic data transformed
relevant
data semantic relevant data/ retrieve
analysed semantic schema data data CREMA Data
relevant data schema
Harmonisation
data/ <<interface>>
data Services (DHS)
<<interface>> analysed data schema
Data Source
Schema Analyser retrieve
analyse Connectors
schema serialise
analyse linked data data
concepts analysed data
get
linked concepts schema
exe
<<interface>> <<interface>> transformation
Linked Concepts data Harmonisation data/data transformed Harmonisation
Analyser schema wrapper Services
[Ad-hoc] exe transformation
data/
transformed data
get/provide exe data/
linked
linked concepts transformation transformed data
concepts
get/provide
Linked Concepts linked Transformation
Services and concepts Maps Designer
Engine
Visualiser linked concepts [Talend Open Studio for Data Integration]
[Docker services]
[Ad-hoc]
show
linked
linked concepts store/retrieve retrieve
concepts provide
concepts provide concepts map maps maps
get/provide concepts publish
linked concepts concepts get
<<interface>> <<interface>>
<user interface> <<interface>> <user interface> <<interface>>
Linked Concepts Concept Provider
Mapping UI Access to DLP Publish in MPM Access to CRI
API API
provide
get/provide concepts concepts get/set store/
linked execute publish maps maps
linked concepts concepts semantics retrieve
concepts
<user interface> T4.1 CREMA Data T6.1 CREMA T4.3 CREMA Cloud-
T4.5 (SVA)
T6.5 CREMA Model, Model Library Marketplace and based RAID
T5.1 (PDE)
Dashboard and and Profiles (DLP) Monetisation (MPM) Infrastructure (CRI)
Visualisation (DBV)
Maps
Store
Specific CPS Gateway (CVA/WP7/

WP8), T6.3 CREMA Manufacturing Big
Data, Knowledge and Analytics (BDA)
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.

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

Parameters
engineId : string ID of the Map fromFagorClutch42
HTTP userToken : string The userToken P3L4CtoKn

Parameters propagated
through all
requests.
object : object A serialised <transformation>

<engineId>fromFagorClutch42</engineId>
object to
<engineVersion>1.4</engineVersion>
transform, <sourceFormat>CSV</sourceFormat>
embed in a <targetFormat>XML</targetFormat>
wrapper <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 POST /dhs/transform/fromFagorClutch42?session=P3L4CtoKn HTTP/1.1

object=<transformation><engineId>fromFagorClutch42</engineId><engineV
15
http://json-ld.org/
ersion>1.4</engineVersion><sourceFormat>CSV</sourceFormat><targetForm
at>XML</targetFormat><dataIn><![CDATA[name;temperature;pressure|\n|cl
utch1;63.1;600|\n|clutch2;61.7;586|\n|clutch3;59.7;614|\n|clutch4;64.
1;603|\n|]]></dataIn></transformation>
Response

Code
200 Object transformed
401 Insufficient rights
404 Map not found
502 Invalid transformation
HTTP Entity <transformation>

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

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=t
argetFormat&version=version&session=userToken

Parameters
engineId : string Id of the transformation fromFagorClutch42
engine
sourceFormat : string Format of the source data CSV
targetFormat : string Format of the target data XML
version : string Version of the transformation 1.4

engine
HTTP userToken : string The userToken propagated P3L4CtoKn

Parameters through all requests.
object : object An object representing an name;temperature;pressu

object of the specified data re|\n|
type. clutch1;63.1;600|\n|
clutch2;61.7;586|\n|
clutch3;59.7;614|\n|
clutch4;64.1;603
Combined POST
Example /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

Code
200 Schema analysed
204 Schema processed correctly but no result provided
409 Object with specific ID already exists in the Bucket
HTTP Entity <transformation>

<sourceFormat>CSV</sourceFormat>
<targetFormat>XML</targetFormat>
<dataIn><![CDATA[
clutch1;63.1;600|\n|
clutch2;61.7;586|\n|
clutch3;59.7;614|\n|
clutch4;64.1;603|\n|
]]></dataIn>
</transformation>
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
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

Parameters
engineId : string Id of the transformation transport
engine

object : object An object representing an <transformation>

object of the specified data <engineId>fromFag
type. orClutch42</engineId>
<engineVersion>1.
4</engineVersion>
<sourceFormat>CSV
</sourceFormat>
<targetFormat>XML
</targetFormat>
<dataIn><![CDATA[
{
"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>
Combined POST / dhs/returntransformation/fromFagorClutch42?session=P3L4CtoKn

Example HTTP/1.1
Host: crema.eu
object=[{"name":"temp1","value":"45.3"},{"name":"pressure1","value":"
1.2"}]
Response

Code
200 Schema analysed
409 Object with specific ID already exists in the Bucket
HTTP Entity {
"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"
}
]
}
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
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

Parameters
domainId : string? Optional domain transport

[
object : object An object representing an
{
object of the specified data
"name": "temp1",
type.
"value": "45.3"
},
{
"name": "press1",
"value": "1.2"
}
]
Combined POST /dhs/decomposeschema?domain=transport&session=P3L4CtoKn HTTP/1.1

object=[{"name":"temp1","value":"45.3"},{"name":"pressure1","value":"
1.2"}]
Response


Code
200 Schema analysed
HTTP Entity [
{
"concept": "Temperature"
},{
"concept": "Pressure"
},{
"concept": "Time"
}
]
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
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

Parameters
domainId : string Optional domain transport

object : object An object representing an

{
object of the concept
"town": "Milano"
extracted from the schema.
}
Combined POST /dhs/analyseconcept?session=P3L4CtoKn34 HTTP/1.1
object={"town":"Milano"}
Response

Code
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
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
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 Name Description

Parameters
userToken : string The token propagated P3L4CtoKn
through all requests
object : object Setup of the data source {

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

object={"schemaUrl": "https:\/\/crema.eu\/schema\/sch001.dtd",
"format":"DTD", "version":"1.0"}
Response

Code
200 Schema was successfully accessed
204 Not possible to access the schema with current setup
404 Schema not found
4.2.3.1.7 Method “Is Linked”

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

Parameters
conceptId1 : string ID of first concept 2b76
conceptId2 : string ID of second concept 3f8c
HTTP maxDepth : integer Max number of levels to look 10

Parameters for linked concepts
userToken : string The userToken propagated P3L4CtoKn

Combined GET /dhs/link/2b76/3f8c?depth=10&session=P3L4CtoKn HTTP/1.1

Response

Code
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"
]
]
4.2.3.1.8 Method “Create Map”

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
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 Name Description Example

Parameters
file : file A file that contains the (Binary content of the

Manufacturing Map project Manufacturing Map)
created by TOS
Combined POST /dhs/map?session=P3L4CtoKn HTTP/1.1

object=(Binary content of the Manufacturing Map)
Response

Code
201 Map created
404 Knowledge Domain not found
HTTP Entity ID of the Map created

Example:
3f5b
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
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

Parameters
mapId : string ID of the Map 3f5b
HTTP userToken : string The token propagated P3L4CtoKn

Parameters through all requests
Combined GET /dhs/map/3f5b?session=P3L4CtoKn HTTP/1.1

Response

Code
200 Map found
204 Map not found

(Binary content of the Manufacturing Map)
HTTP Entity Result: (Binary stream, only
if Status Code is 200)
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
Update Map
Description This method allows to update an existing Map.
Request
Request URL PUT http://crema.eu/dhs/map/mapId?session=userToken

Parameters

object : object An object representing an (Binary content of the

Map with the data to be Manufacturing Map)
updated
Combined PUT /dhs/map/3f5b?session=P3L4CtoKn HTTP/1.1

object=(Binary content of the Manufacturing Map)
Response

Code
200 Found Map updated
204 Map not found

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
Delete Map
Description This method allows to delete an existing Map
Request
Request URL DELETE http://crema.eu/dhs/map/mapId?session=userToken

Parameters

Combined DELETE /dhs/map/3f5b?session=P3L4CtoKn HTTP/1.1

Response

Code
200 Map deleted
204 Map not found
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
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

Resource mapId : string ID of the map 3f5b

Parameters
file : file A file that contains the JAR (binary content of the
library that will carry out the JAR)
transformation for the
corresponding map
Combined PUT /dhs/map/3f5b/transformer?session=P3L4CtoKn HTTP/1.1

file=(binary content of the JAR)
Response

Code
200 Transformation attached to map
404 Map not found
503 Unable to attach transformation to map
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
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

Parameters
mapId : string ID of the map 3f5b

Combined GET /dhs/map/3f5b/transformer?session=P3L4CtoKn HTTP/1.1

Response

Code
200 Transformation attached to map
204 Map found but no transformation was attached

404 Map not found
HTTP Binary stream with the content of the JAR library
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
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

Parameters

Combined PUT /dhs/map/3f5b/publish?session=P3L4CtoKn HTTP/1.1

Response

Code
201 Map deployed
404 Map not found
412 Map exists but no transformer JAR was attached to it
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
Annotate Service
Description This method attaching some meta information to the transformation service of a map
Request

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

Parameters

metadata : object JSON structure containing all {

the metadata associated to a "mapId": "3f5b",
Transformation Service "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"
]
}

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":"enable
d","accessGroups":"FAGOR"},"keywords":["fagor","clutch","transformation","clutchXYZ3
46"]}
Response

Code
201 Map correctly annotated
404 Map not found

412 Map exists but no deployment found
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
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

Parameters


Response

Code
201 Map published
404 Map not found
412 Map exists but no transformer was attached to it
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
Create Concept
Description This method allows to store a new concept.
Request
Request URL POST http://crema.eu/dhs/concept?session=userToken

Parameters


object : object An object representing a See JSON-LD specification

concept to be created
Combined POST /dhs/map?session=P3L4CtoKn HTTP/1.1

object=JSON-LD encode of the concept to be created
Response

Code
201 Concept created
HTTP Entity ID of the concept created (URL-encoded URI)

Example:
http://www.example.com/ontology.owl/MyConcept
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
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

Parameters
conceptId : string ID (URL-encoded URI) of http%3A%2F%2Fwww.exam
the concept ple.com%2Fontology.ow
l%23MyConcept
HTTP userToken : string The token propagated P3L4CtoKn

Parameters through all requests
Combined GET
Example /dhs/map/http%3A%2F%2Fwww.example.com%2Fontology.owl%23MyConcept?sessi
on=P3L4CtoKn HTTP/1.1
Host: crema.eu
Response

Code
200 Concept found

HTTP Entity Result : JSON-LD encoded An object representing JSON-LD serialisation format of
object (only HTTP/200 the ontology identified by the received ID
result)
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
Update Concept
Description This method allows to update an existing concept.
Request
Request URL PUT http://crema.eu/dhs/concept/conceptId?session=userToken

Parameters
conceptId : string ID (URL-encoded URI) of the http%3A%2F%2Fwww.exampl
concept e.com%2Fontology.owl%23
MyConcept

object : object An object representing a An object representing

concept with the data to be JSON-LD serialisation format
updated of the ontology identified by
the received ID
Combined PUT
Example /dhs/concept/http%3A%2F%2Fwww.example.com%2Fontology.owl%23MyConcept?s
ession=P3L4CtoKn HTTP/1.1
Host: crema.eu
object= JSON-LD encode of the Concept to be updated
Response

Code
200 Concept updated
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.

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

Delete Concept
Description This method allows to delete an existing concept
Request
Request URL DELETE http://crema.eu/dhs/concept/conceptId?session=userToken

Parameters
conceptId : string ID (URL-encoded URI) of http%3A%2F%2Fwww.exam
the Concept ple.com%2Fontology.ow
l%23MyConcept

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

Code
200 Concept deleted
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
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

Parameters
conceptName : string Name of the concept city
HTTP maxDepth : integer? Max number of levels to look 10

Parameters for linked concepts


Combined GET /dhs/concept/city/links?depth=10&session=P3L4CtoKn HTTP/1.1

Response

Code
200 Link found
204 No Concepts related
HTTP Entity List of Concepts in JSON-LD format
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
Is Linked
Description This method allows to retrieve a path of linked concepts between two concepts.
Request

method=methodName&depth=maxDepth&session=userToken

Parameters
conceptName : string Name of the concept city
HTTP methodName : string Method used to get the namesimilarity

Parameters related concepts (e.g. link,
name similarity, description
similarity)
maxDepth : integer? Max number of levels to look 10

for linked Concepts

Combined GET
Example /dhs/concept/city/links?method=namesimilarity&depth=10&session=P3L4Ct
oKn HTTP/1.1
Host: crema.eu
Response

Code
200 Link found

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

filter=filterList&depth=maxDepth&session=userToken

Parameters
conceptName : string Name of the Concept city
HTTP filterList : string List of conditions Lan:EN;Domain:Geography

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

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

Code
200 Link found

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
<transformation>
<formatIn>CSV</formatIn>
<formatOut>XML</formatOut>
<dataIn><![CDATA[
clutch1;63.1;600|\n|
clutch2;61.7;586|\n|
clutch3;59.7;614|\n|
clutch4;64.1;603
]]></dataIn>
</transformation>
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.

Listing 2: DHS Example Authorisation Definition

{
"userId": "758920",
"user”: "Higuain Hernandez",
"company": "FAGOR",
"authorisation":
[
{"company": "FAGOR", "permission": "Full Access, Restricted Resources"},
{"company": "GOIZPER", "permission": "unauthorised"}
];
}
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/
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/
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
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.
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

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)
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
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 bucket_name : Name of the bucket to be products

Parameters created
BucketName user_icons
application/json
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

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
List Buckets
Description Retrieves a list of buckets for a type
Request
Request URL GET /version/crema/cri/owner/type/info
type : BucketType Datatype of resource(s) semistructured
Response
200 Success
HTTP Body Delivers general bucket information and an array of bucket IDs
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
Describe Bucket
Description Returns information about the bucket
Request
Request URL GET /version/crema/cri/owner/type/core/bucket_name

type : BucketType Datatype of resource(s) semistructure

d
bucket_name : Name of the bucket customers

BucketName
Response
HTTP Status Code Value Description
200 Success
404 Bucket not found
HTTP Body Contains a bucket description object
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
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
bucket_name : Name of the bucket customers

BucketName
Response
200 Bucket has been deleted

… See Table 43 for miscellaneous codes.
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"
{"rawdata": [{"$binary": "bXlkYXRh", "type":"\x02"}]}
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
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
bucket_name : Name of the bucket where the customers

BucketName object shall be stored
JSON Body rawdata : An array of 1..n objects

Parameters JSONobject[]
application/json
acl : AclDef? Create object(s) with special ACL
Binary Applicable only for Binary Buckets. This creates a single binary object with the
application/octet- default ACL.
stream
20
https://docs.mongodb.org/manual/reference/mongodb-extended-json/#binary
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.
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
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
bucket_name : Name of the corresponding customers

BucketName bucket
id : ObjectId Id of the object to be updated 1a2b3c
JSON Body acl : AclDef? Updates the ACL of the object

Parameters
rawdata : JSONobject An array with 1 object
Response

200 Object updated
404 Object not found
HTTP Body Contains either an object, no payload or a message
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
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
bucket_name : Name of the corresponding customers

BucketName bucket
id : ObjectId Id of the object to be updated 1a2b3c
JSON Body acl : AclDef? Updates the ACL of the object

Parameters
rawdata : JSONobject An array with 1 object
Response
200 Object updated

HTTP Body Contains either an object, no payload or a message
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
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
bucket_name : Name of the bucket containing the customers

BucketName object
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
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
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/core/bucket_name
type : BucketType Datatype semistructure

d
bucket_name : Name of the bucket to be queried customers

BucketName
HTTP Body (JSON) last_id : JSON? The value given by the last page 12345
read, or Null for the first read
request issued.
limit : int? Maximum number of records to 10

return
query : MongoDB query to execute.

JSONObject? 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 12345

read, or Null if there is no further
content.
num_read : int Number of records returned 10
Values : ReadInfo[]

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

d
bucket_name : Name of the bucket to be queried customers

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

read)
Response
200 Success
HTTP Body (JSON) Name : Type Description Example
num_deleted : int Number of records deleted 10
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.

Table 54: RESTful Interface Description – Create Repository

Create a Repository
Description Creates a new repository.
Request
Request URL POST http://crema.eu/cri/semantic?session=userToken

Parameters
userToken : string? The user token propagated User1234
HTTP object : object An object that holds the {

Parameters repository information. The “id”:”repoId”,
values for “id” and “name”
are mandatory. “title”:”repoTitle”,
}
Combined POST /cri/semantic/?session=user1234 HTTP/1.1

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

Code
201 Repository created
409 Repository exists already
502 Database error
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
Delete a Repository
Description Deletes a specific repository.
Request
Request URL DELETE http://crema.eu/cri/semantic/repositoryId?session=userToken

Parameters
repositoryId : string ID of the Bucket repostory123


Combined DELETE /cri/semantic/repository123?session=user1234 HTTP/1.1

Response

Code
200 Repository deleted
404 Repository not found
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
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

Parameters
repositoryId : string ID of the Bucket repository123
userToken : string? The userToken propagated User1234

HTTP object : object A full CREATE graph {

Parameters management operation in “create”:”CREATE GRAPH
SPARQL 1.1 Update format. <http://crema/graph>“
}
POST /cri/semantic/repository123?session=user1234 HTTP/1.1
Combined
Content-Type: application/x-www-form-urlencoded
object={"create": "CREATE GRAPH <http://cream/graph>"}
Response

Code
201 RDF Graph created
409 RDF Graph exists already
502 Database error

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

Parameters
repositoryId : string Name of the Bucket repository123

HTTP object : object An object that holds a {"query": "

Parameters SPARQL 1.1 query. PREFIX xsd:
<http://www.w3.org/2001
/XMLSchema#>
PREFIX ns:
<http://crema.eu/ns#/>
SELECT * {?s ?p ?o}"}
POST /cri/semantic/repositoryIdquery?session=user1234 HTTP/1.1
Combined
object={"query": "PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX ns: <http://crema.eu/ns#>
SELECT * {?s ?p ?o}"}}
Response

Code
201 OK
409 Query not in SPARQL 1.1 format
502 Database error

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

"@context": "http://crema.eu/cps.jsonld",
"@id": " http://crema.eu/ ",
"key1": "valu1",
"key2": "value2"
}
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
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

Parameters

HTTP object : object An object representing a {

Parameters SPARQL 1.1 Update string. "update": "PREFIX ns:
<http://crema.eu/ns#>
INSERT DATA
{ GRAPH
<http://crema/graph> {
<http://crema/entry1>
ns:price 42 } “}"
}
PUT /cri/semantic/repository123?session=user1234 HTTP/1.1
Combined
object={"update": "PREFIX ns: <http://crema.eu/ns#>
INSERT DATA
{ GRAPH <http://crema/graph> { <http://crema/entry1> ns:price 42 } "}
Response

Code
201 OK

409 Update operation not in SPARQL 1.1 Update format
502 Database error

JSON Optional Update An optional result of the update operation. Can also include
Attributes result an exception message.
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
Delete a RDF Graph
Description Deletes all data entries of a graph.
Request
Request URL DELETE http://crema.eu/cri/semantic/repositoryName?session=userToken

Parameters

HTTP object : object A full DROP graph {

Parameters management operation in "delete":"DROP GRAPH
SPARQL 1.1 Update format.
<http://crema/graph>"
}
DELETE /cri/semantic/repository123?session=user1234 HTTP/1.1
Combined
object={"delete":"DROP GRAPH <http://crema/graph>"}
Response

Code
201 Graph deleted
409 RDF Graph not found
502 Database error

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
{
"_typeName": "CreateInfo", //(This object type)
"id": "012345-123-1234567890", //Document ID
"etag": "\"0123456789012345\"" //Document revision
}
Listing 5: Read Information

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

{
"_typeName": "QueryResponse",
"lastId": "012345-123-1234567890",
"numRead": 10,
"values":[
… /* Read Info */
]
}
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

Listing 7: Sample report message for parsing error fault

{
"_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",
}
Listing 8: Sample report message for an access denied response

{
"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",
}
Listing 9: Sample report message for an unspecified error response

"{
"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",
}

Listing 10: Bucket Description Object

{
"_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
}
}
Listing 11: Bucket List

{
"_typeName" : "bucketList",
"itemCount" : "325"
"bucketList" :
[
{
"id" : "5459d6c482e88c8c0b000029",
"name" : "pdf_file_23",
"type" : "binary"
},
{…}
]
}
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.

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
{
"userId":"19929",
"user": "Brian Branston",
"company ": "Tenneco",
"authorisation":
{
"permission":
{
"level": ”ReadOnly",
"scope":
[{
"bucketid":"5498",
"dataObjectIds":["129864","321","4783",…]
},{
"bucketid":"2486",
"dataObjectIds":["4682","123","3874",…]
}]
}
}
}
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/
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
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
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

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

"type": "Int"
}]
}
Combined POST /cva/sf HTTP/1.1

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

Code
201 Type created
409 Type exists already
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
Delete Type
Description This method deletes an existing type in SF.
Request
Request URL DELETE http://crema.eu/cva/sf/typeId

Parameters
typeId : string Name of the type Person
Combined DELETE /cva/sf/Person HTTP/1.1

Response

Code
200 Type deleted
404 Type does not exist

JSON None None
Attributes
4.4.3.1.3 Method “Get Type”

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
Get Type
Description This method gets all properties of a type available in SF
Request
Request URL GET http://crema.eu/cva/sf/typeId

Parameter
typeId : string Name of the Type Person
Combined GET /cva/sf/Person HTTP/1.1

Response

Code
201 Type has been found
404 Type not found
JSON List A list of all type Ids and their properties

Attributes Optional list {
"typeId": "Person",
"propertyArray": [{
"propertyId": "name",
"flag": "name",
"type": "String"
}, {
"propertyId": "function",
"type": "String"
}, {
"propertyId": "age",
"type": "Int"
}]
}
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 Types
Description This method gets the list of types available in SF, each with a list of its available simple
properties.

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

Response

Code
201 At least one type found in list, list is output
404 Type not found
JSON List A list of all type Ids and their properties

Attributes Optional list [{
"typeId": "Person",
"properyArray": [{
"flag": "name",
"type": "String"
}, {
"propertyId": "function",
"type": "String"
}, {
"propertyId": "age",
"type": "Int"
}]
}, {
"typeId": "Machine",
"properyArray": [{
"flag": "name",
"type": "String"
}, {
"propertyId": "model",
"type": "String"
}, {
"propertyId": "production date",
"type": "Time"
}]
}
…
]
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
Create 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

Parameters
typeId : string Name of the type Person
HTTP object : object Object of a given type {

Parameters
“name”: ”Danny”,
“function”: “Engineer”,
“age”: “31”
}
Combined POST /cva/sf/Person/Objects HTTP/1.1

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

Code
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 none none
Attributes
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
Delete Object
Description This method deletes the instance of an object of a given type and all its property values.
Request

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

Parameters
typeId : string ID of the type Person
HTTP object: String Id of the object to delete {

Parameters/
“objectId: ”
“04007zLyLmG4B1s0000A4
W0002S:UserDataModel::[C
ustom]Person”
}
Combined DELETE /cva/sf/Person/Objects/ HTTP/1.1

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

Code
200 Object deleted
404 Type not found

JSON None None
Attributes
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
Get Object
Description This method gets all object property values of an Object.
Request
Request URL GET http://crema.eu/cva/sf/typeId/Objects/

Parameters
typeId : string ID of the Type Person
HTTP objectId: String Id of the requested Object {

Parameters/
“objectId: ”
“04007zLyLmG4B1s0000
A4W0002S:UserDataMod
el::[Custom]Person”
Combined GET /cva/sf/Person/Objects/ HTTP/1.1

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

Code
201 Object found
404 Type not found
JSON list A list of properties of an object with their values.

Attributes Optional list Example:
{"_id" :
"04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Cus
tom]Person",
"name": "Danny",
"function": "Engineer",
"age": "31"
}
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
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

Parameters
Combined GET /cva/sf/Person/Objects/ HTTP/1.1

Response
Value Description

HTTP Status 201 Object found

Code
404 Type not found
JSON List A list of all object IDs and their properties of the given type
[
{
“_id”:
“04007zLyLmG4B1s0000A4W0002S:UserDataModel::[Cust
om]Person”,
“name”: "Danny",
“function”: "Engineer",
“age”: “31”
},
{
“_id”:”04007zLyLmG4B1s0000A4W0002V:UserDataModel:
:[Custom]Person”,
“name”: "Tim",
“function”: "Team Leader",
“age”: “37”
}
]
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
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

Parameters
HTTP property : string Those properties {

Parameters describe a type “propertyId”:“country”,
“type”:”string”
}
Combined POST /sf/Person/ HTTP/1.1


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

Code
201 Property created
404 Type not found
400 Property with specific ID already exists for the type

JSON None None
Attributes
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
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

Parameters
propertyId : string ID of the type property. Country

Unique in the context of an
object.
Combined DELETE /sf/Person/country HTTP/1.1

Response

Code
200 Property deleted
404 Property not found
404 Type not found
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.

Table 71: CVA RESTful Interface – Create 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

Parameter
HTTP object : Object JSON defining new {

Parameter property. Syntax of “propertyId”:
“propertyId” is important to “__<Product>is_in__<P
ensure property is
rocess Area>”,
correctly created in SF
“type”: “Bool”
}
Combined POST /sf/ComplexPropertylist/ HTTP/1.1

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

Code
201 Property created
404 Type not found
404 Property with specific ID already exists for the type
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
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

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

HTTP object : Object JSON defining the target {

Parameter complex property “propertyId”:
“__<Product>is_in__<Pro
cess Area>”,
}
Combined DELETE /cva/sf/Person/objects/complexPropertyList

Example HTTP/1.1
Host: crema.eu
object = {“propertyId”:”__<Product>is_in__<Process Area>”,”type”:
“Bool”}
Response

Code
200 Property deleted
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
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

Parameters
propertyId : string ID of the property to be read age
HTTP object: object ID of the data object. Unique {

Parameters/ in the context of the Type “objectId: ”
Request Body “04007zLyLmG4B1s0000
JSON A4W0002S:UserDataMod
el::[Custom]Person”,
}
Combined GET /sf/Person/objects/age

Example

HTTP/1.1
Host: crema.eu
object = {“propertyId”: “__<Product>is_in__<Process Area>”,”type”:
“Bool”}
Response

Code
201 Object found
404 Type not found
JSON list The result of the property value requested

{ “value”: 31 }
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
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

Parameters
typeId: string ID of the Type Person
propertyId : ID of the property of the object of location

string the type
HTTP objectId: string ID of the data object. Unique in the {

Parameters/ context of the Type “objectId”:
Request Body “04007zLyLmG4B1s0000A4
JSON W0002S:UserDataModel::[C
ustom]Person”,
“value”: "Test Area"
}
Combined PUT /sf/Person/Objects/age

Example
HTTP/1.1
Host: crema.eu

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

Code
200 Found objects updated
404 Type not found
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
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

Parameters
propertyId : string ID of the property of the location

object of the type
targetId: string ID of the stream receiver PCE

components
HTTP object: string ID of the data object. {

Parameters/ Unique in the context of the
“objectId”:
Request Body Type
“04007zLyLmG4B1s0000
}
Combined PUT /sf/Person/objectList/location/PCE/stream HTTP/1.1

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

Code
200 Property found and streaming started
404 Type not found
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
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

Parameters
propertyId : string ID of the property of the location

object of the type
targetId : string ID of the stream receiver PCE

components
HTTP object: string ID of the data object. Unique {

Parameters/ in the context of the Type “objectId:
Request Body “04007zLyLmG4B1s0000
}
Combined DELETE /sf/Person/objects/location/PCE/stream HTTP/1.1

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

Code
200 Property found and streaming stopped
404 Type not found

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

Parameters
Object : Object Represents a complex type of {
property “propertyId”:
“__<Product>is_in__<Proc
ess Area>”,
“keys”: [“10001”, ”Rework
Area”]
}
Combined GET /sf/complexPropertyList

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

Code
201 Property row found
404 Property row not found
JSON List The result of the property value requested

{
“value”: true
}
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 Values
Description This method gets all the rows for a particular complex property.

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

HTTP
property : string ID of the complex property for __<Product>is_in__<Pr
Parameters
which all rows have to be read ocess Area>
Combined GET /cva/sf/ComplexPropertylist HTTP/1.1

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

Code
201 Property row found
404 Property row not found
JSON List All property values

[
{
keys: [“10001”, ”Rework Area”],
value: true
},
{
keys: [“10002”, ”Rework Area”],
value: true
},
…
]
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
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
Name Description Example

HTTP/Paramet
Property : object represents a complex object “{
ers
property value propertyId:
“__<Product>is_in__<Pro
cess Area>”

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

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

Code
200 Property set
404 Type not found
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
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
{
"userId": "597134"
"user": "Charles",
"company": "CREMA",
"authorisation":
{
"permission": "IT Access"
}
}
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.

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/
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/
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.
Technical Technical
users users
<user interface> <user interface> T4.4 CREMA CPS, Sensor

T6.5 CREMA Dashboard T6.5 CREMA Dashboard Abstraction and
and Visualisation (DBV) and Visualisation (DBV) Virtualisation (CVA)
<user interface>
CREMA Service Virtualisation
<user interface>
Template Service Virtualisation and Abstraction (SVA)
Manager Manager
call for
call service description, wrapper
access templates call
semantic annotation
data access
binary/ REST CPS/sensor Data
Sensor wrappers
Security Layer
<user interface>
Semantic semantics
linked Annotation
Manager get fwd fwd
concepts fwd fwd
get semantics
linked concepts semantics
get
semantics get
T4.2 CREMA Data linked concepts
Harmonisation Services
(DHS)
linked
concepts
linked
concepts Service
Template Control templates Virtualisation
request Control
get
linked concepts
service
templates templates services
templates request
request data data
data
T4.3 CREMA T6.1 CREMA

Cloud-baSed RAID Marketplace and
Infrastructure (CRI) Service Monetisation (MPM)
Template
Repository
Repository
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.
• 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.
CREMA Cloud Process and Container
Messaging Runtime
Environment (PRU) Proxy Service Wrapper
service execution <<interface>> <<interface>> T5.2 CREMA Cloud

BPMS check availability Process and Messaging
request Start Service Get Availability
Runtime Environment
(PRU)
start service get availability
Service
service
availability
<<interface>> monitoring /
Service Monitoring API end of service exectution
events
monitoring /
end of service exectution
events
Notification Service
Figure 7: Proxy Service Wrapper Architecture Diagram

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/

Parameters
serviceIP : string IP and Port of the Service serviceIP=10.10.10.10:123
4
HTTP object: object An object representing an { "monServiceURL":

Parameters object of the URL to the "10.10.10.10:5678",
monitoring service and "inputparams":
input parameters to start
{"key1":"value1",
an execution of the service
"key2":"value2"} }
POST http://<serviceIP>/resources/ HTTP/1.1

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

Code
201 Success. Request fulfilled.
424 Unknown error occurred.

Response 1:
JSON Result: object
Attributes {
"started": "true"
}
Response 2:
{
"started": "false",
}
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
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/

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

Code
200 Success. Response received.
424 Unknown error occurred.

Response 1:
JSON Result: object
Attributes {
"state": "available"
}
Response 2:
{
"state": "blocked"
}
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
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
"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"
},
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).

Listing 15: Semantic Annotation of a Service

"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": [
Tool: t",
Material: ma",
"http: //127.0.0.1: 8080/CREMA/Ontologies/ProcessOntology.owl#
Round: r"
]
}
]
},
"outputs": {
"and": [
Part: p",
"http: //127.0.0.1: 8080/CREMA/Ontologies/ProductOntology.owl#Shape: s",
]
},
"preconditions": {
"and": [
isValidated(t)",
isInstalled(t)",
]
},
"effects": {
"and": [
isUsed(p)",
]
},
},
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.

Listing 16: Linked Concepts, Executable Part and Service Schedule

"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"}
}]
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.
Listing 17: SVA Example Authorisation Definition
{
"userId": "597134"
"user": "Charles",
"company": "CREMA",
"authorisation":
{
"permission": "service provider",
"templates": "Tenneco",
"services": "Tenneco"
}
}

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
41
https://nodejs.org/en/
42
https://www.npmjs.com/
43
http://gruntjs.com/
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.
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.

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

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.

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

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
<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>
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
<crema:service>
<crema:abstractServiceID>5023282A-298F-4713-A037-
BE528998F2C5</crema:abstractServiceID>
<crema:concreteServiceID/>
</crema:service>

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
<crema:service>
<crema:abstractServiceID>5023282A-298F-4713-A037-BE528998F2C5
</crema:abstractServiceID>
<crema:concreteServiceID origin="user">BE3B7136-B020-4B01-B28F- 08FA3E177F08
</crema:concreteServiceID>
</crema:service>
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
[{
"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#Orig
inal_Equipment_Efficiency"
}]

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
<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>
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.
{
"name": "CREMA",
"uri": "http://crema/schema/bpmn/crema",
"prefix": "crema",
"xml": {
"tagAlias": "lowerCase"
},
"types": [
{
"name": "ProcessDefinition",
"superClass": [ "Element" ],
"properties": [
{
"name": "version",
"type": "Version"
}
]
},
...

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
{
"userId": "597134"
"user": "Charles",
"company": "CREMA",
"authorisation":
{
"permission": "Read Access"
}
}
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.

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

T5.1 CREMA Cloud

T6.2 CREMA process_log
Collaborative Process
Monitoring and
Design Time
Alerting (MON)
Environment (PDE)
request
process
process_log
process execution request
execution request
<<interface>> <<interface>> request process_log
Process Execution Request Process Log
API API
process process request

execution_request log process log
process
<<interface>> process_log
<user termination request
Optimized
<user interface> interface> Security Layer process API
T6.5 Dashboard and use Start/
Visualisation (DBV) Terminate/ process
execution request optimized
Status Process
process
Execution
T4.3 CREMA Cloud- process Process Execution Manager
status request request Process
based RAID
process Instance optimized
response to instance Infrastructure process
user request Controller
Process
Log save process_log control request process control
Store process_execution process log process instance
log T5.5 CREMA
Design Time and
Process Runtime
Model process_model request Optimisation
Store process_model request optimisation (ODERU)
BPMS
streaming
reserve services
data
T5.3 CREMA On- release service
demand Service Message
Leasing and <<interface>> Bus
lease service streaming
Releasing (OSL) Service data
service URI
Monitoring API
Process Instance Executer T6.3 CREMA

Manufacturing
CREMA Cloud Process and Messaging Runtime Environment Big Data,
Knowledge
(PRU) and Analytics
(BDA)
service execution monitoring / streaming

request end of service exectution data
events
Service Start Notification

Service
Interface Service
Instantiated Proxy Service Wrapper
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
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
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
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
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

Parameters
HTTP object : object JSON object that holds the {

Parameters ID of the process model. "processmodel" :
Furthermore, it has the
optional values for the "model123",
process service plan "input": [
execution. Those values are
passed to the executing {"key1" : "value1"},
process instance at the {"key2" : "value2"}
beginning.
]}
Combined POST /pru/pminstaces?session=user1234 HTTP/1.1

object={"processmodel":"model123", "input": [{"key1":"value1","key2":"value2"}]}
Response

Code
200 Execution started
404 Process model not found
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
Optimised Process Model Available
Description This method is called if an optimised process service plan is available.
Request

Request URL PUT http://crema.eu/pru/pminstances/instanceId?session=userToken

Parameters
isntanceId : string The ID of the process Instance1234
instance that should use the
optimised process service
plan.

{
HTTP object : object JSON object holding the ID
Parameters of the instance that had to be "newModel":
optimised and the ID of the "model123"
optimised process service }
plan.
Combined PUT /pru/pminstances/instanceId?session=user1234 HTTP/1.1

object={“newModelId”:”model123”}
Response

Code
200 Execution continued
404 Process instance not found
409 Process model not found
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 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

Parameters
instanceId : string The identifier of a running instance123
process instance

Combined GET /pru/pminstances/instance123/logs?session=user1234 HTTP/1.1

Response

Code
200 Log for Process Instance found
404 Log for Process Instance not found

Attributes
Result : object Camunda BPM Process Log
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
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

Parameters
instanceId : string ID of the process instance. testId
processStepId : string ID of process step. testStepId

Response 1:
HTTP object : object JSON object representing an
Parameters exception (type=exception) {
or the end of the execution "serviceId": "1234",
(type=finished) "type":
"termination",
"response" : [
{"key1": "value1"},
{"key2": "value2"},
{"keyn": "valuen"}
]
}
Response 2:
{
"serviceId": "1234",
"type": "failure",
"reason":
"Errormessage"
}

Combined POST /pru/pminstances/testID/service/testStepId HTTP/1.1

object={“serviceId”: “1234”, “type”:”failure”, “reason”:”Errormessage”}
Response

Code
200 OK
404 Process Instance or Process step not found
409 Process Step not found
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
{
"userId": "597134"
"user": "Charles",
"company": "CREMA",
"authorisation":
{
"permission": ["ExecutionrAccess", "RestrictedResources"],
}
}

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/
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
53
https://aws.amazon.com/sdk-for-java/
54
https://jclouds.apache.org
55
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.
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
Cloud Resources
Availability
Service
Availability Interface
Service
Interface
service URI
cloud resource cloud resource check
allocation URI availability deploy/terminate
service
Cloud cloud resource URI
Resource service
Management request
availability
cloud resources
get instantiated
reserve services services
T6.1 CREMA service definition
Marketplace and request service definition Service Manager
Monetisation (MPM) report service release instantiated
service URI services
service check
leasability reserve release lease
service
leasability services service new service
<<interface>> <user interface>

<<interface>>
Service leasability Organisational
Service leasing API
API Web UI
service
leasability reserve lease
check services new service get
CREMA On-Demand Service service release instantiated
Leasing and Releasing (OSL) leasability service service URI services
T5.4 CREMA Design T5.2 CREMA Cloud Process <user interface>

time and Runtime and Messaging Runtime T6.5 CREMA Dashboard
Optimisation (ODERU) Environment (PRU) and Visualisation (DBV)
Figure 14: OSL Architecture Diagram
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
Lease 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

Parameters
processID : string ID of the process Process1
serviceID : string ID of the service Service1v123

Combined POST /osl/service/Process1/Service1v123?session=User1234 HTTP/1.1

Response

Code
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” }
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
Release Service
Description This method releases a specific Proxy Service Wrapper instance.
Request
Request URL DELETE

http://crema.eu/osl/service/serviceInstanceID?session=userToken

Parameters
serviceInstanceID : ID of the Proxy Service Service1v123i1337
string Wrapper instance


Combined DELETE /osl/service/Service1v123i1337?session=User1234 HTTP/1.1

Response

Code
200 Proxy Service Wrapper deleted
404 Proxy Service Wrapper not found
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
Leaseability Check
Description This method checks the leaseability of a specific service
Request
Request URL GET

http://crema.eu/osl/serviceLeaseability/serviceID?session=userToken

Parameters
serviceID : string ID of the service Service1v123

Combined GET /osl/serviceLeaseability/Service1v123?session=User1234 HTTP/1.1

Response

Code
200 Service is leaseable
409 Service is not leasabile

JSON Result: object {“service” : “service1”, “leaseability” : “true” }
Attributes {“service” : “service2”, “leaseability” : “false” }
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.
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

Parameters
processID : string ID of the process Process123

HTTP serviceList : object A JSON object, which lists { “services” : [

Parameters the required services {“service” :
including their timeslots for a
“serviceID”,
process.
“start” :
“startTimeInUTC”,
“end” : “EndTimeInUTC”
}
]
}
Combined POST /osl/reserveServices/Process123?session=User1234 HTTP/1.1

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

Code
200 Services reserved
409 Service is not available

JSON Attributes Result: object {“services” : [“service1” : ok”, “service2” :

“failed”, “service3”: “failed”] }
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
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

Parameters
processID : string? ID of the process Process123

Combined GET /osl/instantiatedServices/Process123?session=User1234 HTTP/1.1

Response

Code
200 Service list is available
JSON Attributes Result: object {“services” : [

{
“process” : “Process123”,
“serviceID” : “service1v123”,
“serviceURI” : “http://10.10.10.10:1234”,
“serviceInstanceID” : “Service1v123i1337”
},
{
“serviceURI” : “http://10.10.10.10:12”,
},
{
“serviceURI” : “http://10.10.10.10:1111”,
},
] }
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.
be structured. It uses the predefined permission labels to set the rights for each user.
Listing 25: OSL Example Authorisation Definition
{
"userId": "597134"
"user": "Charles",
"company": "CREMA",
"authorisation":
{
"permission": "regular",
"services": ["service1", "service11", "service111"]
}
}
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
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
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.

T5.3 CREMA On-demand T4.4 CREMA CPS,

Service Leasing and Sensor Abstraction and
Releasing (OSL) Virtualisation (CVA)
service check
leasibility register to
service data streams
data streams
leasibility
CREMA Design Time &
Runtime Optimisation Service
data stream Data Stream
Selection and
(ODE/ORU) Planning
request Processing
service plans
process logs
functional
request process logs (re-)planning
request data streams
optimise
process optimise
T5.2 CREMA Cloud Process process instance
and Messaging Runtime instance <<interface>>
Environment (PRU) optimised ORU API optimised optimised
process process instance service plan Simulation-based
instance Optimisation Service Plan
get optimal Workflow non-functional Optimisation
get optimal optimisation
T5.1 CREMA Cloud service plan Handling
service plan <<interface>> request
Collaborative Process Design ODE API
Time Environment (PDE) optimised optimised
service plan service plan
monitored
user acceptance events
answer
optimised
<user interface> <user interface> process
present process process
T6.5 CREMA Dashboard use Optimisation model
instance and instance
and Visualisation (DBV) UI
check for user
acceptance get actual
service KPI
available get services/ optimised request actual

services/ request updates service event channel service KPI
historic get historic
updates plan
service KPI service KPI get process
model
T6.1 Marketplace and T6.3 CREMA Manufacturing T4.3 CREMA Cloud- store T6.2 CREMA Monitoring
Monetisation (MPM) Big Data, Knowledge and based RAID optimisations and Alerting (MON)
Service Repository Analytics (BDA) Infrastructure (CRI)
process
models
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.
communication interfaces of the ODERU are defined as RESTful interfaces.
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

Parameters

Parameters composition (optimisation) "ProcessModel ID":
problem "ID1",
"ObjectiveFunction": [{
"Dim1": {"type":
"MIN","parameter":
"@X1"},
"Dim2": {"type":
"MIN","parameter":
"(@X2 + @X3)/@Y"},
"Dim3": {"type":
"MAX","parameter":
"AVG(@Z)"}}],

"deadline": "2015-11-
04T14:00:00"
}
Combined PUT /oderu/PM/Compose/?session=user1234 HTTP/1.1

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

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

Attributes
Result : identifier of the {"ProcessServicePlanID":”PM1_PSP1”,
PSP (concatenation of “OptimisationValue”:87.50}
the PMID and the PSP
version) and the
optimisation value
achieved (only
HTTP/200 result)
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.

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

Parameters

Parameters optimisation problem
"ProcessServicePlanID":”PM1_P
SP1",
"Contraints":
[“Var1<k1”,”Var2>=k2”],
"Dim1": {{"type":
“MIN","parameter": "@X1"}}],
"deadline": "2015-11-
04T14:00:00"
}
Combined PUT /oderu/PM/Optimise?session=user1234 HTTP/1.1

object={“ProcessServicePlanID": "PM1_PSP1", "Contraints":
["@lenght<120","@ROI>=2.345"],"ObjectiveFunction": [{ "Dim1": {
"type": "MIN", "parameter ": "@global_cost"}}]}
Response

Code
200 Optimisation correctly executed, result returned
204 Optimisation finished, no possible process service plan

available for the given process model with these constraints


Process Model from the ID or to store back the resulting

520 Impossible to execute the Optimisation requested.

Attributes
Result : identifier of the {"ProcessServicePlanID":”PM1_PSP2”,
PSP (concatenation of "Contraints": ["@lenght<120","@ROI>=2.345"],
the PMID and the PSP
version), the constraint “OptimisationValue”:87.50}
set used and the
optimisation value
achieved (only
HTTP/200 result)
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
Approve optimised process service plan
Description Approve an optimised process service plan
Request
Request URL PUT http://crema.eu/oderu/PSP/Approve?session=userToken

Parameters
HTTP object : object An JSON object {

Parameters representing the PSPID "ProcessServicePlanID":
and the user decision "PM1_PSP1",
about the current version "acceptance": TRUE|FALSE
acceptance }
Combined PUT oderu/PSP/Approve?session=user1234 HTTP/1.1

object={"ProcessServicePlanID": "PM1_PSP1", "acceptance": TRUE}
Response

Code
202 Acceptance flag modified to TRUE
205 Acceptance flag modified to FALSE

404 Process Model ID not existing in the CRI
409 PSP version received does not exist
520 Impossible to modify the acceptance flag
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
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

Parameters

Parameters composition (optimisation) "ProcessInstanceID":
problem
"PM1_PI1",
"ObjectiveFunction":
[{ "Dim1": {{"type":
“MAX","parameter":
"@X1"}}],
"deadline": "2015-11-
04T14:00:00"
}
Combined PUT /oderu/PI/Compose/?session=user1234 HTTP/1.1

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

Code
200 Composition correctly executed, result returned

204 Composition finished, no possible process service plan

available for the given process instance

Process Instance from the ID or to store back the resulting

520 Impossible to execute the composition requested.

Attributes
Result : identifier of the {"ProcessServicePlanID":”PM1_PI1_PSP1”;
PSP (concatenation of “OptimizationValue”:87.50}
the PIID and the PSP
version) and the
optimization value
achieved (only
HTTP/200 result)
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
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
Request URL PUT http://crema.eu/oderu/PI/Optimise/?session=userToken

Parameters

Parameters optimisation problem "ProcessInstanceID":
"PM1_PI1",
"Contraints":[“Var1<K1”,
”Var2<=K2”, ”Var2>K3”],
"Dim1": {{"type":
“MAX","parameter": "@X1"}}],
"deadline": "2015-11-
04T14:00:00"
}
Combined PUT /oderu/PI/Optimise/?session=user1234 HTTP/1.1

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

Code
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

Process Instance from the ID or to store back the resulting

could be not optimised.
520 Impossible to execute the Optimisation requested.

Attributes
Result : identifier of the {"ProcessServicePlanID":”PM1_PI1_PSP1”,
PSP (concatenation of

the PMID and the PSP "Contraints": ["@length<19",

version) and the "@used_energy<=155", "@used_ energy>59"],
optimisation value
“OptimisationValue”:87.50}
achieved (only
HTTP/200 result)
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
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

Parameters

Parameters composition (optimisation) "ProcessServiceID":
problem "PM1",
"ProcessTaksID":
"PT1",
"Dim1": {"type":
"MIN","parameter":
"@X1"},
"Dim2": {"type":
"MAX","parameter":
"AVG(@Z)"}}],
"candidates_nr: "6",
"RequiredLevel": 65
}
Combined GET /oderu/PI/Compose/?session=user1234 HTTP/1.1

object={"ProcessServiceID": "PM1", "ProcessTaksID": "PT1",
"ObjectiveFunction": [{"Dim1": {"type": "MIN","parameter": "@X1"},
"Dim2": {"type": "MAX","parameter": "AVG(@Z)"}}], "candidates_nr: "6",
"RequiredLevel": 65}

Response

Code
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

Process Model from the ID.
520 Impossible to run the service matching requested.

Attributes
Result set: array of {"Result" : [{"ServiceID":"S1",
process service IDs with
"fitness":87.50}, {"ServiceID":"S9",
matching level
"fitness":71}, …]}
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
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

Parameters

Parameters Process Model "ProcessModel ID":
identification
"PM1"

Combined GET /oderu/PM/Optimise/?session=user1234 HTTP/1.1

object={"ProcessModelID": "PM1"}
Response

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

Attributes
Result set : array of {"Result" : [{"ProcessServicePlanID":
PSPIDs (only HTTP/200 "PM1_PSP1", "OptimisationValue":87.50},
result) {"ProcessServicePlanID":"PM1_PSP3",
"OptimisationValue":79.335}, …]}
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
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

Parameters


Parameters Process Model "ProcessInstanceID":
identification "PM1_PI1"
}
Combined GET /oderu/PI/Optimise/?session=user1234 HTTP/1.1

object={"ProcessInstanceID": "PM1_PI5"}
Response

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

Attributes
Result set : array of {"Result" : [{"ProcessServicePlanID":
PSPIDs (only HTTP/200 "PM1_PSP1", "OptimisationValue":87.50},
result) {"ProcessServicePlanID":"PM1_PSP3",
"OptimisationValue":79.335}, …]}
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.

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

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.

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

Parameters
serviceId : string ID of the service 2983749AC234DF

Combined GET /mpm/services/137?session=user1234 HTTP/1.1

Response

Code
200 Object retrieved successfully
JSON Attributes Service : Object A service object matching the query.
66
https://www.payone.de/en/platform-integration/interfaces/
Example:
"Service":
{
"serviceID": "2983749AC234DF",
"isDraft": "False",
"concreteServiceID": "Service_0m5fx1g",
"abstractServiceID": "null",
"serviceDescription": {...},
"semanticAnnotation": {...},
"linkedConcepts":{...},
"serviceSoftware":"../2983749AC234DF.war",
"payment":{...},
"schedule":{...},
"state": "blocked"
}
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
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 serviceType : String? Type of the service (concrete concrete

Parameters or abstract
page : int? Enables the user to use 3

pagination
limit : int? Request a limited number of 50

entities

Combined GET
Example /mpm/services?serviceType=concrete&page=3&limit=50&session=user1234
HTTP/1.1
Host: crema.eu
Response

Code
200 Services retrieved


JSON Service : List A list of service objects.
Attributes 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":
[
{
"isDraft": "False",
"concreteServiceID": "Service_0m5fx1g",
"payment":{...},
"schedule":{...},
"state": "blocked"
},
{…},
{
"isDraft": "false",
"concreteServiceID": "Service_0m52rg9",
"serviceName": "machining:Lifting",
"payment":{...},
"schedule":{...},
}]

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

Parameters
{
HTTP object : object An object representing an
Parameters object of the specified "serviceID":
service "309485AC456DF",
"isDraft": "false",
"concreteServiceID":
"Service_0m52rg9",
"abstractServiceID":
"null",
"serviceName":
"machining:Lifting"
"serviceDescription":
{...},
"semanticAnnotation":
{...},
"linkedConcepts":{...
},
"serviceSchema":"../s
erviceSchema.xml",
"serviceSoftware":"..
/309485AC456DF.war",
"payment":{...},
"schedule":{...},
}
POST /mpm/services?session=user1234 HTTP/1.1
Combined
object={"serviceID":"309485AC456DF", "isDraft":"false",
"concreteServiceID":"Service_0m52rg9", "abstractServiceID":"null",
"serviceName":"machining:Lifting", "serviceDescription": {...},
"semanticAnnotation": {...}, "linkedConcepts":{...},
"serviceSoftware":"../309485AC456DF.war", "payment":{...},
"schedule":{...}, "state": "available"}
Response

Code
201 Service created
402 HTTP Body contains errors
409 Service with this Id exists already
502 Service is not created
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
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

Parameters
serviceId : string ID of the service 132
userToken : string The token propagated User1234

{
HTTP object : object An object representing an
Parameters object of the specified data "serviceID":
type with attributes set, which "309485AC456DF",
will be updated in the data "isDraft": "false",
objects found with the query. "concreteServiceID":
"Service_0m52rg9",
"abstractServiceID":
"null",
"serviceName":
"machining:Lifting"
"serviceDescription":
{...},
"semanticAnnotation":
{...},
"linkedConcepts":{...
},
"serviceSchema":"../s
erviceSchema.xml",
"serviceSoftware":"..
/309485AC456DF.war",
"payment":{...},
"schedule":{...},
}
PUT /mpm/services/132?session=User1234 HTTP/1.1
Combined
object= {"serviceID":"309485AC456DF", "isDraft":"false",
"concreteServiceID":"Service_0m52rg9", "abstractServiceID":"null",

"serviceName":"machining:Lifting", "serviceDescription":{...},
"semanticAnnotation":{...}, "linkedConcepts":{...},
"serviceSoftware":"../309485AC456DF.war", "payment":{...},
"schedule":{...}, "state":"available"}
Response

Code
201 Service is updated
400 Request could not be understood
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
Delete Service
Description Deletes a specific Service from the Service Repository.
Request
Request URL DELETE http://crema.eu/mpm/services/serviceId?session=userToken
Resource Name / Type Description Example

Parameters
serviceId : string ID of the Service testID2
userToken : string The user token propagated User1234

Combined DELETE /mpm/services/testID2?session=User1234 HTTP/1.1

Response

Code
200 Service deleted
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.

Table 104: MPM RESTful Interface – Create Proxy Service Wrapper

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 userToken : string? The userToken propagated User1234

HTTP Object : object The file to be uploaded to the {

Parameters Service Registry “ServiceRefId”:”1284”,
"filepath":”../test.exe
",
"mime_type":"applicatio
n/octet-stream"
}
Combined POST /mpm/proxyservicewrapper?session=user1234 HTTP/1.1

object = {“ServiceRefId”:”1284”, "filepath":”../test.exe",
"mime_type":"application/octet-stream"}
Response

Code
201 Proxy Service Wrapper created
402 Payload is missing / not applicable
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
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

Resource userToken : string? The userToken propagated User1234

Combined GET /mpm/proxyservicewrapper/137?session=user1234 HTTP/1.1

Response

Code
200 Proxy Service Wrapper has been retrieved

JSON Service : List A list of service objects.
Attributes Example:
{
"MetaProxyServiceWrapper":
{
"ServiceId": "137",
"ServiceRef":
"mpm/services/137?session=user1234",
"BucketRefId": 3,
"objectId": 50,
"ServiceProxyWrapperRef":
"/cri/bucket/3/50?session=userToken"
}
}
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
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 serviceId : string ID of the service 137

Parameters
HTTP object : Object The service to be released {

Parameters including payment “UserId”:”2083749837”,
information “processId”:”283ASD28”,
“usagetime”:”5”

Combined POST /mpm/services/137/released?session=user1234 HTTP/1.1

object={“UserId”:”2083749837”, “processId”:”283ASD28”,
“usagetime”:”5”}
Response

Code
201 Release Information created
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
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 wrapperId : string ID of the Proxy Service 8238

Parameters Wrapper

Combined DELETE /mpm/proxyservicewrapper/8238?session=user1234 HTTP/1.1

Response

Code
200 File successful deleted
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.

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=userT
oken

Parameters
uid : string? ID of the schedule entry 19400

owner (CREMA Component /
Process)

Combined GET /mpm/services/137/schedule?uid=19400&session=user1234 HTTP/1.1

Response

Code
200 Service schedule retrieved successfully
JSON Attributes Service Schedule : A service object matching the query.

Object Example:
"ServiceSchedule": [
{
"uid": "19400",
"appointment": {"start": " 1446628200000",
"end": " 1446631800000"}
},{…}
{
"uid": "19400",
"appointment": {"start": "1446562800000",
"end": "1446564600000"}
}]
]

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

Parameters

HTTP object : Object The Appointment to be {

Parameters added to the Service "appointmentId":
Schedule
"28937",
"processId":"19400",
appointment":
{appointmentId:"start":
"1446628200000", "end":
"1446631800000"
}
Combined POST /mpm/services/137/schedule?session=user1234 HTTP/1.1

object= {"appointmentId": "28937","processId":"19400", appointment":
{"start": "1446628200000", "end": "1446631800000"}
Response

Code
201 Appointment created successfully
402 Post Object is missing or not complete
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.

Table 110: MPM RESTful Interface – Update 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?sessi
on=userToken

Parameters
uid : string ID of the schedule owner 19400

HTTP object : Object The Appointment to be {"appointmentId":"2892"

Parameters added to the Service , "processId": "29",
Schedule appointment": {"start":
"…", "end": "…"}
PUT /mpm/services/137/schedule/29?session=user1234 HTTP/1.1
Combined
object= {"appointmentId":"2892", "processId": "19400",
appointment":{"start":"1446628200000", "end":"1446630000000"}
Response

Code
201 Appointment updated successfully
404 Service or Schedule not found
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
Delete Service Schedule
Description This method deletes an appointment from a service schedule based on a service Id
from the Service Registry.
Request

Request URL DELETE

http://crema.eu/mpm/services/serviceId/schedule/appointmentId?session
=userToken

Parameters
appointmentId : string ID of an appointment in the 29

schedule

DELETE /mpm/services/137/schedule/29?session=user1234 HTTP/1.1
Combined
Response

Code
200 Appointment deleted successfully
404 Service or Schedule not found
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
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

Parameters

DELETE /mpm/services/137/schedule?session=user1234 HTTP/1.1
Combined
Response

Code
200 Schedule cleared successfully

416 Schedule was already empty
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
{
"appointmentId": "178",
"processId": "29834",
"start":"110792384729347",
"end":"110792384730347”
}
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.

Listing 27: Service Payment information Example

{
"consumerId": "29834",
"payPer":"use",
"costs": "250”,
“currency”: “euro”,
“usage”: “1”
}
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.
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.
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
{
"userId": "597134"
"user": "Charles",
"company": "CREMA",
"authorisation":
{
"services":
{
"level": "User",
"scope": "Company"
},
"schedules":
{
"level": "User",
"scope": "Company"
},
"invoices":
{
"level": "User",
"scope": "Company"
}
}
}

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

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

T5.2 CREMA Cloud Process T6.3 CREMA Manufacturing

and Messaging Runtime Big Data, Knowledge and
Environment (PRU) Analytics (BDA)
push process
data calculate KPI
process data KPI
<<interface>> T4.3 CREMA Cloud-

<<interface>>
Access to based RAID
Access to KPIs
Process Data Infrastructure (CRI)
get
KPI <<interface>> historical data
get calculate Historic
process Access to
process KPI Data
data Historical Data
data
historical
Data historical data get data
request process Service historical data
data/KPI info process data/KPIs
CRUD rules/KPI <<interface>>
CRUD rules/KPI Rules
<<interface>> process Access to
rules/KPI & KPIs
Monitoring and data KPI Rules and KPIs
rules/KPI
Alerting API get
get
process
KPI
data
rules/KPI Rule Engine ack ack T5.2 CREMA Cloud Process

<<interface>>
Service exec and Messaging Runtime
CRUD rules Optimisation API
(EasyRules) optimisation Environment (PRU)
rules/KPI request
notify exec process
use alarm instance optimisation
ack
<user interface> notify alarm <<interface>>

Rules UI Dashboard API CREMA Monitoring
and Alerting (MON)
use
<user interface>
T6.5 CREMA Dashboard
and Visualisation (DBV)
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

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

Parameters
HTTP object : Object The alarm request body {

Parameters which l includes a number "name": "My Alarm",
of attributes. "priority": "High",
"category": "Cat_A",
process_instance_id":
"12300"
}
Combined POST /mon/alarms?session=user1234 HTTP/1.1

object = {"name": "My Alarm","priority": "High","category": "Cat_A",
process_instance_id": "12300"}
Response

Code
201 Alarm created
409 Alarm exists already

5xx MON backend error
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
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

Parameters
p_instance_id : string ID of the process instance. 12300

Combined GET /mon/alarms/12300?session=user1234 HTTP/1.1

Response

Code
200 OK
404 Not found
5xx MON backend error

JSON AlarmList : List<Object>
{"Alarms": [
Attributes {
"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"
}]}
JSON is used as the structure of the common MON internal API objects for the
communication with Rules UI via the RESTful interfaces.


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
{
"userId": "597134"
"user": "Charles",
"company": "CREMA",
"authorisation":
{
"permission": "ROLE_ADMIN"
}
}
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.
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/
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/
Figure 18: BDA Architecture Diagram

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

Parameters
queryId : string ID of the Query queryId=averagePressur
eSensorTemp
userToken : string The userToken User1234

propagated through all
requests.
Response

Code
200 OK, Query found
502 Database error
JSON Result set Sample Result of the query execution

Attributes [
{
"sensor": "PressureSensor",
"averageTemperature": "TestValyue”
}
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
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

Parameters
streamId : string ID of the incoming streamId=stream1234
streaming

HTTP object : object An object representing the {"topic": "myTopic",

Parameters topic of the streaming data "port" :
and the address/IP of the "http://195.235.97.154"
data source
}
Example PUT /bda/streaming/start/stream1234?session=userToken HTTP/1.1

Host: crema.eu
object {“topic”:”myTopic”, "port":"http://195.235.97.154"}
Response

Code
200 OK, BDA status updated
204 BDA status not updated
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
Stop Listening to Streaming 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

Parameters
streamId : string ID of the incoming streaming streamId=stream1234

Example PUT /bda/streaming/start/stream1234?session=userToken HTTP/1.1

Host: crema.eu
Response

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

Parameters
HTTP object : object JSon object representing the {

Parameter process data "pid": "19400",
“status": {"start":
"1446628200000", "end":
"1446631800000"
}

Example PUT /bda/streaming/stop?session=userToken HTTP/1.1

Host: crema.eu
object {"pid": "19400", “status": {"start": "1446628200000", "end":
"1446631800000”}
Response

Code
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
/**
* @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);
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.
Listing 32: JSON Example – Invoke Query

{
"queryId": "QueryId"
}

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.
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
{
"userId": "597134"
"user": "Charles",
"company": "CREMA",
"authorisation":
{
"permission": "Write Access"
}
}
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
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
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/
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.

T4.4 CREMA CPS,

T6.1 CREMA T4.3 Cloud-based
Sensor Abstraction
Marketplace and RAID Infrastructure
and Virtualisation
Monetisation (MPM) (CRI)
(CVA)
Request Service Request

Location Upload Image
Service Information location-based
Description Information
Information Image Data PCE Web Service
Service Location-based
Description Information Image Data Highlight Manager
Manager Manager
Forward Upload Notify Upload

Get location Service Confirmation
Information
information Information
Meta Data
Service Information
Get Service Information Notification

Send Highlighting Collaboration API
Send Manager
Send Notification Notification
Send
Notification
<user interface> Notification
External Streaming Content
PCE UI Infrastructure
Stream
Get Context
T6.5 CREMA Dashboard and Video External
Visualisation (DBV) Notification Service
Streaming Data Context Information
Notification Push
Streaming Data Content Notification PCE Mobile Device
Stream Video
Mobile
Collaboration
Stream Manager Notification
Manager
Manager
Streaming Data
Context
Start Stream Get Context
T4.3 Cloud-based Asset Asset Notification Show Notification

Download <user interface>
RAID Infrastructure
Download Asset Manager Collaboration UI
(CRI)
Send Download
Command
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.

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

Parameters
HTTP object : object An object representing an {

Parameters object of the specified "sender":"user_72982",
service "recipient":"user_323",
"message":"test msg",
"timestamp":"2015-10-
25T23:55:22Z"
}
POST /pce/notifications?session=user1234 HTTP/1.1
Combined
Example Host: cream.eu
object={"sender":"user_72982", "recipient":"user_323", "message":"test
msg", "timestamp":"2015-10-25T23:55:22Z"}
Response

Code
201 Notification has been created successfully forwarded as a
Push-Notification
502 Notification cannot be forwarded as a Push-Notification
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
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

Parameters

Parameters specified highlighted image "sender":"user_72982",
"recipient":"user_323",
"title":"Test",
"description":"this is
a test",
"base64Image":"jA0EAwMC
xamDRMfOGV5gyZPn…yX1BBP
OQAE4BHbh7PfTDIn"
}
POST /pce/highlighting?session=user1234 HTTP/1.1
Combined
object={"sender":"user_72982", "recipient":"user_323", "title":"Test",
"description":"this is a test",
"base64Image":"jA0EAwMCxamDRMfOGV5gyZPn…yX1BBPOQAE4BHbh7PfTDIn"}
Response

Code
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
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
Download Highlighting
Description Retrieves a stored highlighted image from the CRI.
Request
Request URL GET http://crema.eu/pce/highlighting/imageId?session=userToken

Parameters
imageId : string The id of the image to be Image_1209
downloaded

GET /pce/highlighting/Image_1209?session=user1234 HTTP/1.1
Combined
Response

Code
200 Request was successful
404 Image not found

JSON Image : Object An image object matching the query.
Attributes Example:
"Highlighting":
{
"sender": "user_72982",
"recipient": " user_323",
"title": "Test",
"description": "this is a test",

"base64Image":
"jA0EAwMCxamDRMfOGV5gyZPn…yX1BBPOQAE4BHbh7PfT
DIn"
}
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
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

Parameters
replaced

object : object An object representing
HTTP {
Parameters the specified
highlighted image "sender":"user_72982",
"recipient":"user_323",
"title":"Test2",
"description":"this is
another test",
"base64Image":"
yX1BBPOQAE4BHbh7PfTDIn…
jA0EAwMCxamDRMfOGV5gyZP
n"
}
PUT /pce/highlighting/Image_1209?session=user1234 HTTP/1.1
Combined
object = {"sender":"user_72982", "recipient":"user_323",
"title":"Test2", "description":"this is another test",
"base64Image":" yX1BBPOQAE4BHbh7PfTDIn…jA0EAwMCxamDRMfOGV5gyZPn"}
Response

Code
200 Request was successful
404 Image not found

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

Parameters
deleted

Combined DELETE /pce/highlighting/Image_1209?session=user1234 HTTP/1.1

Response

Code
200 Deletion was successful
404 Image not found
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"

{
"recipient": "user_323",
"message": "test msg",
"timestamp": "2015-10-25T23:55:22Z"
}
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"
{
"recipient": "user_323",
"title": "Test",
"description": "This is a test",
"base64Image": "yX1BBPOQAE4BHbh7PfTDIn…jA0EAwMCxamDRMfOGV5gyZPn"
}
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.
{
"userId": "597134"
"user": "Charles",
"company": "CREMA",
"authorisation":
{
"permission": "true"
}
}

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
81
http://www.w3.org/TR/html401/present/frames.html#h-16.5
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.
/***
* @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>
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
/***
* @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>
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
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/
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.
authenticate/authorise update user CREMA Dashboard and

user User
T3.4 Holistic Security Authentication
Management
Visualisation (DBV)
and Privacy Concept Controller userdata
token / user
(SPC)
user manage user
Request permission
token login
view/interact
information <user interface> UI Component
Browser UI Configuration
get notifications Dashboard UI Controller
component
get notifications user
Interact Notification response
interaction
Controller show notifications get logs
return notifications data
UI Component configure UI
show logs view/interaction View Container updated UI
pass notifications request
DBV Notification
save notifications Log Controller
API
<include UI>
T4.3 CREMA Cloud- get logs response request

based RAID
CREMA
push notifications Component X
process
models return logs
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

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

Request URL POST http://crema.eu/dbv/notifications?session=userToken

Parameters
HTTP object : object An object representing an {

Parameters object of the specified "Sender":"PRU",
notification
"Topic":"Process
finished",
"Message":"Process X
has been completed
successfully",
"TimeStamp": "2015-12-
12 13:37:12"
}
Combined POST /dbv/notifications?session=user1234 HTTP/1.1

object={"Sender": "Component X","Topic": "Process finished",
"NotificationContent": "Process X has been successfully completed",
"TimeStamp": "2015-12-12 13:37:12"}
Response

Code
201 Notification created
403 Unauthorized user/component
502 Database error
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
{
"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"
}

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”
/***
* @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>
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
"notifications": [
{
"Topic": "Process finished",
"Message": "Process A of the CREMA Component X has been successfully completed",
"TimeStamp": "2016-05-27T11:40:52.280Z"
},
{
"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"
},
{…}
]
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:

• 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",…]
}
}

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.

External
access token Browser Authentication
Providers
authentication
access token
external Holistic Security and
external API response
<user interface>
API call
Privacy Concept (SPC)
Login UI (via DBV)
Credentials
access Token
user credentials
token API keys
access token
Libraries
CREMA /API key authorise Core Logic

Component X
access token/
user metadata user credentials
get permission
permission
access token Security API
Token Configuration User Management
access token <user interface>
Libraries
CREMA /API key Management UI

Component Y
Component Plugin Framework
user metadata
permission template
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.

features of the SPC are defined as RESTful interfaces.
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
Create User
Description Creates a new user in the SPC component.
Request
Request URL POST http://crema.eu/spc/users?session=userToken

Parameters
{
HTTP object : object A user object representing
Parameters an object of the created "user": "…",
user "company": "…",
"authorisation": {…}
}
Combined POST /spc/users?session=user1234 HTTP/1.1
object{"user":"…","company": "…","authorisation":{…}}
Response

Code
201 User created
409 User exists already
502 Database error
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.

Table 126: SPC RESTful Interface – Get User

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

Parameters
userId : string Id of the user 1024

Combined GET /spc/users/1024?session=user1234 HTTP/1.1

Response

Code
200 User retrieved
404 User not found
502 Database error

JSON User : Object
{
Attributes "userId": "1024",
"user": "…",
"company": "…",
"authorisation":{…}
}
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 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

Parameters
page : int? Enables the user to use 3

pagination

limit : int? Request a limited number 50

of entities
Combined GET /spc/users?session=user1234&page=3&limit=50 HTTP/1.1

Response

Code
201 Userlist retrieved
502 Database error

JSON User : Object
"metadata":
Attributes {
"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": "…",
},{…},
{
"userId": "1074",
"user": "…",
"company": "…",
}
]
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
Update User
Description Updates a user in the SPC component based on a user Id.
Request

Request URL PUT http://crema.eu/spc/users/userId?session=userToken

Parameters

{
HTTP object : object A user object representing
Parameters an object of the created "user": "…",
user "company": "…",
"authorisation": {…}
}
Combined PUT /spc/users/1024?session=user1234 HTTP/1.1

object{"userId":"1024", "user":"…","company": "…","authorisation":{…}}
Response

Code
200 User updated
400 Bad Request
404 User not found
502 Database error
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
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

Parameters

Combined DELETE /spc/users/1024?session=user1234 HTTP/1.1

Response
Value Description

HTTP Status 200 User Deleted

Code
404 User not found
502 Database error
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
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

Parameters
userId : string Id of the User 1024

Combined GET /spc/users/1024/profile?session=user1234 HTTP/1.1

Response

Code
200 User retrieved
404 User not found
502 Database error

JSON User : Object
{
"user": "…",
"company": "…"
}
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
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

Parameters
username : string username of the user test
password : string password of the user pw_test
Combined POST /spc/session?username=test&password=pw_test HTTP/1.1

Example Host: crema.eu1
Response

Code
201 Session created
401 Username or password are wrong

JSON user_accesstoken :
{"user_accesstoken":"aSioZoif828290cDACeio2F"}
Attributes Object
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
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

Parameters
Combined GET /spc/session/User1234 HTTP/1.1

Response

Code
200 Session exists
404 Session not found

JSON User : Object
{
"user": "…",

"company": "…"
}
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
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

Parameters
Combined DELETE /spc/session?userToken=User1234 HTTP/1.1

Response

Code
200 Session deleted
404 Session not found
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
{
"userId": "1234",
"groups":[
{“groupName” : "CREMA_manufacturerA_factoryAa_internal"},
{“groupName” : "CREMA_manufacturerA_factoryAa_marketing"},
]
}
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
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.

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) It is agreed that the data transfer is
component shall be solely routed via the done via internal services. These
process execution engine PRU (T5.2) and services are used by the PDE, which
thus instructions for this will be via the process enables the user to drag those
designer PDE (T5.1). This means that PDE services to configure a process
must have the facility to indicate this – e.g.
specific intrinsic steps, additional properties
on process steps – and PRU must execute
such instructions.
Monitoring UI MON UI could be also integrated with the PDE MON will be integrated with DBV but
component. not with the PDE, since PDE is
based on BPMN.IO tool and will be
used for process modelling
Monitoring Is monitoring (MON - T6.2) functioning all the It is decided that a business rule is
running scope time or only in connection with a running always related to a process instance
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.
Influence of alerts The Alert component (MON - T6.2) may alert The PRU offers an interface that can
from MON the user via DBV but also influence the be used by the MON to inform about
process runtime (PRU - T5.2) – for example to an event
halt or terminate a process
CPS and The way the Data is stored/described between This process is described in Section
Sensors’ Data for the CVA (T4.4)/SVA (T4.5) end points, the 4.4 and 4.5
Analysis 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

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.

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.

Annex A
Figures
Figure 1: CREMA Global Architecture Diagram ................................................................. 13
Figure 2: DLP Architecture Diagram .................................................................................. 19
Figure 3: DHS Architecture Diagram .................................................................................. 40
Figure 4: CRI Architecture Diagram ................................................................................... 66
Figure 5: CVA Architecture Diagram .................................................................................. 87
Figure 6: SVA Architecture Diagram ................................................................................ 108
Figure 7: Proxy Service Wrapper Architecture Diagram .................................................. 109
Figure 8: PDE Architecture Diagram. ............................................................................... 117
Figure 9: PDE Design Canvas ......................................................................................... 119
Figure 10: Properties Panel .............................................................................................. 119
Figure 11: Toolbox Menu ................................................................................................. 119
Figure 12: Process Model Store ....................................................................................... 120
Figure 13: PRU Architecture Diagram .............................................................................. 128
Figure 14: OSL Architecture Diagram .............................................................................. 137
Figure 15: ODERU Architecture Diagram ........................................................................ 145
Figure 16: MPM Architecture Diagram ............................................................................. 160
Figure 17: MON Architecture Diagram ............................................................................. 179
Figure 18: BDA Architecture Diagram .............................................................................. 185
Figure 19: PCE Architecture Diagram .............................................................................. 194
Figure 20: DBV Architecture Diagram .............................................................................. 204
Figure 21: Architecture of the SPC component ................................................................ 211
Tables
Table 1: DLP RESTful Interface – Read CDM-Core ontology ............................................ 19
Table 2: DLP RESTful Interface – Read other public CDM-Core profile ............................ 20
Table 3: DLP RESTful Interface – Copy other CDM-Core profile ...................................... 21
Table 4: DLP RESTful Interface – Read my CDM-Core profile .......................................... 22
Table 5: DLP RESTful Interface – Refresh my CDM-Core profile ...................................... 23
Table 6: DLP RESTful Interface – Update my CDM-Core profile ....................................... 24
Table 7: DLP RESTful Interface – Update metadata of my CDM-Core profile ................... 24
Table 8: DLP RESTful Interface – Commit my CDM-Core profile ...................................... 25
Table 9: DLP RESTful Interface – Delete ontology ............................................................ 26
Table 10: DLP RESTful Interface – Add ontology .............................................................. 27
Table 11: DLP RESTful Interface – Find similar entities in CDM-Core .............................. 28
Table 12: DLP RESTful Interface – Determine similarity of two entities ............................ 29
Table 13: DLP RESTful Interface – Execute DHS query ................................................... 30
Table 14: DLP RESTful Interface – List all CDM-Core ontologies ..................................... 31
Table 15: DLP RESTful Interface – Retrieve a CDM-Core ontology by ID ........................ 32
Table 16: DLP RESTful Interface – Set equivalence of entities in CDM-Core ................... 32
Table 17: DLP RESTful Interface – Find CDM-Core entities by name ............................... 34
Table 18: DLP RESTful Interface – Increase the weight (popularity) of an entity .............. 35
Table 19: DLP RESTful Interface – Read the weight (popularity) of an entity ................... 36
Table 20: DHS RESTful Interface – Transform .................................................................. 42
Table 21: DHS RESTful Interface – Prepare Data ............................................................. 44

Table 22: DHS RESTful Interface – Return Transformed Data .......................................... 45
Table 23: DHS RESTful Interface – Decompose Schema ................................................. 47
Table 24: DHS RESTful Interface – Analyse Concept ....................................................... 48
Table 25: DHS RESTful Interface – Connect Data Source ................................................ 49
Table 26: DHS RESTful Interface – Is Linked .................................................................... 50
Table 27: DHS RESTful Interface – CRUD-Operation Create Map ................................... 51
Table 28: DHS RESTful Interface – CRUD-Operation Read Map ..................................... 51
Table 29: DHS RESTful Interface – CRUD-Operation Update Map .................................. 52
Table 30: DHS RESTful Interface – CRUD-Operation Delete Map .................................... 53
Table 31: DHS RESTful Interface – Attach Transformer to Map ........................................ 53
Table 32: DHS RESTful Interface – Retrieve Transformer from Map ................................ 54
Table 33: DHS RESTful Interface – Deploy Map as Service ............................................. 55
Table 34: DHS RESTful Interface – Annotate Service ....................................................... 55
Table 35: DHS RESTful Interface – Publish Map ............................................................... 57
Table 36: DHS RESTful Interface – CRUD-Operation Create Concept ............................. 57
Table 37: DHS RESTful Interface – CRUD-Operation Read Concept ............................... 58
Table 38: DHS RESTful Interface – CRUD-Operation Update Concept ............................ 59
Table 39: DHS RESTful Interface – CRUD-Operation Delete Concept ............................. 60
Table 40: DHS RESTful Interface – Get Linked Concepts Simple ..................................... 60
Table 41: DHS RESTful Interface – Get Linked Concepts with Method ............................ 61
Table 42: DHS RESTful Interface – Get Linked Concepts with Filter ................................ 62
Table 43: CRI RESTful Interface – Common Return Codes .............................................. 67
Table 44: CRI RESTful Interface – Create Bucket ............................................................. 68
Table 45: CRI RESTful Interface – Delete Bucket ............................................................. 69
Table 46: CRI RESTful Interface – Describe Bucket .......................................................... 69
Table 47: CRI RESTful Interface – Delete Bucket ............................................................. 70
Table 48: CRI RESTful Interface – CRUD Operation Create ............................................. 71
Table 49: CRI RESTful Interface – Read Object ................................................................ 72
Table 50: CRI RESTful Interface – Update Object ............................................................. 73
Table 51: CRI RESTful Interface – Delete Object .............................................................. 74
Table 52: CRI RESTful Interface – Generic Query ............................................................ 74
Table 53: CRI RESTful Interface – Generic Query ............................................................ 76
Table 54: RESTful Interface Description – Create Repository ........................................... 77
Table 55: RESTful Interface Description – Delete Repository ........................................... 77
Table 56: RESTful Interface Description – Create a new Graph ........................................ 78
Table 57: RESTful Interface Description – Query a RDF Graph ........................................ 79
Table 58: RESTful Interface Description – Update a RDF Graph ...................................... 80
Table 59: RESTful Interface Description – Delete a RDF Graph ....................................... 81
Table 60: Message Description .......................................................................................... 82
Table 61: CVA RESTful Interface – Create Type ............................................................... 88
Table 62: CVA RESTful Interface – Create Type ............................................................... 89
Table 63: CVA RESTful Interface – Get Type .................................................................... 90
Table 64: CVA RESTful Interface – Get Types .................................................................. 90
Table 65: CVA RESTful Interface – Create Object ............................................................ 91
Table 66: CVA RESTful Interface – Delete Object ............................................................. 92
Table 67: CVA RESTful Interface – Get Object ................................................................. 93
Table 68: CVA RESTful Interface – Get Objects ................................................................ 94
Table 69: CVA RESTful Interface – Create Simple Property ............................................. 95
Table 70: CVA RESTful Interface – Delete Simple Property .............................................. 96

Table 71: CVA RESTful Interface – Create Complex Property .......................................... 97
Table 72: CVA RESTful Interface – Delete Complex Property .......................................... 97
Table 73: CVA RESTful Interface – Read Data Object ...................................................... 98
Table 74: CVA RESTful Interface – Update Data Object ................................................... 99
Table 75: CVA RESTful Interface – Start Object Property Value Stream ........................ 100
Table 76: CVA RESTful Interface – Stop Object Property Value Stream ........................ 101
Table 77: CVA RESTful Interface – Read Data Object .................................................... 102
Table 78: CVA RESTful Interface – Read Data Object .................................................... 102
Table 79: CVA RESTful Interface – Set Complex Property ............................................. 103
Table 80: SVA RESTful Interface – Start Service ............................................................ 110
Table 81: SVA RESTful Interface – Get Availability ......................................................... 111
Table 82: PRU RESTful Interface – Start a Process Model Execution ............................ 130
Table 83: PRU RESTful Interface – Optimised Process Model Available ........................ 130
Table 84: PRU RESTful Interface – Request Process Log .............................................. 131
Table 85: PRU RESTful Interface – Service Monitoring Event ........................................ 132
Table 86: OSL RESTful Interface – Lease Service .......................................................... 137
Table 87: OSL RESTful Interface – Release Service ....................................................... 138
Table 88: OSL RESTful Interface – Leaseability Check ................................................... 139
Table 89: OSL RESTful Interface – Reserve Services ..................................................... 140
Table 90: OSL RESTful Interface – List all Instantiated Proxy Wrappers ........................ 141
Table 91: ODERU RESTful Interface – Compose Design Time Process Service Plans . 146
Table 92: ODERU RESTful Interface – Optimise Design Time Process Models ............. 148
Table 93: ODERU RESTful Interface – Approve optimised process service plan ........... 149
Table 94: ODERU RESTful Interface – Compose Runtime Process Service Plan .......... 150
Table 95: ODERU RESTful Interface – Optimise Runtime Process Instances ................ 151
Table 96: ODERU RESTful Interface – Find matching services for process step ............ 153
Table 97: ODERU RESTful Interface – Retrieve Design Time Service Plans ................. 154
Table 98: ODERU RESTful Interface – Retrieve Runtime Service Plans ........................ 155
Table 99: MPM RESTful Interface – CRUD-Operation Create ........................................ 161
Table 100: MPM RESTful Interface – Get Services ......................................................... 162
Table 101: MPM RESTful Interface – Create Service ...................................................... 164
Table 102: MPM RESTful Interface – Update Service ..................................................... 165
Table 103: MPM RESTful Interface – Delete Service ...................................................... 166
Table 104: MPM RESTful Interface – Create Proxy Service Wrapper ............................. 167
Table 105: MPM RESTful Interface – Lease Services ..................................................... 167
Table 106: MPM RESTful Interface – Release Services .................................................. 168
Table 107: MPM RESTful Interface – Delete Proxy Service Wrapper ............................. 169
Table 108: MPM RESTful Interface – Get Service Schedule ........................................... 170
Table 109: MPM RESTful Interface – Create Service Schedule ...................................... 171
Table 110: MPM RESTful Interface – Update Service Schedule ..................................... 172
Table 111: MPM RESTful Interface – Delete Appointment from Service Schedule ......... 172
Table 112: MPM RESTful Interface – Clear Service Schedule ........................................ 173
Table 113: MON RESTful Interface – Create Alarm ........................................................ 180
Table 114: MON RESTful Interface – List all Alarms ....................................................... 181
Table 115: BDA RESTful Interface – Invoke Built Query ................................................. 186
Table 116: BDA RESTful Interface – Start Listening to Streaming Data .......................... 187
Table 117: BDA RESTful Interface – Stop Streaming Data ............................................. 187
Table 118: BDA RESTful Interface – Push Process Data ................................................ 188
Table 119: PCE RESTful Interface – Send Notification ................................................... 195

Table 120: PCE RESTful Interface – Create Highlighting ................................................ 196
Table 121: PCE RESTful Interface – Download Highlighting ........................................... 197
Table 122: PCE RESTful Interface – Replace Highlighting .............................................. 198
Table 123: PCE RESTful Interface – Delete Highlighting ................................................ 199
Table 124: DBV RESTful Interface – Push Notification .................................................... 206
Table 125: SPC RESTful Interface – Create User ........................................................... 212
Table 126: SPC RESTful Interface – Get User ................................................................ 213
Table 127: SPC RESTful Interface – Get Users .............................................................. 213
Table 128: SPC RESTful Interface – Update User .......................................................... 214
Table 129: SPC RESTful Interface – Delete User ............................................................ 215
Table 130: SPC RESTful Interface – Access User Data .................................................. 216
Table 131: SPC RESTful Interface – User Login ............................................................. 216
Table 132: SPC RESTful Interface – User Login ............................................................. 217
Table 133: SPC RESTful Interface – User Logout ........................................................... 218
Table 134: Solved Issues ................................................................................................. 220
Listings
Listing 1: Data in CSV wrapped with XML document to be transformed by DHS .............. 63
Listing 2: DHS Example Authorisation Definition ............................................................... 64
Listing 3: String Example "mydata with UTF-8 encoding" .................................................. 71
Listing 4: Create Information .............................................................................................. 82
Listing 5: Read Information ................................................................................................ 82
Listing 6: Query Response ................................................................................................. 82
Listing 7: Sample report message for parsing error fault ................................................... 83
Listing 8: Sample report message for an access denied response .................................... 83
Listing 9: Sample report message for an unspecified error response ................................ 83
Listing 10: Bucket Description Object ................................................................................. 84
Listing 11: Bucket List ........................................................................................................ 84
Listing 12: CRI Example Authorisation Definition ............................................................... 85
Listing 13: CVA Example Authorisation Definition ............................................................ 105
Listing 14: General Information of a Service .................................................................... 112
Listing 15: Semantic Annotation of a Service ................................................................... 113
Listing 16: Linked Concepts, Executable Part and Service Schedule .............................. 114
Listing 17: SVA Example Authorisation Definition ............................................................ 114
Listing 18: Process Definition Example ............................................................................ 121
Listing 19: Abstract Service XML Element Example ........................................................ 121
Listing 20: Concrete Service XML Element Example ....................................................... 122
Listing 21: Constraints Dictionary ..................................................................................... 122
Listing 22: Constraint XML Element Example .................................................................. 123
Listing 23: PDE Example Authorisation Definition ............................................................ 124
Listing 24: PRU Example Authorisation Definition ........................................................... 133
Listing 25: OSL Example Authorisation Definition ............................................................ 142
Listing 26: Service Schedule Scheme Example ............................................................... 174
Listing 27: Service Payment information Example ........................................................... 175
Listing 28: MPM Example Authorisation Definition ........................................................... 175
Listing 29: Business Rule Definition Interface and Example ............................................ 176
Listing 30: MON Example Authorisation Definition ........................................................... 182
Listing 31: API Method Signature for Invoking a Built Query ........................................... 189
Listing 32: JSON Example – Invoke Query ...................................................................... 190
Listing 33: BDA Example Authorisation Definition ............................................................ 190
Listing 34: PCE Content Format "Notification" ................................................................. 199
Listing 35: PCE Content Format "Highlighted Image" ...................................................... 200
Listing 36: JSON Example – Push Notification ................................................................ 207
Listing 37: Function Example – Signature of the method “getNotifications” ..................... 208
Listing 38: JSON Example – Result of the method Get Notifications ............................... 208
Listing 39: DBV Example Authorisation Definition ............................................................ 209
Listing 40: Response from the SPC to an authorisation request ...................................... 218


t33 d33 Technical Specification v100 PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

t33 d33 Technical Specification v100 PDF

Загружено:

Авторское право:

Доступные форматы

Cloud-based Rapid Elastic MAnufacturing

WP3 – Architecture, Functional & Technical

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

Delivery Date: 12/2015

Dissemination Level: Public

This document provides an in-depth technical definition of

Danny Pape, ASC

Internal Reviewer 1 Matthias Klusch, DFKI

Internal Reviewer 2 Dale Stone, DNIT

WP3: Architecture, Functional & Technical Specification, Security & Privacy

ID D3.3: Technical Specification

Due Date 31.12.2015

Delivery Date 31.12.2015

Status For Approval

T3.3 - D3.3 - T3.3 - D3.3 - Technical Specification - Document Date: Page:

Ascora GmbH, Germany Dot NET IT, United Kingdom

Technology Application Network Limited,

German Research Center for Artificial IKERLAN S. Coop., Spain

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

Information Catalyst, United Kingdom

T3.3 - D3.3 - T3.3 - D3.3 - Technical Specification - Document Date: Page:

T3.3 - D3.3 - T3.3 - D3.3 - Technical Specification - Document Date: Page:

4.3.3.6 Method “Create Object” ............................................................. 71

5.2.1 Technology Base & Reuse ..................................................................... 125

6.1.3.8 Method “Release Service” ....................................................... 168

6.5 Dashboard & Visualisation ................................................................................. 201

T3.3 - D3.3 - T3.3 - D3.3 - Technical Specification - Document Date: Page:

List of Figures, Tables and Listings

T3.3 - D3.3 - T3.3 - D3.3 - Technical Specification - Document Date: Page:

1.1 CREMA Project Overview

1.2 Deliverable Purpose, Scope and Context

1.3 Document Status and Target Audience

1.4 Abbreviations and Glossary

1.5 Document Structure

2 General Description of the Technical Specification

Figure 1: CREMA Global Architecture Diagram

T3.3 - D3.3 - T3.3 - D3.3 - Technical Specification - Document Date: Page:

3 General Technology Selection

3.1 Data Storage

3.2 Security and Privacy

T3.3 - D3.3 - T3.3 - D3.3 - Technical Specification - Document Date: Page:

3.3 Public Interfaces

3.4 Data-Interchange Format

3.5 Semantic Data

3.6 Component-based Technical Specification

T3.3 - D3.3 - T3.3 - D3.3 - Technical Specification - Document Date: Page:

4 CREMA Manufacturing Virtualisation &

4.1.1 Technology Base & Reuse

4.1.1.1 Standards for resource codification

4.1.1.2 Standards for semantic data querying and reasoning

4.1.1.3 Missing Elements and Implementation Needs

4.1.2 Component Structure Overview

Data Model, Model Library

Data Model Framework API Linked

T4.2 CREMA Data

Figure 2: DLP Architecture Diagram

4.1.3 Public Interfaces

4.1.3.1 RESTful Interfaces

In the following, whenever JSON-LD is used as parameter, there is no example provided

4.1.3.1.1 Method “Read CDM-Core Ontology”

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

Resource Name Description Example

HTTP object : object An object representing one {