Z-Bre4k Architecture D1.3 V1 · DSS/FMECA/Predictive maintenance components: DSS component assesses the machines’ performance to accurately diagnose and predict failures, to improve

Grant agreement nº: 768869

Call identifier: H2020-FOF-2017

Strategies and Predictive Maintenance models wrapped around physical

systems for Zero-unexpected-BRE4Kdowns and increased operating life

of Factories

Z-BRE4K

Deliverable D1.3

Z-BRE4K system architecture

Work Package 1

Industrial Demonstrators’ Analysis & System Specifications

Document type : Report

Version : v.1.0

Date of issue : 31/01/2018

Dissemination level : Public

Lead beneficiary : ATLANTIS

This project has received funding from the European Union’s

Horizon 2020 research and innovation programme under

grant agreement nº 768869.

The dissemination of results herein reflects only the author’s view and the

European Commission is not responsible for any use that may be made of

the information it contains.

The information contained in this report is subject to change without notice and should not be construed as a

commitment by any members of the Z-BRE4K Consortium. The information is provided without any warranty of any

kind.

This document may not be copied, reproduced, or modified in whole or in part for any purpose without written

permission from the Z-BRE4K Consortium. In addition to such written permission to copy, acknowledgement of the

authors of the document and all applicable portions of the copyright notice must be clearly referenced.

© COPYRIGHT 2017 The Z-BRE4K Consortium.

All rights reserved.

Z-BRE4K Project

Grant Agreement nº 768869 – H2020-FOF-2017

D1.3 v.05 Page 2/ 82

Executive Summary

Abstract

� This deliverable is the work obtained during the effort

done in task T1.3 Design and architecture of the Z-Bre4ak

system. Initially, we present the approach and

methodology used to describe, achieve and document Z-

BRE4K architecture. Numerous standards and patterns

have been used to develop this work, e.g. the

ISO/IEC/IEEE 42010 – “Systems and software engineering

- Architecture description”. This standard establishes the

methodology for the architectural description of

software intensive systems that implies a process based

on a set of relevant architecture viewpoints, conceptual,

functional, information, and deployment.

� The first goal is to define, identify and classify the

principles, limitations, restrictions of the system, due to

the fact that the Z-BRE4K’s system is based upon

Industrial Data Spaces and AUTOWARE platform.

The main parts of Z-BRE4K’s system are the following:

� Shop floor: Sensors, PLCs, industrial devices,

cameras, assets.

� Industrial Data Spaces: This technology fosters

secure data exchange among its participants, while at

the same time ensuring data sovereignty for the

participating data owners.

� AUTOWARE platform: AUTOWARE focuses on a

service-based approach denoted as software defined

autonomous service platform (in the following, also

abbreviated as “service platform”) based on open

protocols and implementing all the functionalities

(physical, control, supervision, MES, ERP) as services.

As a result, the components can be reused, the

solution can be reconfigured and the technological

advanced can be easily followed.

� Real-time monitoring and simulations components:

They are designed to support different actors of the

company to evaluate machines and production

systems conditions for a better planning of

maintenance operations to maximize machines

Z-BRE4K Project


D1.3 v.05 Page 3/ 82

availability avoiding critical and unexpected failures.

From the network of Cyber-Physical Systems (CPS)

that will be deployed throughout the factory shop

floor (Networked Machine Level – NML), and will be

focused at the Individual Machine Mode. It will be

responsible of the cognitive pre-processing of the

raw data coming from the different sensors or

actuators related to a given device, with the goal of

driving to a more meaningful stream of features.

� Physical objects 3D models, rendering and

visualization components: They will exploit

metrological information (point clouds, based on

them 3D models and visualizations will be rendered)

of the scanned assets. Their purpose is the integral

management of quality control information.

� DSS/FMECA/Predictive maintenance components:

DSS component assesses the machines’ performance

to accurately diagnose and predict failures, to

improve maintainability and operational efficiency at

the shop floor, while increasing the remaining useful

life of production assets and preventing unexpected

breakdowns by using the failure effects identified by

the FMECA component.

Keywords

Architecture, Components, FIWARE, AUTOWARE, Industrial

Data Spaces, Components, Information flow, Middleware,

Cloud, Fog, Strategies, Predictive Maintenance

Z-BRE4K Project


D1.3 v.05 Page 4/ 82

Revision history

Version Author(s) Changes Date

0.1

Konstantinos Grevenitis

(ATLANTIS)

Cristina Regueiro Senderos

(INNOVALIA)

Deliverable outline

and report write-up 15/11/2017

0.2


(ATLANTIS)


(INNOVALIA)

New content added 10/01/2018

0.3


(ATLANTIS)


(INNOVALIA)

New content added 11/01/2018

0.4 Konstantinos Grevenitis

(ATLANTIS) New content added 24/01/2018


(ATLANTIS)

Updated based on

AIMEN feedback.

Grammar and

vocabulary

corrections.

Template updated

25/01/2018


(ATLANTIS)

Updated based on

ATLANTIS feedback.

Various errata

corrected.

Abbrevations

updated.

29/01/2018

0.7 Daniel Gesto Rodriguez

(AIMEN)

Minor formatting

corrections 30/01/2018

1.0 Daniel Gesto Rodriguez

(AIMEN) Release 30/01/2018

Z-BRE4K Project


D1.3 v.05 Page 5/ 82

TABLE OF CONTENTS

TABLE OF CONTENTS ................................................................................................ 5

TABLE OF FIGURES .................................................................................................... 9

LIST OF TABLES ....................................................................................................... 10

ABBREVIATIONS ..................................................................................................... 11

1 INTRODUCTION ............................................................................................... 13

Purpose and Scope of this deliverable ................................................................ 13

Content and Structure of this Deliverable ........................................................... 13

2 ARCHITECTURE DESIGN AND DOCUMENTATION APPROACH ............................ 14

Methodology ....................................................................................................... 14

Background .......................................................................................................... 14

2.2.1 RAMI 4.0 ....................................................................................................... 14

2.2.2 AUTOWARE Framework ............................................................................... 16

Communication View .......................................................................................... 19

2.3.1 Internal Communication .............................................................................. 19

2.3.2 Communication with the ambient environment ......................................... 23

AUTOWARE and RAMI 4.0 Compliance ............................................................... 24

3 Z – BRE4K SYSTEM ARCHITECTURE ................................................................... 26

Overview .............................................................................................................. 26

Conceptual View .................................................................................................. 26

3.2.1 What is a component? ................................................................................. 26

3.2.2 Principles of Component−Based Design ...................................................... 27

Information View ................................................................................................. 27

3.3.1 Overview of the Information Flow ............................................................... 27

Blackboard System .............................................................................................. 31

Z – BRE4K Strategies ............................................................................................ 33

3.5.1 Overview ...................................................................................................... 33

Z-BRE4K Project


D1.3 v.05 Page 6/ 82

3.5.2 Z – BRE4K Strategies ..................................................................................... 34

AUTOWARE Building Blocks ................................................................................ 37

3.6.1 Overview ...................................................................................................... 37

3.6.2 Main blocks .................................................................................................. 40

Industrial Data Spaces ......................................................................................... 45

3.7.1 Overview ...................................................................................................... 45

3.7.2 Functional Requirements ............................................................................. 49

4 FUNCTIONAL VIEW .......................................................................................... 52

Condition Monitoring .......................................................................................... 52

4.1.1 Overview ...................................................................................................... 52


4.1.3 Associated Strategies ................................................................................... 53

4.1.4 Component Diagram .................................................................................... 53

4.1.5 Supported APIs ............................................................................................. 53

Cognitive Embedded Condition Monitoring Component.................................... 53

4.2.1 Overview ...................................................................................................... 53




Semantic Framework ........................................................................................... 55

4.3.1 Overview ...................................................................................................... 55




4.3.5 Supported APIs ............................................................................................. 57

Z-BRE4K Project


D1.3 v.05 Page 7/ 82

DSS ....................................................................................................................... 57

4.4.1 Overview ...................................................................................................... 57




FMECA.................................................................................................................. 61

4.5.1 Overview ...................................................................................................... 61




VRfx ...................................................................................................................... 64

4.6.1 Overview ...................................................................................................... 64




Predictive Maintenance and Machine Simulators .............................................. 66

4.7.1 Overview ...................................................................................................... 66




4.7.5 Supported APIs ............................................................................................. 68

M3 Gage .............................................................................................................. 69

4.8.1 Overview ...................................................................................................... 69



Z-BRE4K Project


D1.3 v.05 Page 8/ 82


Μ3 Software ........................................................................................................ 70

4.9.1 Overview ...................................................................................................... 70




5 DEPLOYMENT VIEW ......................................................................................... 73

5.1.1 Z-BRE4K Components Software Requirements ........................................... 73

5.1.2 Z-BRE4K Components Hardware Requirements .......................................... 76

6 CONCLUSION ................................................................................................... 79

7 REFERENCES .................................................................................................... 80

ANNEX ................................................................................................................... 81

A.1 Component Template .............................................................................................. 81

A.1.1 Overview ............................................................................................................ 81

Α.1.2 Functional Requirements .................................................................................. 81

� Α.1.3 Associated Strategies ................................................................................. 81

A.1.4 Component Diagram ......................................................................................... 81

Α.2 Software and Hardware Requirements Template ................................................... 82

Z-BRE4K Project


D1.3 v.05 Page 9/ 82

TABLE OF FIGURES

Figure 1. RAMI 4.0 3D Model ...................................................................................................... 15

Figure 2. AUTOWARE Framework ............................................................................................... 16

Figure 3. Example of heterogenous communications ................................................................. 21

Figure 4. Heterogenous and Hierarchical communications ........................................................ 22

Figure 5. OPC - UA Communications ........................................................................................... 23

Figure 6. Industrial Data Space Ecosystem (source: Fraunhofer) ............................................... 24

Figure 7. Mapping AUTOWARE to RAMI 4.0 - Layers .................................................................. 25

Figure 8. Mapping AUTOWARE to RAMI 4.0 - Hierarchy Levels (I) ............................................. 25

Figure 9. Mapping AUTOWARE to RAMI 4.0 - Hierarachy Levels (III) ......................................... 25

Figure 10. 4+1 View model .......................................................................................................... 26

Figure 11. Information Flow Diagram ......................................................................................... 27

Figure 12.Information viewpoint diagram .................................................................................. 29

Figure 13. A blackboard - system application consists of three major components .................. 31

Figure 14. Z-BRE4K overall architecture diagram........................................................................ 32

Figure 15. Synergies and interactions between the eight Z - BRE4K strategies .......................... 33

Figure 16. AUTOWARE Reference Architecture .......................................................................... 39

Figure 17. AUTOWARE Software Defined Autonomous Service Platform .................................. 41

Figure 18. Integration of the hierarchical heterogeneous communication and data

management architecture into the AUTOWARE reference architecture ................................... 43

Figure 19. Embedded of the fog node into the defined architectural framework ..................... 44

Figure 20. Redborder Security Solution Components ................................................................. 45

Figure 21. General Structure of Reference Architecture Model ................................................. 46

Figure 22: Roles and Interactions in the Industrial Data Space .................................................. 48

Figure 23. Functional Architecture of the Industrial Data Space ................................................ 49

Figure 24. Main Entity Types of Information Model ................................................................... 51

Figure 25. Condition Monitoring Component Diagram .............................................................. 53

Figure 26: Cognitive Embedded Condition Monitoring Component Diagram ............................ 55

Figure 27. Semantic Framework Component Diagram ............................................................... 56

Figure 28. DSS Component Diagram ........................................................................................... 60

Figure 29. FMECA Component Diagram ...................................................................................... 64

Figure 30. VRfx Component Diagram .......................................................................................... 66

Figure 31. Predictive Maintenance and Machine Simulators functionality flow ........................ 67

Figure 32. Predictive Maintenance and Machine Simulators component diagram ................... 68

Figure 33. M3 Gage Component Diagram ................................................................................... 69

Figure 34. M3 Software Component Diagram ............................................................................ 71

Z-BRE4K Project


D1.3 v.05 Page 10/ 82

LIST OF TABLES

Table 1. Condition Monitoring API .............................................................................................. 53

Table 2. Semantic Framework API .............................................................................................. 57

Table 3. Qualitative severity classification for FMEA. ................................................................. 62

Table 4. Risk/criticality matrix ..................................................................................................... 63

Table 5. Condition Monitoring component software requirements .......................................... 73

Table 6. Cognitive Embedded Condition Monitoring component software requirements ........ 73

Table 7. Semantic framework component software requirements ............................................ 73

Table 8. DSS component software requirements ....................................................................... 73

Table 9. FMECA component software requirements .................................................................. 74

Table 10. VRfx component software requirements .................................................................... 74

Table 11. Predictive Maintenance component software requirements ..................................... 74

Table 12. Machine Simulators component software requirements ........................................... 74

Table 13. M3 Gage component software requirements ............................................................. 74

Table 14. M3 Software component software requirements ...................................................... 75

Table 15. AUTOWARE component software requirements ........................................................ 75

Table 16. Condition Monitoring component hardware requirements ....................................... 76

Table 17. Cognitive Embedded Condition Monitoring component hardware requirements ..... 76

Table 18. Semantic Framework component hardware requirements ........................................ 76

Table 19. DSS component hardware requirements .................................................................... 76

Table 20. FMECA component hardware requirements .............................................................. 77

Table 21. VRfx component hardware requirements ................................................................... 77

Table 22. Predictive Maintenance component hardware requirements .................................... 77

Table 23. Machine Simulators component hardware requirements .......................................... 77

Table 24. M3 Gage component hardware requirements ........................................................... 77

Table 25. M3 Software component hardware requirements ..................................................... 77

Table 26. AUTOWARE component hardware requirements ....................................................... 78

Z-BRE4K Project


D1.3 v.05 Page 11/ 82

ABBREVIATIONS

Abbreviation Name

3GPP 3rd Generation Partnership Project

API Application Programming Interface

CAD Computer-Aided Design

CPPS Cyber Physical Production Systems

CRUD Create Read Update Delete

DA Device Abstraction

DB Database

DBMS Database Management System

DSS Decision Support System

FH Frequency Hopping

ERP Enterprise Resource Planning

FoF Factories of the Future

FMEA Failure Modes and Effect Analysis

FMECA Failure Modes, Effects and Criticality Analysis

GUI Graphical User Interface

HMI Human Machine Interface

HTTP Hypertext Transfer Protocol

ICT Information and Communications Technology

IDS Industrial Data Spaces

IEEE Institute of Electrical and Electronics Engineers

IoT Internet of Things

JSON Java Script Object Notation

KMS Knowledge Management System

KPI Key Performance Indicator

KRI Key Risk Indicator

RPN Risk Priority Number

M2M Machine-to-Machine

MAC Medium Access Control

MQTT Message Queuing Telemetry Transport

NoSQL Not only SQL

OEM Original Equipment Manufacture

Z-BRE4K Project


D1.3 v.05 Page 12/ 82

OPC UA OPC Unified Architecture

PLC Programmable Logic Controller

RAMI Reference Architecture Model for Industry

RDF Resource Description Framework

REST Representational State Transfer

SCADA Supervisory Control and Data Acquisition

SGAM Smart Grid Architecture Model

SPARQL Simple Protocol and RDF Query Language

SME Small and Medium Enterprises

SQL Structured Query Language

SWRL Semantic Web Rule Language

TCP/IP Transmission Control Protocol/Internet Protocol

TDMA Time Division Multiple Access

TSN Time-Sensitive Network

W3C World Wide Web Consortium

XML Extensible Markup Language

Z-BRE4K Project


D1.3 v.05 Page 13/ 82

1 INTRODUCTION

Purpose and Scope of this deliverable

This document defines and describes Z-BRE4K’s architecture, that all partners will implement

and apply based on the defined strategies, use cases, and technological objectives. It includes

aspects related to the identification of the major system components, how they should interact

and how their external interfaces should be defined. The architecture is the most critical part of

the project, because it provides a standard that fullfils all functional and non-functional

requirements. Several functional requirements and architectural constraints are defined in the

document. Gathering and validation of requirements and use cases have been performed in

parallel to the architecture definition process.

Content and Structure of this Deliverable

The deliverable is organized as follows:

� Section 2 describes Industrial Data Spaces and AUTOWARE platform, thus those two are

the main subsystems, defining most of the principles that the rest of the components

must comply with.

� Section 3 describes the system’s high-level architecture, and how the compoments are

combined with Industrial Data Spaces and AUTOWARE platform.

� Section 4 describes each component’s functionality, main inputs/outputs,

implentemented strategies, including diagrams and supported APIs tables, if they exist.

� Section 5 describes the system’s the information pipelines (components inputs/outputs

relationships) and information flow.

� Section 6 describes system’s deployment. All software and hardware requirements are

included.

� Section 7 summarizes the main conclusions.

� Section 8 includes all the refereances that have been used.

Z-BRE4K Project


D1.3 v.05 Page 14/ 82

2 ARCHITECTURE DESIGN AND DOCUMENTATION APPROACH

Methodology

The Z-BRE4K architecture is designed and developed on the foundations of the AUTOWARE

reference architecture and building blocks enabling the convergence of Information

Technology (IT), perational Technology (OT), Engineering Technology (ET) and the leveraging of

interoperability of Industrial Data Spaces (IDS), for the support of a factory ecosystem. The

objective is to develop a highly adaptive real-time Machine (network of components) Simulation

platform that wraps around the physical equipment for predicting uptimes and BRE4Kdowns –

thus creating intuitive maintenance control and management systems.

The AUTOWARE Open OS has been selected as Z-BRE4K framework for cognitive CPPS service

development and strategy implementation since the OS components have been extensively and

successfully piloted in more than 250 advanced manufacturing experiments as part of the I4MS

(www.i4ms.eu) programme and more importantly AUTOWARE has been designed specifically

with SMEs in mind. These two elements will allow that Z-BRE4K strategies can be easily

integrated over legacy machines and IT systems with minimum interference and that even SMEs

are able to easily integrate advanced predictive maintenance strategies in the very same IT

framework used to deal with production optimisation or zero-defect manufacturing processes.

Background

2.2.1 RAMI 4.0

The RAMI 4.0 (Reference Architecture Model for Industry 4.0) (RAMI4.0, 2017) specification was

published in July 2015. It provides a first draft of the reference architecture for the Industry 4.0

initiative, trying to group different aspects in a common model and to assure the end-to-end

consistency of “… technical, administrative and commercial data created in the ambit of a means

of production of the workpiece” across the entire value stream and their accessibility at all times.

Although the RAMI 4.0 is essentially focused on the manufacturing process and production

facilities, it tries to focus on all essential aspects of Industry 4.0. The participants (a field device,

a machine, a system, or a whole factory) can be logically classified in this model and relevant

Industry 4.0 concepts described and implemented.

The RAMI 4.0 3D model (see Figure 1Figure 1) summarizes its objectives and different

perspectives and provides relations between individual components. The model adopts the

basic ideas of the Smart Grid Architecture Model (SGAM), which was defined by the European

Smart Grid Coordination Group (SG-CG) and is worldwide accepted. The SGAM model was

adapted and modified according to the Industry 4.0 requirements.

Z-BRE4K Project


D1.3 v.05 Page 15/ 82

Figure 1. RAMI 4.0 3D Model

The RAMI 4.0 model aims at supporting a common view among different industrial branches like

automation, engineering and process engineering. The 3D models combine:

� Hierarchical Levels (Y Axis): this axis collects the hierarchy levels envisaged by the IEC

62264 international standards on the integration of company computing and control

systems;

� Cycle & Value Stream (X Axis): the second axis represents the life cycle of facilities and

products. The RAMI4.0 takes the IEC 62890 standard for life cycle management as a

reference point to structure the life cycle. This axis focuses on features able to provide

a consistent data model during the whole life cycle of an entity.

� Layers (Z Axis): finally, the vertical axis, represents the various perspectives from the

assets up to the business processes.

The combination of the elements on these three axes is quite innovative, especially the elements

on the X Axis. Indeed, the RAMI4.0 is the only reference architecture to explicitly analyse and

take into account entities’ life cycles.

One of the main objective of RAMI4.0 is to provide an end-to-end (i.e. since the inception of the

product’s idea, till its dismantling or recycling) framework able to connect and consistently

correlate all technical, administrative and commercial data so to create value streams providing

added value to the manufacturer.

Many elements are available in RAMI4.0, e.g. models, types, instances, production lines,

factories, etc.). They differentiate between objects, which are elements that have a life-cycle

Z-BRE4K Project


D1.3 v.05 Page 16/ 82

and data associated with it. On the other hand, there are so-called “active” elements inside the

different layers and are called Industry 4.0 components (I4.0 component). I4.0 components are

also objects, but have to ability to interact with other elements, and can be summarized as

follows:

� It provides data and functions within an information system about an, even complex,

object;

� It exposes one or more end-points through which its data and functions can be accessed;

� They have to follow a common semantic model.

Therefore, the RAMI4.0 framework goal is to define how I4.0 component communicate and

interact with each other and how they can be coordinated to achieve the objectives set by the

manufacturing companies.

2.2.2 AUTOWARE Framework

The AUTOWARE consortium has created a framework based on other existing frameworks (e.g.

BEinCPPS, FIWARE, RAMI4.0) and taking into consideration the industrial requirements from

several use cases, thereby aiming to be a solution-oriented framework. Figure 2 shows the

AUTOWARE Framework with its main components.

Figure 2. AUTOWARE Framework

2.2.2.1 AUTOWARE Ecosystem

On one side, around the world, traditional manufacturing industry is in the throes of a digital

transformation that is accelerated by exponentially growing technologies (e.g. intelligent robots,

autonomous drones, sensors, 3D printing). Indeed, there are several European initiatives (e.g.

I4MS initiative) and interesting platforms that are developing digitalization solutions for

manufacturing companies in different areas: robotic solutions, cloudification manufacturing

Z-BRE4K Project


D1.3 v.05 Page 17/ 82

initiatives, CPS platforms implementation, reconfigurable cells, etc. However, all these initiatives

were developed in isolation and they act as isolated components.

On the other side, manufacturing SMEs need to digitalize their processes in order to increase

their competitiveness through the adoption of ICT technologies. However, the global

competition and the individualized products and solutions that currently exist make it difficult

for manufacturing SMEs to access all this potential.

For this reason, AUTOWARE defined a new Autonomous Factory Ecosystem allowing

manufacturing SMEs to gain a clear competitive advantage for the implementation of their

manufacturing processes. The idea was to gather new generation of tools and decision support

toolboxes capable of supporting CPPS and digital services cloudification, robotics systems,

reconfigurable cells, etc. thanks to a faster and holistic management of several initiatives and

tools into an open ecosystem providing a more seamless transfer of information across physical

and digital worlds.

Therefore, AUTOWARE defines an open CPPS ecosystem that will gather all resources together,

thus enabling SMEs to access all the different components in order to develop digital automation

cognitive solutions for their manufacturing processes.

AUTOWARE reduces the complexity of the access to the different isolated tools significantly and

speed up the process by which multi-sided partners can meet and work together. Indeed,

AUTOWARE connects several initiatives for strengthening the European SME offer on cognitive

autonomous products and leveraging cognitive autonomous production processes and

equipment towards manufacturing SMEs. Thus, AUTOWARE leverages the development of open

CPPS ecosystem that will join several stakeholders’ needs:

� Manufacturing SMEs which will be able to develop digital cognitive automation systems

thanks to a facilitated access to several ICT tools.

� Automation and machine tool/robot providers which can incorporate open CPS trusted

platforms as part of next generation smart production line components and solutions.

� Developers of cognitive (learning, analysis, knowledge management capability services)

and automation apps for autonomous service support.

� Providers of cloud and HPC simulation and computation services that could host the

operation of advanced cognitive services.

� Integrators and solution providers that built production line solutions for SMEs and

OEMs.

2.2.2.2 AUTOWARE Reference Architecture

AUTOWARE leverages a reference architecture from BEinCPPS (fully aligned with CRYSTAL and

EMC2 CPS design practices and ARROWHEAD cloudification approach) across I4MS competence

domains (cloud, CPPS, robotics), acting as a glue among potential users and developers and a

friendly ecosystem for business development, more efficient service development over

harmonized architectures (smart machine, cloudified control, cognitive planning- app-ized

operation).

Z-BRE4K Project


D1.3 v.05 Page 18/ 82

2.2.2.3 AUTOWARE Enablers

AUTOWARE leverages several SME enablers; e.g. augmented virtuality, reliable wireless

communications, CPPS trusted auto-configuration, smart data distribution and cognitive

planning to ease cognitive autonomous systems.

AUTOWARE Roles

Within the AUTOWARE framework, the following roles were identified:

� End Users (SME): The main target group of the AUTOWARE project are SMEs (Small and

Medium Enterprises) that are looking to change their production according to Industry

4.0, CPPS and Internet of Things (IoT). These SMEs are considered the end user of the

AUTOWARE developments, whereby they do not have to use all the developed

technologies, but can only be interested in a subset of the technologies.

� Software Developers: As the AUTOWARE platform is an open platform, software

developers can create new applications that can run on the AUTOWARE system. To

support these users in their work, the system provides high usability and intuitiveness

level, so that software developers can program the system to their wishes.

� Technology Developers: The individual technical enablers can be used as a single

technology, but being an open technology, they can also be integrated into different

technologies by technology developers. The technology must be open and once again

be intuitive to re-use in different applications. Technology developers can then easily

use the AUTOWARE technology to develop new technologies for their applications and

create new markets for the AUTOWARE results.

� Integrator: The integrator is responsible for the integration of the technologies into the

whole manufacturing chain. To target this user group, the technologies must support

open interfaces, so the system can intuitive be integrated into the existing chain. The

advantage of the open interfaces is that the integrator is not bound to a certain brand

or vendor.

� Policy Makers: Policy makers can make or BRE4K a technology. To increase the

acceptance rate, the exploitation and dissemination of the technology must be at a

professional level and additionally, the technology must be validated, supporting the

right standards and targeting the right problems currently present on the market. Policy

makers can push technologies further into the market and act as large catalyst for new

technologies.

� HW Developers: For hardware developers it is important to know what kind of hardware

is required for the usage of the different technologies. In ideal case, all kind of legacy

hardware are capable of interacting with new hardware, but unfortunately, this is not

always the case.

� Automation Equipment Providers: The technologies developed within the AUTOWARE

project can be of interest to other automation equipment providers, e.g. robot

providers, industrial controller providers, sensor providers, etc.

2.2.2.4 AUTOWARE Standards

As AUTOWARE focuses on many different aspects (e.g. communication, cloud/fog computing,

Human-Robot Interaction, etc.), there are many standards related to the different fields:

Z-BRE4K Project


D1.3 v.05 Page 19/ 82

� IEEE 802.15.4e: an amendment of IEEE 802.15.4 standard, which introduces new MAC

mechanisms that allow devices to support a wide range of industrial and commercial

applications.

� IEC WirelessHART: an open industrial standard developed to meet special requirements

of wireless communication at field level in the process industry. It consistently fulfils all

specific requirements for reliability, security, cost-efficiency and ease of use.

� IETF RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (LLN), which

provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN

towards a central point as well as point-to-multipoint traffic from the central point to

the devices inside the LLN are supported.

� IEEE 802.1 TSN: Time-Sensitive Networking (TSN) is a set of IEEE 802 Ethernet sub-

standards that are defined by the IEEE TSN task group. These standards enable

deterministic real-time communication over Ethernet.

� 3GPP Standards for cellular telecommunications network technologies, Release 14 and

15, with particular interest in:

� Serie 36: LTE (Evolved UTRA), LTE-Advanced, LTE-Advanced Pro radio technology (TS

36.300, TS 36.321, TR 36.881, …)

� Serie 38: Radio Technology beyond LTE (TS 38.300, TS 38.321, …)

Communication View

Z-BRE4K architecture will be based on AUTOWARE Reference Architecture (see section 3.4 for

more details), so the connectivity approach is also based on the one considered by AUTOWARE.

2.3.1 Internal Communication

2.3.1.1 Heterogeneous communications

Communication technologies play a key role in Industry 4.0 solutions as any device or machine

in the shopfloor (sensors, actuators, embedded computers, smartphones, machines etc.) are

interconnected and exchange data both between themselves and outside of the factory.

Nowadays, field communication buses and automation networks must therefore not only

guarantee that machines and facilities can carry out production with safety, precision and

efficiency, but they must also help towards establishing a universal solution for integrating

different IT systems.

Traditionally, communication networks in industrial systems have been based on wired

fieldbuses and Ethernet-based technologies, and often on proprietary standards such as HART,

PROFIBUS, Foundation Fieldbus H1, etc. While wired technologies can provide high

communications reliability, they do not provide the required flexibility and adaptability to meet

Industry 4.0 requirements. Looking at today’s situation, an increasing number of manufacturers

are using Industrial Ethernet solutions to implement new machine connectivity as there is

enough bandwidth available to transmit safety-critical data as well as IT protocols via a common

medium in addition to fast real-time data transmission. In addition, users and manufacturers

benefit from the use of standardized Ethernet hardware, such as passive and active

infrastructure components. However, there is many competing communication solutions and

although they all use the widespread Ethernet technology, they specify different protocols and

Z-BRE4K Project


D1.3 v.05 Page 20/ 82

profiles in the superimposed ISO/OSI layers. Thus, devices that support different Industrial

Ethernet standards are not compatible or interoperable with each other. The current trend in

the Ethernet IEEE 802.1 TSN (Time Sensitive Networks) standard, which will eventually make

time-controlled transmission of real-time critical messages via standard Ethernet components

possible. Most likely, this Ethernet TSN technology will improve the heterogeneous landscape

of real-time Ethernet dialects.

Wireless communication technologies present key advantages for industrial monitoring and

control systems. They can provide connectivity to moving parts or mobile objects (robots,

machinery or workers), and offer the desired deployment flexibility by eliminating the need of

cable installation. Operating in unlicensed frequency bands, WirelessHART, ISA100.11a and

IEEE802.15.4e are some of the wireless technologies developed to support industrial

automation and control applications. These technologies are based on the IEEE 802.15.4 physical

and MAC (Medium Access Control) layers, and share some fundamental technologies and

mechanisms, e.g., a centralized network management and Time Division Multiple Access

(TDMA) combined with Frequency Hopping (FH).

On the one hand, current industrial applications demand a wide range of different

communication requirements that are difficult to be efficiently satisfied with a single

communication technology. In this context, current connectivity architectures exploit the

different capabilities of the available communication technologies (wired and wireless) to meet

the wide range of requirements of industrial applications.

For example, Figure 1 shows an example of heterogeneous communications needed in a

company that develops robotic systems for loading individual products into packaging machines

or finished packs into shipping containers. As illustrated in Figure 1, from the communications

perspective 4 main nodes can be identified. The MS (Machine System) can be considered the

brain of the machine and handles product distribution. The HMI (Human Machine Interface) is

used by the operators for a day to day control of the machine using 3D visualisation. The PLC

(Programmable Logic Controller) controls the servomotors at robots, conveyors and other

equipment, performs motion tasks and path planning for the robots based on commands

received from the MS. Finally, the Vision node runs a Vision Application that supports multiple

cameras. These 4 main nodes exchange data between them following the identified links in

Figure 3, and with other nodes (cameras, cloud and robots). The latency requirements are

especially high for the exchange of commands between the PLC and the robot. Most of the links

do not demand very high bandwidth, except the link used for raw images acquisition.

Z-BRE4K Project


D1.3 v.05 Page 21/ 82

Figure 3. Example of heterogenous communications

A massive M2M (Machine to Machine) connectivity will require an Access Point to support

hundreds of thousands of fields devices, with obvious limitations on the data rates each can

support, and thus on rates at which they are enquired for (new) data. Maintenance for such

large connectivity should be very low, thus a very long battery period for such devices will be a

necessity. A battery life for wireless devices greater than 10 years will mean that many hard to

reach sensors and actuators could only sustain very low data rates. Reliability will play a critical

role in industrial requirements with safety protection and control applications, calling for

resilient data management schemes. In addition to all these requirements, a network should

also be able to provide pervasive connectivity experience for the devices that may transition

from outdoors to indoors location in a mobile scenario. Finally, data availability issues impose

other specific requirements. For example, depending on applications, data might not be

replicated outside of a set of devices or a geographical area for ownership reasons. Data might

have to be replicated, instead, on other groups of nodes for data availability. Conversions across

data formats might be needed, to guarantee interoperability across different factory or

enterprise systems. All these issues belong to the broader concept of data sovereignty that is

the focus of the Industrial Data Space (IDS) initiative.

Z-BRE4K Project


D1.3 v.05 Page 22/ 82

2.3.1.2 Hierarchical Communication

On the other hand, the main objective of having a centralized network management is to achieve

high communications reliability levels. However, the excessive overhead and reconfiguration

time that results from collecting state information by the central manager and distributing

management decisions to end devices, limits the reconfiguration and scalability capabilities of

networks with centralized management. To overcome this drawback, factories have started to

divide a large network into multiple subnetworks, and implement a hierarchical network

architecture. Each subnetwork has its own manager that deals with the wireless dynamics within

its subnetwork. A global entity oversees the management of the entire network and coordinates

with the subnetwork managers. For these reasons, recent proposals for Industrial Wireless

Networks rely on hierarchical architectures which integrate heterogeneous technologies at the

WSNs to efficiently guarantee the wide range of different communication requirements of

industrial applications.

2.3.1.3 AUTOWARE Connectivity Solution

As it has been stated in 3.5 , AUTOWARE defines a heterogeneous and hierarchical connectivity

solution in which different communication technologies can be considered. In other words, the

AUTOWARE proposal is based on several hierarchical subnetworks or cells implementing

heterogeneous technologies and covering the whole industrial plant (or several plants). Each

network node is connected to the cell that is able to most efficiently satisfy its communication

needs. For example, WirelessHART can be used to monitor a liquid level and control a valve,

while 5G communications can be employed for time-critical communications between a sensor

and an actuator. TSN could be a good candidate to implement long-distance backhaul links

between static devices. Figure 1 illustrates the concept of cells in the proposed heterogeneous

architecture with five cells implementing two different technologies. Technology 1 and

Technology 2 could represent WirelessHART and 5G technologies. Technology 3 is used to

connect each cell through a local management entity (Local Manager), to a central management

entity (Orchestrator) in Figure 4 and it could be implemented with TSN.

Figure 4. Heterogenous and Hierarchical communications

Z-BRE4K Project


D1.3 v.05 Page 23/ 82

2.3.1.4 OPC – UA

The Unified Architecture OPC (OPC UA) is a communication protocol for industrial automation

applications. It is based on the client-server principle and allows continuous communication

from individual sensors and actuators to the ERP system or the cloud. The protocol is

independent of the platform and has integrated security mechanisms. It is flexible and totally

independent; therefore, it is considered the ideal communication protocol for the

implementation of Industry 4.0.

OPC UA covers the gap between the IP-based computing world and the production plant as all

the data from the production process is transferred by means of a single protocol, either within

the same machine, between machines or between a machine and a database in the cloud. OPC

UA eliminates the need to use the traditional fieldbus systems at the factory level.

OPC UA is built to be platform independent and the communication is built into layers on top of

the standard TCP/IP stack. Above the standard transport layers there are two layers, one that

handles the session and one to establish a secure channel between the client and server, as

shown in Figure 5.

Figure 5. OPC - UA Communications

The transport layer is made up of TCP/IP and on top of that SSL, HTTP or HTTPS. The

Communication layer secure the communication channel not just that the data is corrupted but

it also secures the authentication so that the end points can’t be infiltrated and changed. This is

based on X.509 certificates that have three parts to it and the first peer to peer trust needs to

be manually done but after that the rest is taken care of securely.

2.3.2 Communication with the ambient environment

Nowadays, companies need a controlled handling of data as well as a secure cross-company

data exchange to successfully manage the digital transformation. In this context, the Industrial

Data Space (IDS) ensures digital sovereignty over data and services and ensures the digital

Z-BRE4K Project


D1.3 v.05 Page 24/ 82

identity of all parties involved, as shown in Figure 6 (from public data to production and logistics

networks and commercial and industrial services involved in the manufacturing process).

Figure 6. Industrial Data Space Ecosystem (source: Fraunhofer)

The Industrial Data Space is a virtual data space where all companies that adhere to the common

rules can exchange, link and enrich data securely and confidently. All the data is securely

managed on the cloud, so the connectivity among all the stakeholders involved is based on

TCP/IP protocols over any MAC protocol such as Ethernet or wireless technologies. The specific

protocol depends on the specific technology considered for the specific cell or sub-network in

the factory.

AUTOWARE and RAMI 4.0 Compliance

The overall AUTOWARE Framework and Reference Architecture is also related to the RAMI4.0,

as this is the identified reference architecture for Industry 4.0. The goal of the AUTOWARE

project was to keep the developments related to the topics of Industry 4.0 and keep the

Reference Architecture and Framework related to the RAMI4.0. To establish this link, the

consortium mapped the different concepts and components of the AUTOWARE Framework to

the RAMI4.0 model. In the following figures (Figure 7 to Figure 9), a set of mappings has been

provided, which is far from the final one.

Z-BRE4K Project


D1.3 v.05 Page 25/ 82

Figure 7. Mapping AUTOWARE to RAMI 4.0 - Layers

Figure 8. Mapping AUTOWARE to RAMI 4.0 - Hierarchy Levels (I)

Figure 9. Mapping AUTOWARE to RAMI 4.0 - Hierarachy Levels (III)

Z-BRE4K Project


D1.3 v.05 Page 26/ 82

3 Z – BRE4K SYSTEM ARCHITECTURE

Overview

An architecture description approach was chosen as part of our methodology. In particular, the

description of the Z-Bre4k architecture is based on the “4+1 view model” approach, which

specifies that an architecture can be described based on four complementary views including a

logical view, a process view, a deployment view and an implementation view. These views are

complemented by a set of specified scenarios and use cases, which are used to validate the

architecture (see Figure 10).

Figure 10. 4+1 View model

In the 4+1 approach, special emphasis is paid in the logical view, which depicts the high-level

view of the architecture, including its main components and the way they are structured

together. Following the specification of the logical view, an implementation view can be derived

and elaborated in order to provide insight on the implementation task of the architecture, while

a process view can be also elaborated in order to show the dynamic behavior of the system,

including interactions and information flows between the various components. Finally, the

deployment view provides insights on the physical implementation and deployment of a system

that is based on the specified architecture.

Apart from adherence to the 4+1 view approach, the present deliverable has taken account prior

WP1 developments (notably the requirements and use cases) in order to develop the Z-Bre4k

architecture. In particular, the architecture of the project will satisfy the functional and non-

functional requirements of the project.

Conceptual View

Component-based architecture’s goal is the decomposition of the design into individual logical

or physical components. It provides a higher-level abstraction and BRE4Ks down the problem

into sub-problems, each associated with one or more components.

Component-based architecture ensures component reusability and development’s flexibility, in

a way each development team does not interfere with other teams’ work. A component

encapsulates functionality and behaviors into a reusable and self-deployable unit.

3.2.1 What is a component?

A component is a modular, portable, replaceable, and reusable set of well-defined

functionalities that encapsulates its implementation and exporting it as a higher-level interface.

It is intended to interact with other components, directly or indirectly. It has an obviously

defined interface and conforms to a recommended behavior common to all components within

an architecture.

Z-BRE4K Project


D1.3 v.05 Page 27/ 82

3.2.2 Principles of Component−Based Design

� The software system is decomposed into reusable, cohesive, and encapsulated

component units.

� Each component has its own interface that specifies required ports and provided ports;

each component hides its detailed implementation.

� Connectors connected components, specifying and ruling the interaction among

components. The interaction type is specified by the interfaces of the components.

� Components interaction can take the form of method invocations, asynchronous

invocations, broadcasting, message driven interactions, data stream communications,

and other protocol specific interactions.

Information View

3.3.1 Overview of the Information Flow

Information flow describes the flow of the data among the component and the AUTOWARE

platform and the transformations applied to that data. It also allows us to model the system’s

and subsystems’ inputs and outputs schemas and the repositories’ (relational or not) schemas.

3.3.1.1 Information Flow

Figure 11. Information Flow Diagram

Z-BRE4K Project


D1.3 v.05 Page 28/ 82

The diagram above, is a logical one, not a physical one, some parts of the Z-BRE4K system, are

intentionally left out.

The Z-BRE4K system’s main input is data from the shop floor. Assets, sensors, cameras, industrial

devices produce and send data to the system. All the data from the field first meet AUTOWARE’s

Industrial Data Spaces, and then flow into the rest of the components.

Users/employees via HMI input data to the system or parameterize the components.

There are four main data pipeline areas. All data pass through the C03 to be homogenized and

be used by the components, based on the Z-BRE4K’s principles.

C01, C02 and C08 produce statuses, alarms warnings, predictions. C05 needs input from users

to calculate risks, RPNs, criticality matrixes and alerts. All that data is necessary for the C04

component to deliver strategies, recommendations, notifications, reports and updated

schedules. Finally, C09, C10, C06 are related to XYZ cloud points, 3D representations and

visualization data of physical objects.

If we could describe Z-BRE4K’s data in sets, we would say that we have five sets:

1. Predictive and assets monitoring dataset

2. Failures/criticalities/KRI/Alerts dataset

3. Geometrical data, XYZ cloud points, 3D models, renderings etc. dataset

4. Decisions/suggestions/plans dataset

5. Simulations results dataset

3.3.1.2 Information viewpoint

Figure 12.Information viewpoint diagram

Z-BRE4K Project


D1.3 v.05 Page 30/ 82

On the information viewpoint we see the way the architecture, stores, manipulates, manages

and distributes information. The ultimate purpose is, from a high-level point of view, to illustrate

the exchanged information between the envisioned components.

A brief explanation of each data is described below:

� Shop Floor data: Data related to the shop floors, concerning assets, employees,

activities, production or other data logs, collected from automated systems, computers,

sensors, scanners, cameras and other various devices.

� Machine data: After the shop floor data has been filtered and processed by C01 machine

data is produced. Machine data describes the status of the machine and provides alarms

and warning if specifics parameters and limitations are not satisfied

� Sensors data: After the shop floor data has been filtered and processed by C02 sensors

data is produced. Packed information including informative features for condition

monitoring purposes that are based on the installed sensors, so the data doesn’t have

specific format and values.

� Prognosis data: C08, based on shop floor data, simulates the production line and

produces possible problems/failures/malfunctions that might happen in the future.

� Physical objects properties data: Physical objects properties are the dimension, color,

weight, density, volume, mass that are used and input to the C09 component.

� XYZ cloud points data: Point clouds is a set of data in a three-dimensional coordinate

system. C09, that is actually a 3D scanner produces this set. Point clouds are used for 3D

CAD models’ creation, metrology/quality inspection, and a multitude of visualization,

animation, rendering and mass customization applications.

� 3D models’ data: The mathematical representation of any scanned surface of an object.

In Z-BRE4K, the 3D representations, are solid, shell and boundary.

� Stereoscopic and visualization data: Immersive virtual environments use stereoscopic

methodologies, to create high fidelity virtual experiences in which users can interact

with the three-dimensional models and perceive relationships at their true scale. The

visualization data is related to the simulation results.

� Historical data: Data produced in the past available in database(s) or in files.

� KRI/RUL(Remaining Useful Life)/Schedules/Strategies/Rules/ RPN (Risk Priority

Numbers) data: All those data provide a number of rules, limits, execution paths (if-

then-else) to the system and define/alter its behavior.

� Criticalities (numbers and matrices): Criticalities link the probability of a FM occurrence

with its severity

� Fault data: Historical information regarding critical component reliability, reports on the

procedures and actions taken with regard to Fault Detection, Fault Diagnosis, Prognosis

and implementation, type of BRE4Kdowns, severity, risk, service time, reports on causal

relationships between component states and type of failure

Besides the above data, some of the components produce alarms, warnings, notifications based

on some predicates. Also, reports are generated.

Z-BRE4K Project


D1.3 v.05 Page 31/ 82

Blackboard System

A blackboard system presented at Figure 13 is mainly, an artificial intelligence approach based

on the blackboard architectural model, where a common knowledge base, the "blackboard", is

iteratively updated by a diverse group of specialist knowledge sources, starting with a problem

specification and ending with a solution. Each knowledge source updates the blackboard with a

partial solution when its internal constraints match the blackboard state. In this way, the

specialists work together to solve the problem. The blackboard model was originally designed

as a way to handle complex, ill-defined problems, where the solution is the sum of its parts.

Figure 13. A blackboard - system application consists of three major components

The blackboard component acts as a central repository system. Components act independently

at the common data structure stored on the blackboard, they respond on changes and create

new reactions according to changes. Interaction between components is implemented via the

blackboard. The overall Z - BRE4K component diagram is shown at Figure 14 below:

Figure 14. Z-BRE4K overall architecture diagram

Z – BRE4K Strategies

3.5.1 Overview

Z-BRE4K considers 8 scalable strategies at component, machine and system level, addressing

failure management and risk control through predictive maintenance modelling and DSS

automation. The Z-Strategies will PREVENT/PREDICT/DIAGNOSE/REMEDIATE failures,

MANAGE alarms and mitigation actions, and SYNCHRONISE with shop-floor operations and

plant management systems, while ensuring the SAFETY of the workers. Our aim is to apply a

holistic approach to increase maintainability, accurately predict the condition and the remaining

useful life of machines at the shop floor, and adapt the system performance to increase the

operating life span of production systems.

The following figure illustrates the rationale of the Z-Strategies structure:

Figure 15. Synergies and interactions between the eight Z - BRE4K strategies

In particular, Z-Strategies address:

1. The prediction of the occurrence of a failure (Z-PREDICT).

2. The early detection, the analysis and the support to avoid a current or emerging failure

(Z-DIAGNOSE).

3. The prevention of failure occurrence, building up, or even propagation in the whole

production system (Z-PREVENT).

Z-BRE4K DIAGNOSIS framework (predictive analytics)

Events Alarms

PREDICT

PREVENT

• DIAG

NOSE

• ESTIM

ATE

RUL

Failure predictions

Enhanced failure data

MANAGE

Failure criticality True positive alarms

• REMEDIATE

• SAFETY

Enriched true positive failure data

SYNCHRONISE

Assets, resources & schedules

Higher Level Plant Manage

ment systems

Z-BRE4K Project


D1.3 v.05 Page 34/ 82

4. The estimation of the remaining useful life of assets (Z-ESTIMATE).

5. The orchestration of the above strategies and the management of mitigation actions,

through KPI monitoring and real-time decision support (Z-MANAGE).

6. The replacement, reconfiguration, re-use, retirement, and recycling of

components/assets (Z-REMEDIATE).

7. The synchronization of remedy actions, production planning and logistics (Z-

SYNCHRONISE).

8. Preservation of safety, health, and comfort of the workers (Z-SAFETY).

3.5.2 Z – BRE4K Strategies

3.5.2.1 Z-PREDICT

The events detected from the physical layer at the shop floor through condition monitoring

instrumentation, are processed by the Z-BRE4K Condition Monitoring and Machine Simulation

components (incl. VR visualizations through VRfx); enriching the existing knowledge of the

system (experience), learning new patterns, and raising attention towards behavior that cause

operational and functional discrepancies (e.g. alarms for predicted failures). The more the data

pool is being increased, the more precise (repeatability) and accurate the predictions will be.

To this end, the Strategy predicts the expected performance of components and their

maintenance needs; predicting current or emerging failures. Upon failure prediction, the status

of the involved assets (components, machines, systems) changes color (e.g. yellow) at the Z-

BRE4K visualization layer.

Related functional block(s):

� Condition monitoring.

� Cognitive embedded condition monitoring.

� Machine simulators.

� VRfx.

� Predictive Maintenance.

3.5.2.2 Z-PREVENT

The Strategy for the prevention of failure occurrence is based on input from the prediction

Strategy (i.e. degraded performance of assets or failure); the Z-PREDICT is predecessor of Z-

PREVENT. A corroborating approach is being used in terms of:

a) Similarity of failure and performance degradation predictions;

b) Hierarchy of involved components, by grouping related predictions and considering

assets’ dependencies and hierarchy; part(s) > component(s) > machine(s) > system(s).

The above factors are analyzed in order to prevent the building up or even propagation of a

failure that leads to BRE4Kdown of asset(s) and production/operation stoppages. Furthermore,

the Strategy prevents multiple alarm activations on similar failures.



Z-BRE4K Project


D1.3 v.05 Page 35/ 82


� FMECA.

3.5.2.3 Z-DIAGNOSE

The Strategy is invoked when a current or an emerging failure or system performance

degradation is predicted/detected. The Z-PREDICT is predecessor of Z- DIAGNOSE.

The Strategy analyses the events resulted in the failure or low performance; by mapping the

true reasons, the Strategy triggers actions supporting avoidance of generation or emerging of

the failure. Furthermore, it assesses the severity of the problem and its potential impact on the

plant (e.g. production lines).

Weighted factors will be used to calculate the criticality of the failure, in order to:

a) Adapt accordingly system parameters influencing decision-making;

b) Recommend prolonging the operational life of the involved asset(s) until the next

planned maintenance, or re-planning maintenance.

The final decision on the actions is based on the Z-MANAGE Strategy.



� FMECA.

3.5.2.4 Z-ESTIMATE

This strategy will combine the information from the Z-DIAGNOSE and Z-PREDICT with the

machine simulators, in order to estimate the remaining useful life of the assets. The estimated

values will also be combined with the information from the maintenance operations (physical

examination from operators) as well as from the specifications provided from the manufacturer

and the physical model of the asset. The last 2 factors will be used as the starting point for the

estimation process, where after each simulation iteration, the deviation of the real-model from

the physical model will be reduced, having an accurate virtual-model wrapped around the actual

state of each machine and its components. The trends for the fatigue and ware rates will provide

a confident RUL estimation.



� VRfx.


3.5.2.5 Z-MANAGE

The outputs of the PREDICT/PREVENT/DIAGNOSE/ESTIMATE Strategies are processed by the Z-

MANAGE Strategy to offer the overall supervision and optimization features of Z-BRE4K.True

positive failures will be processed by the DSS in order to address the incident. False positives

(and false negatives) are clustered within the Z-PREDICT and Z-PREVENT Strategies, while this

Strategy performs a 2nd level alarm management:

Z-BRE4K Project


D1.3 v.05 Page 36/ 82

a) Multiple alarm activations clustered as related to the same failure, will be filtered out

to a single alarm;

b) Time-based and similarity-based corroborating analysis will be applied (i.e. alarms from

different detection/prediction sources which are considered as corroborating sources

for a given failure mode) to increase/decrease confidence levels on triggered alarms,

and improve efficiency of alarm management.

c) Final true-positive alarms will give raise to alarm(s) to the higher-level plant

management systems (e.g. ERP/MES) and also change the status of the involved asset(s)

in the visualization layer.

Additionally, the production is optimized by better scheduling (Z-SYNCHRONISE Strategy), taking

into account the impact of each failure. The optimized scheduling and adaptability of operations

improves the overall flexibility, placing a premium on the production assets, extending their

operating life, while preserving increased assets availability.



� FMECA.

� DSS.

3.5.2.6 Z-REMEDIATE

The decision-making in the event of a true-positive failure triggers the Z-REMEDIATE Strategy,

which classifies the input in terms of effect, criticality, type, asset history, etc. Based on the

component/assets types (repairable-non-repairable) and their RUL, the Strategy may

recommend the:

1. replace,

2. reconfigure and/or re-use

3. retire

4. recycle Action(s)

Furthermore, the strategy triggers the Z-SYNCHRONISE and Z-SAFETY strategies from which the

maintenance actions will be planned and organized.


� FMECA.

� DSS.

3.5.2.7 Z-SYNCHRONIZE

The predecessor Z-REMEDIATE strategy will identify the type of action required for diagnosed

(decided) failures which will be fused with the Z-MANAGE output. This strategy will synchronize

all the remedy actions with production planning and logistics (e.g. shift the production from one

machine to another due to failure or deteriorated condition/performance; rearranging workload

among assets, planning maintenance at the right time). To this end, the Strategy supports

optimized co-scheduling maintenance with plant operations / production, interfacing with

higher level plant management systems (e.g. ERP/MES).

Z-BRE4K Project


D1.3 v.05 Page 37/ 82


� DSS.

3.5.2.8 Z-SAFETY

The Strategy supports increased Health & Safety during Z-BRE4K shop floor operations. It will be

invoked when a maintenance operation takes place, in order to act as an operational

“handbrake”. Since most of the accidents occur during maintenance actions, the Z-SAFETY will

prevent any activation to the machine that is under investigation or repair. The “Safety-Mode”

will lift any unauthorized control from the personnel for the whole duration of the maintenance.

Apart from reducing the accidents, Z-SAFETY will also take into account the comfort of the

human personnel on the shop floor, e.g. extreme heat or noise may be tolerable for the

machines but not for humans.


� DSS.

AUTOWARE Building Blocks

3.6.1 Overview

The AUTOWARE Framework describes many features and concepts for the development within

the Z-BRE4K project:

� Platform: Platforms contain different technology building blocks with communication

and computation instances with strong virtualization properties with respect to both

safety and security for the cloudification of CPS services

� Architecture: Platforms focused on cloudification of CPS services should make a

template style approach for flexible application of an architectural design for suitable

implementation of predictive maintenance solutions.

� Connectivity to IoT has an open interface allowing connection and disconnection from

the platform, orchestrating and provisioning services efficiently and effectively.

� Dynamic configuration of systems as soon as systems allow automatic integration of

other systems to connect or disconnect from the system, dynamic configuration

including scheduling is implemented. The deployment of new functionalities, new

services and new system structures pose new safety and security system requirements;

component must be more dynamically configured and validated, and finally integrated

into these systems.

� Autonomous controls. High automation levels and autonomy require a high degree of

design and development work around sensors and actuators on the one hand and a high

degree of efficient and robust sensor fusion on the other.

� Virtualization of real-time functions. Control functions can be virtualized and executed

away from machine environments and machine data can be accessed remotely in real-

time. This enables a large variety of novel functionalities as it allows the geographical

distribution of computationally intensive processes, executed remotely from the

location of action.

Z-BRE4K Project


D1.3 v.05 Page 38/ 82

The main components of the AUTOWARE framework which could be considered for Z-BRE4K

architecture are:

� AUTOWARE Reference Architecture.

� AUTOWARE Enablers.

3.6.1.1 Reference Architecture

AUTOWARE Reference Architecture (RA) aligns the cognitive manufacturing technical enablers,

i.e. robotic systems, smart machines, cloudified control, secure cloud-based planning systems

and application platform to provide cognitive automation systems as solutions while exploiting

cloud technologies and smart machines as a common system. The goal of the AUTOWARE RA is

to have a broad industrial applicability, map applicable technologies to different areas, and to

guide technology and standard development.

From a structural perspective, the AUTOWARE RA covers two different areas denoted as

domains:

� Design domain: it describes the design and development methods, tools and services

for designing AUTOWARE CPPS. The components of the design domain enable users to

intuitively design the applications (usability enablers).

� Runtime domain: it includes all the systems that support the execution and operation

of the AUTOWARE CPPS.

The AUTOWARE RA has four layers/levels (see Figure 16), which target all relevant layers for the

modelling of autonomous CPPS in the view of AUTOWARE:

� Enterprise: The enterprise layer is the top layer of the AUTOWARE reference

architecture and encompasses all enterprise’s factories.

� Factory: At the factory layer, a single factory is depicted. This includes all the various

work cells or production lines available for the complete production.

� Work cell/Production Line: The work cell layer represents the individual production line

of cell within a company. Nowadays, a factory typically contains multiple production

lines (or production cells), where individual machines, robots, etc. are located in.

� Field Devices: The field devices layer is the lowest level of the reference architecture,

where the actual machines, robots, conveyer belt, etc., but also controllers, sensors and

actuators are positioned.

Z-BRE4K Project


D1.3 v.05 Page 39/ 82

Figure 16. AUTOWARE Reference Architecture

To uphold the concept of Industry 4.0 and to move from the old-fashioned automation pyramid

(where only communication was mainly possible within a specific layer and to establish

communication between the different layer, complicated interfaces were required), the

communication concept is a “Pillar” to cover all the mentioned layers. The communication pillar

enables direct communication between the different layers. The Pillar is named Fog/Cloud and

uses wired (e.g. IEEE 802.1 TSN) and wireless communication to create direct interaction

between the different layers by using Fog/Cloud concepts (blue column in Figure 16).

Finally, the last part of the AUTOWARE Reference Architecture focuses on the actual modelling

of the different technical components inside the different layers (green column in Figure 16). On

each layer, different tools or technologies are applied and for all of them different modelling

approaches are available. The goal of these modelling approaches is to ease the end user/system

developer/system integration developing the tools or technologies for the various levels.

Additionally, it could be possible to have modelling approaches that take the different layers

into account and make it easier for the users to model the interaction between the different

layers.

3.6.1.2 Enablers

AUTOWARE provides a collection of enablers that facilitates the different users of the

AUTOWARE Framework to interact with the system on various levels. Within AUTOWARE, there

are three different enablers: technology, usability and Verification and Validation (V&V).

Technology Enablers

Within the AUTOWARE Framework, there is a collection of Technology Enablers, which can be

identified as the technical tools, methods and components developed or provided within the

AUTOWARE framework. Examples of technology enablers within the AUTOWARE project are e.g.

robotic systems, smart machines, cloudified control systems, fog nodes, secure cloud- and fog-

Z-BRE4K Project


D1.3 v.05 Page 40/ 82

based planning systems as solutions to exploit cloud and fog technologies and smart machines

as a common system.

In addition, to support connectivity and data management in CPPS, novel deterministic

communication technologies and dynamic reconfiguration have been also considered as

technology enablers within AUTOWARE. It also defines the integration and orchestration of

various computing resources and CPPS trusted open platform at the scale of edge, cloud and

High-Performance Computing (HPC). As a final technology enabler, AUTOWARE framework

provides a reference implementation for a software defined autonomous services platform that

can be applied to various industrial applications. This platform is based on fog node and cloud

technology to provide the cognitive capabilities to the identified production systems.

Usability Enablers

Usability enablers are components that guarantee the usability of the AUTOWARE platform,

technical enablers and tools by the manufacturing SMEs, resulting in an easy access and

operation of the tools.

V&V Enablers

Although CPPS are defined to work correctly under several environmental conditions, in practice

it is enough if it works properly under specific conditions. In this context, certification processes

help to guarantee correct operation under certain conditions making the engineering process

easier, cheaper and shorter for SMEs that want to include CPPS in their businesses.

In addition, certification can increase the credibility and visibility of CPPS as it guarantees its

correct operation under specific standards. If a CPPS is certified to follow some international or

European standards or regulation, it is not necessary to be certified in each country, so the

integration complexity, cost and duration are highly reduced.

3.6.2 Main blocks

Once the complete AUTOWARE framework overview has been presented, the focus is on the

most useful technological blocks for Z-BRE4K.

3.6.2.1 Software Defined Autonomous Service Platform

Due to the recent development of numerous technical enablers (e.g. IoT, cloud, edge, HPC etc.),

it is possible to take a service-based approach for many components of production information

systems (IS). When using a service-based approach, instead of developing, deploying and

running our own implementations for all production IS tasks, an external service provider can

be considered, and the end-user can rent access to the offered services, reducing the cost and

knowledge needed.

AUTOWARE focuses on a service-based approach denoted as software defined autonomous

service platform (in the following, also abbreviated as “service platform”) based on open

protocols and implementing all the functionalities (physical, control, supervision, MES, ERP) as

services. As a result, the components can be reused, the solution can be reconfigured and the

technological advanced can be easily followed.

Z-BRE4K Project


D1.3 v.05 Page 41/ 82

Figure 17 includes the reference architecture of the AUTOWARE service platform showing also

how all the functionalities are positioned in the overall scheme of production IS. There are

different functionalities (and therefore, services) on the different layers depending on the scope,

but all of them are interconnected.

Figure 17. AUTOWARE Software Defined Autonomous Service Platform

3.6.2.2 Cloud Services Enablers

AUTOWARE considers several cloud services enablers for an easier implementation of the

different services or functionalities. The most useful enablers are:

� Backend Device Management – IDAS: For the translation from IoT-specific protocols

into the NGSI context information protocol considered by FIWARE enablers.

� Orion Context Broker: It produces, gathers, publishes and consumes context

information.

� Cosmos: For storage & big data analysis.

� Wire Cloud: For the development of web components.

� DyCEP: For Real-Time processing.

� DyVisual: For dynamic visualization and interaction.

All these enablers were developed inside FIWARE and FITMAN projects.

3.6.2.3 Connectivity and Data Management

Industrial applications demand a wide range of different communication requirements that are

difficult to be efficiently satisfied with a single communication technology. In this context,

AUTOWARE exploits the different capabilities of the available communication technologies

(wired and wireless) to meet the wide range of requirements of industrial applications. As a

result, AUTOWARE defines a heterogeneous communications solution. For example, it can use

WirelessHART for non-time critical monitoring or production applications while 5G can be

considered for Ultra Reliable Low Latency Communications (URLLC). In addition, wired

communication technologies can be also considered, as for example, IEEE Time-Sensitive

Z-BRE4K Project


D1.3 v.05 Page 42/ 82

Network (TSN), which improves Ethernet standard guarantying data rates and latencies even

under high-load traffic conditions.

AUTOWARE defines different scalable cells implementing heterogeneous technologies to cover

the whole industrial plant (or several plants). Different cells can use different communication

technologies but inside each cell, the same communication technology is considered. Each

network node is connected to the cell that is able to most efficiently satisfy its requirements.

The proposed reference communication and data management architecture considers a

hierarchical structure that combines local and decentralized management (local managers, LM)

with centralized decisions (orchestrator) to efficiently use the available communication

resources and carry out the data management in the system. The management structure is

depicted in Figure 4. Heterogenous and Hierarchical communications on page 25.

The Orchestrator oversees the global coordination of the radio resources assigned to the

different cells, establishing constraints to the radio resource utilization that each cell has to

comply with in order to guarantee coordination and interworking of different cells, and finally

guarantee the requirements of the industrial applications developed in the whole plant. Each

LM is in charge of the local management of the radio resources within its cell, and makes local

decisions to ensure that communication requirements of nodes in its cell are satisfied.

Furthermore, the Orchestrator plays a key role in the AUTOWARE smart data distribution

solution ensuring that data is located in the cells where it can be accessed by appropriate

decision makers in a timely manner based on the performance of the underlying communication

infrastructure. In addition, the massive amounts of generated data by IoT technologies as well

as the quick data access required for some control applications, make decentralized data

management inevitable. LMs decide where, inside the cell, data need to be replicated, stored

and moved dynamically, based on the requirements of the specific applications, and the

resources available at the individual nodes.

As a result, ¡Error! No se encuentra el origen de la referencia. shows the AUTOWARE

hierarchical architecture for communication and data management. The data exchange

between the different AUTOWARE components is carried out exploiting the Fog and/or Cloud

concepts, which interconnect all the functional layers of the AUTOWARE reference architecture,

providing communication links between devices, entities and applications implemented in

different layers, and within the same layer.

Z-BRE4K Project


D1.3 v.05 Page 43/ 82

Figure 18. Integration of the hierarchical heterogeneous communication and data management architecture into the

AUTOWARE reference architecture

As shown in Figure 18, field devices such as sensors, actuators, mobile robots, etc., are

distributed throughout the factory plant participating in different industrial processes or tasks

(Field Devices Layer). Various LMs can be implemented at different work cells or production lines

(Work cell/Production Line Layer) to locally manage the communication resources and the data

in the different communication cells deployed in the industrial plant.

When there is only one plant, the Orchestrator is in charge of the global management of the

communication resources and data used by the different sub-networks deployed within a

factory plant (Factory Level). However, if different plants are deployed, and they are close

enough so that the operation of a cell implemented in a plant can affect the operation of a

different cell in the other plant, the Orchestrator manage the communication resources of the

different plant (Enterprise Level).

3.6.2.4 Fog Computing

AUTOWARE extends a cloud-based architecture to a more flexible and efficient one based on

fog computing, which is defined by the OpenFog Consortium as follows: “A horizontal, system-

level architecture that distributes computing, storage, control and networking functions closer

to the users along a cloud-to-thing continuum”. Adding an intermediate layer for data

aggregation and computing capabilities at the edge of the network resolves the bottlenecks and

disadvantages in complex industrial scenarios:

� Data bottlenecks that occur on the interface between IT and cloud infrastructure.

� Disability to guarantee pre-defined latencies in the communication.

� Sensor data are sent unfiltered to the cloud.

� Limited intelligence on the machine level.

These drawbacks can be repealed using fog nodes. In addition, strict requirements on timing or

even real-time constrains can only be achieved by avoiding long transmission of the data. Thus,

the fog computing approach is inherently avoiding the latencies.

Z-BRE4K Project


D1.3 v.05 Page 44/ 82

Figure 19 shows the embedding of the fog node into the AUTOWARE framework. The

architecture supports the following aspects:

� Machine Control capabilities: AUTOWARE platform can control the different machines

(e.g. robots, machines, etc.) within the plant or the manufacturing cell. It can connect to

remote I/Os via an integrated PLC.

� Device Management capabilities: It allows users to perform management of multiple

machines in a distributed manner. The device manager is situated in the main office,

whereas the devices are distributed over the factories, possible worldwide. The

communication between the device manager and the different devices must be

implemented over a secure and safe communication channel.

� Data Gateway: It enables the communication between other fog nodes, between the

fog node and the cloud and with a remote operator.

� Visualization capabilities: The AUTOWARE open platform provides standard interfaced

(wired and wireless) to guarantee connectivity via user interfaces to access data via

reports, dashboards, etc.

� Application Hosting functionality: It can be located as well in the fog as in the cloud.

Figure 19. Embedded of the fog node into the defined architectural framework

The pillars of this architecture, which are common themes of the OpenFog reference

architecture, include security, scalability, openness, autonomy, RAS (reliability, availability and

serviceability), agility, hierarchy and programmability.

3.6.2.5 Security

AUTOWARE includes some security solutions to guarantee its correct operation. It includes the

use of the red border solution, which is a scalable and user adaptable Real-time Network Traffic

Analysis (NTA) and an active cybersecurity platform (intrusion prevention, malware detection

etc.) based on big data analysis and Open Source. Red border carried out tens, hundreds, or

thousands of probes in the network that gather data and actively filter traffic based on security

policies, threat/attack detection, and reputation. Its operation is based in three phases:

� Collect: red border natively collects terabytes of data in various network protocols by

means of a network sounding (see left picture in ¡Error! No se encuentra el origen de la

referencia.). It collects information related to security events, traffic events (NetFlow,

sFlow, jFlow, Flexible NetFlow) etc.

Z-BRE4K Project


D1.3 v.05 Page 45/ 82

� Analyze: red border software (see right picture in Figure 208) applies operational

intelligence, data mining or data correlation among others analysis techniques to

determine the attacks or threats in AUTOWARE. In addition, it also analyzes the network

traffic, to detect possible congestion or bottlenecks.

� Act: red border includes several security-oriented sensors and probes, extending the

ability to detect and act upon security incidents. It also interacts with leading security

products to automatically apply basic security countermeasures to stop or mitigate

incidents.

Figure 20. Redborder Security Solution Components

Industrial Data Spaces

3.7.1 Overview

The Industrial Data Space foster secure data exchange among its participants, while at the same

time ensuring data sovereignty for the participating data owners. The Industrial Data Space

Association defines the framework and governance principles for the Reference Architecture

Model, as well as interfaces aiming at establishing an international standard which considers the

following user requirements:

� Data sovereignty: It is always the data owner that specifies the terms and conditions of

use of the data provided (terms and conditions can simply be »attached« to the

respective data).

� Data usage control: In line with the central aspect of ensuring data sovereignty, a data

owner in the Industrial Data Space may attach usage restriction information to its data

before it is transmitted to a data consumer. The data consumer may use this data only

if it fully agrees to that usage policy.

� Decentralized approach: The architecture of the Industrial Data Space does not require

central data storage capabilities. Instead, it follows a decentralized approach, which

means that data physically remain with the respective data owner until they are

transmitted to a trusted party. Thus, the Industrial Data Space is not a cloud platform,

but an architectural approach to connect various, different platforms.

� Multiple implementations: The Industrial Data Space Connector, being a principal

component of the architecture, is implemented in different versions: a standard version,

which runs in corporate or cloud environments, a mobile version running on devices

with limited capacities, and an IoT version tailored to the requirements of Internet-of-

Things based scenarios.

Z-BRE4K Project


D1.3 v.05 Page 46/ 82

� Standardized interfaces: Both the architecture of the Industrial Data Space Connector

and its communication API are subject to standardization.

� Certification: The Industrial Data Space materializes as a distributed network of

Connectors, representing data endpoints. Each implementation of the Connector, as

well as each organization seeking admission to the Industrial Data Space, has to undergo

a certification process, ensuring trust and reliability across the entire business

ecosystem.

� Data economy: The Industrial Data Space Connector allows the creation of novel, data-

driven services making use of data apps (i.e., software components providing dedicated

data-related service functionalities). The participants in the Industrial Data Space can

request these data apps from an app store.

� Secure data supply chains: The Industrial Data Space aims at enabling secure data

supply chains (i.e., networks consisting of data providers and data consumers), ranging

from the source the data originates from (e.g., a sensor on an IoT device) to the actual

point of use (e.g., an industrial smart service for predictive maintenance).

In compliance with common system architecture models and standards (such as ISO 42010, 4+1

view model, etc.), the Reference Architecture Model uses a five-layer structure expressing

stakeholder concerns and viewpoints at distinct levels of granularity (Figure 21).

Figure 21. General Structure of Reference Architecture Model

The IDS reference architecture consists of the following layers:

� Business Layer specifies and categorizes the different stakeholders (namely the roles) of

the Industrial Data Space, including their activities and the interactions among them.

� Functional Layer comprises the functional requirements of the Industrial Data Space and

the concrete features derived from them (in terms of abstract, technology-agnostic

functionalities of logical software components).

� Process Layer provides a dynamic view of the architecture; using the BPMN notation, it

describes the interactions among the different components of the Industrial Data Space.

� Information Layer defines a conceptual model which makes use of “linked data”

principles for describing both the static and the dynamic aspects of the Industrial Data

Space’s constituents (e.g., participants active, Data Endpoints deployed, Data Apps

advertised, or datasets exchanged).

Z-BRE4K Project


D1.3 v.05 Page 47/ 82

� System Layer is concerned with the decomposition of the logical software components,

considering aspects such as integration, configuration, deployment, and extensibility of

these components.

In addition, the Reference Architecture Model contains three cross-sectional perspectives:

� Security: It provides means to identify participants, protect data communication, and

control the usage of data.

� Certification: It defines the processes, roles, objects, and criteria involved in the

certification of hardware and software artifacts as well as organizations in IDS.

� Governance: It defines the roles, functions, and processes from a governance and

compliance point of view, defining the requirements to be met by an innovative data

ecosystem to achieve corporate interoperability.

3.7.1.1.1 Business Layer: roles

Figure 220 shows the separate roles involved in the IDS and how they are connected to each

other.

� Data Owner: has the legal rights and complete control over its data. Usually, a

participant acting as Data Owner assumes the role of Data Provider at the same time.

� Data Provider: The Data Provider exposes data to be exchanged in the Industrial Data

Space. Exchanging data with a Data Consumer is the main activity of a Data Provider. To

facilitate a data request from a Data Consumer, the Data Provider must first provide

metadata about its data to a Broker. At the end of a data exchange completely or

partially performed, the successful (or unsuccessful) completion of the transaction

(from the perspective of the Data Provider) can be logged at a Clearing House (to

facilitate billing, conflict resolution, etc.). Furthermore, a Data Provider can use Data

Apps to enrich, transform or improve their data in some way.

� Data Consumer: The Data Consumer receives data from a Data Provider. From a

business process modelling perspective, the Data Consumer is the mirror entity of the

Data Provider; the activities performed by the Data Consumer are therefore similar to

the activities performed by the Data Provider. Before the connection to a Data Provider

can be established, the Data Consumer can search for existing datasets using a Broker.

The Broker then provides the required metadata for the Data Consumer to connect to a

Data Provider.

� Broker Service Provider: The main duty of the Broker Service Provider (or Broker) is to

manage a metadata repository that provides information about the data sources

available in the Industrial Data Space. The activities of the Broker mainly focus on

receiving and providing metadata. The Broker must provide an interface to receive

metadata from the Data Providers. These metadata should be stored in some internal

repository for being queried in a structured manner.

� Clearing House: The Clearing House is an intermediary that provides clearing and

settlement services for all financial and data exchange transactions The Clearing House

should log all activities performed in the course of a data exchange. After (part of) a data

exchange has been completed, both the Data Provider and the Data Consumer should

Z-BRE4K Project


D1.3 v.05 Page 48/ 82

confirm transmission and reception of the data, respectively, by logging the transaction

at the Clearing House.

� Identity Provider: For secure operation, and to avoid unauthorized access to data in the

Industrial Data Space, there has to be a service to verify identities. The Identity Provider

should offer a service to create, maintain, manage and validate identity information of

and for participants in the Industrial Data Space.

� App Store: The App Store provides applications that can be deployed in the Industrial

Data Space to enrich the data processing workflows.

� App Provider: App Providers develop Data Apps to be used in the Industrial Data Space.

� Vocabulary Provider: The Vocabulary Provider manages and offers vocabularies (i.e.,

ontologies, reference data models, or metadata elements) that can be used to annotate

and describe datasets.

� Software Provider: A Software Provider provides software that implements the

functionalities required by the Industrial Data Space. Unlike Data Apps, software is not

provided by the App Store, but delivered and used based on individual agreements

between a Software Provider and a software user (e.g., a Data Consumer, a Data

Provider, or a Broker Service Provider).

� Service Provider: If a participant does not deploy the technical infrastructure required

to participate in the Industrial Data Space itself, it can transfer the data to be made

available in the Industrial Data Space to a Service Provider hosting the required

infrastructure for other organizations.

Figure 22: Roles and Interactions in the Industrial Data Space

Z-BRE4K Project


D1.3 v.05 Page 49/ 82

3.7.2 Functional Requirements

3.7.2.1 Data and Service architecture

Figure 231 shows the Functional Architecture of the Industrial Data Space, grouping the single

items of the list into functional entities to be provided by the Industrial Data Space.

Figure 23. Functional Architecture of the Industrial Data Space

3.7.2.1.1 Trust and security

Although requirements related to trust and security are usually non-functional, they are

addressed by the Functional Layer, since they represent fundamental features of the Industrial

Data Space. The Trust & Security entity can be split into three main aspects: Security,

Certification, and Governance, representing the three cross-sectional perspectives of the

Reference Architecture Model

3.7.2.1.2 Connectors

The central functional entity of the Industrial Data Space is the Connector. It facilitates the

exchange of data between participants. The Connector is basically a dedicated communication

server for sending and receiving data in compliance with the Connector specification.

Participants should be able to run the Connector software in their own IT environment.

Alternatively, they may run a Connector on mobile or embedded devices.

� Data exchange: The Connector must receive data from an enterprise backend system,

either through a push mechanism or a pull mechanism. The data can be provided via an

interface or pushed directly to other participants

� Data processing and transformation: A data processing app (subtype of a Data App)

should provide a single, clearly defined processing functionality to be applied on input

data for producing an expected output.

3.7.2.1.3 Vocabulary and metadata management

Participants must have the opportunity to describe, publish, maintain and manage different

versions of metadata. Metadata should describe the syntax and serialization as well as the

semantics of data sources.

� Broker and indexing: The operator of a Connector must be able to provide an interface

for data and metadata access. Each Connector must be able to transmit metadata of its

data sources to one or more brokers

Z-BRE4K Project


D1.3 v.05 Page 50/ 82

� Vocabulary management: To create metadata, the operator may use vocabularies which

help structure metadata. The operator can use standard vocabularies, create own

vocabularies, or work collaboratively with others on new vocabularies provided by

vocabulary hubs.

3.7.2.1.4 App ecosystem

The App Ecosystem describes the lifecycle of each Data App (spanning its implementation,

provision in the App Store, and installation and support).

� Data app implementation: The developers of Data Apps should be able to annotate the

software with metadata (about exposed functionality and interfaces, pricing model,

license, etc.)

� Deployment in App store: Any authorized Data App developer may initiate a software

provision process (App Store publication). Prior to publication in the App Store, Data

Apps must pass an optional evaluation and certification process controlled by the

Certification Body

� Installation and support: A dedicated Connector service should support authorized

users in (un-)installing Apps not originating from an official App Store. A dedicated

Connector service should support authorized users in searching, installing, and

managing (e.g., removal or automated updates) Apps retrieved from an App Store.

3.7.2.1.5 Identity Management

Every Connector participating in the Industrial Data Space must have a unique identifier. Each

Industrial Data Space Connector must have a valid certificate. Each Connector must be able to

verify the identity of other Connectors (with special conditions being applied here; e.g., security

profiles).

3.7.2.1.6 Clearing House

Any transaction of participants can be logged. Privileged access to the Clearing House should

require strong authentication (e.g., 2-factor authentication)

3.7.2.2 Process layers: Interaction

The Process Layer describes the interactions between the different components of the

Industrial Data Space. These can be:

� Providing Data (from a Data Provider to the Broker Service).

� Exchanging Data (between a Data Consumer and a Data Provider).

� Publishing Apps (from App Provider to App Store).

� Using Apps (from Data Provider or Data Consumer to App Store).

3.7.2.3 Information layer: domain-agnostic information

The information layer constitutes a central agreement shared by both participants and

components, facilitating compatibility and interoperability.

Z-BRE4K Project


D1.3 v.05 Page 51/ 82

3.7.2.3.1 Industrial Data Space Vocabulary

The Industrial Data Space Vocabulary provides a formal, machine-readable representation and

specification of concepts envisaged by the Information Model. It leverages a stack of W3C

standards based on the Resource Description Framework (RDF).

3.7.2.3.2 Information Model

The Information Model can be divided into four sub-models as it is illustrated in Figure 24.

� Participant Model, focusing on the participants (community of stakeholders) in IDS.

� Connector Model, focusing on the infrastructure components of IDS.

� Data App Model, focusing on the Data Apps providing reusable software packages for

data integration and processing.

� Data Asset Model, focusing on the central commodity of IDS.

Figure 24. Main Entity Types of Information Model

3.7.2.4 System layer: technical components

The roles defined in the Business and Functional Layers are now mapped onto a concrete data

and service architecture in order to meet the requirements, resulting in what is the technical

core of the IDS. From the requirements identified, three major technical components can be

derived:

� Connector.

� Broker.

� App Store.

These are supported by four additional components, which are not specific to the IDS:

� Identity Provider.

� Vocabulary Hub.

� Update Repository (source for updates of deployed Connectors).

� Trust Repository (source for trustworthy software stacks and fingerprints as well as

remote attestation checks).

Z-BRE4K Project


D1.3 v.05 Page 52/ 82

4 FUNCTIONAL VIEW

Condition Monitoring

4.1.1 Overview

Z-BRE4K Condition Monitoring module will be designed to support different actors of the

company to evaluate machines and production systems conditions in order to better plan

maintenance operations to maximize machines availability avoiding critical and unexpected

failures.

Condition monitoring module will be used to visualize data regarding the machine status. Data

will be acquired form sensors installed around the machines specialized in gathering the intrinsic

and extrinsic machine’s key performance parameters, as well as the state of the components in

order to visualize the relevant machine information.

The intrinsic parameters represent each factor that affects the machines behavior on system

level, such as structural health, degradation of components, production rate, temperature,

vibration, etc. The extrinsic parameters involve factors that affect the machines performance

but are not in the system level such as ambient conditions, ambient temperature, humidity,

operator’s or system’s inputs, etc.

The most appropriate information to obtain from the machines are under evaluation with the

business cases of the project.

Such information will be integrated with reference models (created using ontologies) as well as

snapshots describing possibly critical operative conditions and parameters of the asset.

The industrial machine module will support production managers during the daily production

monitor and assessments and in scheduling maintenance operations to maximize machine

availability. The module will be also used by workers to detect the main machine issues in order

to act in short time.


Main input(s):

� Data from sensors located on the industrial machines.

� Data from PLC.

� Data from industrial devices.

� Reference model and snapshots correlating machine parameters and system failures.

Main output(s):

� Machine/component status, alarms, warnings.

� Process information.

� All this information will be available through the interaction with the module’s API.

Main functionalities:

� Visualize the machine conditions in order to act in short time.

� Get an overview of the components status to support maintenance planning.

Z-BRE4K Project


D1.3 v.05 Page 53/ 82

4.1.3 Associated Strategies

Z-BRE4K Condition Monitoring module (Figure 24) contributes to Z-Strategies:

� Z-Predict: systems condition monitoring provides the basis for raising attention towards

parameters/behaviors that cause operational and functional discrepancies (e.g. alarms).

� Z-Diagnose: through the machine parameters monitoring is possible to reconstruct the

machine configuration when the failure is detected.

� Z-Manage: the condition monitoring module supports the optimal maintenance

scheduling to maximize machine availability and extend its operative life.

4.1.4 Component Diagram

Figure 25. Condition Monitoring Component Diagram

4.1.5 Supported APIs

Table 1. Condition Monitoring API

Cognitive Embedded Condition Monitoring Component

4.2.1 Overview

From the network of Cyber-Physical Systems (CPS) that will be deployed throughout the factory

shop floor (Networked Machine Level – NML), this technology will be focused at the Individual

Machine Mode. It will be responsible of the cognitive pre-processing of the raw data coming

from the different sensors or actuators related to a given device, with the goal of driving to a

Production Management APIs

Description

SPRING API The Spring REST API is a set of Java Based

Restful web services which handles the

collection of data sets incoming from data

sources components and provides elaborated

data set to data consumer modules

ANGULAR API The AngularJS Global API is a set of JavaScript

functionalities to handle the data exchange

between UI component and Spring REST API

Z-BRE4K Project


D1.3 v.05 Page 54/ 82

more meaningful stream of features that will feed further processing stages inside the Z-

PREDICT strategy.

CECM will be based on joining human expert knowledge in specific failure detection/prediction

tasks with Pattern Recognition and Machine Learning techniques, in order to get the ability to

extract and pack extremely informative features describing the current state of the machine.

In line with the FOG computing layer of the CPS for Manufacturing architectural view, CECM will

enable to remove unessential data, as well as to minimize the bandwidth and memory/storage

needs for the global Z-BRE4K system operation.


Main inputs:

� Raw data from sensors and actuators.

� Experts’ knowledge for each specific scenario.

� Historical data.

Main outputs:

� Packed information including informative features for condition monitoring purposes. It

will collect the raw output of the data sources related to the process (sensors, actuators,

events) and will use machine learning techniques or expert systems to extract the most

important features/measurements from the raw acquired data in order to avoid a

bottleneck in the communication and storage systems and to ease the predictive

systems to handle high dimensional data.


� Monitoring of the intrinsic and extrinsic machine’s key performance parameters.

� Raw data capture from sensors/actuators.

� Embedded data processing: the raw data captured from the sensors will be processed

to reduce the final data throughput while maximizing the descriptive and discriminating

power for condition monitoring purposes. Expert knowledge and pattern recognition

dimensionality reduction techniques will be used for real-time feature extraction and

dimensionality reduction.

� Communication: the CPS will have connectivity to share the condition monitoring

information across other components of the architecture, mainly feeding the machine

simulators.


� The condition monitoring system (Figure 26) will contribute to all the strategies but

mainly to the Z-PREDICT.

Z-BRE4K Project


D1.3 v.05 Page 55/ 82


Figure 26: Cognitive Embedded Condition Monitoring Component Diagram

Semantic Framework

4.3.1 Overview

Z-BRE4K semantic model (i.e. Ontology) will be designed to serve as a common reference model

for annotation and description of knowledge to represent manufacturing system performance.

Re-use of existing ontologies will be envisaged towards the design of Z-BRE4K ontology. The

ontology will describe the basic entities of the project and model relevant structures of

manufacturing systems and processes, establishing a methodological framework for modelling

not only the actors and procedures at the shop floor, but also machinery and their critical

components, their failure modes and their criticality, their signatures of healthy and

deteriorated conditions, etc. It will be able to meet requirements for access to different aspects

of machinery and process related data and knowledge.

Mainly, the Semantic Framework will use data from the Z-BRE4K Repository, and the Semantic

Data Web Services will provide an interface for the interaction with other components through

the SPARQL query engine. In this context, the designed ontology will be appropriately

implemented using standard-based languages.


Main inputs:

� Data from Z-BRE4K repository (data concerning machines, processes, production data

logs, actors, and activities etc.), e.g. in XML.

Main outputs:

� Semantic enrichment of shop-floor data for modelling not only the actors and

procedures at the shop floor, but also machinery and their critical components, their

failure modes and their criticality, their signatures of healthy and deteriorated

conditions, etc. e.g. as RDF Triplets (to be used by Z-BRE4K Knowledge Base System in

T3.2).

� Semantic rules (e.g. SPARQL-based rules) for data browsing/analysis.


� Serve as a common reference model for annotation and description of knowledge to

represent manufacturing system performance.

Z-BRE4K Project


D1.3 v.05 Page 56/ 82

� Describe the basic entities of Z-BRE4K and model relevant structures of manufacturing

systems and processes.

� Meet the requirements of different stakeholders who need to have access to different

aspects of machinery and process related information and knowledge.


� Z-Manage: Semantic Framework will serve as a common reference model for

annotation and description of knowledge to represent manufacturing system

performance, and will be utilized by the Z-BRE4K Decision Support System (DSS) in T4.2

for this purpose.

� Z-Predict: Semantic framework and its annotation mechanisms will include all the

necessary information to perform analysis that support predictive maintenance and

extended operating life of assets in production facilities, and will be utilized by the Z-

BRE4K Knowledge Base System (KBS) in T3.2 for this purpose.


Figure 27. Semantic Framework Component Diagram

Z-BRE4K Project


D1.3 v.05 Page 57/ 82


Table 2. Semantic Framework API

Semantic Framework API Description

SPARQL The SPARQL Web service is used to send

custom SPARQL queries against the SF RDF

repository as a general-purpose querying web

service. Developers communicate with the

SPARQL web service using the HTTP POST

method. Each results document can be

serialized in many ways, and may be expressed

as one of the following mime types: (i)

text/xml, (ii) application/rdf+xml, (iii)

application/rdf+n3, (iv) application/ sparql-

results +xml, (v) application/sparql-

results+json or (vi) application/json. The

content returned by the web service is

serialized using the mime type requested and

the data returned depends on the parameters

selected.

Knowledge Management The SF RESTful web services can be accessed

directly via API or command line, or may be

controlled and interacted with using standard

content management systems (CMSs). Each

request to an individual web service returns an

HTTP status and optionally a document of

result sets. Each results document can be

serialized in many ways, and may be expressed

as RDF, pure XML or JSON.

DSS

4.4.1 Overview

Production planning, scheduling and manufacturing are dynamic processes. Manufactures must

respond quickly to changes, making efficient and rapid adaptations to their internal processes.

This is a challenging task, which requires flexibility and timely and effective decision-making. To

this end, DSS systems play a pivotal role.

Z-BRE4K will use the DSS component to assess the machines’ performance and accurately

diagnose and predict failures, deciding on actions to prevent their occurrence, suggesting

strategies to activate at each time; and recommending actions to improve maintainability and

operational efficiency at the shop floor, while increasing the remaining useful life of production

assets and preventing unexpected BRE4Kdowns.

Z-BRE4K Project


D1.3 v.05 Page 58/ 82

In the context of the project, the following capabilities will be available:

� Decision support towards increased maintainability and operating life.

� Incorporation / triggering of Strategies.

� Machine-learning based recommendations.

� Maintenance scheduler.

� 2nd level alarm filtering.

� Schedule updates communicated to MES, leveraging available Z-BRE4K system

communication interfaces and protocols.

� Visualization of results.

Scheduling and optimization considerations

Scheduling the maintenance of technical systems is a nontrivial optimization task which is

influenced by many different aspects like reliability and cost optimization. Most of the times,

those two aspects are conflicting as short maintenance intervals cause high maintenance costs.

The resulting problems are highly complex and therefore the use of optimization strategies has

been extensively researched. Methods for modelling and calculating reliability are reaching from

Monte Carlo simulations, Petri nets and Markov models to reliability block diagrams.

Optimization strategies are problem solving heuristics which “intelligently guess” new solutions

based on older experiences and some general assumptions. Their outputs are decision values.

Designers of preventive maintenance schedules must weigh individual costs in an attempt to

minimize the overall cost of system operation. They may also be interested in maximizing the

system reliability, subject to some sort of budget limitation. Other criteria such as availability

and demand satisfaction might be considered as the objective functions. The main problem is

to find the best sequence of maintenance and replacement actions for each component in the

system in each period over a planning horizon, such that total costs are minimized subject to a

constraint on reliability of the system; or the overall reliability of the system is maximized subject

to a constraint on budget of the system.


Main inputs:

� Alarms (1st level alarm filtering is already applied by other components).

� Semantically annotated entities from the Z-BRE4K Ontology.

� Failure modes.

� Effects of failures and their criticality.

� KRIs.

� Predicted / detected defects.

� RUL.

� Production schedules.

� Maintenance plans.

� Resources for maintenance.

Main outputs:

Z-BRE4K Project


D1.3 v.05 Page 59/ 82

� Filtered alarms (2nd level filtering applied).

� Strategies to Initiate (Actions).

� Recommendations.

� Notifications.

� Reports.

� Updated schedules (maintenance, production) to be communicated to MES (i.e. through

Z-BRE4K system communication interfaces and protocols made available by non-DSS Z-

BRE4K components).

� Criticality matrix.


� HMI: It allows the interactions between the system and the users to communicate with

the DSS.

o UI: The user inputs/reads the rules. The rules as an input can be conditions,

query parameters, or provided in Semantic Web Rule Language (SWRL).

o Results visualization: The results are visualized in various graphics, dashboards,

KPI visualizations, etc., for further understanding and analysis.

� Knowledge management:

o Rules engine: Is the software that executes one or more rules in runtime. It

supports rules, facts, priority (score), mutual exclusion, preconditions, and other

functions. It also provides the ability to register, define, classify, and manage all

the rules, verify consistency of rules definitions, define the relationships

between different rules, and relate some of these rules to other system entities

affected by or need to enforce one or more of the rules.

o Maintenance Scheduler:

� Overall planning of maintenance processes (routing output with task

steps and human/ material prerequisites, timing of activities, etc.)

� Detailed scheduling identifying the optimal time in terms of

• workload (workers' availability),

• production capacity and Schedule,

• availability of the support team, stock level of spare parts,

• energy savings,

• Interfacing with higher level management systems for co-

scheduling maintenance and production (minimizing

production work disturbance).

� Auditing: It assess effectiveness of maintenance operations. It provides to the reports

based on best practices and KPIs compliant to international standards (e.g. EN15341

based KPI calculations).

� Data persistence:

o Intermediate storage: The homogenized data is stored in this intermediate

storage before is computed by the rules engine.

o Rules: All rules from the users are persistent.

o Results: The produced results by the rules engine and the DSS.

� Actions: Actions are published for immediate consideration.

Z-BRE4K Project


D1.3 v.05 Page 60/ 82

� Suggestions: A list of suggestions in a human-readable medium.

� Schedule updates: production/maintenance schedules are

communicated to MES (i.e. through Z-BRE4K communication interfaces

and protocols made available by non-DSS Z-BRE4K components).

� Notifications: Data in text or html format, send to rendering devices

such as SMS, MMS or emails through other services. Web hooks may

apply.

� Reports: Generated files (e.g. PDF, CSV, XLSX) sent to file system.


� Z-MANAGE

� Z-REMEDIATE

� Z-SYNCHONIZE

� Z-SAFETY


Figure 28. DSS Component Diagram

Z-BRE4K Project


D1.3 v.05 Page 61/ 82

FMECA

4.5.1 Overview

Failure Modes and Effect Analysis (FMEA) is a systematic procedure for the analysis of a system

to identify the potential failure modes, their causes and effects on system performance. FMEA

generally deals with individual failure modes and the effect of these failure modes on the

system. Each failure mode (FM) is treated as independent.

FMECA (Failure Modes, Effects and Criticality Analysis) is an extension to the FMEA to include

a means of ranking the severity of the FMs to allow prioritization of countermeasures. This is

done by combining the severity measure and frequency of occurrence to produce a metric called

criticality (i.e. considering criticality combined with severity as a measure of risk).

Using the failure effects identified by the FMEA each effect is allocated to an appropriate

severity class. A frequency for the failure event is calculated from failure data or estimates for

the part concerned. Multiplied with the mission time of concern, the frequency yields a

criticality number C = λ * t, where λ = FM frequency and t = time of component/system

operation.

Furthermore, in the Z-Bre4k operational risk context, we’ll use the concept of the Risk Indicator

(commonly known as a key risk indicator or KRI), which in general, is a metric that provides

information on the level of exposure to a given operational risk which the organization has at a

particular point in time. KRIs will be used to provide an early signal of increasing risk exposures

in various areas of production machines, through an early warning to identify potential event

that may harm continuity of production (e.g. due to a machine failure). Αre capable of showing

that the production process is subject or has a high probability of being subject to a risk that

exceed the defined risk appetite.

Finally, as a corroborating risk assessment element, in Z-Bre4k we’ll also use the concept of Risk

Priority Number (RPN), as a metric to denote risk-prioritization in machine failures, dependent

on Severity (S) [1], on Probability (P)[2] and on Detectability (D)[3].

Definitions

Our Z-Bre4k risk assessment work will be based on the international standard IEC6081231. We’ll

define metrics to measure each KRI with multiple KRIs being associated to single or multiple

risks. In order to associate risks with identified failure modes (FM) of machinery, we’ll define

the Risk as R = S (Severity) * P (Probability). We’ll define Risk Priority Numbers, as

RPN = S * P * D

Each of these 3 factors (S, P, D) would be considered as individual KRIs, with secondary and

tertiary-level risk factors also considered for SEVERITY and DETECTION:

� Indicative Severity related KRIs: financial impact, impact on plant/shop floor security,

quality of production output, workers’ safety, energy consumption

Indicative Detection related KRIs: metrology parameters showing the machinery

condition (associated with the FM), how easy and accurately these parameters could be

Z-BRE4K Project


D1.3 v.05 Page 62/ 82

measured, the reliability of the interpretation of these parameters towards detecting a

particular FM (e.g. wrong decision about the occurrence of a particular FM).

For each KRI max/min tolerance thresholds will be defined, based on levels of risk appetite and

tolerance specified in each of project use cases. Should a KRI breach the min/max tolerance

level, this will be escalated in order to activate preventative measures, i.e. an alarm will be issued

to be handled by the DSS subsystem.

Severity will be treated as a metric for the assessment of the significance of the FM’s effect on

machine/part operation. Our classification will consider the following Severity levels:

Table 3. Qualitative severity classification for FMEA.

Class Severity level Consequence to persons or environment

4 Catastrophic A failure mode which could potentially result in the failure of the

system's primary functions and therefore causes serious damage

to the system and its environment and/or personal injury.

3 Critical A failure mode which could potentially result in the failure of

the system's primary functions and therefore causes

considerable damage to the system and its environment, but

which does not constitute a serious threat to life or injury.

2 Marginal A failure mode, which could potentially degrade system

performance function(s) without appreciable damage to system

or threat to life or injury.

1 Insignificant A failure mode which could potentially degrade the system's

functions but will cause no damage to the system and does not

constitute a threat to life or injury.

Probability of FM occurrence will be calculated as P = 1 – e-C where:

• C (criticality number of a component or system) = ∑ ��

• Ci (criticality number of a given FM) = λi x tj

• λi = FM frequency

• tj = time of component/system operation.

For each production machine, we’ll determine the indenture level (submachines, replaceable

units, individual parts, etc.). To this end, failure effects identified at the lower level may become

FMs at higher level, and the FMs at the lower level may become failure causes at higher level,

etc. Our high-level FMs classification distinguishes the following main categories:

1. failure during operation,

2. failure to operate at prescribed time,

3. failure to cease operation at prescribed time,

4. premature operation,

5. failure due to lower level component.

Our Criticality Matrix will link the probability of a FM occurrence with its severity; where FMs in

the top right corner represent HIGH risk, and bottom left FMs imply lowest risk:

Z-BRE4K Project


D1.3 v.05 Page 63/ 82

Table 4. Risk/criticality matrix

Frequency of occurrence

of failure effect

1 Insignificant 2 Marginal 3 Critical 4 Catastrophic

5: Frequent Undesirable Intolerable Intolerable Intolerable

4: Probable Tolerable Undesirable Intolerable Intolerable

3: Occasional Tolerable Undesirable Undesirable Intolerable

2: Remote Negligible Tolerable Undesirable Undesirable

1: Improbable Negligible Negligible Tolerable Tolerable


Main inputs:

� Machinery systems (submachines, replaceable units, individual parts, etc.)

� FMs per machinery system

� Severity and effects per FM

� Failure data (i.e. in order tocalculate frequency of FMs)

� Time of component/system operation per FM (i.e. in order to calculate criticality number)

� KRIs, incl. secondary and tertiary factors

� Tolerance level per KRI (min/max thresholds)

Main outputs:

� Risks with calculated values

� RPNs

� Criticality numbers per FM

� Criticality Matrix

� Alerts (i.e. when a KRI breaches the min/max tolerance level)


� Risk (R) & Probability (P) of a FM occurrence builder

� RPN & Severity & builder

� Effects builder

o Identify those failures which have unwanted effects on system operation, e.g.

preclude or significantly degrade operation or affect the safety of the user, and

the sequences of events brought about by each identified item failure mode,

from whatever cause, at various levels of the system’s functional hierarchy.

o A classification of identified failure modes according to relevant characteristics,

including their ease of detection, capability to be diagnosed, testability,

compensating and operating provisions (repair, maintenance, logistics, etc.);

� Potential causes of failure mode builder

� Alerter (issues and dispatches alerts when a KRI breaches the min/max tolerance level)

� Criticality Matrix builder

Z-BRE4K Project


D1.3 v.05 Page 64/ 82


List the Z-BRE4K strategies the component contributes to.

� Z-PREVENT

� Z-DIAGNOSE

� Z-MANAGE

� Z-REMEDIATE


Figure 29. FMECA Component Diagram

VRfx

4.6.1 Overview

To support humans in understanding complex issues and context, visualization is seen as a

suitable mean to tackle complexity and to generate an overview. Especially in technical areas, a

promising approach is 3D-based visualization under application of Virtual Reality (VR). Thereby,

immersion facilitates another way of access to data models and their understanding in an

intuitive manner – so, to enable humans to concentrate on their technical task and be relieved

of the challenge to understand and interpret the data itself.

VRfx is a tool for rapid creation of high quality VR visualizations. Based on geometric models

from various data sources like CAD or animation systems, users can compose scenes using an

easy-to-use graphical user interface. Materials and Shaders can be applied to any node in the

loaded geometric models. The full functionality of modern GPU hardware is accessible through

Z-BRE4K Project


D1.3 v.05 Page 65/ 82

the CgFX effect file format. This provides great flexibility in the creation of new shader effects

not found in the shader library coming with VRfx.

VRfx also allows the specification of simple Interactions without the need for programming or

scripting, and animations and behavior described in VRML 2.0 scenes can be accessed. Custom

interactions and functionality can be added through a plug-in interface.

VRfx stores only references to external resources. This yields greater flexibility and

interoperability in working with geometries, textures, and shaders, than a proprietary scene file

format can provide. For example, it is possible to modify a geometry resource and use it without

any modification in the VRfx scene.

The VRfx runtime system supports virtually any immersive display environment, e.g. CAVETMs,

PowerWalls, etc. A wide range of tracking hardware and input devices are supported. VRfx

scenes created on the desktop can be viewed in an immersive environment without any

modification. The full functionality of the VRfx GUI is available in immersive mode, too, which

allows for very quick and efficient fine-tuning for a particular display environment.

VRfx’, a simulation and visualization framework runnable on hardware environments from

desktop PCs up to Virtual Reality (VR) environments with projections on one or more sides, i.e.

PowerWalls and CAVEs. VRfx enables the realistic visualization of simulation models in a

stereoscopic, immersive manner. It is applied in a service-oriented manner at clients of industry

(e.g. AUDI, BMW) and public services and is deployable at TRL9. However, as of today, the

simulation models in VRfx are static in the sense that they do not change over time, but by user

interaction. In Z-BRE4K means to automatically adapt and especially update the simulation

models used by VRfx will be developed. Z-BRE4K will bring this new capability, the automatic

data-driven retrofitting of simulation models to TRL7. So, VRfx will be used in Z-BRE4K to

visualize models of equipment and related simulation results to advance human understanding

and thereby to improve related decisions.


Main inputs:

� Geometric data of the considered manufacturing equipment to be visualized.

� Information about the current state and related changes of the considered equipment.

Main outputs:

� Stereoscopic, immersive visualization to advance human understanding.

� Visualization of simulation results.


� HMI: The human-machine interface enables the interactions between the users and the

system to communicate with VRfx.

o UI: Support the input of visualization data by file selection and the preparation

of geometric models for visualization.

Z-BRE4K Project


D1.3 v.05 Page 66/ 82

o Visualization: Visualize the resulting models in a stereoscopic, immersive

manner.

� Input data processing: Input data is processed to enable appropriate visualization.

� Data persistence:

o Intermediate storage: The processed data for visualization is stored in the file

system by VRfx.



� Z-Predict

� Z-Estimate


Figure 30. VRfx Component Diagram

Predictive Maintenance and Machine Simulators

4.7.1 Overview

Overall an event analysis method to find the causes of failure/BRE4Kdown, evaluate the impact

and eliminate the potential causes of sudden BRE4Kdowns by understanding the events that

lead to BRE4Kdowns. By detecting the chain actions that will cause failure, finding solutions to

avoid or alert operations for remedial actions.


Main inputs:

A. Machine Simulators:

� Detail CAD/CAE details of the machines and the critical components (source: OEM

Repository).

� Detailed engineering electro/mechanical and electronics properties and specifications

of the machines (Repository: OEM and Machine Operators e.g. users).

� Existing embedded (sensors/actuation/controllers) Data Acquisition systems for

condition monitoring of the machines. If not existing suggestions for mounting such

equipment (sensors mainly) on the machines. (Source: OEM).

� Control Area Network specifications (e.g. Profibus, Modbus, devicenet…) (Source

Operator and OEM).

� The specifications of the Machine Network SCADA systems (Source: Operator and OEM).

Z-BRE4K Project


D1.3 v.05 Page 67/ 82

� Any existing Machine and Production Process Simulation files and details. (Source:

OEM).

� Overall specifications and technical set up of the real-time data management systems

(Source: OEM).

� Production line data (Network of machines in action) (Source Operator).

B. Predictive Maintenance

� Historical information regarding critical component reliability, MTBF, and any other

Maintenance information (Source: Maintenance Log Books OEM and operator).

� Detail reports on the procedures and actions taken with regard to Fault Detection,

Fault Diagnosis, Prognosis and implementation (Source: Operator and OEM)

� Type of BRE4Kdowns, severity, risk, service time. (Source: OEM, Z-Prevent, Z-Manage)

� Current preventative maintenance plans (Source OEM and Operator)

� Reports on causal relationships between component states and type of failure (Source:

OEM and Operator)

Main outputs:

� Predicted Meantime between failure

� Predicted Service Time

� Prognosis


� Machine/Component Simulator: Provides visual and the necessary illustration of

machine state. Using mathematical models and logics the function is to display the

current state of the machine with respect to potential failures (alarms) and causes of

failures.

� Predictive Maintenance: Provides a predicted failure mode, meantime between failure,

Type of failure, and possible cause.

Figure 31. Predictive Maintenance and Machine Simulators functionality flow

Z-BRE4K Project


D1.3 v.05 Page 68/ 82


� Z-PREDICT

� Z-DIAGNOSE

� Z-PREVENT

� Z-MANAGE


Figure 32. Predictive Maintenance and Machine Simulators component diagram


API Description

Supported API for other entities to

communicate with Machine Simulator

Description of the supported API:

Interfaces with machines, controllers,

production planning applications, and

BRE4Kdown alarm systems, Machine and

component CAE/CAM/Simulator files

(API coming direct from those sources –

OEM facilitated or from AUTOWARE)

Supported API for other entities to

communicate with Predictive Maintenance

Interfaces with Component A (Machine

Simulators), machines, controllers,

production planning applications, and

BRE4Kdown alarm systems, Machine and

component CAE/CAM/Simulator files

(API coming direct from those sources –

OEM facilitated or from AUTOWARE)

Z-BRE4K Project


D1.3 v.05 Page 69/ 82

M3 Gage

4.8.1 Overview

Z-BRE4K will exploit metrological information (point clouds…) of the products inspected to build

applications for Zero BRE4K downs of inline quality control equipment as well as for predictive

maintenance services for smart and fast machine verification and condition monitoring. In this

context, the M3 Gage component will be used for the digitalization of a physical object/part in

order to obtain its metrology information.

M3 Gage is a dimensional inspection system specifically designed for in-line inspection. It

digitizes parts and obtains a virtual part with high accuracy from which different data that can

later be obtained (geometries, CAD comparison, dimensional deviations…). M3 gage brings a

complete integration, connectivity and traceability in just one workflow.


Main inputs:

� Physical object to digitalize.

Main outputs:

� XYZ cloud points


� Digitalization of a physical object (virtual part): Obtaining XYZ cloud points.

� Highly accurate Surface Representation.



� Z-Predict

� Z-Prevent

� Z-Diagnose


Figure 33. M3 Gage Component Diagram

Z-BRE4K Project


D1.3 v.05 Page 70/ 82

Μ3 Software

4.9.1 Overview

Z-BRE4K aims to build applications for Zero BRE4K down of inline dimensional quality control

equipment as well as to create predictive maintenance services for smart and fast machine

verification and condition monitoring. This will be achieved by means of exploiting dimensional

metrology information in the form of point clouds from the parts inspected and knowledge of

the status of the in-line inspection systems. In this context, the M3 software component will be

used for the organization, analysis and reporting operations of the metrological information,

taking advantage, if required, of the storage and computational capabilities of the cloud to carry

out advanced operations and provide smart added value services (back-ups, automated back-

ups, incremental back-ups, security access…).

M3 is the name given to the platform that will serve to integrate different data sources, mainly

from M3 gage systems (in Z-BRE4K in line dimensional inspection systems). The M3 platform

serves as a data repository as well as allows the interconnection of information from various

sources using a format that can be used by the M3 Analytics module. The platform will also

provide computing mechanisms to process the data it contains and generate additional

information.

M3 Analytics module (M3 Dashboard, M3 Statistics, M3 Reports) is a powerful tool that

enables the visualization, the statistics analysis and the reporting operations related to all the

data stored in the cloud by means of several algorithms and computational components. As this

tool makes use of the memory and computational resources available in the cloud, it is possible

to use it anytime and anywhere and by means of a simple computer or tablet with low

computational capacities. Its major features are:

� Create control dashboards.

� Combine production data with measurement data.

� Automation of reports.

� Histograms.

� Cp and Cpk Statistics.

� Custom Filters.

M3 Dashboard enables the organization of the information based on the parameters that

interest you. M3 Statistics enables the analysis of the production process from any device at any

time. Finally, M3 Reports enables the creation of your own customized report templates to

share with your clients.


Main inputs:

� XYZ cloud points.

Main outputs:

� 3D representations.

Z-BRE4K Project


D1.3 v.05 Page 71/ 82

� Recommendations.

� Notifications.

� Reports.

� Histograms.


� M3 Cloud: Distributed storage in the cloud.

� M3 Dashboard: Organization of the information based on the parameters of interest.

� M3 Statistics: Analysis of the production process (3D visualization, histograms,

statistics etc.).

� M3 Reports: Creation of customized report templates to share with your clients.



� Z-Predict

� Z-Prevent

� Z-Diagnose


Figure 34. M3 Software Component Diagram

The main components are:

� Admin: It is the web administration interface of the M3 platform. It will allow to create,

consult and modify data sources (in this case instances of M3), as well as to manage

their associated information. It will also allow to check the date of the synchronization

status, as well as to configure the synchronization frequency. In the same way, from the

Z-BRE4K Project


D1.3 v.05 Page 72/ 82

administration interface it is also possible to create work environments for M3Analytics

users, and assign the M3 data sources to which they will have access. Another

functionality is the consultation of projects loaded in M3 taking into account all the

associated sources. This component interacts directly with: Web Server (since it is

hosted on it), M3CloudDB, Job Scheduler, Ingest & Sync and Workspacer.

� Web Server: It is the web server where the M3 administration application is hosted.

Therefore, either directly or indirectly, it also works with the same modules as Admin.

� M3CloudDB: It is a relational database with data about the configuration of the web

server, information on data sources, their synchronization status, tasks, schedules and

working environments configurations.

� M3CloudDB API: It offers functions to interact and perform CRUD operations on

M3CloudDB.

� Job Scheduler: It is the module responsible for the execution and programming of

asynchronous tasks.

� Ingest & Sync: The mission of this module is to carry out the ingestion of data from an

M3 data source to the common repository (Big Data Storage). It will be in charge of

saving the data in the space corresponding to the M3 source that is being processed,

and that, in case of existing data, they are updated with the new ones.

� Big Data Storage: As previously mentioned, it is the common repository where all the

data coming from the different M3 sources configured in M3Cloud are stored.

� BigDAPI: It is the API to more easily access the data stored in the Big Data Storage.

� Workspacer: This module is responsible for preparing a database accessible from a

M3Analytics application.

� Workspace 1...n: It is about each of the work environments created by the Workspacer.

It consists of a relational database containing the data of the projects an M3Analytics

user is working on, as well as the information that has been generated with that data.

Z-BRE4K Project


D1.3 v.05 Page 73/ 82

5 DEPLOYMENT VIEW

5.1.1 Z-BRE4K Components Software Requirements

5.1.1.1 Condition Monitoring

Table 5. Condition Monitoring component software requirements

Software requirements

� Operating systems: Windows, Linux

� Programming language JDK: JAVA 1.8.x

� Application server: Tomcat 8.5

� Webserver: Nginx 1.1x or Apache HTTP Server 2.4.x

� Relational DBMS: MySQL 5.7

� Optional DBMS: Cassandra v.3.x

5.1.1.2 Cognitive Embedded Condition Monitoring

Table 6. Cognitive Embedded Condition Monitoring component software requirements


� Operating systems: Linux

� Software frameworks: Anaconda (Python distribution), Tensor flow, Keras

5.1.1.3 Semantic Framework

Table 7. Semantic framework component software requirements


� Operating system: CentOS 6, CentOS 7, Ubuntu 14.04

� Software frameworks: Open Semantic Framework

� Web servers: PHP 5.4 or higher

� Relational DBMS: MSSQL Server 2014

� Other related-dependent software/tools/etc.: Dapper, React

5.1.1.4 DSS

Table 8. DSS component software requirements


� Operating system: Windows 8, 10, 64-bit-Versions preferred

� Software frameworks: .NET framework 4.7

� Web servers: IIS for on premises installation / Azure for cloud installation


� Other related-dependent software/tools/etc.: Dapper, React

Z-BRE4K Project


D1.3 v.05 Page 74/ 82

5.1.1.5 FMECA

Table 9. FMECA component software requirements


� Operating system: Windows 8, 10, 64-bit-Versions preferred

� Software frameworks: .NET framework 4.7

� Web servers: IIS for on premises installation / Azure for cloud installation


� Other related-dependent software/tools/etc.: Dapper

5.1.1.6 VRfx

Table 10. VRfx component software requirements


� Operating system: Windows 7 SP1+, 8, 10, only 64-bit-Versions

� Software frameworks: under construction

� Web servers: under construction

� Other related-dependent software/tools/etc.: under construction

5.1.1.7 Predictive Maintenance

Table 11. Predictive Maintenance component software requirements


� Not available at the moment

5.1.1.8 Machine Simulators

Table 12. Machine Simulators component software requirements



5.1.1.9 M3 Gage

Table 13. M3 Gage component software requirements


� Operating system: MS Window Win7 minimum (MS WXP not supported). Standards:

m3, qif, dmo, dmi, csv, stl, step, xml

Z-BRE4K Project


D1.3 v.05 Page 75/ 82

5.1.1.10 M3 Software

Table 14. M3 Software component software requirements


� Operating system: MS Window Win7 minimum (MS WXP not supported). Standards:

m3, qif, dmo, dmi, csv, stl, step, xml

5.1.1.11 AUTOWARE

Table 15. AUTOWARE component software requirements


FIWARE IDAS

� A virtual machine with CentOS

5.8 installed.

� Java Runtime Environment,

Tomcat, Mongo DB and Monit.

FIWARE ORION CONTEXT BROKER

� Operating system:

CentOS/RedHat.

� Database: MongoDB is required.

The recommended versions are

2.6/3.0/3.2/3.4. It is not

recommended using MongoDB

2.4.x., as some queries may not

work.

� RPM dependencies.

� It depends on the following

packages: boost-filesystem,

boost-thread, gnutls, libgcrypt,

logrotate and libcurl.

FIWARE COSMOS

� VirtualBox or VMWare.

� Hadoop cluster (Hortonworks

Data Platform (HDP)., Cloudera

Distribution for Hadoop (CDH),

MapR ETC.)

� HDFS service, YARN service,

MapReduce2, Hive service.

FIWARE WIRECLOUD

� A Database Manager (MySQL,

PostgreSQL, SQLite3...).

� Python 2.7 or python 3.4+.

� WireCloud should work on Linux,

Mac OS and Windows. However,

it is better to use Debian

Wheezy+, CentOS 6+, Ubuntu

12.04+ or Mac OS X 10.9+.

FITMAN DyCEP � Java 6.

Z-BRE4K Project


D1.3 v.05 Page 76/ 82

� Python 2.6.

� Supervisord.

� Zookeeper Server.

� ActiveMQ broker.

5.1.2 Z-BRE4K Components Hardware Requirements

5.1.2.1 Condition Monitoring

Table 16. Condition Monitoring component hardware requirements

Hardware requirements

There are no particular hardware requirements in order to deploy the i-Like machines so far.

The only recommendation is to have enough Hard drive capacity to store data coming from

machines or other sources.

5.1.2.2 Cognitive Embedded Condition Monitoring

Table 17. Cognitive Embedded Condition Monitoring component hardware requirements


� Processing power (CPU): ARM based platform (e.g. jetson tx2, beagblebone,

raspberry etc.), including a GPU only in the use cases that require

computationally intensive algorithms.

� Other related-dependent software/tools/etc.: Peripherical sensor interface. (In

some cases where the component is directly connected to the sensor).

5.1.2.3 Semantic Framework

Table 18. Semantic Framework component hardware requirements


� Processing power (CPU): i5 preferable

� HDD: 500 GB hard disk

� RAM: At least 16GB

5.1.2.4 DSS

Table 19. DSS component hardware requirements


� Processing power (CPU): Minimum i3-8350K

� RAM: 8GB

Z-BRE4K Project


D1.3 v.05 Page 77/ 82

5.1.2.5 FMECA

Table 20. FMECA component hardware requirements



� RAM: 8GB

5.1.2.6 VRfx

Table 21. VRfx component hardware requirements



� RAM: At least 4GB, 8GB preferred

5.1.2.7 Predictive Maintenance

Table 22. Predictive Maintenance component hardware requirements



5.1.2.8 Machine Simulators

Table 23. Machine Simulators component hardware requirements



5.1.2.9 M3 Gage

Table 24. M3 Gage component hardware requirements


� Processing power (CPU): Core i3

� HD: 500GB minimum

� RAM: 4GB minimum

� Graphic Card: 1024MB minimum

� Database: MySQL

5.1.2.10 M3 Software

Table 25. M3 Software component hardware requirements


� Processing power (CPU): i5 preferable

� HDD: 500 GB hard disk

Z-BRE4K Project


D1.3 v.05 Page 78/ 82

� RAM: At least 16GB

5.1.2.11 AUTOWARE

Table 26. AUTOWARE component hardware requirements


FIWARE IDAS � A minimum of 1024 Mb of RAM

and 30 Gb of HDD are needed.

FIWARE ORION CONTEXT BROKER � RAM: 1 GB, especially if abusing

of the batching mechanism.

� HDD: A few GB may be enough

(around 30 GB)

FIWARE COSMOS � 32 GB RAM and at least 500 GB

HDD.

FIWARE WIRECLOUD � No special requirements.

Z-BRE4K Project


D1.3 v.05 Page 79/ 82

6 CONCLUSION

The deliverable D1.3 describes the main results of task T1.3, i.e. the achievement of defining the

Z-BRE4K’s architecture.

We used the top-down approach and the resulting platform will act as main driver for

interpretation and explanation of the activities related to the design and management of a zero-

defect manufacturing system at large. For this reason, it constitutes a practical and useful tool

for the whole consortium in exploring and interpreting the implications and opportunities of

implementing it.

The main achieved goal of the present work is to lay the basis for a consistent design, based on

Industrial Data Spaces, AUTOWARE and the components. The architecture ensures consistency

of the future design and development activities to be carried out in the next work packages thus

avoiding the risk of scattered development and low level of interoperability.

The whole concept of the project relies on the creation of an overall framework of integrated

tools. The issue of creating such a holistic yet focused and usable solution has been addressed,

be defining functionalities, requirements and needed data. In this way, we ensure that all the

future efforts will be coherently focused on the same, commonly shared and accepted

objectives and functionalities.

Z-BRE4K Project


D1.3 v.05 Page 80/ 82

7 REFERENCES

� [INDUSTRIAL DATA SPACES 2015] WHITE PAPER – FRAUHOFER

https://www.fraunhofer.de/content/dam/zv/en/fields-of-research/industrial-data-

space/whitepaper-industrial-data-space-eng.pdf

� [BEinCPPS Architecture and Business Processes]

https://docs.wixstatic.com/ugd/03d390_38d6c3469128467d8e08e07b78f34bbd.pdf

� [AUTOWARE] AUTOWARE D1.3 (ARCHITECTURE)] http://www.AUTOWARE-eu.org/

� [ISO/IEC/IEEE] ISO/IEC/IEEE 42010:2011 https://www.iso.org/standard/50508.html

� [Tipsuwan, Y. and Chow, MY, Control methodologies in networked control systems,

Control Engineering Practice. 11: 1099–1111, 2003]

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.325.940&rep=rep1&type=

pdf

� [ReconCell] http://www.reconcell.eu/

� [The Fortissimo Marketplace. Advanced Simulation, Modelling & Data Analytics for

Industry] https://www.fortissimo-project.eu/

� [FIWARE Technologies enabling Industry 4.0]

http://www.fiware4industry.com/?page_id=292

� [BEinCPPS Architecture - Layers]

http://media.wix.com/ugd/03d390_8dec5cb0f8544fb8a5d2e068feed232a.pdf

� [SIEMENS MindSphere] https://www.siemens.com/global/en/home/company/topic-

areas/digitalization/mindsphere.html

� [sCorPiuS Project – Roadmap – Future trends and Research Priorities for CPS in

Manufacturing – White Paper - January 2017] https://www.scorpius-project.eu/

� [GPU vs FPGA Performance Comparison – White Paper]

http://www.bertendsp.com/GPU_vs_FPGA_Performance_Comparison.pdf

� [Cullinan, C., Wyant, C., Frattesi, T., & Huang, X. (2013). Computing performance

benchmarks among cpu, gpu, and fpga.] https://web.wpi.edu/Pubs/E-

project/Available/E-project-030212-123508/unrestricted/Benchmarking_Final.pdf

� [KRIs, Deloitte,9/2014]

www.rims.org/annualconference/riskforum2014/Documents/Key%20Risk%20Indicato

rs.pdf

� [Key Risk Indicators, Scorecard, and Template]http://www.bscdesigner.com/key-risk-

indicators-kris-and-risk-scorecards.htm

� [FAILURE MODE EFFECTS ANALYSIS (FMEA)] http://asq.org/learn-about-

quality/process-analysis-tools/overview/fmea.html

� [Why FMEA is Critical in Industrial Manufacturing] http://www.huimfg.com/fmea-

critical-industrial-manufacturing/

� [Analysis techniques for system reliability–Procedure for failure mode and effects

analysis] https://webstore.iec.ch/preview/info_iec60812%7Bed2.0%7Den_d.pdf

Z-BRE4K Project


D1.3 v.05 Page 81/ 82

ANNEX

A.1 Component Template

A.1.1 Overview

Overview of the component being specified in terms of purpose, functionality, business logic,

implementation aspects

Α.1.2 Functional Requirements

Main inputs:

� Pls. Specify main input-1; Additionally, pls. give an indication where the input item is

expected to come from (e.g. from Repository, or from Operator, or from Component-

XYZ)

� ......

� ......

� Main outputs:

� Pls. Specify main output-1 Additionally, pls. give an indication of the output recipient /

consumer (e.g. stored in Repository, presented to Operator, or to be used in

Component-XYZ)

� ......

� ......

� Main functionalities:

� Pls. Specify main functionality-1

� ......

� ......

� Α.1.3 Associated Strategies

� List the Z-BRE4K strategies the component contributes to.

� Strategy-Z: how the component-X contributes to Strategy-Z ….

� ……: ……

A.1.4 Component Diagram

Pls. include a component diagram of Component-X. Example:

Z-BRE4K Project


D1.3 v.05 Page 82/ 82

Α.2 Software and Hardware Requirements Template


� Software requirement 1

� Hardware requirements

� Hardware requirement 1