SpringerLink
Book Title Service Oriented, Holonic and Multi-agent Manufacturing Systems for Industry of the Future Series Title
Chapter Title An “Additive” Architecture for Industry 4.0 Transition of Existing Production Systems
Copyright Year 2020
Copyright HolderName Springer Nature Switzerland AG
Corresponding Author Family Name Tavola
Particle
Given Name Giacomo
Prefix Suffix Role Division
Organization Politecnico di Milano
Address Via Lambruschini 4/b, 20156, Milan, Italy
Email giacomo.tavola@polimi.it
Author Family Name Caielli
Particle
Given Name Andrea
Prefix Suffix Role Division
Organization Politecnico di Milano
Address Via Lambruschini 4/b, 20156, Milan, Italy
Email andrealuigi.caielli@polimi.it
Author Family Name Taisch
Particle
Given Name Marco
Prefix Suffix Role Division
Organization Politecnico di Milano
Address Via Lambruschini 4/b, 20156, Milan, Italy
Email marco.taisch@polimi.it
Abstract Industry 4.0 is nowadays the reference paradigm for production system implementation. The reasons lay in several motivations, among which the product/process data availability. This is paramount in supporting product tracking and tracing, feeding optimization applications, enabling sophisticated maintenance approaches and in monitoring resources and energy consumption in a sustainability perspective. While the setup of “green field” implementations is usually easier and well defined, problems arise when there is an existing system with physical shop-floor devices, applications and on-going production processes that
implementation strategy and a system architecture able to upgrade an existing production system to “Industry 4.0 compliant” status, keeping into account features and characteristics of said system, and applications without direct intervention (software or hardware) on the system and without perturbations of any on-going business. The proposed AI40A (Additive I40 Architecture) is structured on three basic components of: Data collection, Data transfer and Condition detection and trend forecasting. Each component and sub-module can be relocated individually on physical servers, cloud or edge computing virtual machines, based on availability or resources, computational needs or security reasons. As proof of concept, a prototype of the Additive Industry 4.0 Architecture that is implemented in Industry 4.0 Lab (I4.0Lab) of the School of Management of Politecnico di Milano in Bovisa (Milano) Campus will be shown. Two industrial applications are currently deployed on top of it: Production Rescheduling on Condition and Prognostic Maintenance based on Condition Regression with AR (Augmented Reality) support.
Keywords (separated by '-')
Transition of Existing Production Systems
Giacomo Tavola(&), Andrea Caielli, and Marco Taisch Politecnico di Milano, Via Lambruschini 4/b, 20156 Milan, Italy
{giacomo.tavola,andrealuigi.caielli, marco.taisch}@polimi.it
Abstract. Industry 4.0 is nowadays the reference paradigm for production system implementation. The reasons lay in several motivations, among which the product/process data availability. This is paramount in supporting product tracking and tracing, feeding optimization applications, enabling sophisticated maintenance approaches and in monitoring resources and energy consumption in a sustainability perspective. While the setup of“green field” implementations is usually easier and well defined, problems arise when there is an existing system with physical shop-floor devices, applications and on-going production processes that cannot be disturbed or interrupted, and need to be interfaced. This paper is aiming to define an implementation strategy and a system architecture able to upgrade an existing production system to “Industry 4.0 compliant” status, keeping into account features and characteristics of said system, and applications without direct intervention (software or hardware) on the system and without perturbations of any on-going business. The proposed AI40A (Additive I40 Architecture) is structured on three basic components of: Data collection, Data transfer and Condition detection and trend forecasting. Each component and sub-module can be relocated individually on physical servers, cloud or edge com-puting virtual machines, based on availability or resources, computational needs or security reasons. As proof of concept, a prototype of the Additive Industry 4.0 Architecture that is implemented in Industry 4.0 Lab (I4.0Lab) of the School of Management of Politecnico di Milano in Bovisa (Milano) Campus will be shown. Two industrial applications are currently deployed on top of it: Production Rescheduling on Condition and Prognostic Maintenance based on Condition Regression with AR (Augmented Reality) support.
Keywords: Industry 4.0
IntegrationAdditive architecture5GIoT1
Introduction
The transformation towards Industry 4.0 paradigm poses the challenge of imple-menting, on-top of an existing infrastructure, a radically new vision of the production system. Two main aspects are involved:
1. Data that were used toflow in hierarchical way across different levels (see Fig.1on the left) are now available to all modules.
AQ1
© Springer Nature Switzerland AG 2020
T. Borangiu et al. (Eds.): SOHOMA 2019, SCI 853, pp. 1–12, 2020.
https://doi.org/10.1007/978-3-030-27477-1_20
2. Decisions that were taken at upper levels by application modules are now seman-tically considered at any level, even at physical levels, where intelligent devices or CPS (Cyber Physical Systems) [1] are actors in such process.
Another challenge is represented by the impact of the organizations of such transformations, encompassing not only technical and organizational aspects, but human and leadership ones as well. These challenges lead nowadays to an expensive, time and effort consuming way to integrate an existing plant in the Industry 4.0 paradigm, which is usually the main obstacle barring factories from becoming com-pliant with the new technology. From these issues, the need arose for a solution which is able to overcome all these problems in a simple way.
This paper aims to present a possible solution for an additive architecture that, exploiting the new technologies available, allows for a non-invasive, simple and direct way to make a plant Industry 4.0 compliant. Said solution had been named AI40A (Additive Industry 4.0 Architecture).
Thefirst chapter will present in details the steps and requirement that have to be taken into account when trying to apply the proposed Architecture. The second chapter presents the Architecture itself in all its components. The third chapter describes the implementation in the I4.0Lab [2] and the projects that orbit around said Architecture, manly the 5G project. Finally, some remarks on the proposed architecture will be made in the conclusions.
2
Digital Transformation: Steps and Requirements
Before starting a digital transformation, it is fundamental to identify AS-IS situation of the candidate plant to properly address technological implementation and organizational transformation. An existing production system can be categorized considering its “Industry 4.0 maturity” according to different aspects. Transformation processes need to be addressed under different perspectives. At Politecnico di Milano, a methodology named Dreamy [3] was developed to assess maturity according to Technological, Operational and Organizational coordinates of production system. An example of this approach and assessment was developed in the context of European funded projects
Fig. 1. From hierarchical to decentralized [1]
(PERFoRM [4]). The proposed architecture is utilizing outputs from Dreamy method-ology to identify technological prerequisites. On the other side, the AI40A is suitable to be implemented according the transition directions suggested by the above-mentioned methodologies [5].
In order to apply the AI40A, some technological enablers are required. The fol-lowing list reports the mandatory components:
1- Process monitoring and control are managed by a PLC-based system compliant with industrial standards [6].
2- Thefield or shop-floor is exposing information in an open and transparent way utilizing OPC-UA [7] and compliant to IEC 62541 standard.
3- All devices (Machines’ control logic, PLC, etc.) are connected via a TCP-IP net-work infrastructure. Test implementation at I40Lab utilizes three totally equivalent alternatives: IEEE 802.3– Ethernet, 802.11-WiFi and 5G experimental connection. Contrary to thefirst two alternatives, 5G is not yet a standardized technology and its utilization is mainly experimental. The selection of a specific communication standard for physical and data link levels (ISO OSI [8]) depends upon the avail-ability of infrastructure andfield conditions.
4- In order to have complete information of the status of production process and products’ information the presence of a MES (Manufacturing Execution System) [9] is necessary to which it is possible to establish a 2-way communication via a standard (e.g. SOAP) or proprietary protocol.
Each of these prerequisites needs to be evaluated and validated before AI40A implementation.
The traditional data hierarchy of the Manufacturing Systems based on the CIM Pyramid or ISA95 (see Fig.1 - From Hierarchical to Decentralized [1]) model is radically changed in the perspective of CPPS (Cyber Physical Production System). Now data accessibility and their associated granularity are attributes exposed at any level of the production process to monitoring and control the environment.
Key features of the proposed architecture are:
• It is not invasive since it is totally additive to the existing systems;
• There is no need to change existing code (on field devices or applications); • No hardware modification or wired connection to field equipment is needed, only
power supply to sensors is required. In case of LORA [10] IEEE 802.15.4 g or LowPAN [11] IEEE 802.15.4 devices’ connection to power grid is not even necessary;
• It is able to monitor a number of field parameters by collecting data via low cost sensors or interfacing existing OPCUA [7] infrastructure;
• Information can be handled asynchronously (via a Real Time data distribution bus based on MQTT - Message Queue Telemetry Transport- protocol) and syn-chronously (via a persistency infrastructure based on MongoDB [12], a document oriented database specifically oriented to flexible management of IoT data) and made available to multiple applications and functions, in a standard format (JSON), in order to sustain multiple applications or functions;
• It is scalable in terms of collection speed rates, data volumes and number of data collection points;
• It is based on open standards and open source solutions, allowing complete access to data and connection with other data repositories (e.g. PLM, ERP, etc.); • It is cost effective as based on open sources software and utilizes open architecture
hardware (e.g., Raspberry PI) forfield interfacing.
3
Additive I40 Architecture
In order to achieve the above-mentioned objectives of “non-invasiveness”, cost reduction, integration and monitoring, the following approaches were considered for architecture design and components selection (Table1):
Table 1. Objectives and consequent approaches
Objective Approach
Non“invasive” collection of various data type from the physical environment
A Raspberry PI [13] based software module was developed to collect information both from the physical level and for accessing data present in the existing system of PLCs. To such purpose the stack developed on Raspberry PI is able to drive various commercial sensors (I2C [14], SPI [15]) able to measure different values as vibration, acceleration, temperature. It is also able to directly collect data from the OPCUA environment of the equipment [16]
Reduce cost for sourcing, installation and development of data collection
Raspberry PI Model 3 system is a powerful and inexpensive standard platform for application development. A broad community of developers is working on this platform, providing a variety of software components for data collection and communication. Cheap devices can be connected very easy to it and software development IDE allows simple SW development and performance optimization. Reduced dimensions and robustness of existing hardware configuration allow installation in harsh environments. Embedded Ethernet and WiFi interfaces allow easy network connection. Other components of the architecture are OpenSource modules (e.g. MQTT Mosquitto, MongoDB, GoogleNet, etc.)
(continued)
AQ2
The basic components of the AI40A are:
• A general-purpose Python module able to drive several sensor types via I2C, SPI, USB buses running on a Raspberry PI Model 3 (Debian distribution) box. In Fig.2
- non the left the Raspberry PI box with few sensors connected on and on the right the drilling station (one of the stations composing the I4.0Lab) with the added sensors.
The following table shows the type of supported sensors.
• A software module able to elaborate and store information in a MongoDB repository.
• A software module able to generate CNN (Convolutional Neural Network) struc-tures out of a number of observations for further recognition of events and trends
Table 1. (continued)
Objective Approach
Integration in existing manufacturing
shop-floor environment All components of architecture are fully IPcompliant and support a number of ISO level 1 and 2 stacks (802.3 Ethernet, 802.11 WiFi). 5G technology experimentations were done in prototype environment at I40Lab in the context of UC31 [17] of the Italian Government [18] 5G test initiative. It is a novel experience of adoption of this communication technology in the manufacturing environment. Thanks to full OPCUA utilization with existing monitoring and control systems, no change to software on PLCs or wired connection with them was required
Integration in existing manufacturing applicationenvironment
One of the key features of AI40A is the possibility to be“added” to existing
environment. Data are circulated and distributed on MQTT architecture, a well know and adopted data communication system for process monitoring and control [19]. Data collected from thefield are formatted according JSON format for easy interpretation, distribution and correlation
Advanced monitoring of process dynamics, semantic data annotation, optimization and maintenance
Data collected from sensors are synchronously or asynchronously available for elaboration. The experimentation developed at Politecnico di Milano include processing by a CNN
(Convolutional Neural Network) [20] engine for pattern recognition of operational conditions to reschedule production process. Evaluation of system evolution is achieved via analysis of collected data and regression forecasting [21]
• A software module to analyse each new observation from sensors, classify and correlate them
• A software environment to deploy in a distributed environment the production solution.
Figure3 depicts the AI40A structure with the listed SW components, plus addi-tional tools and the main message exchangeflows.
On the left side the existing plant infrastructure is represented. The OPCUA module exposes process and plant data, which can be collected by a virtual sensor implemented in Python on the Raspberry PI. The utilization of these data allows correlating plant/PLC data with other data collected by physical sensor (see below). On the other hand, they can be utilized to build a complete digital representation of the process. This flow is identified with (A).
The OPCUA module of the plant is also exposing information able to control the data collection process. In fact, it is extremely inefficient to gather data on a continuous base, since this would only generate huge network traffic and useless storage occu-pancy. In the proof of concept, data are collected by sensors on a workstation only when a product is being processed in that workstation. Thisflow is identified with (B). The physical dynamics of the plant non collectable from OPCUA platform are con-nected by real sensors installed on the machinery. Currently a number of drivers to interface various sensors on different bus types were developed (as shown in Table2). Supported buses are I2C, SPI and USB, while the implemented sensors are able to collect vibrations, accelerations, sounds, temperature, humidity and images. The considered
Fig. 2. Raspberry PI implementation and drilling station at I40Lab-POLIMI Table 2. Supported sensors type
1 USB piezo vibrator sensor
2 I2C/SPI bus synchronous accelerometer 3 Temperature and humidity
4 I2C/SPI bus asynchronous accelerometer
5 Vibrator (is a special type able to generate a controlled disturbance to the monitored process)
6 Access to OPCUA variable on host system– ‘virtual’ sensor 7 USB camera (frames or streams)
sensors are low cost and are intended to be installed without need to interact with existing infrastructure both in terms of electrical or software connection; they are only connected to Raspberry PI boxes. Thisflow is identified with (C) in Fig.3.
The existing infrastructure includes also the MES (Manufacturing Execution Sys-tem) at the top left.
The control of the sensors is carried out by Raspberry PI boxes (identified with (1) in Fig.3) on top of which is a standard Python module, which is able to control each sensor type and to synchronize operations with the physical line. The configuration of a specific sensor is done via the production line JSON configuration file (LineCfg.json). This file defines the number of workstations in the line, and which sensors are present in each workstation. Here follows an example of saidfile, describing sensors connected to a workstation (number 2 named“Magazine”) and controlled by a Raspberry PI (Box 1). It controls 2 sensors; one is an accelerometer (whose Sensor Type - S_T– is 4) and the second one is a virtual sensor (S_T: 6), which reads the OPCUA tag “ns = 2;i = 2”. Box parameters specify the Raspberry PI unit where the sensor control is deployed; multiple sensors can be controlled by a single box.
Fig. 3. AI40A Architecture Components and Connection
{
"WorkStation":2, "Name":"Magazine", "Folder":"WKS2", "Sensors":[ {"Box": 1,"Status": "On","S_N": 1,"S_T": 4,"MQTT_Server":
"192.168.1.85","MQTT_Port": 1883, "MQTT_Batch": 200, "OPCUA_Server": "opc.tcp://192.168.1.85:4840","OPCUA_Tag": "ns=2;i=5","OPT1": ""}, {"Box": 1,"Status": "On","S_N": 2,"S_T": 6,"MQTT_Server":
"192.168.1.85","MQTT_Port": 1883, "MQTT_Batch": 200, "OPCUA_Server": "opc.tcp://192.168.1.85:4840","OPCUA_Tag": "ns=2;i=5","OPT1":
"ns=2;i=2"}] }
In the samefile, the MQTT_Server and MQTT_Port identify the MQTT broker to which to connect, while the OPCUA_Server identifies the OPCUA server to syn-chronize on or to read from.
Each Box is connected via MQTT protocol with the rest of the architecture via a flow identified with (D) in Fig.3. The reason for selecting the MQTT protocol is due to his lightweight, the efficiency and flexibility specifically suited for IoT data collection. The TCP transport layer can be implemented on a number of physical layers, 802.3 Ethernet Cable, 802.11 WiFi, LORA.
As specified above, data communication utilize a MQTT broker (for the I40Lab implementation Mosquitto [22] implementation was used). Data persistency is imple-mented on a MongoDB platform [12]. Raw data from sensors are collected and pro-cessed by Formatter module (identified with (2) in Fig.3). Here, raw data collected are structured in a JSON format named“RUN”, describing a self-contained data set related to a specific event in the field, e.g. single product operations on a specific machine or a fault condition. Here follows an example of a RUN for data collected by a 3-axis accelerometer, with sampling data frequency at 200 Hz, during a working cycle on a drilling machine: "Body":[{"a_x":1.01,"a_y":-0.024,"a_z":0.06}, {"a_x":1.018,"a_y":-0.017,"a_z":0.059}, {"a_x":0.969,"a_y":0.004,"a_z":0.058}, …..… {"a_x":0.935,"a_y":-0.002,"a_z":0.027}, {"a_x":1.011,"a_y":-0.051,"a_z":0.062}], "Footer":{"Date":"2019-03-11 10:08:04.443897", "Time":1552295284.444036,"Signal":"EoD", "W_N":3,"S_N":1,"S_T":4,"Fs":200}}} {"Run":{"Header":{"Date":"2019-03-11 10:07:52.423101", "Time":1552295272.423189,"Signal":"SoD", "W_N":3,"S_N":1,"S_T":4,"Fs":200},
The JSON formatted output data is, from one side, stored in MongoDB (flow M3), while on the other side it is sent to the Reasoner module (identified with 3 in Fig.3) via the flow M2. The Formatter Module is also semantically annotating data, enabling correlations between streams.
The Reasoner Module is the core engine of the evaluation of data coming in real time from the field. It implements a data classification algorithm based on neural network approach. For each data RUN received, a CNN is able to recognize specific data patterns coming fromfield sensors, allowing for a classification of the process in ‘Correct’ or ‘Fault’. Reasoner was developed utilizing MATLAB functions for CNN management. MATLAB runtime libraries can be deployed in easy way in operational environments. Based on information classification from sensors, Reasoner generate (M5) a representation of each workstation status that can be displayed on different type of devices by Andon module (4).
In case problems arise requiring reconfiguration of the production process, a message is sent (M4) to the MES Interface module, which is taking care to instruct (E) Plant MES to reschedule production. Policies for product rescheduling are coded in the MES-Interface module as part of the application management of the process.
Periodically each CNN is (re)generated utilizing historical data provided by the module Mongo Query (6), which collects batch data from the MongoDB database and (I1) fed them (I2) to the CNN Train (7), which trains a Neural Trained Network, based on GoogleNet [23], with said data.
4
I4.0Lab Implementation and 5G Experiment
In I40Lab of Politecnico di Milano an experimentation connecting sensors with a 5G infrastructure was tested, implementing a high speed, low latency and secure sensors connection. In Fig.4, a“classical” deployment of the architecture in a wired or WiFi environment set in the I4.0Lab is depicted, while in Fig.5 such implementation is represented, where the 5G infrastructure connects wireless sensors.
The ‘non-5G’ implementation connects ‘data collection’ items (the sensors and Raspberry PI) to the line and the ‘processing’ items, which are hosted in the Lab servers. This is a quite simple and straight-forward implementation, and highlights the simplicity and modularity of the solution.
Modularity allows for different components to be deployed among physical servers, cloud or edge VM (Virtual Machines). Such implementation can benefit of characteristic 5G features [24]. Among them are:flexibility and mobility for production and logistics
Fig. 4. 802.3-802.11 network connection
applications; extreme reliability (99.999%) and low latency (less than 2 ms end-to-end) in communications; multi-access Edge Computing architectures with the possibility for hosting more real-time critical applications near end-points to minimize latency.
In addition, 5G network slicing feature allows creating factory-specific network slices in which all critical data remain inside the factory. High performance network-assisted geo-localization technology will also contribute to the efficient management of supply chains and related logistics applications, as envisaged module for Augmented Reality supported maintenance operations. An example of mobile application is the “Andon” module, identified with 4 in Fig.3, implementing a dashboard with detailed machine status and maintenance info. This application can be utilized on mobile (or wearable) devices (see bottom left in Fig.5).
AI40A allows deployment of application modules on physical servers, cloud infrastructures (VMs) or -as specified in Fig.5. - 5G network connection - utilizing Edge computing capabilities provided by the 5G infrastructure.
As can be seen by a comparison between Figs.4 and 5, in order to adapt the I4.0Lab architecture to the 5G it was enough to simply “move” some of AI40A modules into different machines (real or virtual–VM), still leaving the plant untouched.
5
Conclusions
AI40A– Additive Industry 4.0 Architecture is aiming to provide a standard and light weight platform for I40 paradigm adoption in existing production environments. This is often one of the major road-blocks to adoption of I40 technologies in operational environments where risks to impact on-going business are critical.
Fig. 5. 5G network connection
Communication, data storage and data representation standards utilized would allow a simpler development of further application layers of top of it or integration with existing tools.
Different data sources (sensors’ data, machines’ status, and products’ related data) are collected according the same framework and stored in a common data persistency repository without any interference with the existing working environment. All col-lected data are synchronized on the same time clock allowing precise time correlation. Distributed agents allow deploying the architecture in aflexible way depending on the needs of a specific case. Possible configurations span from centralized to com-pletely distributed in multilayer edge/cloud environments.
The Manufacturing Team at the School of Management of Politecnico di Milano is working on new prognostic and forecasting modules for production optimization and predictive maintenance. The Manufacturing Team is also working on full adoption of 5G communication and edge processing technologies in industrial production envi-ronments validating their utilization in manufacturing envienvi-ronments.
References
1. Scorpius project (2016).www.scorpius-project.eu
2. Industry 4.0 lab www.industry40lab.org (2019).www.industry40lab.org
3. De Carolis, S.: Guiding Manufacturing Companies Towards Digitalization a Methodology for Supporting Manufacturing Companies in Defining their Digitalization Roadmap (2017) 4. PERFoRM Project www.horizon2020-perform.eu (2014).www.horizon2020-perform.eu
5. Calà, A., Boschi, F., Luder, A., Tavola, G., Taisch, M.: Migration towards digital manufacturing automation - an assessment approach. In: The 1st IEEE International Conference on Industrial Cyber-Physical Systems (ICPS 2018), Saint-Petersburg, Russia (2018)
6. IEC 61158-1, Industrial communication networks - Fieldbus specifications - Part 1: Overview and guidance for the IEC 61158 and IEC 61784 series (2014)
7. OPCUA Foundation, OPCUA Foundation (2019).https://opcfoundation.org/
8. ISO, ISO/IEC 7498-1 (1994).https://www.iso.org/standard/20269.html
9. IEC 62264, IEC 62264 (2015)
10. LORA Alliance https://lora-alliance.org/ (2017).https://lora-alliance.org/
11. lowpan http://6lowpan.tzi.org/ (2019).http://6lowpan.tzi.org/
12. Mongo DB, Mongo DB (2019).https://www.mongodb.com/
13. Raspberry PI, Raspberry PI (2019).https://www.raspberrypi.org/
14. I2C Org www.i2c-bus.org (2019).www.i2c-bus.org
15. Raspberry PI SPI Bus, Raspberry PI SPI Bus (2019)
16. FreeOpcUA, FreeOpcUA (2019).https://github.com/FreeOpcUa/
17. working-in-5 g-industry-40, working-in-5 g-industry-40 (2018). www.milanodigitalweek. com/eventi/working-in-5g-industry-40
18. MISE 5G experimentation, MISE 5G experimentation (2018). https://www.mise.gov.it/ images/stories/documenti/Avviso_pubblico_16_marzo_2017_-_Sperimentazione_5G.pdf
19. IBM, MQTT for IoT (2019). https://developer.ibm.com/blogs/open-source-ibm-mqtt-the-messaging-protocol-for-iot/
20. MATLAB CNN, MATLAB CNN. https://it.mathworks.com/solutions/deep-learning/ convolutional-neural-network.html
21. MATLAB, Predictive Maintenance (2018). https://www.mathworks.com/products/ predictive-maintenance.html
22. Eclipse Mosquitto, Eclipse Mosquitto (2019). https://projects.eclipse.org/projects/ technology.mosquitto
23. MATLAB Googlenet, MATLAB Googlenet (2019). https://www.mathworks.com/help/ deeplearning
24. Gupta, R.K.J.A.: A Survey of 5G Network: Architecture and Emerging Technologies. IEEE (2016)
Book ID : 482823_1_En Chapter No : 20
Please ensure you fill out your response to the queries raised below
and return this form along with your corrections.
Dear Author,
During the process of typesetting your chapter, the following queries have arisen. Please check your typeset proof carefully against the queries listed below and mark the necessary changes either directly on the proof/online grid or in the ‘Author’s response’ area provided below
Query Refs. Details Required Author’s Response AQ1 This is to inform you that corresponding author has been identified as per the
information available in the Copyright form.
AQ2 Please check and confirm if the inserted citation of Table 1 is correct. If not, please suggest an alternate citation.
