MANTIS · V0.2 08/01/2018 UNINOVA First Draft V0.3 18/01/2018 UNINOVA Preliminary Version sent...

Cyber Physical System based Proactive Collaborative

Maintenance

MANTIS

Interface, Protocol and Functional

Interoperability Guidance and Specification

Work Package WP2 - Service platform architecture development

Version 1.1

Contractual Date of Delivery 28/02/2018

Actual Date of Delivery 03/05/2018

Dissemination Level Public

Responsible Martin Becker (FHG)

Contributors Pedro Maló (UNINOVA), Giovanni Di Orio (UNINOVA), Guilherme Brito (UNINOVA), Luis Paiva (UNINOVA), Jose Luis Flores (IKERLAN), Raul Miñ on (IKERLAN), Veli-Pekka Salo (WAPICE), Felix Larrinaga (MGEP), Ignacio Arenaza (MGEP), Michael Hackner (BOSCH), Martina Pianta (3E), Philippe Duthoit (3E), Dirk Devriendt (3E), Csaba Hegedus (AITIA), Istavan Moldovan (BME), Erkki Jantunen (VTT)

Reviewers Felix Larringa (MGEP), Urko Zurutuza (MGEP)

D2.10 Interface, Protocol and Functional Interoperability Guidance and Specification 662189 – MANTIS – ECSEL-2014-1

ii http://www.mantis-project.eu MANTIS

The MANTIS consortium consists of:

Num. Short Name Legal Name Role Country

1 MGEP Mondragon Goi Eskola Politeknikoa J.M.A. S.Coop. CO ES

2 MONDRAGON Mondragon Corporacion Cooperativa S.Coop. BEN ES

3 IKERLAN Ikerlan S.Coop. BEN ES

4 TEKNIKER Fundacion Tekniker BEN ES

5 FARR Fagor Arrasate S.Coop. BEN ES

5.1 KONIKER Koniker S.Coop. TP ES

6 GOIZPER Goizper S.Coop. BEN ES

7 ACCIONA Acciona Infraestructuras S.A. BEN ES

8 MSI Mondragon Sistemas De Informacion S.Coop. BEN ES

9 VTT Teknologian Tutkimuskeskus VTT Oy BEN FI

10 LUAS Lapin Ammattikorkeakoulu Oy BEN FI

11 NOME Nome Oy BEN FI

12 FORTUM Fortum Power And Heat Oy BEN FI

14 WAPICE Wapice Oy BEN FI

15 AAU Aalborg Universitet BEN DK

16 DANFOSS Danfoss A/S BEN DK

19 VESTAS Vestas Wind Systems A/S BEN DK

20 SIRRIS Sirris Het Collectief Centrum Van De Technologische Industrie BEN BE

21 ILIAS Ilias Solutions Nv BEN BE

22 ATLAS Atlas Copco Airpower Nv BEN BE

23 3E 3e Nv BEN BE

24 PCL Philips Consumer Lifestyle B.V. BEN NL

25 PHC Philips Medical Systems Nederland B.V. BEN NL

26 PHILIPS Philips Electronics Nederland B.V. BEN NL

27 S&T Science and Technology B.V. BEN NL

28 TU/E Technische Universiteit Eindhoven BEN NL

29 RUG Rijksuniversiteit Groningen BEN NL

30 UNINOVA UNINOVA - Instituto de Desenvolvimento de Novas Tecnologias BEN PT

31 ISEP Instituto Superior de Engenharia do Porto BEN PT

32 INESC Instituto de Engenharia de Sistemas e Computadores do Porto BEN PT

33 ADIRA ADIRA - Metal Forming Solutions S.A. BEN PT

34 ASTS Ansaldo STS S.p.A. BEN IT

35 CINI Consorzio Interuniversitario Nazionale per l’Informatica BEN IT

36 AIT Austrial Institute of Technology GmbH BEN AT

37 HBM Hottinger Baldwni Messtechnik GmbH BEN AT

38 INNOTEC Innovative Technology and Science Limited BEN UK

39 AITIA AITIA International Inc. BEN HU

40 BME Budaperst University of Technology and Economics BEN HU

41 JSI Josef Stefan Institute BEN SI

42 XLAB XLAB d.o.o. BEN SI

43 FHG Fraunhofer Institute for Experimental Software Engineering IESE BEN DE

44 M2X M2Xpert GmbH & Co KG BEN DE

45 STILL STILL GMBH BEN DE

46 BOSCH Robert Bosch GMbH BEN DE

47 LIEBHERR Liebherr-Hydraulikbagger GmbH BEN DE

48 SATA Sataservice Oy BEN FI

49 XTEL Xtel Aps BEN DK

50 NEOGRID Neogrid Wireless Aps BEN DK

662189 – MANTIS – ECSEL-2014-1 D2.10 Interface, Protocol and Functional Interoperability Guidance and Specification

http://www.mantis-project.eu iii MANTIS

Document Revisions & Quality Assurance

Revisions:

Version Date By Overview

V0.1 01/12/2017 UNINOVA Preliminary Version of the Final Document

V0.2 08/01/2018 UNINOVA First Draft

V0.3 18/01/2018 UNINOVA Preliminary Version sent distributed and shared to the consortium

V0.4 08/02/2018 MGEP Comments and speech and grammar checking

Contributions on the MIMOSA standard

V1.0 01/03/2018 UNINOVA Final Version of the document

V1.1 03/05/2018 MGEP Last edition


iv http://www.mantis-project.eu MANTIS

Abstract

This document deeply analyses the main problem of interoperability in the context of cyber-physical systems. It is intended to augment the MANTIS Architectural Reference Model (MARM) – presented in

the deliverables D2.2, 2.6 and 2.9 – with the interoperability perspective i.e. to extend the MARM with specification and guidelines for enabling the inclusion of the MANTIS platform in already existent ecosystems.

Interoperability is a critical issue in all the applications that need communication, cooperation and

collaboration of humans, numerous distributed heterogeneous devices/components and ICT systems. It plays a fundamental role whenever the designed system/platform will be part of a large ecosystem with different stakeholders.

Interoperability is a necessary condition for assuring effective communication between distinct devices/components and ICT systems. Since communication can take place both horizontally and vertically

then interoperability needs to be analysed at different abstraction levels from concrete/physical to abstract.

The analysis carried out in this document provides a how-to description on how to design and develop MANTIS enabled cyber physical systems, as well as, how to integrate legacy systems into the MANTIS platform.


http://www.mantis-project.eu 5 MANTIS

Table of Contents

1 About this document .......................................................................................................... 9

1.1 Role of the Deliverable ........................................................................................................... 9

1.2 Relation to the other MANTIS Tasks ...................................................................................... 10

1.3 Methodology ....................................................................................................................... 12

1.4 Document Structure ............................................................................................................. 14

2 Introduction .................................................................................................................... 15

3 Interoperability ................................................................................................................ 16

3.1 Introduction to Interface, Protocol and Functional Interoperability ................................................ 18

3.1.1 Basic Definitions ....................................................................................................................... 21

3.2 Exemplary Application Context ............................................................................................... 22

3.2.1 Interoperability in Production Asset Maintenance ......................................................................... 22

3.2.2 Interoperability in Vehicle Maintenance Management ................................................................... 26

3.2.3 Interoperability in Energy Production Asset Management ............................................................. 30

3.2.4 Interoperability in Health Equipment Maintenance ....................................................................... 34

State-of-the-Art Relevant Approaches ................................................................................................. 38

3.2.5 Arrowhead ................................................................................................................................ 38

3.2.6 IMC-AESOP ............................................................................................................................. 39

3.2.7 PRIME ..................................................................................................................................... 40

3.2.8 IoT-A ....................................................................................................................................... 40

3.2.9 FIWARE ................................................................................................................................... 42

3.2.10 SOFIA2 ................................................................................................................................ 43

4 Interoperability in MANTIS ............................................................................................... 44

4.1 The Approach ..................................................................................................................... 44

4.2 MANTIS Cloud-based Environment Interoperability Reference Model ............................................ 46

4.2.1 The Concept ............................................................................................................................. 46

4.2.2 The Interoperability Levels/Tiers ................................................................................................ 47

4.2.3 Exemplary Use Cases ................................................................................................................. 49

4.3 Discussion and Wrap-up ........................................................................................................ 59

5 Focusing on Standards: ISO 13374 and the role of MIMOSA .................................................. 60

5.1 The role of standards in Achieving Interoperability ..................................................................... 60

5.2 MIMOSA Standards ............................................................................................................. 61

6 Interoperability Guidance and Specifications ......................................................................... 62

6.1 Formalizing the MANTIS Interoperability Framework ................................................................. 64

6.1.1 Conceptual Integration ............................................................................................................... 64

6.1.2 Application Integration............................................................................................................... 65

6.1.3 Technical Integration ................................................................................................................. 66

6.2 Physical Entity Virtualization ................................................................................................. 68

6.2.1 Interoperability Domain Model and MANTIS-ARM Domain Model: relations ................................. 68

6.2.2 Interoperability Domain Model for MANTIS-enabled CPS............................................................. 69


6 http://www.mantis-project.eu MANTIS

6.2.3 MANTIS-enabled CPS Engineering Approach .............................................................................. 72

6.2.4 Methodology for creating MANTIS-enabled CPS: applying the PRIME and IMC-Aesop approaches . 74

6.3 Event-based Ontology for Systems Interactions within the MANTIS Service-based Platform .............. 78

6.3.1 MANTIS CPS Event Processing Model ....................................................................................... 78

6.3.2 MANTIS CPS Event Information Model ...................................................................................... 79

6.4 Message Exchange Patterns within the MANTIS Service-based Platform ....................................... 81

6.4.1 Push/Fire-and-forget ................................................................................................................. 81

6.4.2 Request/Response-Reply ............................................................................................................ 82

6.4.3 Publish/Subscribe ...................................................................................................................... 84

6.4.4 Advanced Message Queueing Protocol ........................................................................................ 86

6.4.5 Data-Flow Technologies Supporting Different Message Exchange Patterns .................................... 89

6.4.6 Message Exchange Patterns Model for MANTIS-enabled CPS ...................................................... 92

6.5 Semantic Data Representation and Exchange ............................................................................ 97

6.5.1 Semantic Data Representation and Exchange Model for MANTIS-enabled CPS ............................. 97

6.5.2 Semantic Data Representation for MANTIS using MIMOSA ......................................................... 99

7 Starting with Generic-Proof infrastructure interoperability ..................................................... 107

7.1 Definition of a generic architecture as a proof of concept .......................................................... 108

7.2 Guidance on How to Virtualize Physical Entities into a CPS ...................................................... 112

7.2.1 Technology for Virtualizing Physical Entities: How to Select? ..................................................... 112

7.2.2 Design and Implementation of the Native Communication Library (Connector to Physical Entities)115

7.3 Structuring the System of CPSs: Identification of the Functional blocks, Interfaces and Information flow 127

7.3.1 CPS Functional Blocks ............................................................................................................ 127

7.3.2 CPS Interfaces ........................................................................................................................ 130

7.3.3 CPS Information Flow ............................................................................................................. 130

References ........................................................................................................................... 132

Appendix I ........................................................................................................................... 136



List of abbreviations used

AADL Architecture Analysis and Design Language ABAC Attribute Based Access Control ADA Active Digital Artefact AMQP Advanced Message Queuing Protocol API Application Programming Interface ARM Architecture Reference Model B2B Business-to Business B2C Business-to-Consumer BC Business Case BDC Database Configuration CAD computer-aided design CAN Controller Area Network CBM Condition Based Maintenance CCU Connectivity Control Unit CEF Connecting European Facilities CEN European Committee for Standardization CEP Complex Event Processing CMfg Cloud Manufacturing CoAP Constrained Application Protocol CPE Cyber Physical Entity CPS Cyber Physical System CSV Comma Separated Values DDS Data Distribution Service DSE Domain Specific Enabler DOW Description of Work DPWS Device Profile for Web Services DRM Distributed Reference Monitor EE Extended Enterprise EEBus E-Energy Bus eHGI eHealth Governance Initiative EHRs Electronic Health Records EICTA European ICT Industry Association EIF European Interoperability Framework EnMS Energy Management System EVSM Extended Value Stream Mapping ERP Enterprise Resource Planning ETSI European Telecommunications Standards Institute EU European Union FIPA Foundation for Intelligent Physical Agents FTP File Transfer Protocol GE Generic Enabler GPS Global Positioning System HIE Healthcare Information Exchange HTTP Hypertext Transfer Protocol HW Hardware ICT information and communication technology IDE Integrated Development Environment IIC-RA Industrial Internet Consortium – Reference Architecture IoT Internet-of-Things ISA Interoperability Solutions for European Public Administrations IT Information technology JADE Java Agent Development Framework JPA Java Persistence API KM Knowledge Management KP Knowledge Processor



LCA Life Cycle Assessment M2M Machine-to-Machine MEP Message Exchange Pattern MES Manufacturing Execution System MOM Message Oriented Middleware MQTT Message Queuing Telemetry Transport NGN Next Generation Networks NIST National Institute of Standards and Technology OBU On-board Unit OEM Original Equipment Manufacturer ONC Office of the National Coordinator OPC-UA Open Platform Communications – Unified Architecture OpenADR Open Automated Demand Response OWL Web Ontology Language OSA Open System Architecture OSI Open Systems Interconnection OT Operation Technology P2P Pear-to-Pear PDM Product data management PES Product Extension Services PLC Programmable Logic Controller POJO Plain Old Java Object PSS Product Service System QoS Quality of Service R&D Research and development RBAC Role Based Access Control RDF Resource Description Framework REST Representational State Transfer RTD Research and Technological Development SCADA Supervisory Control and Data Acquisition SDK Software Development Kit SME Small and Medium-sized Enterprise SOA Service Oriented Architecture SOAP Simple Object Access Protocol SPARQL RDF Query Language STS Socio-Technical System SW Software TAM Technology Acceptance Model TCP Transmission Control Protocol UDP User Datagram Protocol US United States USEF Universal Smart Energy Framework UML Unified Modelling Language VCU Vehicle Control Units WP Work package SIB Semantic Information Broker SOC Service oriented Computing



1 About this document

1.1 Role of the Deliverable

The document is the main outcome of the “Task 2.2 – Interoperability and runtime system properties”

that is part of the “Work Package 2 – Service Platform Architecture Development” of the MANTIS

project. The principal aim is to develop specification and guidelines for interface, protocol and functional interoperability while providing instructions on how to perform efficient and effective data and information validation, processing and decision-making throughout the processing chain (from data sources to decision-making functions). Furthermore, the document does not neglect fundamental aspects for semantic data

representation and exchange to assure consistent, safe, secure, and predictive behaviours of the functionalities built in line with the MANTIS ARM.

The document is organized in viewpoints, especially starting from the section 4, where interoperability issues are applied to the MANTIS problem and are considered/analysed at distinct levels, namely:

component, edge and platform level. The document starts with an introduction (section 2) where the core aspects – addressed during the MANTIS project – are presented while spotlighting the interoperability facet. Subsequently (section 3 and 4), the document explores the importance of interoperability in the

context of cyber physical systems applied in distinct domains (the ones relevant for MANTIS) and the MANTIS approach to identify and solve interoperability issues. Finally, this analysis is finalized in section

5 where interoperability guidance and specifications are extracted in order to be part of the overall MANTIS ARM.

This document, D2.10 – Interface, protocol and functional interoperability guidance and specification Final Version, reports the last version of the interoperability specifications and – thus – it aimed to

present a consolidated version of the specification and guidance on how to reach/assure interoperability within the MANTIS platform (already presented in D2.3 and D2.7) together with the whole interoperability framework that has been developed. As a part of this document three white papers are provided that are aimed to show how to use the framework



1.2 Relation to the other MANTIS Tasks

Task 2.2 analyses the service platform architecture and overall design developed in Task 2.1 using – from one side – the use case scenario requirements gathered in Task 1.2 and the platform requirements

gathered in Task 1.3 and – from the other side – the results from other research initiatives – such as IoT-A, Arrowhead, IMC-AESOP, etc. – that dealt with interoperability issues in Internet-of-Things and

complex cyber physical systems. The results of the analysis are directly used to provide guidance and specifications on how to develop interoperable, consistent, safe and secure services in line with the MANTIS ARM. In case needed, this task will influence the work in Task 2.1 to ensure that the architecture and overall design supports these properties. The Figure 1 depicts the approach applied for Task 2.2

execution.

Figure 1 – Approach Applied for Task 2.2

The results of Tasks 1.2, 1.3 and 2.1 are used as input for Task 2.2 i.e. as the foundation for defining and specifying the interoperability guidelines. The output of Task 2.2 will be then used as input for work package 7 (WP7 – Validation of MANTIS solutions in relevant scenarios). The applied approach is not a one-direction one since two main feedback loops are considered: i) the result of Task 2.2 are retrofitted

to Task 2.1 to refine overall MANTIS ARM; and ii) the results of the WP7 are retrofitted to Task 2.2 to refine interoperability specifications and guidance. Finally, the associated activities in Task 2.2 with respect

to the description of work document are presented in Figure 2.



Figure 2 – Associated activities with respect to the description of work document



1.3 Methodology

The overall aim of the MANTIS project is to develop a cyber-physical system (CPS) based proactive maintenance service platform architecture for enabling the creation of collaborative maintenance

ecosystems. The proposed MANTIS platform will provide a practical mean for implementing collaborative maintenance strategies in a CPS-populated system. CPS are such systems that combine physical entities

with computational and communication capabilities. The combination of new emerging technologies and paradigms together with the wider dissemination of information technologies (IT) in modern processes and/or machines and at different domains of application is providing the baseline for the easy deployment of CPS. The main assumption is that the presence of a CPS-populated platform can potentially optimise

and improve current maintenance activities and their related management systems by relying on the huge

amount of data – gathered during CPS operation – that can be combined and analysed to understand the overall behaviour of a process/machine while enabling the implementation of predictive and proactive maintenance strategies (see Figure 3).

Figure 3 – MANTIS overall concept and data processing levels

Therefore, data extraction, transforming, loading and pattern analysis can be clustered in two categories

and/or levels, namely:

Low level (in this document referred as component and edge levels): extraction, transforming, loading and analysis of simple signals to model and understand the behaviour of selected physical resources and assets. At this level the following algorithms, methods and methodologies are

considered: sensor data fusion (feature fusion, decision fusion), eliminating noise and erroneous data; that can include stochastic methods, Kalman filter, fuzzy logic, logical links or rule-based methods. This will also reduce bandwidth requirements.

High level (in this document referred as platform level): extraction, transforming, loading and

analysis of complex data – typically the results of the low level – to model and understand the global behaviour of physical resources and assets. At this level the following algorithms, methods and methodologies are considered: data mining (classification, cluster analysis, associations and regression analyses), intelligent assessment of data; includes recognition of outliers, k-means-

algorithms, machine learning.

It is important to state that both low and high level are part of the overall MANTIS platform and thus analysed and considered in the same way.

Since data sources are typically characterized by distribution and heterogeneity and the processes/machines in which they are inserted by dynamicity, then there is an urgent need to analyse:



1. how data sources within a process/machine can be virtualized by MANTIS-based services and integrated inside the MANTIS platform (Virtualization of devices of a process/machine into CPS);

2. how CPS can connect to the MANTIS platform services (message exchange pattern)

3. which events and messages are relevant within the MANTIS platform (event-based ontology for

supporting systems interactions); 4. how data should be represented to facilitate the data analysis process performed by the MANTIS

platform services (semantic data representation and exchange); 5. How data can be extracted from messages sent by CPS and transformed/translated in the

MANTIS platform semantic representation format (semantic data representation and exchange);

Considering that all these aspects fall under the umbrella of interoperability they will be profoundly investigated and specification and guidelines for interoperability will be provided. In deliverable D2.3 –

Interface Protocol and Functional Interoperability Guidance and Specifications (V1) most of the topics

above have been studied. The current document is an update of the previous deliverable d2.3 – Interface, protocol and functional Interoperability guidance and specifications (V1) and has been thought to provide – from one side – more details and eventually to extend further the models and specifications of d2.3 and – from the other side – to add new guidance and practical advises on how to implement MANTIS-enabled CPS.

Finally, for the development of the document the following approach has been applied: the table of contents has been sent by UNINOVA to all the partners involved in this task in order to receive standard style and format inputs to the document. The involved partners have the responsibility to convey all the results gathered during the execution of Task 1.2, Task 1.3, Task 2.1 as well as the results from the

technical and general meetings in this document with the goal of providing a set of specifications upon which the entire MANTIS interoperability strategy will rely. The document is a joint effort between partners - both research/academic and industrial – and, for this reason, its development is driven by

several teleconferences in order to create a common understanding between the involved partners and discuss “ hot topics” that are critical and potentially can have high impact on future developments of the

MANTIS solution. Finally, the partners are asked to provide their own specific part to UNINOVA (task leader) that is responsible to compile all the inputs and create a unique and coherent document adjusted to the specific task objectives and most important to the overall project objectives. Once the D2.7 is ready, it is planned to be sent to all the partners for further refinement, review and evaluation.



1.4 Document Structure

The current document is structured as follows:

Section 1. About this document: details the document purpose as well as, the approach applied for the

development of the document while underlining the role played by this document with respect to the whole project;

Section 2. Introduction: provides a quick overview to allow the reader to get a grasp of the main concepts expressed in the document;

Section 3. Interoperability: provides an analysis of the current state of the art on interoperability according to different perspectives and point of views (the one that are relevant for the MANTIS project), and

presenting needs and lacks;

Section 4. Interoperability in MANTIS: presents the main approach to interoperability used in MANTIS.

Section 5. Focusing on standards: ISO 13374 and the role of MIMOSA: provides a brief overview on the importance of the standards for achieving interoperability while focusing on the MIMOSA open standards.

Section 6. Interoperability Guidance: provides the main findings of the investigation conducted in Task

2.2. The results of the investigation are gathered in a set of specification and guidelines for enabling the design and implementation of MANTIS interoperable CPS and services.

Section 7. Starting with Generic-Proof infrastructure: describes a generic MANTIS implementation, i.e. detached from any pilot, and focuses on the technology selection process, virtualization of physical entities

(assets), architectural patterns and interfaces from the interoperability point of view.

Annexes: provides several examples of application and approach used to identify the interoperability issues

within the MANTIS use cases.



2 Introduction

CPS are enabling a new generation of “ smart systems” . The augmentation of physical entities with

computational and communication/connectivity capabilities is opening the doors to new and above all

unprecedented opportunities for European Industries, creating new markets and platforms growth. More and more the applications of CPS are becoming critical to the business success of many companies. As a matter of fact as stated in [1]:

“ In transportation, manufacturing, telecommunications, consumer electronics, and health and medical equipment, and intelligent buildings the value share of electronics, computing, communications, sensing, and actuation is

expected to exceed 50% the end of the decade”

However, even if progresses are being made every day supported by continuous technological

advancements, CPS application and deployment continue to be challenged by set of technical, institutional, and societal issues. Focusing the attention on the technical aspects, interoperability represents today one of the most challenging perspectives. The viability of CPS must address the interoperability problem to allow the cooperation and collaboration between large number of components,

i.e. to allow communication across components, sub-systems, systems and integration in the loop of humans and other ICT systems.

In the context of MANTIS, interoperability will enable the creation of MANTIS-enabled CPS that can be easily and smoothly integrated/connected to the MANTIS platform in order to push monitoring data gathered during their operations with the objective of improving maintenance activities.



3 Interoperability

There is no unique definition of interoperability in the literature since the concept has different meanings

depending on the context. As a matter of fact, according to ISO/IEC 2382-01 [2] interoperability is: “ The

capability to communicate, execute program, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units” . According to Next Generation Networks (NGN) from ETSI’ s technical committee TISPAN [3], interoperability is: “ the ability of equipment from different manufacturers (or different systems) to communicate together on the same infrastructure (same system), or on another” . EICTA defines

interoperability as [4]: “ the ability of two or more networks, systems, devices, applications or components

to exchange information between them and to use the information so exchanged” . Although the particular definition interoperability is always about making sure that systems are capable to share data between each other and to understand the exchanged data [5]. In this scenario the word “ understand” includes

the content, the format, as well as, the semantic of the exchanged data [6]. Interoperability ranges over four different levels [7] namely:

i. physical/technical interoperability: concerns with the physical connection of hardware and software platforms;

ii. Syntactical interoperability: concerns with data format, i.e. it relates on how the data are

structured; iii. Semantic interoperability: concerns with the meaningful interaction between systems, devices,

components and/or applications; iv. and Organizational interoperability: concerns with the way organizations share data and

information.

In particular, the first three interoperability levels are considered in MANTIS, and above all the syntactical and semantic interoperability. In fact, nowadays the physical/technical interoperability is almost solved by the wide dissemination of internet technologies. As stated in [8], the combination of new emerging technologies and paradigms such as IoT, Machine-to-machine (M2M), Cloud-computing/manufacturing,

service-oriented architecture (SOA), service-oriented computing (SOC) together with the wider dissemination of information technology (IT) are driving powerful and, above all, new business opportunities for enterprises by facilitating the systems, devices, applications and components integration.

However, if from one side these technologies and approaches are solving the physical/technical

interoperability, from the other side they alone are not capable to handle the high heterogeneity of modern complex processes and/or machines [9], [10]. The interoperability problem is far to be solved and the dissemination and proliferation of new technologies and devices is growing more and more its complexity. By considering manufacturing context and specifically production system and their automation applications as exemplary application scenario (several manufacturing scenarios are also part of the

MANTIS project) it is clear that interoperability is still a critical issue. As a matter of fact, the typical

heterogeneity of devices, equipment and automation software architectures installed in production systems lead to a separation between operation technologies (OT) and the enterprise IT backbone infrastructure. This separation creates an obstacle to a real cross-layer integration by avoiding that the usage of the data

generated within business and vice versa. It means that there is still a lack of supporting methodologies, techniques and approaches and the ones provided by the research community are still scarce applied in real manufacturing companies. In this scenario, the virtualization of the manufacturing resources – in terms of functionalities – by using intelligent middleware (such as agent and web-service based

technologies) and the application of ontologies will enable the creation of an abstraction layer while allowing the transparent data capture and enterprise cross-layer data distribution for triggering the transformation of information into insight [11], [12].



In MANTIS the data comes from distinct type of sources, namely:

Process/machine/device controllers;

Process supervision systems;

Production control systems;

Enterprise Resource Planning systems;

Etc.

Therefore, it is necessary to standardize and homogenize the way data are represented and structured to

cope with the problem of integrating data from multiple vendor-based systems for the sake of knowledge generation and information distribution to all the necessary decision making nodes. Therefore, the

MANTIS interoperability approach relies on the identification of the main typical interoperability problems detected in the considered use scenarios as a necessary condition for building specifications and guidelines

on best practices to achieve interoperability, i.e. to allow the integration of CPS into the MANTIS platform and the usage of the data provided for optimising the maintenance activities.



3.1 Introduction to Interface, Protocol and Functional Interoperability

Nowadays, the conventional systems and processes – in the most disparate context of application e.g. manufacturing, healthcare, automotive, white goods, logistics etc. and different nature e.g. mechanical,

electrical, and chemical – are evolving into CPS. A working definition for CPS has been offered in [13], where a CPS is defined as a systems consisting of computational, communication and control components

combined with physical processes. Therefore, CPS are establishing the foundation for the deployment of a new generation of complex systems. Until now, embedded computing has been focused on improving on-device computational capabilities, on the other hand CPS are focusing more and more on the necessity to have some kind of communication between CPS, i.e. the need of autonomous CPS to dynamically

interoperate in order to achieve a higher goal. Since many applications and systems require a tight

integration between devices, processes, machines, humans and other software applications than the implementation and deployment of CPS in such ecosystems have a tremendous impact due to their intrinsic characteristics. Doubtless, the necessary condition to enable such as evolution is the wide spread of new network protocols (i.e. Industrial Ethernet) to help components/equipment that are part of

processes/machines to communicate their own status, as well as, data related to their operation. However, communication between two systems is more than the particular network protocol to be used. Several, aspects need to be considered whenever a communication channel between two systems needs to be

established. As a matter of fact, the information flow within a system between physical entities (devices)

goes from the information detection from the data extracted from the process (monitoring) to the information processing (control) to the usage of the information at the system. According to the features and intrinsic characteristics of the physical entities several compatibility levels can be used to classify them (see Figure 4).

Figure 4 – Compatibility levels [14]

The definitions of the compatibility levels depicted in Figure 4 are:

1. Incompatibility: inability of two or more devices to work together in the same application 2. Coexistence: ability of two or more devices operate independently of one another in the same

communication network 3. Interconnectability: ability of two or more devices, regardless of manufacturer, to operate with

one another using the same communication protocols, communication interface. 4. Interworkability: ability of two or more devices to support transfer of device parameters



5. Interoperability: ability of two or more devices to work together in one or more applications 6. Interchangeability: ability of two or more devices to replace each other in working together in one

or more application

The degrees of compatibility strictly depend on the physical entity/device feature. In such a case, physical

entity/device feature can be classified into:

1. Communication feature/part 2. Application feature/part

The provided in [14] describes the physical entity/device communication and application features.



Table 1 – Device Application and Communication Features adapted from [14]

Feature Description Interoperability Level

Device Communication part

Communication Protocol This feature consists of all protocols of layer 1 to 7 of the OSI reference model, i.e. from the physical medium access to the application layer protocol.

Physical Communication Interface

This feature consists of the communication service definition of application layer including the services and the service parameters. Additional mapping mechanisms can be necessary. The dynamic performance of the communication system is part of this feature.

Data Access This feature consists of the object operation definition or the access parameter attributes of the block data input, data output and parameters

Syntactic

Device Application Part

Data Types The data type of the object attributes or block data input, data output or parameter defines this feature.

Data Semantics This feature consists of the characteristic features (parameter attributes) of the application data this can be data name, data descriptions, the data range, Substitute value of the data, default value, persistence of the data after power loss and deployment.

Semantic

Application Functionality This feature consists of specifying the dependencies and consistency rules within the Functional Elements. This is done in the data description part or in a separate behaviour section.

Organizational

Functional Dynamic Behaviour This feature consists of time constraints that influence the data or the general device behaviour. For example the update rate of a process value can influence block algorithms.

Thus, in the context of this document and taking into account the CPS domain, the interoperability compatibility level is the focus. Of particular importance in the case of CPS are:

Integration of computational infrastructures i.e. the integration between the cyber parts of two or

more CPS as well as cyber part of a CPS with other applications. To enable a smooth interaction between CPS, the following aspects needs to be handled:

o Interface interoperability

o Protocol interoperability;



o and functional interoperability (it implicitly includes the syntactic and semantic interoperability as a necessary condition to reach functional interoperability).

Integration of computational infrastructure with physical devices, components and the environment (virtualization).

3.1.1 Basic Definitions

3.1.1.1 Interface interoperability

An interface defines the atomic point of interconnection between two or more systems. Interfaces are

enablers for cooperation and collaboration between entities as well as for data provisioning. The interface of a system represents its signature in the sense that it defines all the characteristics of a system that are

relevant to enable other systems to communicate with. In the context of MANTIS the adoption of standardized interfaces will facilitate the overall flow of data while empowering optimized performance,

diagnostics, and prognostics for improving maintenance activities.

3.1.1.2 Protocol interoperability

The wide dissemination and proliferation of internet solutions in the most disparate application scenarios – spacing from manufacturing to smart grids passing through health care and automotive – are naturally

selecting internet technologies and thus internet-based communication protocols as the de-facto standard

to enable interoperability. A protocol can be defined as a set of rules and conventions that have been formulated with the objective of controlling the exchange of data between two entities/systems that are willing to connect together [15]. Therefore, protocols are necessary for controlling and guarantying the exchange of data between devices and the network. In this scenario, the continuity of TCP/IP, HTTP,

FTP, and other universally accepted internet communications standards across Ethernet-based networks to intranets and the internet is fundamental [16].

3.1.1.3 Functional interoperability

As stated in [17], [18], functional interoperability can be defined as the ability to deploy new functional components on the same architecture instance and to guarantee that these integrations are capable to

work with the other functional components in order to fulfil the required process. Therefore, it relates to the exchange of messages and in particular to the structural definition of the messages to be exchanged during the architecture/platform runtime and thus requires to take into account syntactic and semantic

interoperability issues.



3.2 Exemplary Application Context

3.2.1 Interoperability in Production Asset Maintenance

3.2.1.1 Basic Definitions

Manufacturing companies are typically structured, defined and characterized according to the ISA-95 standard where manufacturing companies are organized into a five level hierarchical model also known as “ automation pyramid” (see Figure 5).

Figure 5 – Manufacturing company functional hierarchical decomposition according to the ISA-95 standard

Focusing the attention on the software infrastructure, the organization presented in [19] can be adopted where three vertical layers are considered, namely: business/management layer, intermediate layer and

manufacturing layer (see Figure 6). The business/management layer of an enterprise contains software

functionality related with accounting, human resources, administration, marketing and monitor markets demands. The intermediate layer is responsible for receiving production orders coming from the business layer, processing it and generate command for the manufacturing layer. Furthermore, it gathers data information about the status of the manufacturing layer, i.e. status of the manufacturing assembly line and current production behaviour/context. The manufacturing layer handles the manufacturing production

process. Modern shop floors are characterized by a high degree of diversity in device functionality, form

factor, communication protocols, input/output features, as well as the presence of many heterogeneous and often proprietary software and hardware components as focused in [20]. The ICT infrastructure of a manufacturing enterprise is highly heterogeneous and distributed, ranging from the business layer with

standardized Enterprise Resource Planning (ERP) solutions, to the manufacturing layer with standardized vendor-specific automation solutions passing through the intermediate layer where the Manufacturing Execution System (MES) used depends on the equipment installed in the manufacturing layer. In this



context, interoperability plays a fundamental role to enable and guarantee the communication inside each layer as well as the between the layers.

Figure 6 – Typical manufacturing company software infrastructure organisation [21]

3.2.1.2 Forms of Interoperability

Interoperability plays a fundamental role in the context of manufacturing production systems. In such a context, the communication between different components such as devices, sensors, production machinery,

monitoring and ERP systems requires a certain degree of interoperability to allow the data exchange and data understanding. During the operation of a production system communication takes place constantly both horizontally and vertically. Horizontal communication takes place between devices/resources/components at field/sensor level of the ISA-95 automation pyramid (e.g., Machine to Machine (M2M) communication). Vertical communication takes place between the software

resources/components installed and deployed at the distinct levels of the ISA-95 automation pyramid starting from the field/sensor level and moving up to the enterprise level. The classical heterogeneity that

characterize manufacturing companies contributes to the exponential growth of interface specifications and communication protocols as also confirmed in [9]. As stated in [8], the combination of new emerging

technologies and paradigms such as IoT, Machine-to-machine (M2M), Cloud-computing/manufacturing, service-oriented architecture (SOA), service-oriented computing (SOC) together with the wider dissemination of information technology (IT) are driving powerful and, above all, new business opportunities for manufacturing enterprises by enabling systems, devices, applications and components integration. However, if from one side these technologies and approaches are solving the physical/technical

interoperability, from the other side they alone are not capable to handle the high heterogeneity of modern manufacturing production systems. For this reason, setting up such systems requires careful planning and the usage of supporting methodologies to ensure communication and – above all – data interoperability. Setting up the systems is not the end, due to the complexity and dynamicity of modern production systems

where components are replaced and added in a regular basis. Meaning that interoperability in a manufacturing company requires a well-defined strategy that comprises – from one side – physical communication links concerns and – from the other side – models, specifications and guidelines that are



detached from the specific technology and/or physical communication link between resources and components. As a matter of fact, production also involves exchange of information with various (internal and external) partners, vendors, systems, and representation of different kinds for information that is used

for production processes. It means that data interoperability is a necessary condition for assuring fully

interoperation between devices/resources and/or components in a manufacturing company. The information flow, in a manufacturing company, has two main directions: horizontal and vertical. However, the communication model is typically different regarding to the direction of the information flow:

Horizontally: a peer-to-peer (P2P) communication is established between devices, resources or

more in general components at the field/sensor level;

And vertically: a client-server communication is established between the distinct levels of the ISA-

95 automation pyramid, i.e. communication between business and production processes (integration between main information technology and operation technology infrastructures).

Finally, another area worth mentioning in regards to interoperability is the functional interoperability between software components and their service interfaces as well explained in [6]. In a manufacturing production system field devices/resources/components and their software are cooperating and/or

interacting with other field devices/resources/components by using information and communication technologies (ICT). However, since the production system is a highly dynamic and evolvable environment

then it is probable that new components need to be added, other to be replaced/removed with a huge impact on the production process because of the time need to perform the change (reengineering process

[22]). The delays or decreased production rate could mean substantial costs and is therefore usually avoided as much as possible. In this scenario, the abstraction of field devices/resources/components in terms of their functionalities could potentially improve the reengineering process by facilitating the overall integration process where field devices/resources/components and more in general software resources/components at all the levels of the automation pyramid could be added and replaced only by

taking into account the functionalities that they brought to the system.

3.2.1.3 Relevant Technologies

3.2.1.3.1 OPC-UA

The OPC UA (Unified Architecture) is the new version of the vastly deployed OPC architecture originally designed by the OPC Foundation to connect industrial devices to control and supervision applications as

explained by [23], [24]. Taking into account the application context, the focus of OPC is on getting access

to large amounts of real-time data while ensuring performance constraints without disrupting the normal operation of the devices. The original OPC specifications were based on Microsoft COM/DCOM meaning that they are becoming obsolete and are rapidly being replaced by the newer standards on interoperability (e.g. Web services). Thus, the main visible transformation when looking at OPC and its newer architecture

OPC-UA is the shift to a cross-platform capable web services [10]. This shift is not the only transformation, since OPC-UA also includes support for secure communication, unification of several OPC data models

as a single set of services and the extension to other domains such as manufacturing (shop-floor), production, maintenance, and business application in order to implement the total integrated manufacturing while enabling a true cross-layer integration (see Figure 7).



Figure 7 – OPC-UA Network environment [24]

From a technological point of view, OPC-UA can be mapped using widespread Web standards, including

XML, WSDL, SOAP and other WS-* specifications, along with other OPC UA defined specifications for UA native communications. Moreover, the criticality of the industrial process imposes security as a fundamental requirement. In this, scenario OPC-UA provides configurable security mechanisms to allow security to not impact too much on the system performance. In order to facilitate and spread as much as possible the usage of OPC-UA technology and strategy/approach the OPC-UA community is collaborating

with major industry standards organizations as well as to the possibility to move the information models provided by these organizations to the end user community. Finally, OPC UA thus provides a homogeneous and generic meta-model and defines a set of web services interfaces to represent and access both structure information and state information in a wide range of devices.

3.2.1.3.2 DPWS

The Device Profile for Web Services (DPWS) has been designed and developed to introduce web services

protocols for device networking [10]. It is currently supported standard by the OASIS Web Services Discovery and Web Services Devices Profile Technical Committee, since June 2009. DPWS is a stack of web-based protocols and profile for devices, which defines two fundamental elements: the device and its hosted services.

Devices play an important part in the discovery and metadata exchange protocols, while its hosted services provide the functional behaviour of the device and depend on their host for discovery.

Besides hosted services possible to be developed by the end-user, DPWS also specifies a set of infrastructure services:

Discovery services (WS-Discovery): used by a device connected to a network to advertise itself

and to discover other devices [OASIS, 2009b]. WS-Discovery uses User Datagram Protocol (UDP) and a multicast address to broadcast and listen to the discovery messages.



Metadata exchange services (WS-MetadataExchange): provide dynamic access to devices hosted services and to their metadata, such as WSDL or XML Schema definitions.

Event publish/subscribe services (WS-Eventing): allow other devices to subscribe to asynchronous messages (events) produced by a given vendor-defined service.

DPWS is built on top of the SOAP 1.2 standard, and relies on additional WS specifications, such as WS-Addressing and WS-Policy, to further constrain the SOAP messaging model. At the highest level, the

messages correspond to vendor-specific actions and events. Messages are delivered using HTTP, Transmission Control Protocol (TCP) and UDP transport protocols. More details about DPWS can be found in [10].

Even if there are no or very few applications that are running by using the DPWS framework/middleware

in the industrial context, it is deeply used with indubitable success in the scientific context as confirmed in several European research projects such as: IMC-AESOP, SOCRADES, SIRENA. In all these initiatives the DPWS technology has been used to enable manufacturing enterprise cross-layer integration while improving the overall enterprise visibility (see Figure 8).

Figure 8 – DPWS peer-to-peer network environment [25]

3.2.2 Interoperability in Vehicle Maintenance Management


Applying the terms and definitions of interoperability from section 3.1 there are three main devices for which interoperability is relevant: vehicle control units (VCU), connectivity control unit (CCU) and the original equipment manufacturer (OEM) or service provider for IT infrastructure in the backend. The

interaction between these devices is illustrated in Figure 8.



Figure 9 – Interaction between VCU, CCU and OEM service provider backend IT

As an example for physical/technical interoperability each VCU is connected with a CCU or a gateway via E/E architecture layout. Relevant signals will be identified and defined for each individual use-case. Afterwards those signals will be provided via bus system and can be pre-processed in an OBU. The OBU

facilitates signal sequencing, signal aggregation and signal buffering. Aggregated signals are provided to the IT infrastructure of a maintenance solution provider where algorithms with different processing depth

enable a state based system or component condition predication.

Regarding syntactical interoperability the data format within vehicle internal communication is well defined and standardized. This is not valid for the way how information is gathered and pre-processed within CCU

and the way of interoperability between CCU and IT infrastructure. There is a lack of semantic and organizational interoperability regarding information exchange on software status of CCU or pre-evaluation algorithms. For an update compatibility after start of vehicle production the apps in CCU and backend algorithms must be consistent for each individual vehicle.

The physical/technical and syntactical interoperability refers to vehicle internal physical connection and information exchange between different VCUs and between VCUs and CCU. The exchange of information within vehicle is realised over different vehicle bus protocols like CAN (ISO 11898) including CAN-FD, SAE J1939, Flexray (ISO 17458), CCP/XCP (ASAM MCD-1 XCP) and future vehicle internal bus protocols e.g. based on TCP/IP.

The architectural connection layout differs between each vehicle manufacturer. The functionality of the

CCU can be realized as single separate physical node on a CAN branch or integrated in a vehicle network gateway. While VCUs communicate in a consistent, predictable and reliable way as vehicle internal communication is standardized one reason for complexity is the vast number on VCUs and different

architectural layouts for the E/E vehicle architecture.

The communication between VCUs and CCU depends on CCU vendor hardware and software interfaces. In most cases information exchange is realized with proprietary closed source software and there is no

interchangeable interoperability given. Among device and software vendors acting as OEM supplier there is a huge number of retrofit vendors which supply independent fleet operators especially in off-road

agriculture, mining or construction business segment.

A common platform for data exchange with open interfaces for interchangeable interoperability reduces complexity and supports provision of maintenance modules from different suppliers.

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=59804




Interoperability is addressed by vehicle manufacturers, device vendors, IT service providers as well as

vehicle component and system suppliers. For this the forms of interoperability as requirements for a MANTIS service based platform are defined in the following. These requirements include terms and

conditions relevant for the interoperability regarding the architectural pattern of the MANTIS system and others that are related to the way of the interoperability regarding user interaction with the platform.

A MANTIS platform shall allow to:

create/model user defined algorithms for processing vehicle data on CCU based on input from vehicle bus, on board diagnosis and VCU signals (Vehicle Use Cases)

This includes to

o develop/model flexible vehicle use cases

o use of different tools for the development/modeling of vehicle use cases

o read out internal signals from ECU from vehicles after start of production

deploy vehicle use cases on CCU

This includes to

o deploy one or more existing vehicle use cases onto one or more OBUs.

o cancel one or more not finished deployment processes

o getting back an overview of all currently running deployment processes

o getting back an overview of closed/cancelled/aborted deployment processes

o get a message back, if started deployment processes are aborted

execute vehicle use cases on CCU and send their results to server backend This includes to

o perform all active vehicle use cases on one OBU in parallel

o have ensured, that all vehicle use cases prepared by OBU are protected, safe, complete

and will be transferred to IT-backend in a quick manner

o have ensured, that with a bad/not suitable/not existing connection to backend the execution of active vehicle use cases on an OBU will not be disturbed or halted. Instead

of disturbing/halting results of vehicle use cases shall be buffered until transfer to backend.

o have a mechanism on OBU for supervision and transfer of use-case execution (CPU-load,

memory load, process status)

o configure the supervision mechanism over backend in order to start the „ right” reactions for the problem solving of a „ problem-” vehicle use cases

store data provided by vehicle use cases on server backend (CCU Data)

This includes to

o store data IT backend which was pre-calculated and prepared by CCU and sent to IT

backend

o understand and reproduce with which configuration (vehicle, CCU, vehicle use case / version) the data on OBU was originated

create/model user defined algorithms for processing CCU data on server backend (Backend Use Cases)

This includes to

o develop flexible backend use cases, by use of standard data mining tools capable of PMML (e.g. for data mining tools)

o define, which data of which version of vehicle use cases shall be used when a backend use

case is executed

o define, when / how often / at which trigger a backend use case shall be executed

o define, which actions depending on the result of a backend use-case shall be triggered. The following actions are feasible: E-Mail, Report, SMS, RSS-Feed etc.

execute backend use cases for incoming CCU data in a production environment



This includes to

o deploy one or more existing backend use cases onto an IT backend

o ensure that every backend use case explicitly shall be provided with the „ right“ data input from CCU

o ensure that all active backend use cases are executed simultaneously onto an IT backend

search for CCU data and export it via different interfaces (e.g. REST, SOAP, UI) This includes to

o search for OBU data over a web service interface and export the results, in order to enable a link of 3rd party-systems

o search for CCU data within a GUI and export the results in order to evaluate them in a

standard analytic toolbox

o export CCU data over an automated interface for ASAM ODS Server

search for results of backend use cases and export them via different interfaces (e.g. REST, Web Services, UI)

This includes to

o kick off the execution of backend use cases via a web service interface and a GUI

o search and export the results of backend use cases via a web service interface in order to

link 3rd party-systems

o Search and export the results of backend use cases within a GUI in order to evaluate them

in standard-analytic tools

manage the existing vehicle use cases This includes to

o change the content of still not deployed vehicle use cases

o change the content of already deployed vehicle use cases

o get an overview of all installed vehicle use cases on one single CCU

o deactivate one or more active vehicle use cases onto one single CCU

o activate one or more inactive vehicle use case onto the CCU

o remove/uninstall one or more vehicle use cases from the CCU

o define the maturity status of vehicle use cases

o reproduce, who, when carried out which changes at a vehicle use case

o reproduce, who, when changed the status of a vehicle use case

o reproduce, who, when deployed/deactivated/activated/deinstalled which vehicle use cases on which OBU

o Ensure that all changes at a vehicle use case have a versioning

manage the existing backend use cases This includes to

o change the content of still not deployed backend use cases

o change the content of already deployed backend use cases

o get an overview of all installed backend use cases on IT backend

o deactivate one or more active vehicle use cases onto IT backend

o activate one or more inactive vehicle use case onto the IT backend

o remove/deinstall one or more vehicle use cases from IT backend

o define the maturity status of backend use cases

Example: „ released“ – vehicle use case is released for production use, „ deprecated“ -

vehicle use case shall not longer be deployed onto OBU; „ unstable“ - vehicle use case is still within a development phase; etc.

o reproduce, who, when carried out which changes at a backend use case

o reproduce, who, when changed the status of a backend use case

o reproduce, who, when deployed/deactivated/activated/deinstalled which backend use

cases on backend it



o Ensure that all changes at a backend use case have a versioning

manage the existing vehicles and CCUs

This includes to

o administrate OBUs. The following actions are feasible: apply, change of master data,

deactivate, ping, assignment to vehicle

o administrate vehicles. The following actions are feasible: apply, change of master data, deactivate

o retrieve the following outline list:

all active/inactive vehicles

all active/inactive OBUs within a vehicle

all active/inactive vehicle use case within a vehicle

o remote flash new CCU-software onto a CCU

o get access to above named functionalities via a GUI

o get access to above named functionalities via a web service interface, in order to link 3rd

party systems

The Connectivity Infrastructure shall assure that:

each user is able to execute only actions it is authorized for

This includes to

o administer vehicle use cases only, if one has the appropriate access rights

o administer backend use cases only, if one has the appropriate access rights

o see only those CCU data and results from backend use cases, for which one has the

appropriate access rights

a separation between sequence and data on OBU exists, i.e. that sequences and data on OBU and backend can be changed autonomously

This includes to

o change only vehicle use cases and maintain application data (separation of software and application data)

o maintain vehicle use cases and change only application data

o change vehicle use cases and change application data simultaneously

3.2.3 Interoperability in Energy Production Asset Management


As pointed in [26]: “ energy generation companies must deliver reliable and cost-effective electricity to meet growing consumer demands while managing the substantial capital and operating investments in their plants and equipment. Profitable operations fundamentally depend on optimized efficiency of electricity production and reduced maintenance and fuel expenses” .

In this scenario, energy asset performance management can provide a comprehensive and unified view of equipment, plant and fleet performance, considering asset health, operational efficiency, energy usage, emissions and maintenance.

Large ICT solution providers such as IBM propose solutions where asset performance management

functions are mapped to business processes (see Figure 10).



Figure 10 – Asset Performance Management functions mapped to business processes [26]

Most energy standards found in the literature address energy efficiency and renewable energy. The objective of those standards is the reduction of energy consumption and the dependency on fossil fuels. ISO International Standards aim to solve the energy challenge by increasing energy efficiency and promoting the development of renewable energy technologies. The standards range from the energy

management system standard ISO 50001 that can be used by any organization in any sector, to standards specific to certain sectors, such as building or transportation.

ISO 5000:20111 supports organizations in all sectors to use energy more efficiently, through the development of an energy management system (EnMS) and provides a framework of requirements for organizations to:

Develop a policy for more efficient use of energy

Fix targets and objectives to meet the policy

Use data to better understand and make decisions about energy use

Measure the results

Review how well the policy works, and

Continually improve energy management.

ISO 50001 also guides organizations on taking a systematic approach in order to achieve continual improvement in energy management and energy performance. Energy management will be sustainable and most effective when it is integrated with an organization's overall business processes (e.g. operations,

finance, quality, maintenance, human resources, procurement, health and safety and environmental). ISO 50001 can be integrated with other management system standards. Integration can have a positive effect

on business culture, business practice, embedding energy management into daily practice, operational efficiency and the operating cost of the management system.

Out of the different standards hierarchically dependant on ISO 50001 two are the standards that could have a relation with equipment and its maintenance since they have a relation with EnMS. Understanding

an EnMS as a system of computer-aided tools used by operators of electric utility grids to monitor, control,

1 http://www.iso.org/iso/home/standards/management-standards/iso50001.htm

http://www.iso.org/iso/home/standards/management-standards/iso50001.htm



and optimize the performance of the generation and/or transmission system. These monitor and control functions are known as SCADA. The standards related to EMS are:

ISO 50003:20142: specifies requirements for competence, consistency and impartiality in the auditing and

certification of EnMS for bodies providing these services. In order to ensure the effectiveness of EnMS

auditing, ISO 50003:2014 addresses the auditing process, competence requirements for personnel involved in the certification process for energy management systems, the duration of audits and multi-site sampling.

ISO 50004:20143 provides practical guidance and examples for establishing, implementing, maintaining and improving an EnMS in accordance with the systematic approach of ISO 50001. The guidance in ISO

50004:2014 is applicable to any organization, regardless of its size, type, location or level of maturity.


Interoperability between energy entities is addressed by several initiatives. In most cases the focus is again on energy efficiency and more specifically on energy demand response flexibility and market trade between energy stakeholders. The main initiatives where interoperability is addressed are:

USEF4: The Universal Smart Energy Framework (USEF) is an international common standard that ensures smart energy technologies and projects are connectable at lowest cost. Its component parts enable the

commoditisation and market trading of flexible energy use and specify all stakeholder roles (new and existing), how they interact and how they can benefit by doing so. USEF describes the market for

flexibility, offering the Framework description, with specifications, designs and implementation guidelines. USEF, currently, solely focusses on market mechanisms to valorise flexibility. Maintenance of equipment is seen as part of the internal business processes and not as a subject for interoperability between organizations. However, USEF has a view on how to use flexibility to positively influence the equipment for an energy Distribution System Operator (DSO). This is part of capacity management and will be

worked out later this year.

OpenADR5: Open Automated Demand Response (OpenADR) is an open and standardized way for electricity providers and system operators to communicate DR signals with each other and with their customers using a common language over any existing IP-based communications network, such as the

Internet. As the most comprehensive standard for Automated Demand Response, OpenADR has achieved widespread support throughout the industry. The OpenADR Alliance was formed by industry stakeholders to foster the development, adoption and compliance of the Open Automated Demand Response

(OpenADR) Smart Grid standard utilizing existing standards from OASIS, UCA and NAESB.

Contacting directly the OpenADR alliance team it was discovered that maintenance data is outside of the

scope of the standard.

EEBus6: The EEBus initiative is one of the world's leading initiatives in the area of the Internet of things with a consistent focus on cross-domain standardization. EEBus has its roots in the sector of smart and renewable energy. The success of smart energy and smart home / building systems largely depends on

the system’ s interoperability. Interoperability has to be understood here in terms of an identical understanding of messages and data that are exchanged between the respective markets and devices. The distinction between exchanged data of an energy management function or a comfort function becomes secondary, as the limitations of both scenarios are merging.

2 http://www.iso.org/iso/catalogue_detail?csnumber=60089

3 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=60041

4 http://www.usef.energy/

5 https://openadr.memberclicks.net/

6 https://www.eebus.org/ueber-uns/



The approach followed by EEBus could be a valid starting point to provide interoperability for Energy Production Asset Management. EEBus defines bridges between the varying domains in specific use cases. By using common and technology neutral data models (aka. neutral messages) these bridges are built.

The neutral data models are in a XSD notation, which is a core element of the EEBus specification. With

this a connectivity concept becomes possible, that works cross-domain.

Figure 11 – EEBus Cross-Domain Interoperability [27]

EEBus connectivity concept connects differing standards and proprietary systems to an overall system, translating neutral messages in varying existing technologies.

The neutral messages are designed right from the beginning to run on various IP based systems as well

as on simple narrow band networks. Hence any technology can transfer information in an interoperable way from system A to system B by using neutral messages.

Figure 12 – EEBus neutral messages mapping [28]

For the mapping/transcription between technologies, information from system A has to be decrypted and after mapping/ transcription encrypted again according to system B. The EEBus Initiative develops

security concepts that are necessary for this process. This allows secure cross technology communication without interference in the existing standard technologies that may be used in a specific communication scenario.

The layer architecture for EEBus relies over standard protocols such IP.



Figure 13 – EEBus architecture [29]

3.2.4 Interoperability in Health Equipment Maintenance


According to WestHealth Institute [30], medical device interoperability refers to information sharing from one device to another or between devices and Electronic Health Records (EHRs). Functional

interoperability would enable clinical medical devices to communicate in a consistent, predictable and

reliable way. By allowing for the exchange of data with other medical devices and with patient data sources and repositories, such as EHRs, medical device interoperability would enhance the function of the systems and devices. Exchange of data between EHRs is commonly designated as Healthcare Information

Exchange (HIE) and has been analyzed in great detail elsewhere.2 The reliable and seamless transfer of information through medical device interoperability can facilitate a number of improvements in efficiency and safety that can be quantified in billions of dollars of savings to the health care system, yet, despite these significant benefits, medical device interoperability is limited today.

According to a recent report by HIMSS Analytics [31], while over 90 percent of the hospitals surveyed by

HIMSS use six or more types of devices that could be integrated with EHRs (such as defibrillators, electrocardiographs, vital sig ns monitors, ventilators and infusion pumps) only a third of hospitals actually integrate medical devices with EHRs today. Additionally, those that are investing in interoperability integrate fewer than three types of devices on average.

Part of the reason for limited interoperability is the high cost and complexity of medical device integration,

which results from the lack of incentives for medical device and HIT companies to use open interfaces to establish interchangeable interoperability. There is a wide range of methods used by device vendors today. Some vendors use distinct proprietary and closed communication methods even among their own devices. Additionally, some standards are loosely specified, with a number of options for configuration, meaning

that even devices that use similar standards may not be able to communicate without further customization. As a result, facilitating the exchange of data between and among medical devices and EHRs currently requires hospitals to invest significant resources in developing custom interfaces and paying

for middleware solutions.

Among the areas of resources waste in the Health system due to the lack of interoperability it is worth mentioning that WestHealth identifies “ 9. Limited ability for operational maintenance and optimization of utilization/inventory management” (see Figure 14).



Figure 14 – Areas of resource waste in Health systems due to the lack of interoperability


In both European Union (EU) and United States (US) countries cyber-physical systems play a fundamental role in health sector. The wider dissemination of cyber-physical systems is rising several interoperability

problems i.e. how these systems could use and exchange health data. As explained in [32], in the US, the Office of the National Coordinator (ONC) for Health IT is responsible for advancing connectivity and interoperability of health information technology (health IT). ONC follows the IEEE definition of interoperability as the ability of systems to exchange and use electronic health information from other

systems without special effort on the part of the user. Health IT interoperability is a key element in helping

transform the health care delivery system into one that provides better care, smarter spending and healthier people. ONC's overarching goal for electronic health information exchange is for information to follow a patient where and when it is needed, across organizational, health IT developer and geographic boundaries.HealthIT.gov includes the use of electronic health records (EHRs) instead of paper medical

records to maintain people's health information.

To lay the fundamental building blocks of interoperability and standardize they have several initiatives underway [33]:

• Meaning through the use of standardized healthcare vocabularies,

• Structure by leveraging standards in HL7,

• Transport using secure email protocols,

• Security through National Institute of Standards and Technology (NIST)-adopted encryption standards, and

• Services through open and accessible application programming interface (APIs).

The European Commission eHealth Action Plan [34] aims at making use of Information and Communication Technologies (ICT) to improve healthcare in Europe. The Action Plan focuses on developing common standards to enhance interoperable healthcare systems among member states. The European Commission has already put in place several activities to improve EU interoperability &

standardisation. The activities (policies, projects and studies) can be found here [35].

https://ec.europa.eu/digital-single-market/news-redirect/11615

https://ec.europa.eu/digital-single-market/news-redirect/11615



Among those activities during the period 2013-2020, the Commission will launch a number of policies:

• The Recommendation on cross-border interoperability of Electronic Health Record systems provides a set of guidelines for the implementation of interoperable Electronic Health Records

capable of exchanging patient data securely across Europe.

• The Council Conclusions on safe and efficient healthcare through eHealth call upon the Member States to ensure that interoperability of eHealth services across organisational and national boundaries is taken into account in their health strategies and investment plans.

• The eHealth Governance Initiative (eHGI) was set up as a High Level working group comprising of representatives from the Member States. Its main task is to drive forward eHealth in Europe fostering the "deployment and actual use of interoperable eHealth services within and between

national healthcare systems".

• The EU-US Memorandum of Understanding on eHealth stresses the need for a joint vision on internationally recognised interoperability standards, and foresees active cooperation and information exchange for the development of solutions enabling secured exchange of clinical information.

• The European Commission's Communication on interoperability for public services introduces the European Interoperability Framework (EIF), which promotes and supports the delivery of European

public services by fostering cross-border and cross-sector interoperability. The EIF is implemented through the Interoperability Solutions for European Public Administrations (ISA) programme.

• The Directive on patients' rights in cross-border healthcare lays down measures to support Member States in developing common identification and 2 authentication measures intended to facilitate transferability of data in cross-border care settings.

• The Proposal for the Regulation on European Standardisation aims to promote wider recognition

of ICT standards developed by global industry consortia, improve participation from SMEs and increase EU standards for services.

• The Commission is executing the Connecting Europe Facility (CEF): a EUR 50 billion funding plan for the deployment of digital services to achieve a digital single market (the Europe 2020 strategy http://ec.europa.eu/europe2020/index_en.htm). A portion of the funding will be targeted

towards cross-border interoperability infrastructure development and related running costs in different public service delivery areas, including eHealth. It includes for example guidelines to

determine trans-European telecommunication networks (broadband, digital service infrastructures).

• The eHealth Governance Initiative (eHGI) is led by the EU Member States to provide input on

legal, ethical and regulatory issues crucial to eHealth implementation. Also semantics and terminology, identification and authentication standardisation that are vital to successful information exchanges are being addressed.

• eHGI is being supported by the EU funded SEHGovIA project, a communication and dissemination

platform.

• CEN Technical Committee 251 is a working group focusing on eHealth standardization within the

EU. The goal is to achieve compatibility and interoperability between independent systems and to enable modularity in EHRs.

• ISA Programme 2010-2015: Citizens and businesses expect efficient public services across Europe. ISA – the Interoperability Solutions for European Public Administrations programme – addresses this need by facilitating efficient and effective cross-border electronic collaboration between

European public administrations.

Additionally, many interoperability projects proposed by the EC focus on clinical research by making Electronic Health Records (EHRs) and other clinical data interoperable



The standards (HL77 o CEN8) provide interoperability for clinical data (EHR or similar) but so far no interoperability mechanisms for Health equipment maintenance have been identified in the literature. This opens the door for research in the field.

Looking into more detail the European Standards provided by CEN 251 there are some standards that

could have a relation with the equipment maintenance since they refer to architecture, enterprise, messages, security or other general purpose components. Some of these standards – extracted from [36] – are outlined next:

CEN/TS14822-4:20059 (WI=00251169) Health informatics - General purpose information components - Part 4: Message headers

CR1350:199310 (WI=00251029) Investigation of syntaxes for existing interchange formats to be used in health care

ENISO12967-1:2011 11(WI=00251250) Health informatics - Service architecture - Part 1: Enterprise viewpoint (ISO 12967-

1:2009)

ENISO12967-2:201112 (WI=00251251) Health informatics - Service architecture - Part 2: Information viewpoint (ISO 12967-

2:2009)

ENISO12967-3:201113 (WI=00251252) Health informatics - Service architecture - Part 3: Computational viewpoint (ISO 12967-

3:2009)

ENISO21090:201114 (WI=00251221) Health Informatics - Harmonized data types for information interchange (ISO 21090:2011)

ENISO27799:200815 (WI=00251184) Health informatics - Information security management in health using ISO/IEC 27002 (ISO

27799:2008)

ENV12443:199916 (WI=00251053) Medical Informatics - Healthcare Information Framework (HIF)

ENV13609-2:200017 (WI=00251128) Health informatics - Messages for maintenance of supporting information in healthcare

systems - Part 2: Updating of medical laboratory-specific information

EN15224:201218 (WI=00362003) Health care services - Quality management systems - Requirements based on EN ISO 9001:2008

7 http://www.hl7.org/

8 https://standards.cen.eu/index.html

9https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:22069,6232&cs=1891C78E31436702F611DF124A309B9FF

10https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:12534,6232&cs=184FBD4CF630BCEF84DF8383584661AE6

11https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:35360,6232&cs=1774084F66D493109D4C4CF6A1AF07B9F

12https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:32451,6232&cs=1F3A63AFCAC951F43AD0D3E862EA4DB59

13https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:35362,6232&cs=17D253747A7253456005F517862C88BBD

14https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:29048,6232&cs=158B35158A21C7D387AC149CC93511236

15https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:24637,6232&cs=1E3F2A0275ED1947CC9AEBE01EF20A48D

16https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:12558,6232&cs=1AC4CE7D749F12EC5B333C192A8B4EC7D

17https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:12633,6232&cs=1C2F56A69BA539DF75B33D66AA37FC976

18https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:34736,622707&cs=1C9C7FAAC1E3E87D55B9C29F85F4CFC10

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:22069,6232&cs=1891C78E31436702F611DF124A309B9FF

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:12534,6232&cs=184FBD4CF630BCEF84DF8383584661AE6

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:35360,6232&cs=1774084F66D493109D4C4CF6A1AF07B9F

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:35361,6232&cs=183EDD57CEE6D5A2F412851D758A05CA7

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:35362,6232&cs=17D253747A7253456005F517862C88BBD

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:29048,6232&cs=158B35158A21C7D387AC149CC93511236

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:24637,6232&cs=1E3F2A0275ED1947CC9AEBE01EF20A48D

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:12558,6232&cs=1AC4CE7D749F12EC5B333C192A8B4EC7D

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:12633,6232&cs=1C2F56A69BA539DF75B33D66AA37FC976

https://standards.cen.eu/dyn/www/f?p=204:110:0::::FSP_PROJECT,FSP_ORG_ID:34736,622707&cs=1C9C7FAAC1E3E87D55B9C29F85F4CFC10



State-of-the-Art Relevant Approaches

3.2.5 Arrowhead19

STUDY ARROWHEAD

DESCRIPTION The Arrowhead project is aimed to provide an intelligent middleware that can be used to allow the virtualization of physical machines into services. It includes principles on how to design SOA-based systems, guidelines for its documentation and a software framework capable of supporting its implementations. The design guidelines provide generic “ black box” design patterns on how to implement application systems to be Arrowhead Framework compliant. It already solves relevant issues regarding interface, protocol and semantic interoperability.

THE FRAMEWORK/ ARCHITECTURE

INPUT FOR MANTIS

The Arrowhead framework is an intelligent middleware that can be easily applied for creating CPS. Each physical entity (ex. CNC machine, robot, etc.) can be virtualized as an Arrowhead compliant service and registered into the Arrowhead Framework in order to be accessed and used within the MANTIS platform. Within the Arrowhead Framework each service providing system is discoverable and invokable;

The Arrowhead framework faces several interoperability issues to enable integration of the information between heterogeneous components by deeply analysing the message exchange patterns, the most used communication protocols and semantic data representation.

CLASS Virtualization middleware & Interoperability

19 http://www.arrowhead.eu

http://www.arrowhead.eu/



3.2.6 IMC-AESOP

STUDY IMC-AESOP

DESCRIPTION The IMC-AESOP project is aimed to use the existing basic SOA and cloud technologies to create new solutions in industrial and infrastructural environments [37]. In particular, the main idea is to take advantage of the wide dissemination of the internet-based technologies in almost all the levels of the automation pyramid (ISA-95 model) for applying the DPWS (Device Profile for Web Services – OASIS standard) as the reference implementation technology to enable virtualization of physical entity (ex. CNC machine, robot, etc.) in terms of services. The usage of DPWS will enable cross-layer integration inside ISA-95 manufacturing enterprise model. The application of a common technology to all the levels of a manufacturing company from shop floor to business management passing through operation management is the approach used in the IMC-AESOP project to solve relevant issues regarding interface, protocol and semantic interoperability (everything is normalized according to the DPWS standard).


INPUT FOR MANTIS

The IMC-AESOP framework provides an intelligent SOA-based middleware (based on DPWS standard) enabling the virtualization of physical entities in terms of their services/capabilities/functionalities and that are provided to the other CPS of the system. By applying the DPWS standard, each physical entity (ex. CNC machine, robot, etc.) will be virtualized as a virtual device that provides services that are accessible over the network. The DPWS standard defines mechanisms to discover and invoke the provided services while relying on well-defined and structured semantic model and supports several message exchange patterns.

Interoperability issues are solved by the adoption of a standard that will guarantee interface and protocol interoperability between all the components.




3.2.7 PRIME20

STUDY PRIME

DESCRIPTION The PRIME project is aimed to design and develop new solutions for the deployment of highly adaptive, reconfigurable self-aware plug and produce assembly systems, which will use multi-agent control, dynamic knowledge sharing, integrated monitoring, and innovative human-machine interaction mechanisms. The PRIME project main result is an agent-based intelligent middleware for advanced monitoring of manufacturing production systems. Within the PRIME agent-based middleware, each physical entity (ex. CNC machine, robot, etc.) is virtualized as an agent that brings into the system a set of capabilities, i.e. provides to the others agents – that are registered into the PRIME Framework – a set of technical abilities that can be use to execute an operation [38]. The middleware also provides mechanisms to discover agents and invoke their capabilities. The communication between agents is based on the FIPA21 standards that defines standard message exchange patterns and basic semantic.


INPUT FOR MANTIS

The PRIME framework provides an agent-based middleware can be used with the purpose of creating CPS, i.e. a middleware that enables the virtualization of physical entities in terms of their capabilities/skills that are provided to the other CPS of the system. Therefore, the PRIME agent-based middleware allows to virtualize physical entity (ex. CNC machine, robot, etc.) as agents that provides capabilities/skills that are accessible over the local network.

The PRIME agent-based middleware relies on Java Agent Development Framework (JADE) as technical environment then the discovering and invocation of provided capabilities/skills are handled by JADE as well as the FIPA standard message exchange pattern.


3.2.8 IoT-A22

STUDY IOT-A

20 http://www.prime-eu.com

21 http://www.fipa.org

22 http://www.iot-a.eu/public

http://www.prime-eu.com/

http://www.fipa.org/

http://www.iot-a.eu/public



DESCRIPTION The IoT-A project is aimed to design and define an architectural reference model and related reference architecture for IoT systems. The IoT-A Architectural Reference Model (ARM) is an effort to handle the emergence of a variety of communication solutions and plethora of a cost-effective, rapidly evolving connected devices. In particular, the ARM enables for higher degree of interoperability between IoT applications by standardizing and characterizing the IoT domain while assuring a common understanding.


INPUT FOR MANTIS

The IoT-A framework defines an architectural reference model for IoT solutions. The IoT-A ARM serves as a basis for the definition of a reference architecture.

The IoT-A framework provides high levels models that are used to specify a reference architecture. The IoT reference architecture, in turn, consists mainly of views and perspectives. These views and perspectives are then used to specify IoT-A compliant concrete architectures.

The IoT-A framework provides interoperability models for data exchange and representation, ontology for events and metadata description model.

CLASS Reference Architecture, functional blocks & Interoperability models



3.2.9 FIWARE23

STUDY FIWARE

DESCRIPTION FIWARE is an open initiative based on the following pillars:

FIWARE platform: provides a rather simple yet powerful set of APIs (Application Programming Interfaces) that ease the development of Smart Applications in multiple vertical sectors. The specifications of these APIs are public and royalty-free.

FIWARE Lab: is a non-commercial sandbox environment where innovation and experimentation based on FIWARE technologies take place.

FIWARE Ops: is a collection of tools that eases the deployment, setup and operation of FIWARE instances by Platform Providers.

FIWARE Acceleration Programme: aims at promoting the take up of FIWARE technologies among solution integrators and application developers, with special focus on SMEs and start-ups.

FIWARE Mundus: is designed to help FIWARE spread in different parts of the world, including Latin American, Africa and Asia.


INPUT FOR MANTIS

• The IoT Backend Device Management Enabler, to integrate the different data coming from the sensors and subsystems.

• The CKAN Enable, to integrate Open Data.

• The Short-term Historic Data enabler, to compute short term data metrics by using a time series database

• The Big Data Enabler, to extract short term and long term predictions and to identify maintenance patterns that could be optimized.

• The Context Adapters Enabler, to interface the platform with external sub-systems,

The CEP (Complex Event Processing) Enabler to analyse and react to events, generating immediate response and triggering actions due to changing conditions.

CLASS Reference Architecture, functional blocks & Interoperability models

23 https://www.fiware.org/



3.2.10 SOFIA224

STUDY SOFIA

DESCRIPTION SOFIA2 is a middleware that allows the interoperability of multiple systems and devices, offering a semantic platform to make real world information available to smart applications (Internet of Things). It is multi-language and multi-protocol, enabling the interconnection of heterogeneous devices. It provides publishing and subscription mechanisms, facilitating the orchestration of sensors and actuators in order to monitor and act on the environment. Cross-platform and multi-device through its SDK, APIs and extension mechanisms allow integration with any device. Further detail available at http://sofia2.com/docs/SOFIA2-Technical-IoT_Platform.pdf

The following product options are available:

• Sofia2 CloudLab: is an instance of Sofia2 deployed on Cloud that allows any person, company, organization, developer or citizen to have free access to public data managed on it and create their own applications for experimental purposes.

• Sofia2 PoC on Cloud: is a dedicated Cloud instance in which an organization has a complete implementation of Sofia2 with a very small cost.

• On Premise: this model is suitable for organizations that want to have Sofia2 in their own infrastructure (Production Environment). The cost is based on the number of cores in which it is deployed.

• Cloud (SaaS): with this model the organization simply accesses to a platform available for it. The cost is based on the number of processed messages per unit time or storage TBs.


INPUT FOR MANTIS

Middleware for IoT, M2M, and Big Data Integration in Real Time


24 http://sofia2.com/home_en.html

http://sofia2.com/docs/SOFIA2-Technical-IoT_Platform.pdf

http://sofia2.com/docs/SOFIA2-Technical-IoT_Platform.pdf



4 Interoperability in MANTIS

4.1 The Approach

The MANTIS approach for interoperability specifications and guidance definition builds up on the main assumption that: the identification of a reference model for interoperability of CPS systems – from which specification and guidance will be extracted – cannot be established without any link to the concrete

architectures – instantiated in the several considered use cases – where they should be applied. Therefore, in order to extract the main requirements for interoperability together with the interoperability model and its level of application the steps presented in Figure 15 have been followed. The main idea is to start a

reverse engineering process where concrete architecture are analysed at different levels of abstraction to

identify where problems can occur and where interoperability reference models should be provided.

Figure 15 – MANTIS Interoperability proposed Approach

The main steps of the proposed approach are the following:

i. Use Case Analysis: characterization of the use case concrete architecture in which the MANTIS platform will be integrated;

ii. Concrete System Unified Description: unique description of the overall system, i.e. use case concrete architecture plus MANTIS platform;

iii. Platform Interoperability needs: identification of the interoperability issues at platform; iv. Edge Interoperability needs: identification of the interoperability issues at edge level; v. Component Interoperability needs: identification of the interoperability issues at component level;

vi. Base technology: identification of the base technologies.

These steps provide the interoperability requirements that are used to create reference models for interoperability, i.e. to define specification and guidance to respond to the main interoperability requirements. The identified reference models for interoperability are:



i. New Tools and technology: to identify tools and technologies that could potentially help/facilitate the integration of the MANTIS platform within the use case ecosystem;

ii. Component Interoperability reference model: to define a model to describe interoperability at the

component level, i.e. integration between physical entities and cyber entities to create CPS;

iii. Edge Interoperability reference model: to define a model to describe interoperability at the edge level, i.e. between several components within the same local network;

iv. Platform Interoperability reference model: to define a model to describe interoperability at the platform level, i.e. integration between digital artefacts that are responsible to analyse the data

provided by CPS located at edge level; v. Global Interoperability reference model: to provide a unique model that is the confluence of the

platform, edge and component interoperability reference models;

vi. Specification and guidelines for interoperability: to compile a set of specifications and guidelines

and/or guidance for facilitating the interface, protocol and functional interoperability between use case ecosystems and MANTIS generic components.



4.2 MANTIS Cloud-based Environment Interoperability Reference ModelThe Concept

4.2.1.1 A Reference Model Perspective

The architecting activities of WP2 want to provide reference solutions to the other work packages, especially to use cases in WP7. Inspired by the IoT-A25 project, a MANTIS Architecture Reference Model

(MANTIS-ARM) has been created to provide the cornerstone for designing, developing and deploying MANTIS-enabled solutions. The MANTIS-ARM (Architecture Reference Model) is one of main results of WP2 together with all the views and perspectives that are associated to it. As stated in D2.2 – Reference Architecture and Design Specification deliverable, the MANTIS-ARM consists of five main elements,

namely (see Figure 16): i) Reference Model; ii) Reference Architecture; iii) Feature model; iv) Guidelines; and v) Reference applications. In particular, the reference architecture provides views and perspectives on distinct architectural aspects that provide the foundation for building compliant Predictive and Preventive Maintenance (P2 M) architectures. In this scenario, interoperability represents a perspective of the MANTIS-ARM reference architecture building block. A perspective defines a collection of activities, tactics,

and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the system’ s architectural views [39] (see Figure 17).

Therefore, interoperability perspective is something orthogonal to the several views defined within the MANTIS-ARM reference architecture building block.

Figure 16 –Main elements of the MANTIS-ARM

Figure 17 – Relation between perspectives and views in MANTIS-ARM reference architecture block [39]

Fulfilling qualitative requirements through the architecting process inevitably leads to design challenges, related design decisions and design choices. Since there is usually more than one solution to each of the design challenges, the MANTIS ARM cannot guarantee interoperability between any two concrete architectures, even if they have been derived from the same requirement set. Nevertheless, the MANTIS

ARM is an important tool in helping to achieve interoperability between MANTIS-compliant systems and within the MANTIS concrete platform itself.

In MANTIS interoperability issues are framed in three main levels, namely:

Component level: focuses on how physical entities should be virtualized, i.e. how physical entities

can be “ cyberized" in terms of the functionalities and/or services that they are able to provide or in other words how to create MANTIS-enabled CPS.

Edge level: focuses on a set of physical entities belonging to the same local system. At this level

the data extracted from physical entities is used to model and analyse the behaviour of the system.

The edge level also includes a sublevel that is the component level where physical entities are analysed singularly. At the machine and component sublevel the data extracted from a physical entity is used to model and analyse the behaviour of a physical entity singularly.

25 http://www.iot-a.eu/public

http://www.iot-a.eu/public



Platform level: focuses on the information exchange and data integration in the cyberspace. At this level the data coming from the edge level is organized in order to be processed by MANTIS digital

artefacts.

The identification of three level for interoperability is inspired by the IIC-RA three-tier architecture pattern [40] that comprises edge, platform and enterprise tiers (see Figure 18). These tiers play specific roles in processing the data flows and control flows involved in usage activities.

Figure 18 – IIC-RA Three Tier Architecture [40]

4.2.2 The Interoperability Levels/Tiers

Even if three main interoperability levels have been identified: component level; edge level; and platform

level, in the this section component and edge level are wrapped in one logical section (4.2.2.1) since we are pointing to physical entities connected to the same local network.

4.2.2.1 Edge Level/Tier

The edge level comprises physical entities that belong to the same local network and or functional area.

The topology and the intrinsic characteristics of the edge level strictly depend on the particular architectural pattern that is used for designing the MANTIS platform. As stated in D2.2. – Reference Architecture and Design Specification deliverable several architectural patterns have been considered as

part of the MANTIS-ARM. Analysing the proposed architectural patterns it is possible to verify that the edge level can be as simple as an elementary gateway that delivers data to the platform level (where the

intelligence is installed and deployed) or as complex as a network of digital artefacts that provide advanced edge data analytics and knowledge generation functionalities as well as transmission of the data to the platform level for more accurate and resource consuming tasks. The digital artefacts are divided into generic digital artefacts and application specific digital artefacts. The former are digital artefacts that are

independent form the application domain while the latter are digital artefacts whose execution strictly

depends on the particular application scenario. Regardless to the particular architectural pattern, it is necessary to virtualize physical entities to be integrated into the edge level and thus platform level. As an example, by considering the IIC-RA three tier architecture pattern, at the edge level data is gathered from the edge nodes. The data can be used to model the behaviour of the edge, i.e. edge data analytics and

knowledge discovery digital artefacts are designed and implemented to analyse the behaviour of the edge nodes as a whole. To allow that it is necessary that physical entities are virtualized to become edge nodes



that are capable to provide data during their lifecycle. Therefore, at the edge level the main interoperability issues are:

1. integration of physical entities into the edge: It implies the virtualization of the physical entities

into CPS (component level interoperability) to be integrated within the edge;

2. and provisioning of the data extracted from the CPS (edge nodes) to the platform level.

4.2.2.1.1 Machine/Component Level

Considering a complex system (e.g. industrial production system) it is composed by a huge amount of machines and their related components. Thus, the machine/component level comprises physical entities that are part of the same functional unit. The machine/component level is not fixed, i.e. the

correspondence between machine/component and CPS strictly depends on the granularity level defined at the design stage of the CPS. As an example, one can define a CPS that is an aggregation of several physical entities in a 1-to-many relation – one cyber entity that receives and (pre-)process data from several physical entities – or a CPS that represents one and only one physical entity in a 1-to-1 relation. The machine/component preliminary analysis is the necessary step to enable virtualization of physical

entities into CPS. At machine/component level the main interoperability issue at machine/component level are:

1. The definition of the granularity level for CPS; 2. and according to the granularity level defined before, the design and development of

communication library for extracting raw data from physical entities and accessing it into the cyber entity.

4.2.2.2 Platform Level/Tier

The platform level receives, processes and forwards commands from/to the edge level. It provides more

complex and resource consuming data analytics and knowledge generation functionalities – wrapped into

digital artefacts – than the edge level. Similarly, to the edge level, the digital artefacts at platform level can be clustered into two main classes; generic and application specific. At platform level data received from the edge level are organized according to a common ontology and/or data model that supports the data flow and exchange between the digital artefacts. According to the architectural pattern the platform level will be populated with totally accessible digital artefacts, i.e. digital artefacts that can be accessed

directly by the edge nodes, or a gateway mediated connection where edge gateways forwards data to

platform gateways that in turn are responsible to provide data to the other digital artefacts into the platform. Since at platform level all the data provided by the edge level are needed to be extracted, transformed, laded and stored then it is necessary that the data are organized according to a common

ontology to enable interoperability across the several digital artefacts that are used to transform the data. Therefore, at platform level the main interoperability issues are:

1. Semantic data representation and exchange to allow that data analytics digital artefacts to process

it; 2. and how to represent the knowledge models generated by data analytics digital artefacts in order

to enable the usage of such models back to the edge level for local control.

4.2.2.3 Interoperability issues that are orthogonal to the three interoperability levels

Finally, there are several interoperability issues that are orthogonal to the considered interoperability levels, i.e. models, guidelines and specifications that can be applied to all the interoperability levels without any

restriction, namely:

1. The definition of the communication protocol and message exchange pattern to use in both edge and platform levels;

2. The definition of an ontology of events to support systems interactions at both edge and platform levels.



3. The mapping, adaptation and translation of the data formats of CPS messages at the edge level to the semantic provided in the platform level.

The above topics reveal interoperability issues that are related on how CPS and, more in general, digital

artefacts are connected together.

4.2.3 Exemplary Use Cases

The employment of the MANTIS interoperability proposed approach within the several use cases envisions

two main phases. The phase 1 is intended to characterize the concrete system with the objective of identifying relevant data sources. During this phase, firstly machine documentation (electrical automation, mechanical diagrams, etc.) has been analysed and the system architecture extracted. Secondly, a tentative

to integrate the concrete system with the MANTIS platform has been done. Once the overall system

architecture (concrete system plus MANTIS platform) has been provided the second phase can finally start. During this phase, the overall system architecture has been described – main functional components and their relationships – by using a predefined set of graphical elements. The main objective was to generate a unique representation of the system that can be easily compared and analysed by all the partners inside the project. These common representation is constituted by four main views, namely:

1. Overall system view: describes the overall system, i.e. use case system plus MANTIS platform. It

is an effort for identifying hardware, software and communication constraints as well as where interoperability should happen. In particular, the three main levels are identified: i) component level; ii) edge level; and iii) platform level;

2. CPS internal view: describes the internal view of a MANTIS CPS and how these sensors are connected to the physical world. Even in this case the communication constraints are identified;

3. CPS interface view: describes the main interface of the provided MANTIS CPS. It is an effort to identify commonalities in the interfaces from distinct use cases in order to define a standard atomic

interface for MANTIS enabled components (i.e. CPS and digital artefacts);

4. And overall system information flow view: Describes the overall information flow starting from physical entities at edge level, passing through digital artefacts at platform levels and coming back to the edge level.



4.2.3.1 Use Case 1.3.1: Press machine maintenance Use Case Brief Description

The main aim is to use the MANTIS platform to develop a smart system for the pro-active maintenance-repair operations of press machines (Use Case –UC- 1.3.1) located around the world based on real-time sensor data, acquisition, pre-processing, subsystems modelling, knowledge extraction and machine learning

techniques.

These elements will be used for enabling a more accurate prediction of potential failures and for planning the most suitable time periods to perform preventive maintenance operations with the aim of reducing down-time. They will also be used to monitor critical parts and key indicators. These tasks will take place at two levels. Firstly, at edge level, where the information is acquired, prep-processed and subsequently

some knowledge is extracted and sent to the platform level for further processing. Secondly, at platform

level, where the information is firstly collected from many press machines, after this the knowledge extraction tasks take place processing all the received information providing useful and clear guides for smart maintenance. The knowledge acquired from all sensors will also contribute to improve the design

of new equipment.

Concretely, in this case study (UC1.3.1), the damage is measured in critical points of the press head of the press machines. To this end, various preprocess tasks are performed after extracting information from two different types of sensors 1) the crankshaft encoder in order to know the position of the rods and 2)

strain gauges located at the rods in order to measure the forces transmitted to the press head.

Besides the damage calculation, there are also sensors to measure temperatures and oil information. For example, sensors in ferrules, in bearings, and for measure the environment temperature



4.2.3.1.2 Applying the Proposed Approach to the Use Case

STUDY PRESS MACHINE MAINTENANCE NOTES

SYSTEM VIEW

The overall system view is fundamental to understand where the information is acquired and where the information is processed and presented to users. In this use case, the system is divided into two levels, an edge level and a platform level. Each press machine is located at edge level jointly with the set of sensors and PLCs involved which have the responsibility to collect and to provide data and knowledge. This information is processed before being sent to the platform for prevention. At platform level, all information provided by all press machines is collected and processed globally to extract useful knowledge for smart maintenance. This knowledge is then presented by means of suitable user interfaces.

CYBER PHYSICAL ENTITY INTERNAL VIEW

This view provides summarized information regarding the different elements involved at the edge level. In contrast to the overall system view, in this one we can see the different elements of the CPE, that is, the press machine, the set of sensors (existing and new sensors), involved PLCs for managing the sensors and for controlling the machine and finally the digital artefacts required for processing the information. In particular, under the paradigm of MANTIS a new set of sensors is introduced for gathering critical information of the more sensitive parts involved in the maintenance-repair tasks such as the structural health, the displacement or the torque.

On the other hand, two new digital artefacts are introduced; the first one is associated with the pre-processing of the information provided by the sensors which aims to prevent processing noisy or incorrect data provided by the sensors. The second one is associated with the extraction of knowledge before sending to the platform.

OVERALL SYSTEM INFORMATION FLOW

In MANTIS the information flow has the following steps:

Data acquisition. the information is collected at the edge level by the sensors and sent for further processing. Data enrichment. The data provided by the sensors are analyzed; cleaned and additional relevant information is included before storing for further processing. Knowledge extraction (local). Based on the information enriched in previous steps local algorithms are applied to extract knowledge and to be sent to the platform. Data flow control and prioritization. The knowledge extraction performed in the last step provides new enriched sources of information. At this point, a policy will dictate how the information is regulated, that is, how each source of information reaches its entry point at the MANTIS platform. This policy will based on different criteria such as:

Nature of the data: text, images, decisions, etc.

Priority: asynchronous events such as alarms should be prioritized.

Security policy: the control flow can encrypt and/or sign digitally the information with the aim of guaranteeing the identity of the origin and the confidentiality of the information.

Message exchange pattern: each new enriched source of information will use the most suitable pattern or service. The system will

Quality control. With the aim to control the quality of the service of MANTIS platform to process and analyze the information from a increasing number of sources of information an additional criteria can impose a conservative transmission rate depending on the circumstances. This criteria can change dynamically and it will governed by the global policy of control information flow.

Specific criteria: the customer can impose additional criteria to control the information flows. The system will be enough flexible to accept multiple criteria.

On the other hand, the system will enable (when necessary) two categories of channels:

Command & Control channel. This is a secure channel where the different policies will be received and enabling the notification of different security events.

o In this sense the security management system will obtain the corresponding security policy which at least include: o Public Key Infrastructure: Public/private cryptographic keys, Digital Certificates, Certification authorities. o Data acquisition policies: new sensors, acquisition rates. o Data enrichment: Algorithms to be used, etc.



o Flow control policies: Priorities, etc. o On-premise local security policies: User Rights, Secure storage, Role management.

Data channel. This is the standard channel for transmitting information which can be divided depending on the data flow policy.

The result is a controlled environment where each flow of information is governed by a specific policy providing global smart flow information. Data Ingestion. Depending on the policy each source of information provided by all CPEs is routed to the corresponding entry point before being processed and stored. User Interface. This component provides a graphical interface of the system. Depending on the global information policy the access to different parts of the graphical interface will be allowed or denied. Knowledge extraction (global) or Business intelligence. In this step a set of business rules dictates how the set of algorithms are applied and how and when the information is stored. Storage and Retrieval. It is a storage system in charge of safekeeping of the information. Global information policy management. This subsystem will comprise (at first) the information security policies which surrounds every step of the information process such as the access control to the platform, the authentication, or the eligibility of the algorithms in the knowledge extraction. It will also comprise policies associated to business needs such as the priorities of the information, the data f low rate from the different origins, etc.



4.2.3.2 Use Case 1.4: Sheet Metal Working Machinery

4.2.3.2.1 Use Case Brief Description

The objective is to use the MANTIS platform to develop an application for the proactive maintenance of the sheet metal working machinery based on real-time sensor data acquisition, sensor fusion, reliability techniques, forecasting and machine learning techniques. These tools will be used for monitoring the

equipment behaviour and enable a more accurate prediction of potential failures. This will facilitate the planning of maintenance operations, significantly reduce down-time and allow for the optimisation of energy consumption. Acquiring knowledge regarding the machines present and future behaviour will also contribute to the improved design of new equipment.




STUDY SHEET METAL WORKING MACHINERY NOTES

SYSTEM VIEW

An edge-based architectural pattern is used within the pilot.

At edge level, there are the following main elements:

o A PC-based PLC that is responsible for monitoring and controlling the Press Brake. o A Safety PLC that is connected to the PC-based main PLC and is responsible for executing the safety logic. o A MANTIS cyber entity deployed on a Raspberry PI that is responsible to get machine data from the PC-based controller,

as well as, to deliver the data to the cloud o A MANTIS HMI for visualization, configuration and diagnostics

At platform level, all data provided is collected and processed globally to extract useful knowledge for smart maintenance. This knowledge is then presented by means of suitable user interfaces.


Several Sensors are installed on the Press brake, some of them are connected to the PC-based controller and others are directly linked to the MANTIS Cyber Entity. These sensors represent new sensors installed in the context of the MANTIS project and used for improving the maintenance activities.


In MANTIS, the information flow has the following steps:

Data acquisition. In this step, the data is collected at the edge level by the sensors and sent for further processing. Data is gathered by the MANTIS Cyber Entity.

Data enrichment. The collected data is cleaned and filtered and further information is attached..

Data Provisioning: the processed data is then sent to the MANTIS cloud for further processing. In this step all the data is collected by the platform before being processed and stored.

Knowledge extraction (global) or Business intelligence. In this step a set of business rules dictates how the set of algorithms are applied and how and when the information is stored.

Storage and Retrieval. It is a storage system in charge of safekeeping of the information.



4.2.3.3 Use Case 2.2: Railways – Turnouts


The goal is to use the MANTIS platform to develop an application for the proactive maintenance of

railway switches based on real-time sensor data acquisition, pre-processing, now casting, forecasting, statistical and machine learning techniques. These techniques will be used for monitoring the switch

behaviour and enable a more accurate prediction of potential failures and for planning the most suitable time periods to perform preventive maintenance operations with the aim of reducing down-time and railway safety risks.

The definition of the proper approaches for the application of the developed methodologies and tools in

the railway domain through the definition of a proof-of-concept is based on the data analysis of information

flows coming from different sources to take proper decisions at different times:

At design time: use already available information from existing systems to create predictive models that can be adapted and used to support the development and/or the maintenance of a systems.

At run-time: use of on-line data collection developing in MANTIS new sensors e diagnostic monitoring systems and analysis techniques to make short-term and long-term predictions on the

status of a working system to plan maintenance properly. Such models will be adaptive, they will

be able to learn from the operating conditions of the single system under investigation and from other similar systems deployed in similar conditions.

Evaluating complex information from the various diagnostic monitoring systems installed wayside on the switch, a reliable predicting model for asset degradation, multiple contingency scenarios and decision support systems will allow to develop maintenance strategies, predictive, risk and condition based

maintenance for a substantial cost reduction increasing the reliability, availability and quality of the railway

infrastructure.




STUDY RAILWAYS - TURNOUTS NOTES

SYSTEM VIEW

The overall system view is fundamental to understand where the information is acquired and where the information is processed and presented to users. In this use case, the system is divided into two levels, an edge level and a platform level.

At edge level, there are the following elements:

o Each Railway Turnout is located at edge level jointly with the set of sensors installed on the rail and on the switch machine

o PLCs involved which have the responsibility to command the movement of the switch o Data Acquisition System which have boards and an industrial pc to collect and to provide data

and knowledge. This information is processed before being sent to the platform for prevention.

At platform level, all information provided by all switches is collected and processed globally to extract useful knowledge for smart maintenance. This knowledge is then presented by means of suitable user interfaces.


At the edge level this view provides summarized information regarding the different elements involved:

o Turnout: switch machine and switch blades o PLC for controlling the switch machine to command the movement of the turnout o Data Acquisition System which have boards and an industrial pc to collect and to provide data

and knowledge. o New set of sensors for gathering critical information of the more sensitive parts involved in the

maintenance-repair tasks such as the displacement of the switch blades, motor current of the switch machine, environment temperature and humidity

At this level, the information is acquired, prep-processed by the Data Acquisition system and subsequently some knowledge is extracted and sent to the platform level for further processing.


In MANTIS, the information flow has the following steps:

Data acquisition. In this step, the information is collected at the edge level by the sensors and sent for further processing.

Data enrichment. The data provided by the sensors are analysed; cleaned and additional relevant information is included before storing for further processing.

Knowledge extraction (local). Based on the information enriched in previous steps local algorithms are applied to extract knowledge and to be sent to the platform.

Data Integration. All sources of information, that is, all information provided by all CPEs is collected by the platform before being processed and stored.

Knowledge extraction (global) or Business intelligence. In this step a set of business rules dictates how the set of algorithms are applied and how and when the information is stored.

Storage and Retrieval. It is a storage system in charge of safekeeping of the information.

In this flow firstly, at edge level, where the information is acquired, prep-processed and subsequently some knowledge is extracted and sent to the platform level for further processing. Secondly, at platform level, where the information is firstly collected from the switch, after this the knowledge extraction tasks take place processing all the received information providing useful and clear guides for smart maintenance.



4.2.3.4 Use Case 3.2: Photovoltaic Plants – Predictive Maintenance


PV plants witness a vast number of physical changes that can trigger, be correlated to or be symptoms

of yield and performance changes, which directly or indirectly affect the ROI, the durability and the general functioning of the park in question and its components. On-site data loggers are almost always in place

to gather most if not all relevant information and store it or send it on to central data warehouses, but maintenance is usually based on simple monitoring of that data and crude, custom made alerting.

Our aim is to integrate new and existing PV plants with more advanced and generic data analysis to ensure better maintenance and higher yields.

Specific challenges:

From the standpoint of a service provider, what is called the edge level in Mantis may be included or not in the system, depending on how much operational responsibility the service provider assumes. In nearly all cases however, relevant components from the edge levels will have a cyber-representation at the platform level.

A big challenge lies in the lack of standardisation in the data structure and communication. Many data

sources are floating around that provide access to inter-related datasets, but use different formats, conventions and protocols. So our attention goes to interface, protocol and syntactical interoperability by means of assisted auto-detection (i.e. with minimal configuration) for data acquisition and to semantic interoperability as a preparation step for data analysis.




STUDY PHOTOVOLTAIC PLANTS NOTES

SYSTEM VIEW

Different projects / plants will see different levels of integration, so rather than an exhaustive list of use cases we summed up some typical implementation examples looked at from an interoperability standpoint. From top to bottom, left to right, the following subsystems are represented in the illustration below: on-site data acquisition, data analysis, central data store and reporting. Each of these subsystems may or may not be setup / operated / maintained by the same entity and as such the connections between them can and will present interoperability challenges at different levels.


We will typically plug in to existing monitoring and data acquisition APIs provided by the manufacturer of the physical devices. If this does not exist or does not provide the features we need, we may do a custom development effort to read out the parameters and present them in a predefined, standardized way to the other software components


Data analysis services using the Arrowhead framework When both the central data storage and the analysis services are under our own control, it is possible to agree on the conventions to follow and we can make certain assumptions w.r.t. the data structure and protocols we will encounter (e.g. message based communication on a fixed message bus location with timestamps in UTC and data following IEC standards), but as soon as an interaction with external parties is needed, interoperability issues come into play. The Arrowhead framework and services allow us to handle the setup and orchestration of these data analysis services in a consistent and flexible manner. The Arrowhead services that provide (partial) automation of interoperability negotiations are still under development, but will allow otherwise independent parties to detect and connect to each other’ s digital assets. In the case pictured below, 3E provides an Arrowhead compliant REST API data service that is registered on the shared Arrowhead Service Registry, which allows other Arrowhead network members to find and consume the service. In our local private cloud setup (this could also run on a public cloud) we have a data acquisition process that can read and interpret data from Arrowhead devices and one or more custom in-house services that provide functionality to the REST API.



4.3 Discussion and Wrap-up

In the context of MANTIS, Task 2.2 contributes to the main goal of interoperability in several ways:

Delivering/Providing/Indicating technical standards upon which the solution will be built. These standards lay down the necessary parameters and/or information to be exchanged to enable

designers to deeply understand the intended functions and interactions of the modules they are creating. It is an effort to explain and provide good quality documents and explanation about the standards that are going to be used to be easy to understand;

Delivering guidance and specifications to assure that all the implementations components,

modules, devices, etc. are interoperable and compatible, i.e. to guarantee that application specific

services and any other new implementation are always developed in line with the MANTIS service platform;

Testing the specifications to provide new guidance on how to test if the developed solutions,

modules, components, devices are complying the standards and the delivered specifications. To do that, generic implementations will be delivered to be used as reference and/or “ as-is” for implementing use-case specific MANTIS architectures.



5 Focusing on Standards: ISO 13374 and the role of MIMOSA

5.1 The role of standards in Achieving Interoperability

ICT standards are one of the key enablers for achieving interoperability. As a matter of fact, they provide a mean to facilitate interoperability between products in a multi-vendor, multi-network and multi-service environment. To achieve useful maintenance procedures and strategies information from large numbers of

smart devices and systems needs to be collected and analysed. In this scenario, standards provide a set of terms, concepts, data formats, document styles and techniques so that the information collected can be easily processed by data analytics tasks, routines, algorithms within different computer program. Thus,

the provisioning and usage of standard models is a fundamental step to achieve interoperability by assuring

that products and services – that comply with them – can communicate and exchange information.

The design and development of integrated system health monitoring and service maintenance platforms is recognized by industry and academia an extremely relevant and “ hot” topic. One challenge of these kind of platforms is the strong presence of vast amounts of data from heterogeneous resources which are

exchanged over a heterogeneous collection of communication channel at different levels ranging from local-nodes to cloud applications. This is also the case of MANTIS that delivers distributed processing

chains, constituted by sophisticated distributed sensing and decision making functions, that are performed at different levels in a collaborative way ranging from: i) local nodes that pre-process raw sensor data and extract relevant information before transmitting it, thereby reducing bandwidth requirements of

communication; ii) intermediate nodes that offer asset-specific analytics to locally optimise performance and maintenance; iii) cloud-based platforms that integrate information from ERP, CRM and CMMS systems and execute distributed processing and analytics algorithms for global decision making. As stated in [41], the success of these systems strictly depends on an open, uniform, and performance-optimized

solution for data management. A solution that includes: data definition, data communication, and data storage. By looking at the MANTIS consortium previous experiences and works the OSA-CBM (Condition Based Monitoring) standard for data transmission will be considered. Next section will provide an overview of such standard and how it can be attached to CPS for enabling data transmission within the MANTIS service platform.



5.2 MIMOSA Standards

The Machinery Information Management Open Systems Alliance (MIMOSA) is a not-for-profit trade association composed of industrial asset management system providers and industrial asset end-users [42]

& [43]. The MIMOSA™ member community is made up of various entities including e.g. process and discrete manufacturing companies, military organizations, capital equipment manufacturers etc. such as

Boeing, Rockwell and U.S. Navy.

MIMOSA's Open Systems Architecture for Enterprise Application Integration (OSA-EAI) specifications connect the separate islands of engineering, maintenance, operations, and reliability information to one entity. The goal is to develop information integration specifications to enable open, integrated solutions

for managing complex high-value assets. MIMOSA's open standards enable collaborative asset lifecycle

management in both commercial and military applications. Its primary domains are registry, condition monitoring, reliability, maintenance and work management functions.

MIMOSA is available from www.mimosa.org and it runs under SQL Server, which can be downloaded, from www.microsoft.com. It is also available for Oracle and XML formats. MIMOSA complies with ISO

13374-1: Condition monitoring and diagnostics of machines -- Data processing, communication and presentation -- Part 1: General guidelines and ISO 13374-2: Condition monitoring and diagnostics of

machines -- Data processing, communication and presentation -- Part 2: Data processing.

More information about MIMOSA is available in four separate Webinars: What is Mimosa, How to install

SQL Server, How to install Mimosa Database and How to define your machinery, components and measurement locations into MIMOSA Registry. The Webinars can be found in EMDESK under WP2- SPA Development and in the Materials folder.

http://www.microsoft.com/



6 Interoperability Guidance and Specifications

In order to assure interoperability within the MANTIS platform, a set of specifications and archetypes

have been provided as part of the MANTIS interoperability guidance. Thus, MANTIS interoperability

guidance concerns the definition of a set of specifications and recommendations that will always be used to ensure that implementations of both physical and cyber entities are MANTIS-enabled or – in other words – are interoperable within the MANTIS platform.

Figure 19 – MANTIS Interoperability guidance map

Therefore, the main idea of this section and related subsections is to provide the reader with generic archetypes that will ensure the compatibility of any new implementation with the MANTIS platform. The MANTIS interoperability guidance covers all the necessary issues and aspects that developers need to consider whenever they want to implement MANTIS-enabled digital artefacts from domain model and

virtualization to data representation and system interactions passing through functional interoperability as shown in Figure 19. The proposed guidance and specification have been thought to solve the interoperability issues identified in section 1.3 namely:

1. how data sources within a process/machine can be virtualized by MANTIS-based services and integrated inside the MANTIS platform (Physical Entity Virtualization);

2. how CPS can connect to the MANTIS platform services (ontology for system interactions – message exchange pattern)

3. which events and messages are relevant within the MANTIS platform (ontology for system interactions – event based ontology);



4. how data should be represented to facilitate the data analysis process performed by the MANTIS platform services (semantic data representation and exchange);

5. How data can be extracted from messages sent by CPS and transformed/translated in the

MANTIS platform semantic representation format (semantic data representation and exchange);

Finally, the MANTIS interoperability guidance ensures that software developers provide digital artefacts that meet all the applicable platform requirements.



6.1 Formalizing the MANTIS Interoperability Framework

The MANTIS Interoperability Framework (MANTIS-IF) has been structured into three main parts:

Conceptual integration (modelling and design stage): it is focused on concepts and their relationships, models and meta-models. It provides the modelling foundation for systemizing the

relevant interoperability aspects for the specific application domain;

Application integration (guidance to instantiate the models): it is focused on methodologies, guidance and patterns to support the design and development of their own MANTIS concrete

instantiations; and

Technical integration (specific technological implementation and integration): it is focused on

technical aspects related to the networking (protocols, connectivity, etc.), hardware

(CPU/memory power is already there, at low-cost and low-power consumption) and – more in general – to integration of heterogeneous data sources.

In particular, the technical integration is mainly focused on the usage of frameworks, technologies and stacks (specifically designed and developed to act as system integrators) – such as Arrowhead, node-red, JMEDS, OPC-UA, etc.) – that allow the development of the supporting infrastructure for the instantiation

of the interoperability specifications. For this reason, it is not considered as part of the present document, that is mainly focused on the conceptual and application integration, even if it will be presented.

6.1.1 Conceptual Integration

The model for conceptual integration (see Figure 20) has been created following a model-driven development approach to enable the design of interoperable and interconnected CPS-populated systems. It starts with the definition of a domain model that is aimed to capture the essence of the CPS while

enabling the specification of the services and interfaces that the CPS must provide. The domain model is then complemented with the semantic data representation and exchange model and the system interaction model. In particular, the semantic data representation and exchange model is aimed to define and specify the structure of all the data and/or the information handled by CPS at the network level. The system interaction model is aimed to define and specify the relevant events produced/consumed within the

MANTIS platform, as well as, the distinct patterns for system interactions.

The conceptual integration addresses specific interoperability issues – related with the design and the

development of CPS-populated systems in line with the MANTIS reference architecture – within four main system dimensions, namely:

1. Architectural: is related with the specific/ concrete architectural pattern used to design the MANTIS platform. Interoperability issues are different in number, type and location if a cloud-based or an edge-based pattern is used and/or a faç ade, broker, mediator patterns are applied in those patterns;

2. CPS: is related to the design and development of a CPS, i.e. to provide guidance and guidelines on how to virtualize physical entities in terms of services/functionalities, especially for those that are low-tech;

3. Information: is related with the description of the data and the definition of the messages/structures exchanged, processed and stored within the MANTIS platform. The messages/structures exchanged are here also connected to a MIMOSA-compliant database that models the specific application context by using the MIMOSA OSA-EAI standard; and

4. Interaction: is related with the definition and the identification of the necessary message exchange patterns (MEPs), i.e. how messages/structures are exchanged within the MANTIS platform.

The previous dimensions can then be used to analyse CPS-based software system from the interoperability point of view to help the design and deployment of MANTIS interoperable concrete platforms while identifying the critical interoperability issues and major challenges.



Figure 20 – Model for Conceptual Integration

6.1.2 Application Integration

The model for application integration (see Figure 21) has been developed to capture and show how the provided interoperability models can be related to a concrete MANTIS platform instantiation without specifying and/or establishing any technology. In particular the model for application integration shows

the relation between the model for conceptual integration and the concrete technical environment used

for developing maintenance platforms compliant with the MANTIS-ARM for the sake of interoperability.

The business model describes the specific domain for the software solution that need to be implemented. It is aimed to provide a solid foundation for the design and implementation of a MANTIS interoperable platform, i.e. to relate the CPS domain model to the specific application domain. The software model represents the instantiation of the semantic data representation and exchange model and system interaction model in the specific domain derived from the business model. Therefore, in the software model all the

necessary models of the conceptual integration are included. Finally, the technical architecture represents and describes the concrete environment, infrastructure and related technologies for supporting the platform/application. In particular, in the context of MANTIS project, the Arrowhead framework have

been chosen as the reference technology for providing the necessary infrastructure while acting as a system integrator solving the physical and the syntactic (partially) interoperability level.

As shown in Figure 21, the business model, software model and technical architecture are then used

for developing MANTIS concrete platforms by addressing the specific architectural pattern, the data

sources (in blue in Figure 21), the structure and the flow of data in the analysis and decision making core (in green in Figure 21), and the description and definition of the necessary communication channels and patterns (in grey in Figure 21).

DomainModel

SematicDataRepresentationand

ExchangeModel

SystemInteractionModel

Event

Model

Patternsfor

Interactions

MantisInterop.

Framework

ArchitecturalDimension

CPSDimension

InteractionsDimension

InformationDimension

DomainModel

SematicDataRepresentationand

ExchangeModel

SystemInteractionModel

EventModelPatternsfor

Interactions

MANTISPredictiveMaintenancePlatformConcreteInstantiation

MANTISPredictiveMaintenancePlatformConcreteInstantiation

MIMOSAOSA-EAIcompliant

Database



Figure 21 – Model for Application Integration

6.1.3 Technical Integration

The technical framework of the MANTIS-IF describes the MANTIS platform (see Figure 22) from the interoperability perspective. The architecture is centred on a set of cyber-physical systems (CPSs), core services and related execution engine, processes, data analytics processors, tools and applications that are

aimed to support maintenance activities in CPS-populated systems.

The model for technical integration relies on the Service Oriented Architecture (SOA) paradigm where a software system and/or platform provides a set of services for enterprise maintenance activities improvement. The model is represented by a 4-tier model that cover all the necessary issues and aspects

that developers need to consider whenever they want to implement MANTIS-enabled digital artefacts, i.e. data representation and exchange, system interactions (event models and patterns for interaction), data transformation and translation and services and functionalities definition, as well as, physical entities virtualization (domain model). The data and services tiers are intended to be coupled and supported by a

SOA-based communication infrastructure that, in turn, provides the necessary mechanisms for discovering,

composing and orchestrating the services. In particular the service framework (at the service tier), and the whole process tier represent the real technology where the interoperability models and specifications are instantiated. A central part of the framework is the MIMOSA data storage that acts as a facilitator for the design and implementation of maintenance applications within the business tier. To empower the

use of the MIMOSA data storage, i.e. to permit the storage of the MANTIS events, related metadata and the result of the data analysis processes, translators and transformations are created.



Figure 22 – Model for Technical Integration



6.2 Physical Entity Virtualization

The physical entity virtualization is the first step to enable interoperability within the MANTIS platform. Virtualization is the process of designing and implementing cyber entities at the network layer that map

physical entities. Each cyber entity provides a logical view of the associated physical entity/entities to other computer systems and/or digital artefacts that are interested in using it/them. The combination of

cyber entity and physical entity/entities is the CPS. Whenever, another digital artefact makes a request to a CPS by using the cyber entity that is living into the cyberspace at the network layer it is redirect to the physical mapped physical entity. The relation between physical and cyber entity represents the foundation for the designing and development of CPS-based applications. To really understand this

relation and – as a consequence – to understand how physical entities can be mapped as cyber entities

a model has been created that explain all the relevant relations between physical and cyber entities in the CPS domain. The proposed model is the first step to establish a supporting methodology for virtualization.

6.2.1 Interoperability Domain Model and MANTIS-ARM Domain Model: relations

Before presenting the interoperability domain model, it is necessary to show how and why this model is important and where it is different from the MANTIS-ARM domain model presented in deliverables D2.2 – Reference Architecture and Design Specification V1, D2.6 – Reference Architecture and Design

Specification V2 and D2.9 – Reference Architecture and Design Specification Final Version.

The interoperability domain model is an effort of describing the essence of a CPS, i.e. the main concepts and the relations between them to model the intricacies of a CPS and understand their behaviour. On the contrary, the MANTIS-ARM domain is an effort to define the main domain of the overall reference architecture, namely: collaborative predictive maintenance. Within this domain CPS are considered as the

enabling paradigm and technology to implement such service-based collaborative predictive maintenance.

Regardless to the specific domain (maintenance), CPS bring a set of interoperability issues that are generic and not related to the specific application domain. For this reason, a description of the CPS domain is provided in the context of this document or more in general in the context of interface, protocol and

functional interoperability guidance and specifications.



6.2.2 Interoperability Domain Model for MANTIS-enabled CPS

Figure 23 – Interoperability Domain Model for MANTIS-enabled CPS

The Interoperability domain model for MANTIS-enabled CPS is inspired on the IoT-A domain model. It is a tentative to try to capture the essence of a CPS. The model is built on the top of the following main concepts:

User: is a human person or some kind of a Digital Artefact (e.g., a Service, an application, or a

software agent) that needs to interact with a Physical Entity.

Functionality: allows the user to indirectly interact with the physical entity. Thus Functionality will allow to act on physical entities and/or to provide information about them. To access a

functionality, the user needs a client, i.e., a software with an accessible user interface.



Physical Entity: is an identifiable part of the physical environment that could be potentially used by users to accomplish their goals.

Cyber Entity: is the representation in the digital world and/or cyber-space of Physical Entities. The Cyber Entities have two fundamental properties:

o They are Digital Artefacts. Cyber Entities are associated to one or more Physical

Entity/ies. On the contrary, Physical Entities could be associated to several Cyber Entities e.g., a different representation per application domain. Each Cyber Entity must have one and only one ID that identifies it univocally. Cyber Entities are Digital Artefacts that – in turn – can be classified as either active or passive. Active Digital Artefacts (ADA) are

running software applications, agents or Services that may access other Functionalities or Resources. Passive Digital Artefacts (PDA) are passive software elements such as database

that contain data about Physical Entities;

o Ideally, Cyber Entities are synchronised representations of a given set of aspects (or

properties) of the Physical Entity. This means that relevant digital parameters representing the characteristics of the Physical Entity are updated upon any change of the former. In the same way, changes that affect the Cyber Entity could manifest themselves in the

Physical Entity.

Cyber Physical System: it represents the composition of one Cyber Entity and the Physical Entity/ies it is associated to. The Cyber Physical System is what actually enables everyday objects

and/or devices to become part of digital processes.

Device: it enables the relation between Cyber Entity and Physical Entity. Devices provide the technological interface (Native Communication Library) for interacting with, or gaining information about the Physical Entity. By so doing the Device actually extends the Physical Entity

and allows the latter to be part of the digital world. A Device thus mediates the interactions

between Physical Entities (that have no projections in the digital world) and Cyber Entities (which have no projections in the physical world), generating a paired couple that can be seen as an extension of either one, i.e. the Cyber Physical System. Devices are thus technical artefacts for

bridging the real world of Physical Entities with the digital world of Cyber Entities. Notice though that Devices can be aggregations of several Devices of different types.

Resources: are software components that provide data from or are used in the actuation on Physical Entities. Since it is the Functionality that makes a Resource accessible, the relations

between Resources and Cyber Entities are modelled as associations between Cyber Entities and Functionality. Resources can be either classified into:

o Network Resources: are Resources available somewhere in the network, e.g., back-end or

cloud-based databases.

o Native Communication Library: are Resources that include executable code for accessing, processing, and storing Sensor information.

Proprietary Local Adapter: Physical Entities can only be accessed locally;

Proprietary Remote Adapter: Physical Entities can be accessible through the

network.



6.2.2.1 Mapping Between MANTIS and IoT-A Domain Models

In order to allow the easy translation of the IoT-A domain model into the MANTIS domain model the

Table 2 has been created. The Table 2 presents the mapping between the concepts of the MANTIS domain model and their counterpart in the IoT-A domain model.

Table 2 – Mapping between MANTIS and IoT-A domain models concepts

MANTIS

domain model

concepts

IoT-A

domain model

concepts

Further

comments

User User The user of the CPS/IoT system.

Human Human User Specialization of the user concept.

Digital Artefact Digital Artefact

Active Digital Artefact Active Digital Artefact

Passive Digital Artefact Passive Digital Artefact

Cyber Entity Virtual Entity

Resource Resource

Network Resource Network Resource

Native Communication Library On-Device Resource Specialization of the Resource concept, the native communication library defines the way a digital artefact can access a physical entity (i.e. a device).

Proprietary Remote Adapter n.a. Further specialization of the concept Native Communication Library that is internally used by the Cyber entity attached to a physical entity.

Proprietary Local Adapter n.a. Further specialization of the concept Native Communication Library that is internally used by the Cyber entity attached to a physical entity.

Device Device

Physical Entity Physical Entity

Cyber Physical System Augmented Entity

Functionality Service The main idea is to detach the concept of cyber physical system from the specific technology, i.e. a resource is exposed by a functionality that in turn can be a service and/or an agent, etc..



6.2.3 MANTIS-enabled CPS Engineering Approach

CPS engineering can be easily considered a branch of the Component engineering. As a matter of fact, the way CPS are designed and developed can be easily mapped with the design and development of

software components. Component engineering is concerned with the development of components as individual building blocks, (Component provider) in comparison to Application engineering which is concerned with the assembly and integration of these building blocks into new solutions or applications.

(Component user)

Component-based development is usually a mixture of top-down decomposition and bottom-up composition. In other words, the system is decomposed into finer-grained parts, that is, subsystems or components, and these are to be mapped to individual prefabricated building blocks. If no suitable

components are found, decomposition is continued. If partially suitable components are found, the decomposition is repeated according to the needs of the candidate component. A found suitable component represents a feasible and acceptable solution for the entire system or the subsystem considered.

In the literature several definitions of a component have been identified:

• “ A unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties” [44].

• A component is a reusable unit of composition with explicitly specified provided and required interfaces and quality attributes that denotes a single abstraction and can be composed without modification [45].

• A component is a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces [46].

• A software component is an independently deliverable piece of functionality providing access to its services through interfaces [47].

An individual component is a software/hardware package, a Web service, or a module that encapsulates a set of related functions (or data). Components are modular and cohesive: all system processes are placed into separate components so that all of the data and functions inside each component are semantically

related.

Components communicate with each other via interfaces. These interfaces specify the services that other components can utilize, and how they can do so. It is a component specification and also means the interaction between the component and its environment (interoperability). Software engineers regard components as part of the starting platform for service-orientation. Components play this role, for

example, in Web services, and more recently, in SOA, whereby a component is converted by the Web service into a service and subsequently inherits further characteristics beyond that of an ordinary component.

Several characteristics should be considered when developing components:

• Unique identity: requires that a component should be uniquely identifiable within its development environment as well as its runtime environment.

• Encapsulated: the client of a component interface does not need to know about the inner workings of the component (implementation) in order to make use of it.

• Substitutable: a component can replace another (at design time or run-time), if the successor

component meets the requirements of the initial component (expressed via the interfaces).

• Reusability: programmers should design and implement software components in such a way that many different programs can reuse them. Furthermore, component-based usability testing should

be considered when software components directly interact with users.

• Extensibility: aims to support evolution by adding new components or evolving existing ones to extend the system´s functionality (for example by providing multiple interfaces)

http://en.wikipedia.org/wiki/Modular_programming

http://en.wikipedia.org/wiki/Service-orientation

http://en.wikipedia.org/wiki/Web_services

http://en.wikipedia.org/wiki/Service-oriented_architecture



An interesting method to design and develop components is outlined in [48] The method called KobrA uses Unified Modelling Language (UML) as primary model-based notation for all analysis and design activities and draws its ideas from many contemporary object-oriented and component-based methods.

Developed by the Fraunhofer Institute for Experimental Software Engineering in Kaiserslautern, Germany

promotes component reuse and follows the principles of modularity, encapsulation, unified functions and data, unique identities, and incremental development. The design/development cycle for KobrA is shown in Figure 24 and considers the following dimensions and stages:

• Composition/decomposition dimension. Decomposition follows the well-established “ divide-and-conquer” paradigm, and is performed to subdivide the system into smaller parts that are easier

to understand and control. Composition represents the opposite activity, which is performed when

the individual components have been implemented, or some others reused, and the system is put together.

• Abstraction/concretization dimension. This is concerned with the implementation of the system and a move toward more and more executable representations. It is also called embodiment, and

it turns the abstract system represented by models that humans can understand into representations that are more suitable for execution on a computer or CPS.

Therefore, the KobrA generic lifecycle starts from decomposition stage, where the necessary elements

(boxes in the figure) of an application and/or digital artefact (digital artefact decomposition) and their functionalities are identified and specified. The result of the decomposition is a set of specifications that

provides abstract description – i.e. without any relation to the specific technology to be used – of these elements and required interfaces between them. During the embodiment stage the specifications are implemented and the generated code is deployed in real hardware. Finally, during the composition and validation stages all the deployed elements and their related functionalities are put together and the overall

behaviour of the digital artefact (digital artefact composition) is validated.

Figure 24 – KobrA method life cycle



6.2.4 Methodology for creating MANTIS-enabled CPS: applying the PRIME and IMC-Aesop approaches

The MANTIS virtualization methodology for creating MANTIS-enabled CPS has been proposed as the

reference process for enabling the virtualization of physical entities and the subsequent integration within

the MANTIS overall platform. It consists of three main macro-activities or stages, namely:

1. Physical Entity Characterization and Native Interface Implementation: during this activity/stage the physical entity that has been selected for virtualization is characterized through the analysis of the system requirements, application scope, system documentation (electrical, automation,

process and instrumentation diagrams, etc.) and data availability (data provided by the physical entity that could potentially be integrated into the MANTIS platform). The information gathered

during this activity/stage is also used to implement the communication channel, i.e. to enable the extraction and provisioning of data from/to the physical entity (implementation of the physical entity native communication library). Since the physical entities can widely vary in terms

of supported communications hardware and software and no uniform standard for all device types can be defined, several categories of device communication need to be considered (also considered in PRIME and IMC-AESOP projects):

a. Proprietary Remote Adapter: Even though on some physical entities have standard

network interface, the access to their own internal functions and data can sometimes only be established using specific adapters or drivers, usually obtained from the device vendor. To integrate such a device within the MANTIS platform, the specific adapter or driver needs to be interfaced with the cyber entity. The cyber entity will effectively open a network connection and starts a proprietary protocol. In this scenario the cyber and

physical entities are deployed on distinct machines and a communication channel between these machines is created. The communication channel can be established by using two

very popular approaches, namely: i. Client/server model: where physical entities are exposed by a client/server

standard communication library instantiated and used within the cyber entity. ii. Event-based model: where physical entities are publishing events on a specific

topic that are consumed within the cyber entity. The final result will be a specific MANTIS-enabled CPS that provides a standardized communication with all the other digital artefacts within the MANTIS platform in the

cyber space and hardware-specific communication with the physical entity. b. Proprietary Local Adapter: physical entities ship with a runtime system and specific drivers

for communication. The behaviour is very similar to the proprietary remote adapter, except for the difference that the communication channel is open locally and not remotely

over a network connection (e.g. a soft-PLC, raspberry PI, etc.). In this scenario, the physical and cyber entities are deployed on the same machine.

c. OPC-UA/DPWS/CoAP/MQTT native physical entities: physical entities provides

natively support to several communication standards such as OPC-UA, DPWS, CoAP, MQTT, etc. According to the specific technology selected to implement a MANTIS-

enabled component it could be necessary to create translators and adapters to enable integration and interoperability of such CPS within the MANTIS platform. As an example if the MANTIS platform will be implemented by selecting DPWS as reference technology for communication then it will be necessary to create MANTIS translators and adapters

for OPC-UA enabled cyber-physical systems.

2. Cyber entity design and integration with physical entity: during this activity/stage the cyber entity is designed and implemented. The cyber entity interacts – from one side – with the physical world by using the native communication library and – from the other side – to the cyberspace (MANTIS platform) through the machine-to-machine technology over the network.

In this scenario, communication aspects are also considered such as protocols, message exchange



patterns (MEPs), semantic data representation and exchange, in order to find the most suited technology to apply, etc.;

3. CPS deployment: during this activity/stage the implemented CPS (cyber entity plus native

communication library to realize synergies between physical and cyber) is deployed and ready to

be used within the MANTIS platform.



Figure 25 – MANTIS Methodology for creating MANTIS-enabled CPS



Therefore, the methodology focuses on how to virtualize physical entities for creating MANTIS-enabled CPS. Particularly, it is grounded on the initial analysis of all the relevant documents of the physical entities as the foundation to practically realise a CPS. The methodology also supports the reengineering activity

of both physical and cyber entities, i.e. a change in data requirements – new and/or distinct data required

by MANTIS platform digital artefacts – are transformed into new configurations for cyber entities that in turn mean a new parameterisation of the data extraction process or in other word for the native communication library.



6.3 Event-based Ontology for Systems Interactions within the MANTIS Service-based Platform

Significant actions, incidents or episodes need to be registered and stored in any system such as MANTIS

platform that promotes monitoring or data analysis for performance improvement. Those events store data relevant to the entities related in the process (e.g. temperature of a surface) but additionally must collect both spatial and temporal information and associate them to entities/measures (e.g. Cyber Entity

controlling rolling sheets/temperature). Events might be triggered and/or should be created after one of these situations:

• Sensor reading

• Operational action

• Breakdown

• Maintenance action

• ….

The Semantic Web is an extension of the Web, in which information is given well-defined meaning, better enabling computers and people to work in cooperation. As the Web enables linking documents with each

other, the Semantic Web tries to do the same with data (interlinking of data). An ontology is a formal naming and definition of the types, properties, and interrelationships of the entities that exist for a particular domain. The Semantic Web creates ontologies to limit complexity and to organize information. The ontology can then be applied to problem solving. The reason behind an Event-based or Event-oriented

ontology or data model in this case is that the ontology will help us on building information systems that support events as the unit of analysis/modelling/visualization explicitly and will enable interlinking of data and automatic machine data processing. Also, as stated before, this will add support for systems

interactions at both edge and platform levels

There can be different perspectives for its application. This document focusses on events from a Situational

Awareness and a Decision Support Perspective. In particular, the approach applied within MANTIS is to extend the MANTIS reference architecture with an event information and processing model that will allow the definition of a hierarchy of events produced/consumed inside the MANTIS platform.

6.3.1 MANTIS CPS Event Processing Model

The event processing model is shown in Figure 26.

Figure 26 – Event Processing Model [49]

The event processing system is composed of three major components, namely: the 'Simple Event Generators', 'Complex Event Generators' and 'Event Consumers'. The simple event generators create simple events from information that enters the event processing system. This information is provided by external information sources and/or data provider. These data providers may be sensing devices that measure environmental states like temperature, pressure or smoke density, or they may be external

applications like banking systems or other systems. In the context of MANTIS, the external data providers



are all fused in a CPS that thus will be responsible to gather the information from physical entities (that are monitoring the environment) and eventually to generate/send events to an event processing system.

Any simple event created may be either directly consumed by an event consumer or may be input for a

complex event generating component. In the first case the event leaves the event processing system and

is further processed outside. Nevertheless, the event consumer may be an external information source to the event processing system itself.

In the second case the simple event is together with other simple or complex events input to a complex event processing component. This component creates complex events from its input events. The generated

complex events may be consumed by an event consuming component or they may be input to another complex event generating component.

6.3.2 MANTIS CPS Event Information Model

Figure 27 – MANTIS Event Information Model (based on the IoT-A event information model [49])



The Figure 27 gives an overview of the event model. It shows a class hierarchy diagram in UML notation that defines the type hierarchy of the event model. Base type of all events is the Abstract CEP Event type (where CEP stands for Complex Event Processing) which is abstract and defines some basic

information that must be contained in any instance of any other event type or object (e.g. DateTime, EventDescription, MeasurementLocation). The classes DateTime and MeasurementLocation are defined to adhere to the OSA-CBM standard (the same is for the UUID type). There are only two other event types in the model that are directly derived from Abstract CEP Event. These are Simple CEP Event, that contains atomic event information and Complex CEP Event that contains information derived by a

complex event processing application. The model provides a generic specification of the event-based ontology upon which MANTIS platform will be built on. The model is the same as the one defined in the context of the IoT-A project. This model has been considered generic enough to enable the description of

any event within the MANTIS platform. Therefore, within MANTIS we decided to adhere to the IoT-A

event reference model which allow the creation of two types of events. The Value Container, Value and MetaData classes are used to model the content of each event that in turn can be as simple as a temperature value to complex string with serialized java objects.



6.4 Message Exchange Patterns within the MANTIS Service-based Platform

The definition of the most suited MEPs – in the context of distributed computed – is a typical problem. MEPS refers to the way messages are exchanged between distributed components. In the context of

MANTIS three type of MEPs are considered, namely:

Push/Fire-and-forget: messages are sent between digital artefacts and between digital artefacts

and CPS. The sender sends the message and the receiver receives the message and ends the message exchange activity;

Request/Response-Reply: request/response messages are sent between digital artefacts and

between digital artefacts and CPS. The sender sends a request message and the receiver receives

the message and informs the sender with a message response;

Publish/Subscribe: messages are sent between digital artefacts and between digital artefacts and

CPS in the form of events. The event source publishes a topic and all the digital artefacts and/or CPS that are interested to the topic subscribe to it and will receive events;

Advanced Message Queuing Protocol (AMQP): messages are sent between digital artefacts and

between digital artefacts and CPS by using a message-oriented middleware paradigm.

The information model that supports the different MEPs in MANTIS is shown in Figure 27.

6.4.1 Push/Fire-and-forget

This kind of pattern considers the case where the integration of several applications with the role of sender cannot be affected by the non-availability of the receiving application (see Figure 28).

Figure 28 – The Push/Fire-and-forget MEP

The Push/Fire-and-Forget involves two parts:

The Originator initiates the conversation by sending a message.

The Recipient receives messages.

This mechanism is the simplest form of all conversations, in fact there is no interaction but it is the most efficient system to send messages, it can be completely decoupled from the recipient it does not need to know anything regarding the recipient. Furthermore, this mechanism does not require the originator to wait until the message is delivered to the recipient and it converts it into a highly scalable message system.

Although this pattern is a very efficient message system it has several limitations. Firstly, it is a messaging

system where there is no conversation state to be taken care of in the design of the system architecture. Secondly, there is no error handling, this leads to a situation where if the recipient is unable to process a message due to invalid or corrupt data there is no possibility to recover from this situation sending

feedback to the originator. Finally, the system has to use guaranteed delivery or be content with best effort delivery. In order to improve some of the lacks of this pattern, it is possible to introduce additional



elements. One of these elements is the Broker/Router which performs additional and complementary tasks as previously explained.

The use of a broker can provide more reliability to the message system taking into account that the

originator has not possibility to receive any kind of acknowledgement. Furthermore, the broker can check

and correct the information and it has the capability to enrich the information.

6.4.2 Request/Response-Reply

This kind of pattern is one of the basic methods [50] that systems use to communicate with each other. In this kind of communication System A (Consumer) sends a message to System B (Provider) and the

last one responds to the request (see Figure 29). This pattern of communication has the following features:

The channels are unidirectional.

It utilizes two asynchronous Point-to-Point Channels.

It separates request and reply messages.

Figure 29 – The Request/Response-Reply MEP

In this pattern the system in charge of performing requests has its own reply queue, but the system in charge of sending the replies must know the destinations. In this situation, there are two alternatives:

1. Send the reply to all systems (consumers). See Figure 30.

Figure 30 – The Request/Response-Reply MEP with multiple consumers

2. Hard code the consumers in the producer; this approach violates the principle of context-free service.

MANTIS requires to overcome these limitations and to provide a more flexible and efficient request-reply

pattern, furthermore it is expected to have advanced features such as to have more than one provider for



the consumers or a specific control of the sequence of messages. With this aim in mind an improved request-reply pattern should be used with the following features:

Multiple service providers. Each request message can be consumed by more than one service

provider.

Support of Competing Consumers, that is, only one service receives each request message.

Channel queues up pending requests.

Consumer identifiers. These will specify a Return Address in the request message.

Service provider will send a reply message to specified channel.

Correlation identifiers. That is, each message will contain a unique identifier and the provider will

copy the ID in the reply message. In this way consumer can check the request and response.

Blocking and non-blocking replies. Depending on the relevance of the context a reply can involve to block a consumer until receiving the answer before continuing with other operations.

These advanced features are represented graphically in Figure 31.

Figure 31 – The Request/Reply/Response MEP with multiple consumers and advanced features

On the other hand, additional features associated to message channels can be required such as:

Shared message queues. Although each consumer utilizes its own channel sometimes an additional

and special queue is required under special situations such as errors or failures in specific systems.

Broadcast message. This kind of channel can be used to notify special events which affect to all

providers.

Finally, with the aim of providing more reliability and enriching the information a new element is typically

used in this kind of paradigms, that is, the broker or router. This element has an important role for empowering the message system architectures and performs different tasks. Firstly, it routes the messages to the correct endpoint, the broker can perform this task by using different criteria such as the content,

the destination (typically a web service), or any complex combination of different criteria; it works like a network router. The routing of the messages is based on a typical rule based system, where each rules is checked in order to decide the most suitable destination (see Figure 32).



Figure 32 – The Broker-based MEP

Secondly, the broker performs some pre-processing tasks with the aim of cleaning and purifying the information. Finally, sometimes the broker can enrich the information by supplementing additional

information regarding the process; this facilitates the processing of the information by the destination.

In summary, the use of this pattern jointly with the inclusion of brokers suits very well in many processes of MANTIS such as the re-learning of machine learning models or control models. In these cases, the

costliest work is performed in the learning phase and the system must wait until a new model is created, this can be synchronous or asynchronous. Depending on the criticality of the model, MANTIS can impose a synchronous exchange because the previously model is failing and providing poor results or wait until the new model is created because the model is working but it requires some improvements.

6.4.3 Publish/Subscribe

The publisher / subscriber pattern is a communication paradigm ([51], [52]) that connects data producers (publishers) with information consumers (subscribers). A publisher element publishes data that are of

interest to other elements called subscribers. A publisher can also be subscriber of data published by other

elements. As shown in Figure 33, a publisher generates its data without explicitly specifying recipients or having knowledge of intended recipients. Every subscriber (interested in a topic) will receive the data generated by the publishers of a topic.



Figure 33 – Publisher/Subscriber overview

This is widely applied paradigm in the design and development of distributed systems as it allows the

elements (publishers and subscribers) are weakly uncoupled and need not know each other.

Within this approach, it is important to mention the OMG standard named “ Data Distribution Service for Real-Time Systems” (DDS) 26; DDS is a M2M middleware standard that aims to enable scalable, Real-time, dependable, high performance and interoperable data exchanges between publishers and

subscribers. OMG DDS is a data-centric middleware based on the schema / structure of "data-in-motion".

The schemas (topics) are explicit partitioned the overall space into logical data-streams (i.e., instances) of data that have an observable lifecycle. DDS DataWriters (belonging to the publishers) and Data Readers (belonging to the subscribers) are used in DDS applications endpoints to write and read data typed messages (DDS samples) from the overall data space, respectively. In this standard, Dissemination is

driven by QoS (Quality of Service) policies associated with DataWriter, Publisher, and Topic.

Figure 34 – Publisher/Subscriber in DDS

Currently there are commercial applications implementing the DDS Standard such as open-source tools. DDS has been a niche technology (defense, space) that is already being used in other scenarios: Driver

Assistance, CAE Flight Simulator, Air Traffic Control, Digital On-Demand Harmonic TV, High-Speed

Financial Trading, Advanced Telescopes.

26 OMG. The Data Distribution Service specification, v1.2. http://www.omg.org/spec/DDS/1.2, 2007



Focusing on the cloud platform site, such Publisher-Subscriber pattern it may also be required. One possible point where it can be applied is in the reception of the messages that reach the cloud from plants / machines and they should be distributed to the cloud-based components responsible for data storage

and/or analysis. The following figure shows the application of this distribution pattern right data at the

point of arrival of input data to the cloud; data distribution is responsible for routing the recipient concerned.

Figure 35 – Publisher/Subscriber in the cloud platform

6.4.4 Advanced Message Queueing Protocol

The usage of Message-Oriented Middleware (MOM) has become a useful paradigm when working with Service Oriented Architectures. In this sense many developments have been created aligned with this idea but with a lack of interoperability, as an answer to this problem a new standard is defined. This

specification is known as Advanced Message Queuing Protocol (AMQP)27, this protocol aims to create interoperability between clients and brokers and to be able to standardize enterprise messaging. This standard defines many features involved in message systems such as message orientation, queuing, routing, reliability and security. It has become the reference of existing reference MOMs such as ActiveMQ28,

RabbitMQ29 and Apache Kafka30.

This standard has originated the creation of several initiatives such as ActiveMQ or RabbitMQ which provide open source implementations of AMQP with the aim to facilitate the deploying of AMQP as a standard mechanism in SOA architectures. ActiveMQ is perhaps one of the most popular and powerful open source implementation of AMQP, it provides enterprise features and support of many different

languages whereas RabbitMQ is considered a leading implementation of the AMQP. It implements broker

27 https://www.amqp.org/

28 http://activemq.apache.org/

29 https://www.rabbitmq.com/

30 https://kafka.apache.org/



architecture, very easy to use and deploy and providing advanced features such as routing, load balancing or persistent message queuing. Finally, Kafka is a distributed messaging system written and used by LinkedIn for page processing. The big advantage of Kafka when compared to ActiveMQ and RabbitMQ

is its speed and the very low overhead and footprint (see Figure 36 and Figure 37).

Figure 36 – Producer/Consumer performance comparison [53]

Figure 37 – Throughput performance comparison [54]

In Kafka, topic messages are written among different partitions to improve the performance. These partitions act as a queue mechanism where producers put messages in a sequential order identified by a numerical id called offset. In this way, different consumers can select from where to start to read messages being able to store the offset to recover the messages order in case of failure (See the Figure 38 and

Figure 39).



Figure 38 – Kafka Partitions

Figure 39 – Kafka Offset

To be fault tolerance, Kafka can also be configured establishing a retention period which determinates how much time the messages are stored in the queue. Another key configuration parameter is the

replication factor which established how many times the messages are duplicated.

As programming languages is concerned, the Kafka project only provides support for java. However, the most important programming languages offer their own APIs to communicate with Kafka. Thus, interoperability among different applications coded in diverse platforms is guaranteed. Therefore, Kafka can be a good candidate to provide a communication mechanism among the different components.

Additionally, due to the interest raised by Kafka more and more connectors are being developed to integrate Kafka with different technologies such as relational and NoSQL databases or real time processing

systems like Spark streaming or Apache Storm31.

In MANTIS the use of message-oriented middleware occupies a central role in many scenarios as previously

cited and it is therefore a key element. The selection of the specific technology strictly depends on requirements about system performances.

31 https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem

https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem



6.4.5 Data-Flow Technologies Supporting Different Message Exchange Patterns

In the last years various data-flow technologies have emerged to work with stream data allowing the connection of different software pieces that can be computed independently and in parallel. A key benefit

of this approach is the use of different connectors provided for linking specific technologies, making them interoperable and compatible.

An example of this type of technologies is Apache Flume32 which claims to collect, aggregate and move

larger amounts of log data from different data sources to a centralized data store in a distributed and reliable way by using stream data flows. Another example is Apache Camel33, an enterprise integration pattern tool where, as the definition indicates, a big number of different patterns are integrated34. Apache Camel enables to connect the inputs and outputs of various technologies being compatible with diverse

transport and messages models as HTTP, ActiveMQ or JMS.

The rest of the section is dedicated to Apache NiFi since it provides an easy to use user interface and a vast number of connectors. Therefore, it is posed as an excellent candidate to satisfy Mantis requirements due to their interoperability support and usability.

6.4.5.1 Apache NiFi

Apache NiFi35 is a technology created by the NSA which provides support for processing and distributing data. NiFi is a high level tool that enables the easy creation of data-flows by integrating a big quantity of connectors (currently 188) to other technologies, called processors. These processors are extremely flexible allowing a wide variety of configurations to create rich data-flows. An example of the configuration of a NiFi processor to create an HTTP request is presented in the Figure 40.

Figure 40 – NiFi processor configuration example

32 https://flume.apache.org/

33 http://camel.apache.org/

34 http://camel.apache.org/enterprise-integration-patterns.html

35 https://nifi.apache.org/



In addition, NiFi is a scalable technology which uses Apache Zookeeper36 to provide a cluster solution and provides a mechanism for guaranteeing the message delivery by using a content repository. Moreover, different instances of NiFi can communicate among them. A common strategy is to put in the edge level

a light instance of NiFi limiting the preprocessing workload and a more powerful instance with the majority

of the workload in the platform.

As interoperability is concerned, internally NiFi uses flow-files, a structure designed to represent the objects that navigates among the different processors. In order to interoperate with other technologies, NiFi implements a large number of protocols such as TCP, HTTP and data formats as Apache Avro37 to

guarantee the interoperability. Therefore, NiFi provides a number of implementations for the communication patterns previously exposed as well as providing more complex tasks that can be useful in the context of the Mantis project, such as data preprocessing or store information in a distributed file

system.

The pattern Push/Fire-and-Forget can be implemented by using the default communication among processors where once a processor receives data-flows perform its specific task and redirects the output to the following processor. Moreover, specific processors use this pattern for receiving external streams of data such as the listenHTTP processor. In addition, input and output ports can be configured to communicate groups of processors using this communication pattern (see Figure 41). It is worth

mentioning that this configuration can be modified by selecting a different alterative related to the nature of the processor, for instance, in a processor that executes queries to a database the possible strategies are Event driven, Timer driven and CRON driven.

Figure 41 – NiFi Pubsh/Fire-and-Forget pattern

Request/Response-Reply is a common pattern that is implemented in various processors. For example, the database processor that queries a database (request) and wait for the results (response). A particularly

clear implementation consists in the use of two processors (HandleHttpRequest and HandleHttpResponse) which implement a server mechanism for performing an HTTP request and returns an HTTP response after executing certain processors (see Figure 42).

36 https://zookeeper.apache.org/

37 https://avro.apache.org/



Figure 42 – NiFi Request/Response-Reply pattern, Publish/Subscribe pattern and Andavanced Message Queuing Protocol

The patterns Publish/Subscribe and Advanced Message Queuing Protocol, as previously mentioned, are implemented by technologies such as RabbitMQ, ActiveMQ or Kafka. NiFi provides support through

various processors to provide support to these technologies. Concretely, there are processors for publishing

and consuming from JMS using ActiveMQ (see Figure 42), generic processors called ConsumeAMQP and PublishAMQP and six specific Kafka processors for consuming and publishing messages from Kafka. Additionally, there are also processors for publish and subscribe from brokers using the MQTT38 which

could be useful for the interoperability of the Mantis Cyber Entities. The Figure 43 illustrates an example where a Kafka publisher publish data from two different data sources, a database and a HTTP service listening for requests, then there are four different Kafka consumers that routes the data obtained to different processors.

Figure 43 – NiFi Publish/Subscribe pattern and Advanced Message Queuing Protocol by using Apache Kafka processors

38 http://mqtt.org/



6.4.6 Message Exchange Patterns Model for MANTIS-enabled CPS

6.4.6.1 Message Exchange Patterns and protocol translation: applying the Arrowhead approach

6.4.6.1.1 Message Exchange Patterns translation

The selection and usage of a message exchange pattern can affect the way digital artefact should be implemented in order to be interoperable. As shown in Figure 44, digital artefacts – implemented by using one of the presented message exchange patterns – are not capable to communicate, i.e. to exchange

data. It means that to be interoperable digital artefacts need to agree on a message exchange pattern or, in other words, digital artefacts need to support natively the defined message exchange pattern Figure 45. Another interesting approach and strategy that can be used when dealing with distinct and heterogeneous

digital artefacts relies on the provisioning of converters to enable translations between one message exchange patterns to another. This is the approach used in the scope of the Arrowhead project where

interoperability between digital artefacts that rely on different message exchange patterns is based on the development of converters (see Figure 46).

Figure 44 – Digital artefacts are not interoperable if a common message exchange pattern is used



Figure 45 – Digital artefacts are interoperable if a common message exchange pattern is defined between them

Figure 46 – Applying the Arrowhead approach for message exchange pattern conversion

As an example of application of the Arrowhead approach the following scenario are considered:

Translation between Request-Reply and Publish/Subscribe message exchange patterns;

and translation between AMQP and Request-Reply message exchange patterns.



Translation between Request-Reply and Publish/Subscribe message exchange patterns

Figure 47 – RR-PS MEP conversion

Translation between AMQP and Request-Reply message exchange patterns

Figure 48 – RR-AMQP MEP conversion considering different technologies



6.4.6.1.2 Protocol translation

The types of digital artefacts and/or physical entities and related resources that can be found within the MANTIS platform are:

New digital artefacts/physical entities: these are supposed to be natively MANTIS platform compatible. It means that a physical entity is already enhanced by a cyber-part.

Legacy systems: digital artefacts and/or resources that are already installed and deployed but do

not provide any mechanism to allow integration within the MANTIS platform.

o Those that can be changed

o Those that cannot be changed (see next Figure 49). It would be the worst case scenario

and external adapters are required.

Figure 49 – Adapter-based approach to enable integration of data providers (i.e. other digital artefacts or physical entities)

If protocol A (data provider native protocol) or protocol B (data provider native protocol) are used, it is

required to (see Figure 50):

generate a converter for each pair of protocols

decide which to use (A or B?). It depends on which provides better QoS (speed ...), security;

If another protocol Z is used (always the same Z):

each producer/consumer just need to develop a converter to ensure interoperability;

Z must provide the desired QoS, security, …, otherwise A and B cannot interact;

Z must be versatile;



Figure 50 – Adapter-based approach to enable integration of data providers (i.e. other digital artefacts or physical entities) protocol identification

If protocol A is the same as protocol B but different from protocol Z then the messages must be packed into Z, the messages are sent by using Z and finally messages are unpacked within each MANTIS adapter. Thus, converters should provide interfaces to the common protocol and to the native protocol (see Figure 51).

Figure 51 – Protocol P conversion

Finally, another class of converters are the semantic converters that can be used for extracting context

information from the events to be stored in the platform semantics for maintenance purposes.



6.5 Semantic Data Representation and Exchange

The semantic data representation and exchange is aimed to describe the structure of all the data and/or information handled by cyber entities at a network level. It means that once a physical entity is virtualized,

the related cyber entity should be designed and developed to cope with the semantic data representation and exchange model. As a matter of fact, once a link between physical and cyber entity is created the

data extracted from the environment should be organized and structured within the cyber entity in order to be transmitted to other digital artefacts within the MANTIS platform. Thus, the provided model details the way information should be modelled inside the cyber entity of a CPS and represents a necessary condition to guarantee that all the data circulating within the MANTIS platform cyberspace satisfies a

well-defined structure to assure interoperability between different digital artefacts.

6.5.1 Semantic Data Representation and Exchange Model for MANTIS-enabled CPS

Figure 52 – Interoperability Semantic Data Representation and Information Exchange Model for MANTIS-enabled CPS

The Figure 52 shows how the information should be structured and – thus – handled and processed in CPS-based system that are MANTIS-compatible. The provided information model is inspired from the IoT information model designed and developed in the scope of the IoT-A project. The obvious similarities



between IoT and CPS-based systems are always pushing a merging of the two research streams. The explanation of the model is extracted from [55].

The main aspects are represented by the elements Cyber Entity, Functionality Description and Association.

A Cyber Entity is the cyber counterpart of a Physical Entity and the Functionality Description describes

the set of functionalities Cyber Entities are sharing within the virtual space. Actually, a functionality can be mapped to a service if the SOA technology is used or a skill/capability in a multi-agent system (MAS). The Association is used to establish the connection between the Attribute of a Cyber Entity and the Functionality Description. As an example, for a temperature sensor a Functionality could be the

“ getTemperature” function that provides information about the temperature Attribute value. A Cyber Entity can have zero to many different attributes (Attribute). Each Attribute has a name (attributeName), a type (attributeType), and one to many values (Value Container). The attributeType specifies the

semantic type of an attribute, for example, that the value represents temperature. It can reference some

ontology concepts. This way, one can for instance, model an attribute, e.g. a list of values, which itself has several values. Each Value Container groups one Value and zero to many Metadata that belongs to the given Value. The Metadata can, for instance, be used to save the timestamp of the Value, or other quality parameters, such as accuracy or the unit of measurement. The Cyber Entity is also connected to the Functionality Description via the Functionality Description – Cyber Entity association. A Functionality

Description describes the relevant aspects of the functionality provided. Additionally, it may contain one

(or more) Resource Description(s) describing the Device accessed by the Resource. Finally, the Resource Description might contain information about the Physical Entity.

6.5.1.1 Mapping Between MANTIS and IoT-A Information Models

In order to allow the easy translation of the IoT-A information model into the MANTIS information model

the Table 3 has been created. The Table 3 presents the mapping between the concepts of the MANTIS

information model and their counterpart in the IoT-A information model.

Table 3 – Mapping between MANTIS and IoT-A information models concepts

MANTIS information model concepts

IoT-A information model concepts

Further comments

Cyber Entity Virtual Entity Please see section 6.2.2.1.

Functionality Description Service Description Describes the functionality associated to the Cyber Physical System. As described in section 6.2.2.1, the idea to consider functionality is to have a more generic approach.

Resource Description Resource Description

Physical Entity Description Device Description

Data Source n.a. In MANTIS each Cyber Physical System is a provider of data that are going to be used for maintenance purposes.

Attribute Attribute

Value Container Value Container

MetaData MetaData

6.5.1.2 Value Concept Specification

The concept of “ Value” within the MANTIS information model is a generic string and can be used to contain simple information like the value of a temperature (25) as well as very complex information like



java serialized object in a format like JSON or XML. The information included in the “ Value” concept is specified and explained by using the “ MetaData” concept.

6.5.2 Semantic Data Representation for MANTIS using MIMOSA

MIMOSA's Open Systems Architecture for Enterprise Application Integration (OSA-EAI) specifications connect the separate islands of engineering, maintenance, operations, and reliability information to one

entity. In MANTIS the focus is on the maintenance domain considering the devices and systems object of that maintenance but also the context related those components that influence their behavior. MIMOSA representation of the maintenance domain is considered semantic because not only measurements are

registered and collected. Plant representation (enterprise, systems, components, sensors …), events,

maintenance information and other related systems information are also accountable. For example, a component behavior can be analyzed at platform level considering the information provided by several sensors attached to it, the results collected from Manufacturing Execution Systems (MES) and the cost of energy associated to it. In order to consider all these parameters and systems, the relation of that component with other elements of the enterprise is necessary. Further, information about its condition

can also be calculated and taken into account. It might be necessary to know which is the Remaining

Useful Life (RUL) of that component at a given time or under some conditions (event). MIMOSA OSA-EAI enables the representation of those elements and its relations. MIMOSA database permits the storage of that representation along with the values or measurements and their relations to certain events.

The MIMOSA OSA-EAI specifications are extensive and in MANTIS only a set of models have been taken into consideration, mainly for system of system representation, events registry and for maintenance purposes.

Figure 53 – Interoperability Semantic Data Representation of Plant information for MANTIS (I)

+enterpriseUIC : long(idl)

+userID : string(idl)

Enterprise

+siteID : long(idl)


+templateYN : boolean(idl)

Site

1

+Controls*

+stTypeID : long(idl)


+mobile_YN : boolean(idl)

SiteType

*

+Classified as

1

*

* +enTypeID : long(idl)


EnterpriseType

*

+Classified as

1

1

+Registers*



Figure 54 – Interoperability Semantic Data Representation of Plant information for MANTIS (II)

+siteID : long(idl)


+templateYN : boolean(idl)

Site (Enterprise Registration Entity)

+segmentID : long(idl)


Segment

+sgTypeID : long(idl)


SegmentType

+databaseID : long(idl)


Database

1

+Registers*

1+Maintains *

*

+Composed of*

*

+Classified as

1

*

+Has Child Type(s)*

0..1 *

*

+Maintains 0..1

+Functionally Equivalent To

0..1

0..1

Model



Figure 55 – Interoperability Semantic Data Representation of Plant information for MANTIS (III)

Figure 53 to Figure 55 shows how the information is structured to represent a plant. The main entities in the models for plant information are:

Enterprise – the corporate level of an organization, or the top organizational structure of a non-profit or military body. Each Enterprise is associated with exactly one Enterprise Type. An enterprise uniquely

registers/births Sites and may control one or more Sites (which could have formerly been controlled by other enterprises). In order for multiple enterprises to exchange MIMOSA information, every Enterprise must request and utilize its unique, unchanging MIMOSA-assigned Enterprise Unique Integration Code (Enterprise-UIC).

Site – an enterprise-defined object (manufacturing plant, facility, fleet platform object). Each Site is associated with exactly one Site Type. Sites uniquely register/birth Segments, Assets, Agents, Databases, and Measurement Locations. For facility applications, the “ Site” can normally represents either the “ as-designed” model of a building or the “ as-built” building. For industrial and manufacturing applications, this entity normally represents the “ as-designed” model of a physical plant or the “ as-built” tangible

plant. For fleet applications, this entity normally represents the “ as-designed” model of a “ mobile platform” (truck, vehicle, aircraft or tank) or the “ as-built” tangible platform. Each Enterprise uniquely

assigns every Site its unique, unchanging Site Unique Integration Code (Site-UIC).

Segment (Functional Area Entity / Breakdown Structure Entity): Associated with a Model – as-designed

functional area or breakdown structure entity for a Model. Each Model-associated Segment is associated with exactly one Segment Type. These segments would normally appear on the engineering drawings of the model. The Segment can be decomposed into one or more Segment Child Structures, which are child Segment functional locations inside the parent Segment. The Segment can have multiple Segment

+assetID : long(idl)


Asset

+asTypeID : long(idl)


AssetType

+manufID : long(idl)


Manufacturer

+databaseID : long(idl)


Database

1

+Registers*

*

+Model of

0..1

1

+Maintains *

*

+Composed of*

*

+Maintains

0..1

*

+Classified as1 *

+Belongs to Class1

+Functionally Equivalent To

0..1 0..1

*

+Manufactured By0..1

ModelSegment

Site



Network Structures defined. A Model-associated Segment can have as-designed Measurement Locations. Associated with an Asset – as-built/as-maintained functional area or breakdown structure entity for a serialized Asset. Each Asset-associated Segment is associated with exactly one Segment Type. These

segments might initially be identical to the Model's Segments, but may be changed to be unique for this

particular Asset. The Segment can be decomposed into one or more Segment Child Structures, which are child Segment functional locations inside the parent Segment. The Segment can have multiple Segment Network Structures defined. An Asset-associated Segment can have as-built/as-monitored Measurement Locations. An Asset-associated Segment can have serialized Asset component parts installed over time,

tracked by Asset Utilization History. Associated to other Segments in a Network -- see Segment Network Structure

Asset – a tangible, instantiated, serialized object. An Asset may be an entire facility, an entire functioning

platform (such as a CH-47 Tail Number XYZ helicopter), or a component piece of equipment, such as a

specific instance of a bearing. Each Asset is associated with exactly one Asset Type. An Asset can be associated with a top-level Segment which defines its internal as-built/as-maintained functional segment structure. A component Asset may be installed on/at a Segment over a period of time (asset tracking). An Asset can be monitored via Measurement Locations, be associated with work, and may be composed of one or more Asset Child Structures. When first referenced in a MIMOSA-compliant system, an

origination Site permanently assigns an Asset an Asset Unique Integration Code.

The explanation of the models is extracted from [56], [57]. For detailed information on the standards refer to those references.



Figure 56 – Interoperability Semantic Data Representation of Asset Data

Data measurements can be associated to assets, segments, networks, etc. The measurements associated with an asset follow the model presented in Figure 56. Asset Data represents data related to an asset. MIMOSA defines 3 types of asset data: numerical data, alpha-numeric character data and BLOB data. Different implementations may be used in MIMOSA for character, bit patterns, encoding and numbering

schemes. MIMOSA does not impose any particular implementation.

Asset

+value : string(idl)

AssetCharacterData

1

-Is Topic Of*

+asCharDataTypeID : long(idl)


AssetCharacterDataType

-Classified as

1

*

+refUnitTypeID : long(idl)


ReferenceUnitType

-Default type of 0..1

*

+engUnitTypeID : long(idl)

-userID : string(idl)

EngineeringUnitType1

-References

*

-With units of

1

*

Database

1

-Maintains*

1

-Maintains *

+value : double(idl)

AssetNumericData

1

-Is Topic Of*

+asNumDataTypeID : long(idl)


AssetNumericDataType

-Classified as

1*

-Default type of

0..1

*

1

-Maintains*

+value : object(idl)

+name : string(idl)

AssetBlobData

1

-Is Topic Of*

+blobDataTypeID : long(idl)


BlobDataType

-Binary type of

1

*

+blobContentTypeID : long(idl)


BlobContentType

-Content type of

1

*

-With units of

1

*

1

-Maintains

*1

-Maintains*

1

-Maintains *

+purchCondTypeID : long(idl)


PurchaseCondType

+asReadinessTypeID : long(idl)


AssetReadinessType

*

-Current Readiness

0..1

*+Readiness When Purchased 0..1

*

+With Condition

0..1

1

-Maintains

*

1

-Maintains

*

Site

+gmtPurchased

AssetOwner

*

*+Owned By



Event information about measurements, assets, segments and other plant elements is also modelled in

MIMOSA. In MANTIS, events are associated to measurements and are record at a measurement location

which has an associated time, transducer ID, and Data Quality. The event could be linked to a single numeric value of a certain type, or a group of related signal processed measurements. Events can be also

related to a segment or asset at a specific point in time or during a specific interval of time. Events can be alarms, operational changes, abnormal condition or even user define events.

Another use of the MIMOSA models is concerned with the representation of maintenance information. Failure cause effect, remaining useful life and other condition based monitoring information is represented using those models. In Mantis asset remaining life is used as an assessment of the remaining life of the

asset associated with the assessing agent, a likelihood probability, and an error estimate (+- X hrs).

Those models have been implemented in a database which tables can be consumed using a HTTP RESTful Interface developed by Lapland University of Applied Sciences, and extended by other partners in Mantis, as part of WP2 [56] JSON documents are used to interexchange data with the database through this interface. A JSON document example with information about data in blob format and related to an asset

is shown in Figure 57. Information about the event related to the data measurement is included in the document (user_tag_ident). A JSON document example with information about the remaining useful life from an asset is shown in Figure 58.

Figure 57 – Representation of Asset blob data in HTTP RESTful interface



Figure 58 – Representation of Asset remaining useful life in HTTP RESTful interface



6.5.2.1 Mapping Between IoT-A Event and MIMOSA Asset Data



7 Starting with Generic-Proof infrastructure interoperability

According to the DoW the main objective of task 2.2 is to develop specifications and guidelines for

interoperability at interface, protocol and functional levels. Such specifications and guidelines should be

used to guarantee that application specific services are always built in line with the MANTIS service platform. A first version of the specifications and guidelines have been developed and included within the deliverable D2.3 – Interface, Protocol and Functional Interoperability Guidance and Specification V1. The document provided a main description of the interoperability concept, how interoperability problems and issues are addressed in MANTIS, and – finally – the MANTIS interoperability guidance and specifications.

The second version (V2) of the deliverable D2.3 – Interface, Protocol and Functional Interoperability

Guidance and Specification named D2.7 will provide generic software implementations to be used as reference and/or “ as-is” for implementing use-case specific MANTIS architectures. These implementations are going to be used to test the guidance and specifications included in D2.3 as well as

to provide new guidance on how to apply standards and specifications to create interoperable artefacts.

To do that, the following steps will be performed:

1) Definition of a generic architecture that can potentially represent all the considered use cases

(generalization from the architectures provided in section 4.2.3); 2) Definition of the information flow, i.e. how the information should flow from CPS to cloud data

analytics algorithms and back to CPS (generalization from the architectures provided in section 4.2.3);

3) Guidance on how to virtualize physical entities into CPS: a. Technology for virtualizing physical entities: how to select?

b. Implementation of the Native Communication Library (the connector to physical entities);

c. How and Where to use the MIMOSA standard; and d. How to use the event information model and semantic data representation and exchange

model as the foundation for enabling communication and data exchange. 4) Guidance on how to use data collected from CPS within the cloud.

Figure 59 – Necessary steps to be performed to test interoperability guidance and specifications



7.1 Definition of a generic architecture as a proof of concept

Figure 60 – Generic Architecture to be used as a proof of concept



Figure 60 presents a generic architecture that has been specified and designed to be used as a generic proof of concept of the MANTIS maintenance service platform, i.e. to describe a use-case independent implementation of the MANTIS maintenance service platform. The architecture has been specified and

designed by analysing the specific architectures provided in section 4.2.3, i.e. by applying a reverse

engineering process the architectural patterns and features, as well as the information flow have been extracted, analysed and documented to create a generic scenario that can be easily adapted to the use case specific needs. The generic scenario contains some relevant results and finding from WP2 tasks such as:

Data and event models from IoT-A project, for data exchange;

Context descriptions and models derived from OSA-CBM standard;

The technology developed/used in the context of the Arrowhead project to be used as integration framework; and

The technology developed/used in the context of the IMC-AESOP project to be used for

virtualizing physical entities.

The Figure 60 shows two possible architectural patterns, namely:

1. Edge-based Architectural pattern: where CPS are not directly connected to the MANTIS cloud

and the communications of the data extracted from the physical entities to the cloud and vice-

versa – from cloud to CPS – are possible by using an edge gateway; and 2. Cloud-based Architectural pattern: where CPS are capable to connect themselves to the cloud to

push data extracted from the physical entities and to eventually receive data from the cloud services.

These two patterns summarize all the possible MANTIS use cases.

In an Edge-based architectural pattern “ high distribution” is a key concept. As a matter of fact, an edge-based architecture is intended to distribute software applications, data and services to the logical extremes of a network near to the source of the data. Technically speaking, it can be realized by using a set of web servers that manage a cluster of computers, i.e. a set of loosely or tightly connected (typically in LAN)

computers that work together to perform a certain task. Therefore, it is the most suited approach whenever there are resources that cannot be connected to the internet or whenever performance of services is a critical issue. The edge-based architectural pattern addresses the problem on how the edge architecture

should be. Also in this scenario, there are several patterns that can be used by considering the specific

application scenario. However, in the context of the MANTIS project and specifically for the generic scenario a “ Mediator” pattern – that belongs to the “ Master-Slave” main category – is used. According to this pattern, an entity is used to manage and handle the way a set of CPS are interacting (see Figure 61). This pattern promotes loose coupling by preventing direct communication between CPSs keeping the overall complexity at a low(er) level. Therefore, the “ Mediator” encapsulates the collective behaviour of

the edge. It is similar to the “ Broker” pattern – that is a large-scale infrastructure paradigm that serves

as backbone for several applications – however, the “ Mediator” pattern is suitable for smaller infrastructures and single application interactions.



Figure 61 – Edge-based Architecture: “ Mediator” pattern

In a Cloud-based architectural pattern “ centralization” of services and data within the cloud is the key

concept. As a matter of fact, a cloud-based architecture is intended to provide a share common environment for services and applications to be provisioned and used with minimal management effort. Technically speaking, cloud environments provide an infrastructure of virtual computing resources that allow users and enterprises to design, implement and use services like data storage, data processing (batch and stream processing, etc.). In the same way as the edge-based architectural pattern, the cloud itself

needs to be designed. The way the cloud is designed also depends on the specific application scenario. However, in the context of the MANTIS project and specifically for the generic scenario a “ Broker” and/or “ Middleware” patter is proposed and used. This pattern provides a complete infrastructure for highly distributed applications and it envisions the presence of an entity – “ Broker” – that is responsible

for coordinating all the communications between distributed software components and/or modules (in the context of MANTIS, CPSs) such as forwarding requests, as well as for transmitting results and exceptions (see Figure 62) [58].

In this document, the focus is not on the architecture itself that is deeply presented and explained in deliverable d2.6 – Reference Architecture and Design Specifications but it is how to create cps, how to

structure, organize and transfer the data extracted from physical entities by considering the specific architectural model and the physical entities constraints. One of the main results of this activity is the definition of a set of guidelines for enabling the design and the implementation of software archetypes that can be used as template for designing and developing specific software components/modules and/or

as “ as-is” implementations that can be used and easily integrated within specific application scenarios.

The next sections aim to help the developers in the process of designing both MANTIS interoperable CPSs and more general software components/modules.



Figure 62 – Cloud Architecture: “ Broker” pattern



7.2 Guidance on How to Virtualize Physical Entities into a CPS

A Cyber Physical System (CPS) refers to: “ the tight conjoining of and coordination between computational and physical resources” . Thus, it represents a new class of engineering systems where

cyber/virtual and physical components are deeply connected and strictly related [59].

In this context, MANTIS aims at supporting the design and development of methods, methodologies,

models and tools to expedite and accelerate the integration and usage of CPSs in a wide range of application scenarios. Thus, the design and development of CPSs is a fundamental requirement in MANTIS.

One of the defining characteristic of CPSs is the injection of cyber/virtual capability in every physical

entity, or in other words, the virtualization of physical entities into CPS. This virtualization is the first necessary step to enable CPSs networking at different scales, integration of the information at multiple temporal and spatial scales, as well as the dynamic behaviour of CPSs (adaptability, configurability, or more in general self-* properties).

7.2.1 Technology for Virtualizing Physical Entities: How to Select?

To virtualize a physical entity into a CPS one must select a framework and/or technology that can be

used to do that. There are several frameworks – based on different programming languages and paradigms (e.g. agents, services, etc) – that can be used to virtualize physical entities. To identify the optimal framework, it is best to use a formal method. By looking at the state-of-the-art, several methods have been created to define a process and/or methodology to assess the usage of a framework, or more in general, of a software. As a matter of fact, the usage of open source technology within companies or

enterprises need to be promoted by a clear gain in business strategy, IT strategy, or technical matters that support, improve or create a competitive advantage in the market [60]. This document proposes the Qualification and Selection of Open Source software (QSOS39) as the reference methodology. It is based on the following interdependent and iterative steps:

1. Define: Identify and define the evaluation criteria (e.g. functional, non-functional and technical criteria) that are to be used for assessing candidate frameworks.

2. Evaluate: Score the project and/or software (functional coverage and maturity of the project).

3. Qualify: weigh the defined criteria so that the overall assessment balances the trade-offs of frameworks based on the priorities defined by the project requirements

4. Select: compare and select the software – based on the previous steps – for possible application.

39 http://www.qsos.org/

http://www.qsos.org/



Figure 63 – General Approach of QSOS

7.2.1.1 Assessment Criteria

The first step of the selection process is the definition of the assessment criteria, i.e. the evaluation of frameworks/technologies with respect to a set of defined criteria. According to QSOS, the evaluation is made by taking into account the maturity and the functional coverage of the framework and/or piece of software grouped by axes. Therefore, the QSOS methodology relies on:

a. Maturity analysis of the considered framework/software.

b. Functional coverage analysis of the considered framework/software.

The QSOS imposes the maturity criteria (see Figure 64).

Figure 64 – QSOS maturity criteria

The functionality coverage criteria are specific to a functional and/or application domain. Table 4 shows a set of criteria that can be considered when assessing a framework/software (to support interoperability).

Table 4 – Example of criterion that can be used to assess a framework/technology (relevant for interoperability)

Criterion Description

Operating System support for both Windows and Linux?

Can the software be deployed on Windows and Linux?

Licensing: Open source or code licence available?

Is the source code of the framework fully available to be able to fix bugs or implement extensions?

Robustness: Dynamic Networking Supported?

Is the framework designed to handle the appearance and disappearance of services during runtime?



Robustness: Uptime (High system uptime?)

Can the system be run over a long period without causing problems, e.g. caused by memory leaks?

Learning Curve How familiar are the developers with the framework? How much knowledge and effort is necessary to create a single agent?

Adherence to standards Does the system support or enforce adhering to standards?

Agent/WS-* Support Support different standards for Agent/WS (Discovery, Addressing, Security, Reliability, Yellow Pages, etc.)

Support for mobile devices Is it possible to deploy implementations in resource-constrained devices?

Support for Orchestration Is it possible to compose services for creating complex ones?

Support for Semantic tags Does the framework provide already implemented semantic mechanisms

Support for distinct MEPs Does the framework support distinct message exchange patterns (MEPs)

Previous Knowledge Is there any partner in the consortium that has experience with one or more of these frameworks

System Integrators Engineering tools

Are user interface and more in general engineering tools available?

7.2.1.2 Application of the assessment criteria and Selection of the framework/software

To evaluate the selected framework/software a score needs to be assigned to the functional coverage criteria. The QSOS proposes the following discrete score:

Table 5 – Score to be assigned to the functional coverage criteria

Score Description

0 Functionality not covered

1 Functionality partially covered

2 Functionality fully covered

This score will be used in the selection step together with the weights assigned to each functionality. The weights are used to filter the selected frameworks/software. To filter between all the selected

frameworks/software maturity filters and functional coverage filters can be used (as shown in Table 6 and

Table 7).

Table 6 – Maturity Filter (to filter on the maturity of the framework/software)

Maturity Filter

Not relevant criterion

Relevant criterion

Critical criterion



Table 7 – Functional coverage Filter (to filter based on the level of the requirement)

Functional coverage Filter

Required functionality

Optional functionality

Not required functionality

7.2.2 Design and Implementation of the Native Communication Library (Connector to Physical Entities)

A virtual entity typically has two communication interfaces, one with the virtual world (cloud, edge, etc.

depending on the specific architectural model that is used) that can have multiple and distinct networking scales and another with the physical world (see Figure 65). The interface with the physical entity establishes a communication channel that transmits data between the physical entity and the virtual space. In the virtual space the data acquired is then used for computations with the objective of analysing

the behaviour of the physical entities to facilitate the decision-making process. Therefore, to enable the tight integration between the virtual and physical entities, the events within the physical world need to

be mapped and fetched within the virtual space and the decisions taken within the virtual space need to be forwarded to the physical world. These considerations are highlighting the importance and criticality of designing and implementing the communication channel between physical and virtual entities.

In the CPS research domain, to main approaches exist for virtualizing physical entities into CPS, namely as stated in [61][62]:

1. Cyberizing the Physical: it consists in specifying the physical system/subsystem with

computational abstractions and interfaces. This also leads to equip physical systems/subsystems

with intelligent enabled embedded systems. 2. Physicalizing the Cyber: it consists in expressing abstractions and interfaces of software and

network components to represent physical systems/subsystems dynamic behaviour in time.

This section describes the “ Cyberizing the physical” approach. As a matter of fact, the aim is to extend the use of modern and future internet technology to create an environment where a huge amount of data

is generated as a necessary condition for enhancing the performance of CPSs. The MANTIS platform will

provide all the necessary mechanisms to enable data transfer and storage as well as methods, methodologies and algorithms to analyse the data in the context of the target application: maintenance. In this scenario, the “ cyberization” of physical entities will enable and facilitate – from one side – the

data transfer from heterogeneous systems and – from the other side – the analysis of such data to improve maintenance strategies in distinct contexts of application. Therefore, in MANTIS the “ physicalizing” approach is used too, in fact the dynamic behaviour of physical entities is extracted and modelled within the cyberspace (virtual space) from the analysis of the data extracted by “ cyberization” .



Figure 65 – Virtual Entity communication interfaces

7.2.2.1 Physical Asset API: Native Communication Library

The native communication library provides the communication channel between the physical entities and the MANTIS service platform. It represents the first step for the integration of the information within the

MANTIS service platform (virtual world).

By considering a multi-layered approach (see Figure 66) – to separate the system in different logical areas

– the native communication library guarantees communication between the physical and virtual worlds.

Figure 66 – Layered approach for communication

The communication with the devices installed in the specific hardware installation needs a native communication library and/or driver. This communication library/driver must be defined to enable a variety of devices to be reached, i.e. multiple implementations of this generic interface could exist to

accommodate the needs of different and heterogeneous devices and facilitate communication across a spectrum of legacy hardware components. The native communication library/driver must then be used to



manage the data exchange between MANTIS and the devices/asset/segments installed and deployed in a specific application context by using a set of predefined functions.

The native communication library interface provides an abstraction layer allowing the cyber entity to be

completely independent from the specific technology used to establish a physical communication channel

to connect with the physical entity, that – in turn – can be implemented by using varying technologies such as CoAP, OPC-UA, filesystem, HTTP sockets, etc. (see Figure 67).

Figure 67 – Virtual and Physical Entities connection by using the Native Communication Library

Thus, the main objective of the native communication library is to hide the complexity of the specific protocol and communication needs while allowing the access to the physical entity through a simple set

of predefined methods (see Figure 68).

Figure 68 – Forwarding calls from client to the component that implements the interface [63]

The native communication library can be implemented by using two main approaches, namely:

Pulling: when new data is needed, the virtual entity initiates the conversation with the physical entity following a client/server communication model and – thus – request-response MEP. Obviously, to communicate, the client and server need to use a common language (that is represented by the models provided in the previous sections). In this approach the virtual entity

only initiates the conversation when it needs data / expects new data to be available.

Figure 69 – Client/Server communication model [63]



Pushing: the physical entity initiates the conversation with the virtual entity whenever some relevant change in the physical world happens, following an observer communication model.

Figure 70 – Observer communication model [63]

7.2.2.1.1 Specifying and implementing the physical entity interface

Specifying the physical entity interface is an important activity for virtualization. The interface should reflect the physical entity responsibilities to provide meaningful services for a client while detaching them from the low-level intricacies. In this section an interface for a physical entity is shown, as well as some specific implementations. When designing and specifying an interface some aspects must be considered as

also stated in [63], namely:

Expressiveness and simplicity: the more expressive and simple a physical entity’ s interface is, the easier it is to use.

Loose coupling and stability: it is necessary to allow separation between a physical entity’ s

interface and protocols used to implement it and virtual entity (client) that is using the interface. Thus, a virtual entity is not interested on how the specific interface with the physical entity is internally design and implemented. Moreover, interface versioning, stability and robustness is a

key issue for the correct behaviour of a CPS.

Distribution: location of the physical entity as well as granularity (i.e. machine, sensor, group of machines, etc.) should be transparent to the virtual entity.

Heterogeneity of physical entities: physical entities can be accessed by using different programming paradigms, models, technologies and protocols that usually are different from the ones used to virtualize them. Despite this heterogeneousness virtual and physical entities should be seamlessly integrated without exposing (mutual) hard-coded dependencies and/or implementation details.

Since a CPS is providing two interfaces (one with physical word/space and the other one with cyber world/space) it is important to highlight that the previous recommendations must be considered in developing the virtual entity interface too.

The listings below are examples of a Native Communication Library interface and possible implementations

with java as the reference programming language.



/**

*

* @author Giovanni Di Orio

*/

public interface INativeCommunicationLibrary {

public void register(Callback callback);

public FunctionalityDescription readDescription();

public List<Attribute> readData();

public void sendData(String value);

public boolean ping();

}

Listing 1 – Example of a Native Communication Library Interface in java language

The concrete physical entity architecture is shown in Figure 71.

Figure 71 – Physical Entity architecture and Native Communication Interface

The code in Listing 2 allows a raspberry pi to get data from a temperature sensor connected to an Arduino

microcontroller. The virtual entity is getting data from the raspberry pi by using the readData method. It is completely detached from the specific implementation of the interface allowing generic virtual entities

regardless of the specific communication link and protocol used. In such a way, the data in the virtual space is always handled in the same manner.



/**

*

* @author pedro barroca

*/

public class TemperatureUninovaCommunicationLib implements INativeCommunicationLibrary{

private final mimosa.ccomml.MeasurementLocation location = new mimosa.ccomml.MeasurementLocation();

private final FunctionalityDescription functionalityDescription;

private final JSONSerializer serializer = new JSONSerializer().transform(new ExcludeNullTransformer(),

void.class).exclude("*.class");

private final JSONDeserializer deserilizer = new JSONDeserializer();

//private final JSONSerializer serializer;

//######################################## Start ###################################################

//Comunications with arduino

SerialPort serialPort;

int request = 1;

/**

* The port we're normally going to use.

*/

private static final String PORT_NAMES[] = {

"/dev/tty.usbserial-A9007UX1", // Mac OS X

"/dev/ttyACM0", // Raspberry Pi



"/dev/ttsS0", //Raspberry Pi

"/dev/ttyUSB0", // Linux

"COM4", // Windows

"COM5", // Windows

};

/**

* A BufferedReader which will be fed by a InputStreamReader converting the

* bytes into characters making the displayed results codepage independent

*/

private BufferedReader input;

/**

* The output stream to the port

*/

private OutputStream output;

/**

* Milliseconds to block while waiting for port open

*/

private static final int TIME_OUT = 2000;

/**

* Default bits per second for COM port.

*/

private static final int DATA_RATE = 9600;

public void initializeCOMConnection() {

// the next line is for Raspberry Pi and

// gets us into the while loop and was suggested here was suggested

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=81&t=32186

//System.setProperty("gnu.io.rxtx.SerialPorts", "/dev/ttyACM0"); //uncomment if the device is an Raspberry Pi

CommPortIdentifier portId = null;

Enumeration portEnum = CommPortIdentifier.getPortIdentifiers();

//First, Find an instance of serial port as set in PORT_NAMES.

while (portEnum.hasMoreElements()) {

CommPortIdentifier currPortId = (CommPortIdentifier) portEnum.nextElement();

for (String portName : PORT_NAMES) {

if (currPortId.getName().equals(portName)) {

portId = currPortId;

break;

}

}

}

if (portId == null) {

System.out.println("Could not find COM port.");

return;

}

try {

// open serial port, and use class name for the appName.

serialPort = (SerialPort) portId.open(this.getClass().getName(), TIME_OUT);

// set port parameters

serialPort.setSerialPortParams(DATA_RATE, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE);

// open the streams

input = new BufferedReader(new InputStreamReader(serialPort.getInputStream()));

output = serialPort.getOutputStream();

} catch (Exception e) {

System.err.println(e.toString());

}

}



/**

* This should be called when you stop using the port. This will prevent

* port locking on platforms like Linux.

*/

public synchronized void close() {

if (serialPort != null) {

//serialPort.removeEventListener();

serialPort.close();

}

}

public String requestData(){

try {

output.write(this.request);

while(!input.ready())

Thread.sleep(2);

return input.readLine();

} catch (IOException ex) {

Logger.getLogger(TemperatureUninovaCommunicationLib.class.getName()).log(Level.SEVERE, null, ex);

} catch (InterruptedException ex) {

Logger.getLogger(TemperatureUninovaCommunicationLib.class.getName()).log(Level.SEVERE, null, ex);

}

return "ERROR in requestData from TemperatureUninovaCommunicationLib!!";

}

//######################################## End #########################################################

public TemperatureUninovaCommunicationLib(){

this.initializeCOMConnection();

//Create descriptions according the models presented in d2.3 and the OSA-CBM standard

mimosa.ccomml.UUID segmentId = new mimosa.ccomml.UUID();

segmentId.setValue(String.valueOf(UUID.randomUUID().getLeastSignificantBits()));

Segment segment = new Segment();

segment.setUUID(segmentId);

mimosa.ccomml.UUID assetId = new mimosa.ccomml.UUID();

assetId.setValue(String.valueOf(UUID.randomUUID().getLeastSignificantBits()));

Asset asset = new Asset();

asset.setUUID(assetId);

AssetSegmentEvent assetToSegment = new AssetSegmentEvent();

assetToSegment.setSegment(segment);

assetToSegment.setAsset(asset);

asset.getAssetSegmentEvent().add(assetToSegment);

segment.getAssetSegmentEvent().add(assetToSegment);

location.setAsset(asset);

location.setSegment(segment);

mimosa.ccomml.UUID identifier = new mimosa.ccomml.UUID();

identifier.setValue(String.valueOf(UUID.randomUUID().getLeastSignificantBits()));

Attribute physicalEntityDescriptionAttribute = new Attribute(identifier, "PhysicalEntityDescription", null,

attributeClazzType.MANAGEMENT.name());

ValueContainer sensorLocationContainer = new ValueContainer();

sensorLocationContainer.setHasValue(new Value(serializer.deepSerialize(location)));

List<MetaData> LmetaData = new ArrayList();

MetaData nameMetadata = new MetaData(MDN.DESCRIPTION.getMdN(), null, SensorMDValue.SENSOR_LOCATION.name());

MetaData typeMetadata = new MetaData(MDN.TYPE.getMdN(), null, String.class.getName());

MetaData formatMetadata = new MetaData(MDN.FORMAT.getMdN(), new ArrayList(Arrays.asList(new

MetaData(MDN.NATIVETYPE.getMdN(), null, MeasurementLocation.class.getName()))), ValueFormat.JSON.getValueFormatName());

LmetaData.add(nameMetadata);

LmetaData.add(typeMetadata);

LmetaData.add(formatMetadata);

sensorLocationContainer.getHasMetaDatas().add(new MetaData(MDN.CATEGORY.getMdN(), LmetaData,

MDCategory.ENT_MD.name()));

physicalEntityDescriptionAttribute.getHasValueContainers().add(sensorLocationContainer);

ValueContainer sensorNameContainer = new ValueContainer();

sensorNameContainer.setHasValue(new Value("Uninova_Temperature_Sensor"));

LmetaData = new ArrayList();

nameMetadata = new MetaData(MDN.DESCRIPTION.getMdN(), null, SensorMDValue.SENSOR_TYPE.name());

typeMetadata = new MetaData(MDN.TYPE.getMdN(), null, String.class.getName());

formatMetadata = new MetaData(MDN.FORMAT.getMdN(), null, ValueFormat.TEXT.getValueFormatName());




sensorNameContainer.getHasMetaDatas().add(new MetaData(MDN.CATEGORY.getMdN(), LmetaData, MDCategory.ENT_MD.name()));

physicalEntityDescriptionAttribute.getHasValueContainers().add(sensorNameContainer);

ValueContainer sensorIdContainer = new ValueContainer();

sensorIdContainer.setHasValue(new Value("4.0.0rc2"));




nameMetadata = new MetaData(MDN.DESCRIPTION.getMdN(), null, SensorMDValue.SENSOR_ID.name());






sensorIdContainer.getHasMetaDatas().add(new MetaData(MDN.CATEGORY.getMdN(), LmetaData, MDCategory.ENT_MD.name()));

physicalEntityDescriptionAttribute.getHasValueContainers().add(sensorIdContainer);

ValueContainer sensorLowerBoundContainer = new ValueContainer();

sensorLowerBoundContainer.setHasValue(new Value("650"));


nameMetadata = new MetaData(MDN.DESCRIPTION.getMdN(), null, SensorMDValue.VALUE_LOWERBOUND.name());


formatMetadata = new MetaData(MDN.FORMAT.getMdN(), new ArrayList(Arrays.asList(new MetaData(MDN.NATIVETYPE.getMdN(),

null, double.class.getName()))), ValueFormat.NUMBER.getValueFormatName());




sensorLowerBoundContainer.getHasMetaDatas().add(new MetaData(MDN.CATEGORY.getMdN(), LmetaData,


physicalEntityDescriptionAttribute.getHasValueContainers().add(sensorLowerBoundContainer);

ValueContainer sensorUpperBoundContainer = new ValueContainer();

sensorUpperBoundContainer.setHasValue(new Value("1024"));


nameMetadata = new MetaData(MDN.DESCRIPTION.getMdN(), null, SensorMDValue.VALUE_UPPERBOUND.name());







sensorUpperBoundContainer.getHasMetaDatas().add(new MetaData(MDN.CATEGORY.getMdN(), LmetaData,


physicalEntityDescriptionAttribute.getHasValueContainers().add(sensorUpperBoundContainer);

ValueContainer sensorReferenceContainer = new ValueContainer();

sensorReferenceContainer.setHasValue(new Value("1000"));


nameMetadata = new MetaData(MDN.DESCRIPTION.getMdN(), null, SensorMDValue.VALUE_REFERENCEVALUE.name());







sensorReferenceContainer.getHasMetaDatas().add(new MetaData(MDN.CATEGORY.getMdN(), LmetaData,


physicalEntityDescriptionAttribute.getHasValueContainers().add(sensorReferenceContainer);

ValueContainer sensorUnitContainer = new ValueContainer();

sensorUnitContainer.setHasValue(new Value("Celsius"));


nameMetadata = new MetaData(MDN.DESCRIPTION.getMdN(), null, SensorMDValue.VALUE_UNIT.name());






sensorUnitContainer.getHasMetaDatas().add(new MetaData(MDN.CATEGORY.getMdN(), LmetaData, MDCategory.ENT_MD.name()));

physicalEntityDescriptionAttribute.getHasValueContainers().add(sensorUnitContainer);

PhysicalEntityDescription physicalEntityDescription = new PhysicalEntityDescription(identifier, null, new

ArrayList(Arrays.asList(physicalEntityDescriptionAttribute)));

physicalEntityDescriptionAttribute.setHasDescription(physicalEntityDescription);

// Describe the Resource

ResourceDescription resourceDescription = new ResourceDescription(physicalEntityDescription, identifier, null, null);

// Describe the Functionalities

mimosa.ccomml.UUID uuidAttribute = new mimosa.ccomml.UUID();

uuidAttribute.setValue(String.valueOf(UUID.randomUUID().getLeastSignificantBits()));

Attribute attribute = new Attribute(uuidAttribute, "Temperature Data", null, attributeClazzType.DATAEXTRACTION.name());

List<Attribute> attributes = new ArrayList();

attributes.add(attribute);

mimosa.ccomml.UUID uuidFunctionlityDescription = new mimosa.ccomml.UUID();

uuidFunctionlityDescription.setValue(String.valueOf(UUID.randomUUID().getLeastSignificantBits()));

functionalityDescription = new FunctionalityDescription(new ArrayList(Arrays.asList(resourceDescription)),

uuidFunctionlityDescription, null, attributes);



attribute.setHasDescription(functionalityDescription);

}

/**

* The callback mechanism is not supported yet

*/

@Override

public void register(Callback callback) {

throw new UnsupportedOperationException("Not supported yet."); //To change body of generated

methods, choose Tools | Templates.

}

/**

* This provides physical entity descriptions according to the models

* specified within the deliverable d2.3

*/

@Override

public FunctionalityDescription readDescription() {

return this.functionalityDescription;

}

@Override

public List<Attribute> readData() {

List<Attribute> attributes = new ArrayList<>();

for (Attribute attribute : this.functionalityDescription.getHasAttributes()) {

if

(attribute.getHasAttributeClazzType().equals(attributeClazzType.DATAEXTRACTION.name())) {

ValueContainer actualValueContainer = new ValueContainer();

//get the value from the Ciberentity

actualValueContainer.setHasValue(new Value(this.requestData()));

List<MetaData> LmetaData = new ArrayList();

MetaData nameMetadata = new MetaData(MDN.DESCRIPTION.getMdN(), null,

SensorMDValue.VALUE_ACTUAL.name());

MetaData typeMetadata = new MetaData(MDN.TYPE.getMdN(), null,

String.class.getName());

MetaData formatMetadata = new MetaData(MDN.FORMAT.getMdN(), new

ArrayList(Arrays.asList(new MetaData(MDN.NATIVETYPE.getMdN(), null, int.class.getName()))),

ValueFormat.NUMBER.getValueFormatName());




actualValueContainer.getHasMetaDatas().add(new MetaData(MDN.CATEGORY.getMdN(),

LmetaData, MDCategory.DATAEXTR_MD.name()));

ValueContainer locationValueContainer = new ValueContainer();

locationValueContainer.setHasValue(new Value(serializer.serialize(location)));


nameMetadata = new MetaData(MDN.DESCRIPTION.getMdN(), null,

SensorMDValue.SENSOR_LOCATION.name());


formatMetadata = new MetaData(MDN.FORMAT.getMdN(), new ArrayList(Arrays.asList(new

MetaData(MDN.NATIVETYPE.getMdN(), null, MeasurementLocation.class.getName()))),

ValueFormat.JSON.getValueFormatName());




locationValueContainer.getHasMetaDatas().add(new MetaData(MDN.CATEGORY.getMdN(),

LmetaData, MDCategory.ENT_MD.name()));

attribute.getHasValueContainers().clear();

attribute.getHasValueContainers().add(actualValueContainer);

attributes.add(attribute);

}

}

return attributes;

}

@Override

public void sendData(String value) {

throw new UnsupportedOperationException("Not supported yet."); //To change body of generated

methods, choose Tools | Templates.

}

/**

* This should be implemented test the connection with

* the physical entity

*/

@Override

public boolean ping() {

return true;

}

}

Listing 2 – Specific Implementation of the Native Communication Interface



7.2.2.1.1.1 Physical Entity Capabilities

The Native Communication Library interface describes physical entities by using a set of methods that allow the related cyber entity to push and pull data to/from the physical world. It needs to be designed

generically enough to be used regardless of the specific technology and/or protocol used to communicate

with the specific physical entity. In this scenario, the specific communication channel is hidden behind the interface. However, the way the Native Communication library is implemented does depend on the physical entity, i.e. the hardware resources (capabilities) of the physical entity have a big impact on the way the interface is implemented. In this context, physical entities can be clustered within three categories based

on their processing capabilities and communication restriction:

a) Smart devices without any communication constraint (e.g. shop floor devices).

b) Smart gateways with or without communication constraints (e.g. sensor network gateways). c) Dumb devices with communication constraints (e.g. vehicular use case).

Depending on the category the device belongs, the native communication library has specific implementations. As a matter of fact, in the case of a) it is possible to create large messages that, in turn, can facilitate a lot the implementation of a complex communication protocol. As for categories b) and – especially – c) the amount of traffic needs to be minimal meaning that small messages must be created. This is a very critical problem if the entire MIMOSA-CBM standard needs to be used – like the

MANTIS project that deeply relies on the MIMOSA-CBM standard – due to its internal complexity that is translated into several concepts and relations between them that are used to model all the aspects of a system regardless of the context of application, i.e. manufacturing, health care, etc.. The complexity of the MIMOSA-CBM standard is extremely positive in the case of smart devices without any communication

constraint (the cluster a)), since it enables the use of a bottom-up approach where a physical entity is responsible for its own description, i.e. the data retrieved from the physical entity is already structured and modelled in a well-defined manner allowing – at the same time – to be properly characterized and

described. In this case the physical entity is aware of its own context of application. On the contrary, in the case of dumb devices and/or smart devices with communication constraints (cluster b) and c)) the

complexity of MIMOSA-CBM standard is a serious drawback. For such typology of devices, a top-down approach must be followed, i.e. the physical entity must provide very small messages to cope with the communication constraints. To do that very few information should be encapsulated in the message content without a proper characterization and description. In this scenario, a context model must be

provided from the outside of the physical entity as a fundamental part of the platform to enable the

“ fetching” of the message from these devices with the context of application.

Figure 72 and Figure 73 show two events (simpleCEPEvent) that are related to the same sensor reading and that can encapsulate a single or multiple data points to describe and characterize the value read. The messages are based on the models presented in section 6. From the figures, it is easy to perceive that the

way the messages are structured and thus the information that they encapsulate affects the size of the message. This aspect can be critical or not depending on the category of the devices and/or physical

entities that are used.



A simplified message which content is the value read from the physical entity and some metadata used to better describe and characterize the value itself. The information within the message is without any context information. As it is this information is meaningless. To fetch specific context around the provided

value, it is necessary to use a context model that will help to explain the value by relying on further

relationships and concepts that are not explicitly represented in the message.

Figure 72 – A first example of a reading from a temperature physical entity (SimpleCEPEvent based on the proposed event model in section 6)

Figure 73, on the other hand, shows another event where more information is included to better characterize, describe and contextualize the reading from the physical entity by including more information

around the reading the complexity of the message and – thus – increasing the size of the message to a

proportion that physical entities with communication constraints are not capable to handle. Therefore, the way information is designed must be a trade-off between physical entity capabilities and the information needed to guarantee that the data is usable from any external application and/or software artefact.



Figure 73 – A second example of a reading from a temperature physical entity (SimpleCEPEvent based on the proposed event model in section 6)



7.3 Structuring the System of CPSs: Identification of the Functional blocks, Interfaces and Information flow

7.3.1 CPS Functional Blocks

The implementation of CPS in complex systems (either industrial or not) offers several advantages that

can be categorized according to the OSA-EAI’ s Common Conceptual Object Model (CCOM) into: asset, segment, site and enterprise. As a matter of fact, the deployment of CPS brings hierarchical advantages, by enabling the creation of effective and efficient processing chain, from asset to enterprise levels:

1. Asset Level: sensor data fusion (feature fusion, decision, fusion), sensor data filtering (eliminating the noise and erroneous values), inclusion of rule-based methods, fuzzy logic, logical links for the

sake of asset smart fault detection and/or self-awareness, self-prediction and local optimization of asset behaviour.

2. Segment Level: information captured from several assets is then used and aggregated to monitor the status and/or the behaviour of segments. At this level, complex algorithms are used to

continuously predict and monitor networks of heterogeneous systems/assets. 3. Site Level: information captured from segments is used at this level for decision making. The focus

at this level is not the performance and/or the availability of the specific machine/asset or segment but the management of the operations to reduce the waste, i.e. site efficiency, effectiveness, productivity, OEE and costs are the key elements.

4. Enterprise Level: information from several sites is aggregated and analysed to enhance the global decision-making process and to help in the definition of the enterprise strategy and position on the market.

Since CPSs are in an early stage of development it is essential to define and identify guidance and

methodologies on how to implement CPS-based systems, i.e. to clearly identify the supporting structure for a CPS-based system and functional layers in the aforementioned four levels. As stated in [64], a CPS-based system can be modelled as a hierarchical 5 layers pyramid regardless of the specific architectural pattern instantiated within a company: cloud-based, edge-based, etc.. as shown in Figure 74, Figure 75, Figure 76, and Figure 77.

The responsibilities of the levels of the pyramid will be different depending on the layer where they are instantiated. As a matter of fact, at an edge layer data analytics and value creation are local to the edge,

i.e. they are applied to the data provided by the edge nodes to extract and analyse information to build models that involve assets and/or segments for optimization, configuration and adaptation of their

behaviour. On the contrary, at the cloud level information is extracted and analysed to build complex models that involve site and enterprise level for optimization, configuration and adaptation of the behaviour of the entire enterprise and/or group of enterprises.

Figure 74 – The 5C architecture of a CPS-based system [64]



Figure 75 – Instantiation of the 5C architecture in a cloud-based architectural pattern

Figure 76 – Instantiation of the 5C architecture in an edge-based architectural pattern



Figure 77 – Instantiation of the 5C architecture in an edge-based architectural pattern (functionalities are divided between the cloud, edge and physical layers)

7.3.1.1 Mapping between the 5C architecture and the MIMOSA OSA-CBM standard

To allow the easy translation of the 5C functional blocks into the MIMOSA OSA-CBM standard the Table 2 has been created that presents the mapping between the functionalities and layers defined of the 5C architecture and MIMOSA OSA.

Table 8 – Mapping between MANTIS and IoT-A domain models concepts

CPS 5C Architecture functional blocks (extracted from [64])

MIMOSA OSA-CBM standard

Further

comments

CONNECTION DATA ACQUISITION Virtualizing Physical entity

CONVERSION DATA MANIPULATION

CYBER STATE DETECTION Data from physical entities are there used by specific data analytics to extract and/or to determine the actual status of the asset/segment and predict their behaviour

HEALTH ASSESSMENT

PROGNOSTIC ASSESSMENT

COGNITION

ADVISORY GENERATION

Recommendations are generated on the basis of the analysis applied on the data at the cyber level. The output of this level is the feedback from the cyber space to the physical space

CONFIGURATION



7.3.2 CPS Interfaces

Based on the way the MANTIS platform is deployed and structured there are some rules that must be followed to help developers to cope with the complexity of fully distributed systems. Since the MANTIS

platform is a SOA-based platform it makes sense to talk about interfaces. There are a set of interfaces that can be defined according to the architectural pattern used, namely:

a) Cloud-based Architectural Pattern:

a. CPS – Cloud Interface: bi-directional interface to ensure – from one side – data to be acquired and/or pushed from CPS to Cloud and – from the other side – to enable requests and/or feedback from cloud level to CPS;

b) Edge-based Architectural Pattern:

a. CPS – Edge interface: bi-directional interface to ensure – from one side – data to be acquired and/or pushed from CPS to Edge and – from the other side – to enable requests and/or feedback from Edge level to CPS;

b. Edge – Cloud Interface: bi-directional interface to ensure – from one side – data to be acquired and/or pushed from Edge to Cloud and – from the other side – to enable

requests and/or feedback from Cloud level to Edge. There is not direct communication between CPS and Cloud. All the communications with the cloud are managed by the edge.

More about the interface can be found in deliverables d2.2 – Reference Architecture and design specification V1 and d2.6 – Reference Architecture and Design specification V2. To guarantee

interoperability within the MANTIS service platform all the messages must be structured according to the models provided in section 6. The content of the message can be appropriately set based on the physical entity capabilities (as presented and deeply explained in section 7.2.2.1.1.1).

7.3.3 CPS Information Flow

The five levels defined by the 5C CPS architecture implicitly define the typical information flow within CPS-based systems from the initial data acquisition from components/assets (the levels I and II of the pyramid) to the data analytics and value creation (the levels IV and V of the pyramid) to support the

operations management & Maintenance and/or strategic decisions within the enterprises. These levels can be instantiated and deployed at different layers from physical entity to cloud passing through edge layer. By considering the edge architectural pattern, the typical information flow in a CPS-based system is the

one represented in Figure 78. One of the most important element in a CPS-based system is the persistent connection between the cyber and physical levels, i.e. a communication channel is created to acquire data

and, most importantly, a communication channel is created to communicate the feedbacks and/or results of the data analytics services deployed in the edge/cloud layers. In the Figure 78, an industrial asset has been considered as example of data source for the CPS-based platform. The data can be acquired and distributed within the CPS-based platform by using one of the MEPs explained in section 6.4. As a matter

of fact, the specific MEP used is a merely technical choice and – thus – does not influence the generic

flow of data and information in a CPS-populated system.



Figure 78 – Information flow based on the example of an industrial asset and edge-based architectural pattern


132 http://www.mantis-project.eu

MANTIS

References

[1] S. Bensalem, M. Cengarle, R. Passerone, A. Sangiovanni-Vincetelli, and M. Torngren, “CPS

Technologies,” Public D4.2, Sep. 2014.

[2] C. Iso and others, “ISO/IEC 2382-1: 1993 Information Technology-Vocabulary-Part

1:Fundamental terms,” 1993.

[3] ETSI, “ETSI TS 186 020 V3.1.1 - Telecommunications and Internet converged Services and

Protocols for Advanced Networking (TISPAN); IMS-based IPTV interoperability test specification,”

Technical, 2011.

[4] EICTA, “EICTA INTEROPERABILITY WHITE PAPER.” 2004.

[5] P. M. N. Maló, “Hub-and-spoke Interoperability: an out of the skies approach for large-scale data

interoperability,” 2013.

[6] A. Martidis, I. Tomasic, and P. Funk, “Deliverable 5.3: CREATE Interoperability.” 25-Aug-2014.

[7] H. van der Veer and A. Wiles, “Achieving technical interoperability,” Eur. Telecommun. Stand. Inst., 2008.

[8] G. D. Orio, D. Barata, A. Rocha, and J. Barata, “A Cloud-Based Infrastructure to Support

Manufacturing Resources Composition,” in Technological Innovation for Cloud-Based Engineering Systems, L. M. Camarinha-Matos, T. A. Baldissera, G. D. Orio, and F. Marques, Eds. Springer

International Publishing, 2015, pp. 82–89.

[9] G. Candido, C. Sousa, G. Di Orio, J. Barata, and A. W. Colombo, “Enhancing device exchange

agility in Service-oriented industrial automation,” in 2013 IEEE International Symposium on Industrial

Electronics (ISIE), 2013, pp. 1–6.

[10] G. Candido, “Service-oriented Architecture for Device Lifecycle Support in Industrial Automation,”

FCT-UNL, 2013.

[11] L. Davidsen, “IBM MQ: Integrated messaging to connect your enterprise.” IBM Corporation, 2014.

[12] Rockwell Automation, “The Connected Enterprise Maturity Model.” CIE-WP002-EN-P, 2014.

[13] M. Cengarle, S. Bensalem, J. McDermid, R. Passerone, A. Sangiovanni-Vincetelli, and M.

Torngren, “Characteristics, capabilities, potential applications of Cyber-Physical Systems: a preliminary

analysis,” D2.1, Nov. 2013.

[14] IEC TC 65/290/DC, “Device Profile Guideline, TC65: Industrial Process Measurement and

Control,” 2002.

[15] S. Kumar, “Interoperability Protocols and standards in LIS,” Workshop on Library 2.0, Feb-2009.

[16] J. Kowal, “What does the internet of Things mean to people who make things?,” Control Engineering, vol. 62, Feb-2015.

[17] ORACLE, “Understanding Functional Interoperability,” Oracle® Application Integration Architecture Pre-Built Integrations 11.1: Functional Interoperability Configuration Guide Release 11.1, 2012. [Online]. Available: http://docs.oracle.com/cd/E24010_01/doc.111/e23518/overview.htm.

[18] K. B. Poon, “Implementing Vocabulary Standards: Where to Begin?” Advance for Health

Information Executives.



[19] M. Mathes, C. Stoidner, S. Heinzl, and B. Freisleben, “SOAP4PLC: Web Services for

Programmable Logic Controllers,” in 2009 17th Euromicro International Conference on Parallel,

Distributed and Network-based Processing, 2009, pp. 210–219.

[20] A. Cannata, M. Gerosa, and M. Taisch, “A Technology Roadmap on SOA for smart embedded

devices: Towards intelligent systems in manufacturing,” in IEEE International Conference on Industrial

Engineering and Engineering Management, 2008. IEEM 2008, 2008, pp. 762–767.

[21] G. Di Orio, “Adapter module for self-learning production systems,” FCT-UNL, 2013.

[22] J. Barata, Coalition Based Approach For ShopFloor Agility. Amadora - Lisboa: Orion, 2005.

[23] T. Hadlich, “Providing device integration with OPC UA,” in Industrial Informatics, 2006 IEEE

International Conference on, 2006, pp. 263–268.

[24] S.-H. Leitner and W. Mahnke, “OPC UA–service-oriented architecture for industrial applications,”

ABB Corp. Res. Cent., 2006.

[25] D. Cachapa, R. Harrison, and A. Colombo, “Configuration of SoA-based devices in virtual

production cells,” Int. J. Prod. Res., vol. 49, no. 24, pp. 7397–7423, Dec. 2011.

[26] IBM, “Asset performance management for power generation.” .

[27] EEBUS Initiative, “EEBUS Technology Concept,” EEBUS Initiative, 2012. [Online]. Available:

https://www.eebus.org/en/technological-concept/. [Accessed: 05-Feb-2016].

[28] EEBUS Initiative, “EEBUS Mappings,” EEBUS Initiative, 2012. [Online]. Available:

https://www.eebus.org/en/technological-concept/mappings/. [Accessed: 05-Feb-2016].

[29] EEBUS Initiative, “EEBUS All IP (SHIP),” EEBUS Initiative, 2012. [Online]. Available:

https://www.eebus.org/en/technological-concept/all-ip-approach/. [Accessed: 05-Feb-2016].

[30] WestHealth Institute, “The Value of Medical Device Interoperability: Improving patient care with

more than $30 billion in annual health care savings.” Mar-2013.

[31] HIMSS Analytics, “Medical Devices Landscape Current and Future Adoption, Integration with

EMRs, and Connectivity.” 2010.

[32] HealthIT.gov, “A Shared Nationwide Interoperability Roadmap version 1.0,” Interoperability, Dec-

2015. [Online]. Available: https://www.healthit.gov/policy-researchers-implementers/interoperability.

[33] HealthIT.gov, “Standards & Interoperability,” Health Information Exchange (HIE), Feb-2014.

[Online]. Available: https://www.healthit.gov/providers-professionals/standards-interoperability.

[34] European Commission, “eHealth Action Plan 2012-2020: Innovative healthcare for the 21st

century.” Dec-2012.

[35] European Commission, “EU activities in the field of eHealth Interoperability and Standardisation:

an overview.”

[36] CEN, “European Committee for Standardization,” 2016. [Online]. Available:

https://standards.cen.eu/dyn/www/f?p=204:105:0

[37] A. Colombo et al., Eds., Industrial Cloud-Based Cyber-Physical Systems: The IMC-AESOP Approach, 2014 edition. New York: Springer, 2014.

[38] ESPRIT Consortium AMICE, Ed., CIMOSA: Open System Architecture for CIM. Berlin, Heidelberg: Springer Berlin Heidelberg, 1993.



MANTIS

[39] N. Rozanski and E. Woods, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2012.

[40] Industrial Internet Consortium, “The Industrial Internet Reference Architecture,” Technical Report,

2015.

[41] E. Gilabert, E. Jantunen, C. Emmanouilidis, A. Starr, and A. Arnaiz, “Optimizing E-Maintenance

Through Intelligent Data Processing Systems,” in Engineering Asset Management 2011, J. Lee, J. Ni, J.

Sarangapani, and J. Mathew, Eds. Springer London, 2014, pp. 1–9.

[42] J. Delsing, IoT Automation: Arrowhead Framework. CRC Press, 2017.

[43] “MIMOSA - An Operation and Maintenance Information Open System Alliance.” [Online].

Available: http://www.mimosa.org. [Accessed: 03-Feb-2017].

[44] C. Szyperski, Component Software: Beyond Object-Oriented Programming, 2nd ed. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002.

[45] G. Booch, Software Components with Ada: Structures, Tools, and Subsystems. Benjamin / Cummings Publishing Company, Incorporated, 1987.

[46] A. W. Brown, Large-Scale, Component Based Development. Upper Saddle River, NJ, USA: Prentice Hall PTR, 2000.

[47] G. T. Heineman and W. T. Councill, Eds., Component-based Software Engineering: Putting the Pieces Together. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2001.

[48] H.-G. Gross, Component-Based Software Testing with UML. Berlin/Heidelberg: Springer-Verlag, 2005.

[49] G. Volksen, S. Becker, T. Jacobs, C. Kleegrewe, and S. Meyer, “Event Representation and

Processing,” Public D2.6, May 2013.

[50] G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, 2004.

[51] D. C. Schmidt and C. O’Ryan, “Patterns and performance of distributed real-time and embedded

publisher/subscriber architectures,” J. Syst. Softw., vol. 66, no. 3, pp. 213–223, Jun. 2003.

[52] P. Avgeriou and P. Tandler, “Architectural patterns for collaborative applications,” Int. J. Comput.

Appl. Technol., vol. 25, no. 2–3, pp. 86–101, Jan. 2006.

[53] J. Kreps, N. Narkhede, J. Rao, and others, “Kafka: A distributed messaging system for log

processing,” 2011.

[54] A. Warsky, “Evaluating persistent, replicated message queues (updated w/ Kafka),” Blog of Adam Warsky, Jul-2014. [Online]. Available: http://www.warski.org/blog/2014/07/evaluating-persistent-replicated-message-queues/. [Accessed: 20-Apr-2016].

[55] Enabling Things to Talk - Designing IoT solutions with the | Alessandro Bassi | Springer. .

[56] J. Valtonen, A. Niemela, and I. Arenaza, “REST Interface for MIMOSA Documentation.” MANTIS

WP2 - Service platform architecture development, 2017.

[57] K. Bever, “MIMOSA Open System Architecture for Enterprise Application Integration (OSA-EAI)

Primer,” Sep-2008.

[58] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern-Oriented Software Architecture, A System of Patterns. John Wiley & Sons, 2013.



[59] S. K. Khaitan and J. D. McCalley, “Design Techniques and Applications of Cyberphysical Systems:

A Survey,” IEEE Syst. J., vol. 9, no. 2, pp. 350–365, Jun. 2015.

[60] jmlopezluj, “An Integral Open Source Software selection model with a case study on IT

Infrastructure Monitoring System,” JM.me. .

[61] E. A. Lee, “CPS Foundations,” in Proceedings of the 47th Design Automation Conference, New

York, NY, USA, 2010, pp. 737–742.

[62] R. Anderl, “Industrie 4.0-advanced engineering of smart products and smart production,” in 19th International Seminar on High Technology, Technological Innovations in the Product Development, Piracicaba, Brazil, 2014.

[63] F. Buschmann, K. Henney, and D. C. Schmidt, Pattern-Oriented Software Architecture, A Pattern Language for Distributed Computing. John Wiley & Sons, 2007.

[64] J. Lee, B. Bagheri, and H.-A. Kao, “A Cyber-Physical Systems architecture for Industry 4.0-based

manufacturing systems,” Manuf. Lett., vol. 3, pp. 18–23, Jan. 2015.



MANTIS

Appendix I

MANTIS Unique Representation for Describing Use Cases Architectures



MANTIS

MANTIS · V0.2 08/01/2018 UNINOVA First Draft V0.3 18/01/2018 UNINOVA Preliminary Version sent...

Documents

Transcript of MANTIS · V0.2 08/01/2018 UNINOVA First Draft V0.3 18/01/2018 UNINOVA Preliminary Version sent...