Cloud-based Rapid Elastic MAnufacturing

Cloud-based Rapid Elastic MAnufacturing WP6 Cloud Manufacturing Collaboration, Knowledge and Stakeholder Interaction Framework T6.2 D6.4 Monitoring and Alerting Framework Prototype II Deliverable Lead: IKER Contributing Partners: IKER Delivery 07/2017 Dissemination Level: Public Version 1.0 This deliverable provides a description of the final prototype implementation of T6.2 Monitoring & Alerting. As stated in the Description of Action (DoA), this deliverable is a prototype (software) deliverable. As such, this document is reduced in length and its only purpose is to briefly describe the prototype functionality as well as to give installation instructions and usage clarifications. This document is delivered with instructions to obtain the software itself.

Status Deliverable Lead Internal Reviewer 1 Internal Reviewer 2 Type Work Package ID Aizea Lojo, IKER Matthias Klusch (DFKI) Norman Wessel (ASC) Other WP6: Cloud Manufacturing Collaboration, Knowledge and Stakeholder Interaction Framework D6.4: CREMA Monitoring and Alerting Framework Prototype II Due Date 31.07.2017 Delivery Date 31.07.2017 Status For Approval Note This is not an official deliverable. The type of the official deliverable is OTHER, as it is a software deliverable. This document mainly describes how to obtain the software and how to run it. Disclaimer The views represented in this document only reflect the views of the authors and not the views of the European Union. The European Union is not liable for any use that may be made of the information contained in this document. Furthermore, the information is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user of the information uses it at its sole risk and liability. 2 / 23

Project Partners Ascora GmbH, Germany Information Catalyst, United Kingdom Technische Universität Wien, Austria Technology Application Network Limited, United Kingdom German Research Center for Artificial Intelligence, Germany IKERLAN S. Coop., Spain Ubisense, United Kingdom Tenneco automotive Europe bvba, Belgium FAGOR ARRASATE S. Coop., Spain Goizper, Spain 3 / 23

Executive Summary The CREMA Monitoring and Alerting (MON) component is responsible for monitoring the runtime process instances from the Cloud Process and Messaging Runtime Environment (PRU) and the data transacted from acquisition processes. Naturally, not all monitored events are relevant and providing all data to a process engineer or similar user via the Dashboard would lead to an information overflow. Hence, only monitoring data which indicates important events should be regarded. For this purpose, process designers can make use of the MON to define KPIs and business rules, which will in most cases be based on the service level objective (SLOs) of their companies (e.g., deadline for particular manufacturing process steps). Whenever a critical threshold of a KPI is met, the MON component will generate an event to be taken into account ad-hoc during process runtime, e.g., to start a maintenance process. The development of the MON component led to the following two subsequent prototypes. Prototype I: Initial alarm detection with Machinery Maintenance use case integration and simple rule creation. Prototype II: Advanced alarm treatment and business rules creation in addition to Automotive use case integration This document provides information about the requirements to use and deploy the prototype and how to install and execute it. The requirements, installation and execution instructions are each described individually for every subcomponent. Additionally, this document provides a status overview of the current features of the prototype. Furthermore, this document provides information about how to use the software, including several interfaces of the CREMA Monitoring and Alerting component. 4 / 23

Table of Contents 1 Introduction... 7 1.1 CREMA Project Overview... 7 1.2 Deliverable Purpose, Scope and Context... 7 1.3 Status and Target Audience... 7 1.4 Abbreviations and Glossary... 8 1.5 Structure... 8 2 Scope and Relationship... 9 3 Requirements and Preparations... 11 3.1 MON Backend... 11 3.2 MON Frontend... 11 4 Deployment... 13 4.1 MON Backend... 13 4.2 MON Frontend... 13 5 Execution and Usage... 14 5.1 Execution... 14 5.1.1 MON Backend... 14 5.1.2 MON Frontend... 14 5.2 Usage... 15 5.2.1 General User Interface Structure... 15 5.2.2 Main Menu Bar... 15 5.2.3 Rules Engine Control Area... 15 5.2.4 Business Rules Panel... 16 5.2.4.1 Business Rules Creation... 16 5.2.4.2 Business Rules Editing... 17 5.2.5 Thresholds of Key Performance Indicators Panel... 18 5.2.5.1 Thresholds Creation... 19 5.2.5.2 Thresholds Editing... 19 5.2.5.3 Thresholds auto-update... 20 5.2.6 Process Monitoring Panel... 20 5.2.7 Alarms Panel... 21 5.2.7.1 Alarms Filtering by Date Range... 21 5.2.7.2 Alarms Data... 22 6 Feature Status... 23 5 / 23

List of Figures, Tables and Listings Figures Figure 1: MON Position in the CREMA Platform Architecture... 9 Figure 2: Architecture of the CREMA Monitoring and Alerting Component... 10 Figure 3: MON Frontend in Web Browser Window... 14 Figure 4: General Structure of MON User Interface... 15 Figure 5: Main Menu Bar... 15 Figure 6: Rules Engine Control Area... 15 Figure 7: Business Rules Panel... 16 Figure 8: Rules Creation Form... 17 Figure 9: Rules Editing Form... 18 Figure 10: Thresholds of KPIs Panel... 18 Figure 11: Thresholds Creation Form... 19 Figure 12: Thresholds Editing Form... 20 Figure 13: Process Monitoring Panel... 20 Figure 14: Alarms Panel... 21 Figure 15: Filtering Alarms by Date Range... 22 Figure 16: Example of Alarm Data and Corresponding Event Data... 22 Tables Table 1: Feature Timeplan Comparison... 23 6 / 23

1 Introduction CREMA Cloud-based Rapid Elastic MAnufacturing is a project funded by the Horizon 2020 Programme of the European Commission under Grant Agreement No. 637066. Within this deliverable, the process of installation and execution of the software prototype is described to support administrators and users. 1.1 CREMA Project Overview CREMA aims at simplifying the establishment, management, adaptation, and monitoring of dynamic, cross-organisational manufacturing processes following Cloud Manufacturing principles. CREMA will also provide the means to integrate data from distributed locations as if the complete manufacturing was carried out on the same shop floor, by integrating extra- and inter-plant manufacturing assets and making them mobile. CREMA will be built upon concepts and methods from the fields of Virtual Factories, Service-oriented Computing, Ubiquitous Computing, Cyber-Physical Systems, the Internet of Things and the Internet of Services, and naturally and most importantly Cloud Computing. To achieve its goals, the project will define tools and approaches in these areas: Manufacturing Virtualisation & Interoperability Cloud Manufacturing Process and Optimisation Framework Cloud Manufacturing Collaboration, Knowledge and Stakeholder Interaction Framework Thus, to achieve its goals, CREMA conducts original research and applies technologies from the fields of full end-to-end integration of Cloud manufacturing, integration of manufacturing assets and corresponding data sources, the design and execution of manufacturing processes, to the end user support via collaboration and interaction tools. For more information, please refer to the project Website 1. 1.2 Deliverable Purpose, Scope and Context The purpose of this deliverable is to accompany the prototype implementation of task 6.2. As such, its main purpose is to briefly clarify the scope of the prototype and to show the download, installation instructions and the use of the software. The document is limited in length as the main focus of the task is the software itself rather than its accompanying document. 1.3 Status and Target Audience This document is listed in the Description of Action (DoA) as public, since it provides original research and technical results which could be interesting for other cloud manufacturing projects or manufacturing frameworks in general. 1 http://www.crema-project.eu/ 7 / 23

1.4 Abbreviations and Glossary A glossary of common terms and roles related to the realisation of CREMA as well as a list of abbreviations is provided as an online glossary 2 / abbreviations list 3. 1.5 Structure This deliverable is broken down into the following sections: Section 1 (Introduction): Provides an introduction for this deliverable, including a general overview of the project, and outlines the purpose, scope, context, status, and target audience of this deliverable. Section 2 (Scope and Relationship): Clarifies the context and scope of the software prototype deliverable and its relationship with other architectural modules. Section 3 (Requirements and Preparations): Outlines the prerequisites to use the software of MON component. Section 4 (Deployment): Provides the installation details. Section 5 (Execution and Usage): Outlines the execution phase and usage phase of the MON component. Section 6 (Feature Status): Shows the status of the second prototype. 2 http://crema-project.eu/glossary 3 http://crema-project.eu/abbreviations 8 / 23

2 Scope and Relationship The CREMA Monitoring and Alerting component (MON) is a web-based monitoring and alerting tool whose user interface is integrated in the CREMA Dashboard and Visualisation component (DBV). It allows the user to define a set of business rules and thresholds in order to determine when alarms have to be triggered because of faults generated in the production processes. MON ingests event data from a message bus that is part of the CREMA Process Runtime component (PRU) and checks it against the defined business rules. Alarms are triggered only if any of the rules is fulfilled. MON also allows to display triggered alarms sorted by importance (critical or warning), status (active or deactivated) or date range. Business rules and thresholds as well as alarms and the corresponding event data are stored and maintained in the CREMA Cloud RAID Infrastructure (CRI). Figure 1: MON Position in the CREMA Platform Architecture The final prototype of the MON component is fully functional in the sense that the expected functionality is in line with its functional specification (D3.2). The current status enables to create, read, edit and delete business rules and thresholds related to the CREMA use cases. These rules and thresholds are stored in the CRI component. The MON also has the functionality of consuming data and matches it with the defined business rules, generating automatically an alarm when any of the rules is fulfilled. The alarms are stored in the CRI as well. Finally, the current version allows the user to visualise these alarms, both activated and deactivated. By default, the alarms are categorised as a function of their importance ( Critical or Warning ) and users can filter the results by a date range and look at the event data that triggered the alarms. 9 / 23

Figure 2: Architecture of the CREMA Monitoring and Alerting Component 10 / 23

3 Requirements and Preparations The MON prototype II is structured into two main subcomponents. One of them is the web interface of the MON component also known as MON Frontend, and the other one is the MON backend which offers the services of the MON component. The MON Frontend consumes services from MON Backend in a RESTful way. The following sections provide requirements for running the MON subcomponents, installation instructions to make it available, and finally the process of how to execute the installed instance of this CREMA component. 3.1 MON Backend The Monitoring and Alerting Framework backend is responsible for offering monitoring services for the CREMA platform. The MON Backend is also the subcomponent that interacts with other CREMA components such as CREMA Cloud-based RAID Infrastructure (CRI), CREMA Cloud Process and Messaging Runtime Environment (PRU) and CREMA Manufacturing Big Data and Knowledge and Analytics (BDA). In order to deploy the MON Backend, a UNIX server host is required. It is recommended to use the Linux distribution Ubuntu 16.04 or above as operating system. In any other operating system the MON subcomponent should be working too, but it cannot be guaranteed. The subcomponent can be deployed using Docker. Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run the application. This guarantees that the software will always run in the same environment, regardless of the host environment. If this approach is chosen, a recent installation of Docker Engine is required. The following commands will install the Docker Engine on Ubuntu 16.04: 1. $ sudo apt-get update 2. $ sudo apt-get install -y \ 3. apt-transport-https \ 4. ca-certificates \ 5. curl \ 6. software-properties-common 7. $ curl -fssl https://download.docker.com/linux/ubuntu/gpg sudo apt-key add - 8. $ sudo add-apt-repository \ 9. "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ 10. $(lsb_release -cs) \ 11. stable" 12. $ sudo apt-get update 13. $ sudo apt-get install -y docker-ce 14. $ sudo usermod -a -G docker `whoami` 15. $ sudo systemctl start docker 16. $ sudo systemctl enable docker 3.2 MON Frontend The user interface of the MON component is responsible for interacting with the user in order to let him/her access the services provided by the backend. 11 / 23

The requirements of the MON Frontend deployment are exactly the same as for the MON Backend. The Linux distribution Ubuntu 16.04 or above shall do as operating system and if deploying in Docker, a recent installation of Docker Engine is required. 12 / 23

4 Deployment 4.1 MON Backend For installing the MON Backend with Docker, a recent version of the subcomponent s source code and Dockerfile are required. To get a recent version of it, please use the following download link and password: Link: http://go.abelssoft.de/crema_mon1 Password: crema_reviewer For installing the MON Backend, a shell to the server is required i.e. via an active SSH connection. The backend s source code contains its corresponding Dockerfile to build the Docker image. The following commands must be executed from the mon_services folder to build and run the image of MON Backend. $ docker build -t mon-engine. 4.2 MON Frontend The same way as installing the MON Backend, an SSH connection to the server shell is required. The MON Frontend subcomponent source code contains a Dockerfile to build a new Docker image. In detail, the Docker image will fire up an nginx webserver and delivers the component automatically. The following command must be executed from the mon_web_interface folder to build the image of the web interface: $ docker build -t mon-www. From a user perspective, no installation is required. The MON Frontend can be accessed with a regular web browser by calling its URL (provided by system administrator) if JavaScript is enabled. The component has been tested on the following web browsers: Google Chrome (Windows, Mac, Linux) 56.0.2924.87 Firefox (Windows, Mac, Linux) 46.0.1 The second prototype of the MON Frontend is available at http://go.abelssoft.de/crema_mon2 (Password: crema_reviewer). 13 / 23

5 Execution and Usage 5.1 Execution 5.1.1 MON Backend When the Docker image of the MON Backend is built, the following command needs to be typed in order to launch the Docker image. $ docker run -d -p 31700:31700 mon-engine The services of the MON subcomponent should now be available at <serveraddress>:31700, where port 31700 should be an open port on the server. 5.1.2 MON Frontend The execution of the frontend is similar to that of the backend. The only difference is the forwarding port that should be different. $ docker run -d -p <PORT>:80 mon-www The web interface of MON component should now be available at <serveraddress>:<port>, where <PORT> is an available port on the server (e.g. 80). To access the MON Frontend, the corresponding URL (configured by system administrator) needs to be called via a web browser. The browser window content looks like the following screenshot (Figure 3): Figure 3: MON Frontend in Web Browser Window An already deployed version of the MON Frontend can also be found as a sub-component of the CREMA-Dashboard at: https://dashboard.crema-project.eu/mon 14 / 23

5.2 Usage 5.2.1 General User Interface Structure Figure 4 shows the user interface of the MON Frontend. First, the red area highlights the Main Menu Bar, which provides access to the general functionalities of the MON component, e.g. creating a new business rule. The green area contains information about the rules engine status and controls for starting and stopping it. In this second prototype, the data consumer is always listening for new messages from the message bus. Main Menu Bar Rule Engine Status 5.2.2 Main Menu Bar Figure 4: General Structure of MON User Interface 1 2 3 4 5 Figure 5: Main Menu Bar The main menu bar (see Figure 5) provides access to the basic functionalities of the MON Frontend. Those are accessed by clicking on the corresponding option and are listed below: Home (1) Business Rules (2) Thresholds (3) Process Status (4) Alarms (5) 5.2.3 Rules Engine Control Area Figure 6: Rules Engine Control Area 15 / 23

The rules engine control area (see Figure 6) shows the current status of the rules engine. The left button s purpose is to start the rules engine and it will be deactivated when the engine is running. The other button, on the right, is for stopping the rules engine and it will not be clickable when the engine is stopped. 5.2.4 Business Rules Panel Rules Deletion Rules Creation Rules Editing Rules Loading Figure 7: Business Rules Panel Figure 7 shows the Business Rules Panel, which provides an easy way for the user to preview all available rules. These rules have been previously created and stored in the CRI. This panel allows the user to create new business rules (in green), to edit existing ones (in red), and to remove them (in yellow). Any of these actions involves another operation in the CRI. After modifications have been made in this panel, the user can upload these rules to the rules engine through the button highlighted in purple. 5.2.4.1 Business Rules Creation The form showed in Figure 8 is designed for creating new business rules. The user has to insert the name of the rule, its description if she/he deems appropriate, the corresponding process instance, and at least one and at most four conditions. For creating the conditions, the user has to choose variables, thresholds and logic, comparative and arithmetic operators, according to the requirements of the scenario. These rules are stored in the CRI from where they can be retrieved by the rules engine. 16 / 23

5.2.4.2 Business Rules Editing Figure 8: Rules Creation Form The form designed for editing already existing rules (see Figure 9) is the same as the one for creation. All the information of the rule is retrieved from the CRI and is displayed to the user so they can change what they estimate appropriate. 17 / 23

Figure 9: Rules Editing Form 5.2.5 Thresholds of Key Performance Indicators Panel Figure 10: Thresholds of KPIs Panel 18 / 23

Figure 10 shows the Thresholds of Key Performances Indicators Panel, which provides an easy way for the user to preview all thresholds of available KPIs. Those that are listed have been previously created and stored in the CRI. This panel allows the user to create new thresholds (in green), to edit existing ones (in red), and to remove them (in purple). Any of these actions involves another operation in the CRI. 5.2.5.1 Thresholds Creation Figure 11: Thresholds Creation Form The form showed in Figure 11 is designed for creating new thresholds of key performance indicators. The user has to insert the name of the KPI, its description if they deem appropriate, the threshold value, and the corresponding type of value. These thresholds are stored in the CRI from where they can be retrieved by the rules creation and edition forms. 5.2.5.2 Thresholds Editing As with the forms of business rules, the form designed for editing already existing thresholds (see Figure 12) is the same as the one for creation. All the information of the threshold is retrieved from the CRI and is displayed to the users. 19 / 23

5.2.5.3 Thresholds auto-update Figure 12: Thresholds Editing Form The threshold value is set the first time by the machine builder expert. The BDA component consumes the data and analyses it. Depending on the outcome of this analysis BDA may suggest to adjust these thresholds. When this button is pressed, the MON component gets this suggestion from BDA and updates it to the new value. 5.2.6 Process Monitoring Panel Figure 13: Process Monitoring Panel Figure 13 shows the panel with the current status of all processes that are currently running for the selected use case in the CREMA platform. The PRU component publishes the updates of every process to the Message Bus. The Monitoring component, which is subscribed to these updates, processes these messages and keeps a list with the state of the processes. Process id (1) shows the id of the process. Name (2) shows the name of the process. Activated (3) shows a visual tip for knowing if the process is running or has already finished. 20 / 23

5.2.7 Alarms Panel Figure 14 shows the Alarms Panel, which provides an easy way for the user to quickly preview an alarms log, showing both active and deactivated alarms. Those that are listed have been previously triggered and stored in the CREMA Cloud Storage (CRI). By default, the alarms are categorised as a function of their importance and if they are active, alarms are highlighted in red (Critical alarm) or in orange (Warning alarm). Furthermore, the user can filter the results by a date range (in green in the Figure 14) and look at the events data that triggered the alarms (clicking the buttons remarked in red in the Figure 14). The Maintain buttons (in purple) that are on the right side have the purpose of starting the maintenance process of each alarm. When any of these purple buttons is clicked and the maintenance process is started, the corresponding alarm is deactivated. Filtering by Date Creation Maintenance Process Start Show Alarm Data 5.2.7.1 Alarms Filtering by Date Range Figure 14: Alarms Panel As it has already been mentioned, the user can filter the alarms visualisation by a date range. Figure 15 shows how users can activate this filter by clicking the checkbox and choosing the start and end dates. 21 / 23

5.2.7.2 Alarms Data Figure 15: Filtering Alarms by Date Range The users can moreover look at the information related to each of the alarms that have ever been triggered. As Figure 16 shows, on one hand, this information contains data only associated with the alarm, such as the timestamp, the machine, which needs the maintenance, and the location of this machine. On the other hand, it contains the data of the event that has triggered the corresponding alarm which, in turn, allows both user and the CREMA component BDA to analyse it. Alarm Data Event Data Figure 16: Example of Alarm Data and Corresponding Event Data 22 / 23

6 Feature Status The following table shows the features the MON component should have at the end of the development, and the individual status of every single planned feature is displayed. The features from the table below are all extracted from the deliverables D3.2 (Functional Specification) and D3.3 (Technical Specification). Table 1: Feature Timeplan Comparison Requirement of MON Prototype II ID / Source Priority Status Comment Create rule, Read rule, Update rule, Delete rule MON_F010 Must Done Create KPI, Read KPI, Update KPI, Delete KPI MON_F020 Must Done Select data wrapper MON_F030 Must Done Generate alarm MON_F040 Must Done Notify alarm MON_F050 Should Done Check alarm MON_F060 Must Done Get Calculated KPI MON_F070 Nice-To-Have Done 23 / 23