Data Acquisition using Arrowhead Framework for Condition Based Maintenance of Industrial Equipment

Johan Jansson Högberg

Computer Science and Engineering, master's level 2019

Luleå University of Technology Department of Computer Science, Electrical and Space Engineering

ABSTRACT

As Industry 4.0 and Internet of Things are established across factories and enterprises, the interest for learning more about these concepts and the possibilities they provide for condition based maintenance is expressed by a factory in Sweden. By addressing the aspects of Internet of Things and Industry 4.0, a system for performing data acquisition from sensors in an industrial environment is developed using Arrowhead Framework. This framework is evaluated around its suitability for this kind of application, and re- garding what the framework may provide to the factory compared to other solutions and systems. A solution featuring a system based on Arrowhead Framework is developed, implemented, and briefly tested. The system is successful in performing data acquisition, and Arrowhead Framework is considered a viable option that may be used to provide a system tailored for different purposes, presumed that the factory is prepared to allocate resources on developing a solution around it.

iii

PREFACE

This thesis work has been a challenging, but yet greatly rewarding experience for me. I am grateful to have had the possibility to perform my thesis work within this industry, and being able to work with all the people involved here. I have been taught many things and experiences, which I am glad to be able to bring with me to future workplaces. I would like to thank my supervisor Ulf Bodin at Lule˚aUniversity of Technology and company supervisor Isak Grimholm for providing me with the guidance needed to realise this thesis work. I would like to thank Jens Aslin˚ for the great cooperation we have had, as well as the guys at IFM and the employees of the IT department at the factory who have supported me by providing tips, help and material needed for this work. Last but not least, I would like to thank PhD student Cristina Paniagua at Lule˚aUniversity of Technology for helping me solve problems I have encountered while working with Arrowhead Framework.

Johan Jansson H¨ogberg

v

CONTENTS

Chapter 1 – Introduction 3 1.1 Background ...... 3 1.2 Motivation ...... 4 1.3 Problem Definition ...... 4 1.3.1 System Requirements ...... 4 1.3.2 Topic Related Questions ...... 5 1.4 Delimitations ...... 5 1.5 Related Work ...... 6 1.5.1 Components and services of Industry 4.0 and IoT ...... 6 1.5.2 Usage of Arrowhead Framework in similar applications...... 6 1.5.3 Similar project previously held at the factory ...... 6

Chapter 2 – Method 9 2.1 Method ...... 9 2.1.1 Research Methodology ...... 9 2.1.2 Evaluation ...... 10

Chapter 3 – Theory 13 3.1 Industry 4.0 ...... 13 3.2 Internet of Things ...... 13 3.3 Cloud- and fog computing ...... 14 3.4 Industrial automation systems ...... 14 3.4.1 ISA-95 ...... 14 3.4.2 RAMI 4.0 ...... 16 3.5 OPC and OPC-UA ...... 16 3.6 Service-oriented architectures ...... 18 3.7 Arrowhead Framework ...... 18 3.7.1 Concept ...... 19 3.7.2 Core systems ...... 19 3.7.3 Compliance and maturity levels ...... 22

Chapter 4 – Plant System 25 4.1 Transportation Buffer ...... 25 4.1.1 Transportation Cart ...... 25 4.1.2 Network structure ...... 27 4.2 Alternative Proof of Concept ...... 27

Chapter 5 – Solution 29 5.1 Solution overview ...... 29 5.2 Sensors ...... 30 5.2.1 IO-Link sensors ...... 31 5.2.2 Vibration sensors and IFM VSE100 Diagnostic electronic . . . . . 32 5.3 Arrowhead Framework components ...... 32 5.4 Connectivity towards networks and internet ...... 33 5.5 Microsoft Azure ...... 34 5.6 ThingWorx ...... 34

Chapter 6 – Results, Evaluation and Future work 37 6.1 Resulting implementation ...... 37 6.2 Evaluation and discussion ...... 41 6.3 Future work ...... 43 6.3.1 Sensors and framework components ...... 44 6.3.2 Cloud services and analysis ...... 44

Appendix A– Tables and Graphs 45

viii Abbreviations & Acronyms

AHF ...... Arrowhead Framework

API ...... Application Programming Interface

BU3 ...... The sequential buffer at the factory

CBM ...... Condition-Based Monitoring

ERP ...... Enterprise Resource Planning

IIoT ...... Industrial Internet of Things

IoT ...... Internet of Things

IR ...... Infrared

MES ...... Manufacturing Execution System

OPC ...... Open Platform Communications

OPC-UA . . . . . Open Platform Communications Unified Architecture

PLC ...... Programmable Logic Controller

PoC ...... Proof of Concept

RAMI4.0 . . . . . Reference Architecture Model Industrie 4.0

SCADA ...... Supervisory Control and Data Acquisition

SOA ...... Service Oriented Architecture

1

CHAPTER 1 Introduction

1.1 Background

Industry 4.0 and Internet of Things are two popular topics regarding the development of and evolution within industries today. The industrial digitization that is occurring enables manufacturers to more easily observe and interact with machines and manufac- turing equipment, in favour for optimizing and increasing production. One area that has benefited from this is the utilization of condition-based maintenance (CBM), where equipment is maintained with regard to its condition, rather than being maintained on a interval-basis regardless of condition. This thesis focuses on a factory that is looking to modernize and take part of the benefits from condition-based maintenance. At this factory, equipment in a certain pro- duction line is maintained on a pre-planned interval-based maintenance routine. During each maintenance occasion, the equipment is inspected manually and treated upon judge- ments from visual inspection. As the inspections are carried out by hand, humans need to physically enter the area of the equipment. Due to safety regulations, any affected production equipment may not be in operation when inspections occur. Consequently, inspections are often scheduled to occur mainly during nights and weekends, outside pro- duction hours. This in turn may lead to high operational costs in terms of expensive maintenance efforts, unforeseen repairs if malfunctions arise between maintenance occa- sions, and in case production is halted during active hours; overtime production in order to cover for lost production time. Another effect that follows from this is a larger amount of staffing as a result of installing a higher capacity to cover the maintenance and repair needs. There is also a risk of a poorer quality outcome as a result of equipment malfunc- tioning, causing direct or indirect quality impacts on the product in case equipment is not maintained properly. Apart from production impacts, malfunctions also increase the risk of injuries to persons. To be able to continue the production in an effective and competitive way in the future, the factory wishes to modernize and increase the efficiency of the maintenance, as well

3 4 Introduction as taking steps towards Industry 4.0.

1.2 Motivation

The factory wishes to advance from the interval-based maintenance that is used today and establish a condition-based maintenance routine for the equipment, as well as explore the area of Industry 4.0 and the possibilities it provides. To enable condition-based maintenance, the idea is to with the use of sensors measure parameters of the equipment which are likely to provide information that can be correlated to wear of the parts in the equipment. By storing the sensed data for the different parameters a model may be created from it. This model may be used for determining the condition of the equipment using real-time data, and finally establish a condition-based maintenance routine.

1.3 Problem Definition

The goal of this master thesis is to provide and implement a solution using Arrowhead Framework, a service-oriented software architecture developed for industrial automation. The solution shall enable data collection from sensors on legacy equipment, and store the data in a location it can be reached for processing, visualization, and analysis. A visualization platform will visualize stored and real-time sensor data. The solution shall utilize Industry 4.0 concepts as a way to demonstrate its possibilities for future interest. The targeted equipment the solution is developed for is a transportation cart in a large sequential buffer, which transports, stores, and sorts the manufactured goods between assembly lines. Furthermore, the factory has engaged a project to rebuild this sequential buffer, making it a suitable target as it more easily may be adapted to be able to utilize the solution produced from this thesis, if desired. The reason behind choosing Arrowhead Framework for this purpose is purely out of interest as it is a newly developed framework and the product of a large EU project involving many partners, including Lule˚aUni- versity of Technology. More of this in section 3.7. By performing this implementation, Arrowhead Framework is investigated and demonstrated regarding its usefulness for the factory and suitability for this type of application.

1.3.1 System Requirements Besides the general goals, there are some specifications and requests regarding the system that the factory wishes to meet. The system shall: • Be a generic IoT-platform.

• Be scalable and flexible in such way that additional hardware may be added to the system to expand its physical size and area of operation, and able to have hardware replaced or upgraded with other hardware. 1.4. Delimitations 5

• Be compliant with any sensors and adjoining systems.

• Refine and identify the data connecting it to events in the real system.

• Be compliant with legacy-equipment.

These requests are established as the factory do not want the system to be restricted for usage with only specific systems and suppliers. This strengthens the motivation for using Arrowhead Framework, as it allegedly is developed to be flexible such that it can be applied to any system or hardware, thus aligning with the points listed above.

1.3.2 Topic Related Questions

• Is Arrowhead Framework suitable for this kind of application? Is it compatible with the systems and equipment at the factory, and can it be used to deliver a satisfactory solution relative to the goals? Are there other applications which the factory may find Arrowhead useful for?

• What is it that Arrowhead can provide for the factory in contrary to the existing systems? What can the factory achieve by implementing a system based on Ar- rowhead Framework, and what needs in the system requirements above can it help realize?

• Is Arrowhead something that the factory should and could continue to implement and develop systems with? Are the engineering times and skill level required suit- able for this kind of factory? What does the different properties of scalability of this system look like?

1.4 Delimitations

The ultimate goal in this project from the factory’s point of view is to derive a model for determining the condition of different components in the production line at the factory, given sensed data, as addressed earlier. However, for the scope of this thesis, both implementing a system for data acquisition, data storage and data refining, as well as performing an analysis for deriving a condition-determining model is not a reasonable amount of work for a single thesis. This thesis will therefore only focus on acquiring and storing data from the sensors, leaving analysis and deriving of a model as future work, as this is the first and also an essential step for reaching the final goal. 6 Introduction

1.5 Related Work

1.5.1 Components and services of Industry 4.0 and IoT In [1], the essential components required for composing a simple system that can perform data acquisition and storage are reviewed. The thesis investigates the concept of Industry 4.0, and implementation of a system that acquires data from a temperature sensor and sends the data to the cloud is made to demonstrate the possibilities and principles of Industry 4.0.

1.5.2 Usage of Arrowhead Framework in similar applications. In [2], Arrowhead Framework is used as an approach for establishing a condition-based monitoring system within the mining industry, in order to combat downtime of produc- tion and increase the efficiency of the maintenance performed on the equipment. The solution delivers measured data from sensors on the equipment up to the cloud with the dynamic service composition from AHF as a key function within the system. Aggregation servers allows data transfer to cloud services while separating local and global clouds, and Mimosa data services are used to describe the measurements with a standardized information model for condition monitoring purposes.

Two different applications are presented [3], which uses Arrowhead Framework as a demonstration of the SOA-based framework and the possibilities of collaborative automa- tion between embedded devices. The first application, a monitoring- and management system for street lights, uses a smart light controller to control LED luminaries, and an adapter component to enable the light controller to offer services to the Arrowhead network. A software component and a web application are developed to provide an API and graphical user interface for accessing the light controllers. The second application, an engine block heater, is connected to an Arrowhead network using an adapter component and is controlled via a web application with a user interface. To further demonstrate the usefulness of SOA, the services developed for the two ap- plications are reused and combined for a third application which monitors luminance and temperature to control street lights and heating time for engine block heaters.

1.5.3 Similar project previously held at the factory Other projects relative to this scope has been held at the factory. One of the employees at the factory who was involved in a project that extended over several years is interviewed regarding the storage solution used in the project. The project involved data acquisition from several hundred sensors, which together generated large amounts of data every day. This data is mediated from the local sites through PLCs and placed in a system of folders on the company server, situated at another site. Methods specially developed for this 1.5. Related Work 7 project are then used to merge and refine the data which is placed in a SQL database afterwards.

CHAPTER 2 Method

2.1 Method

The sections in this chapter reviews the research methodology that is used, and presents criteria for evaluating the resulting solution.

2.1.1 Research Methodology This research addresses the implementation and utilization of Arrowhead Framework in order to create a solution that may be used within a factory for performing data acquisi- tion of industrial equipment. This implementation is also used to evaluate the suitability of the Arrowhead Framework for further usage by the factory. This method can be related to experimental implementation. A solution is created and implemented featur- ing the specific system that is subject to the research, which in this case is Arrowhead Framework. This solution is then evaluated regarding how well this system is able to achieve the desired goals and needs. There are of course other methods to evaluate the suitability of the framework that does not involve performing an implementation of it. However, as the factory ultimately wishes for an implementation of the solution towards the specific purpose as a demonstration, it would, therefore, be time-consuming to first perform a study to evaluate the framework and then implement it, rather than evaluating the framework based on an implementation directly. Furthermore, this method provides a different perspective on the implementation procedure of the framework, where prob- lems and practical complications are encountered which require solving as a part of the implementation process. This may thus provide useful insight towards the evaluation of the system that other methods might not be able to provide. This ultimately led to the choice of this method.

The work begins with researching the topic of industrial data acquisition and enterprise control. This is done in order to form an understanding of what kind of components and

9 10 Method infrastructure that are typically needed when creating a system capable of performing data acquisition in industrial environments. Related work, possible approaches and so- lutions using Arrowhead Framework, and of course the framework itself, are investigated as well. Through interviews and meetings, information is gathered regarding what equipment will be installed at the rebuild of the sequential buffer, and what equipment and services that are available at the factory today for usage with this thesis. These systems and services are researched for their compliance with other system components in terms of interfaces, protocols, and software. Arrowhead Framework is then further researched for its compliance with the existing system and equipment, future equipment that is to be used, and the solution’s relation to the goals and system requirements. To ensure compliance with Arrowhead Framework, a continuous dialogue is held with the factory regarding what sensors and accessories shall be used on the equipment for this thesis. The implementation process then begins of the equipment, services and chosen frame- work. Firstly, the most essential functionalities are implemented, such as fundamental communication between the framework and edge equipment. This includes setting up the Arrowhead core systems on the hardware, and systems for acquiring data from the sen- sors. After that, connection to data storage will be implemented, and lastly visualization of the data is set up. The system will be implemented and tested in a small scale, featuring a small set of sensors. Even though the full scale system will be implemented on the sequential buffer, the test environment may be implemented elsewhere for ease of access and practical reasons. When the implementation is completed, the solution is tested and evaluated.

2.1.2 Evaluation The goals, system requirements, and fundamental questions presented in chapter 1 lay a foundation for evaluation criteria for the resulting solution. Implementation and test of the system will be used to evaluate the solution against the criteria presented here. These criteria will be evaluated by a discussion as a follow-up on the implementation and test of the system, where the criteria and different aspects of the system will be discussed.

Criteria from fundamental solution goals The goals presented in the problem definition (section 1.3) provide concrete guidelines that the solution strives to achieve. Hence, these goals are suitable to be used as criteria to evaluate the completeness of the resulting solution.

Industry 4.0 As stated the solution shall utilize Industry 4.0 technologies, since the factory expressly wishes to ”take steps towards Industry 4.0”. This is hence a fundamental 2.1. Method 11 criterion the solution shall be built upon.

Acquisition The most fundamental step for the entirety of the solution is the ac- quisition of the data. The system must be able to acquire data in order to store any acquired data. Types of data acquisition in terms of types of sensors and applications, and acquisition frequency are to be considered here.

Storage The system shall be able to store the acquired data. Furthermore, the storage shall be accessible for processing, visualization, and analysis. Storage type, size, and accessibility are to be considered here.

Presentation While not mandatory, it is still a significant goal that the system shall be able to present the acquired data. If able to do so; the system will be evaluated regarding how it presents the acquired data, if it is able to visualize it with graphs, etc, if the data presented in real time, and if it is able to present and visualize historical data.

Criteria from system requirements

As the factory has presented requirements the solution shall satisfy, these requirements will also be used as evaluation criteria. These criteria will be used to evaluate the system as a whole, and the suitability of Arrowhead Framework for further utilization within the factory.

Generic IoT-platform The solution shall compose or utilize a generic IoT-platform, as the factory wishes to refrain from using platforms and solutions that are tied to specific vendors and providers, as a precaution to ensure that equipment of any brand may be used

Scalable and flexible When addressing scalability, there are several different aspects of scalability that may be referred to. That the system shall be scalable and flexible mainly refers to the size-, functional-, and generational properties of scalability. More precisely, the solution shall be able to have additional hardware added for which the system easily can be modified or expanded to handle, in order to increase the area of operation. Hardware and applications shall be able to be changed easily.

Compliancy The solution must be independent from usage of hardware and equipment from specific vendors. Furthermore, the solution shall be able to be applied to legacy equipment. This also refers to the heterogeneous aspect of scalability. 12 Method

Data refining To facilitate future analysis of the acquired data, the solution shall refine the acquired data in such way that it may be identified and connected to real events of the physical equipment. CHAPTER 3 Theory

This chapter presents essential theory for areas adjacent to the field of this thesis.

3.1 Industry 4.0

Since the beginning of industrial history, four major revolutions have occurred shaping the industries to what exists today, of which the fourth revolution is occurring now. The first three revolutions signify the introduction of steam- and water-powered machines during the end of the 18th century, electrical-powered machines during the beginning of the 20th century, and electronics and IT for control and automation during the late 1960s. The fourth industrial revolution, Industry 4.0, introduces the usage of the internet of things, services, and cyber-physical systems to the industries. The term Industry 4.0 was introduced in 2011 from the German initiative ”Industrie 4.0”, which purpose is to increase the digitization in manufacturing. [4, 5]

3.2 Internet of Things

The Internet of Things (IoT) is the concept of devices of various kinds, so-called ”things”, being connected to the internet or each other, providing the possibility of service- and information exchange to and from the devices. Examples of IoT-things can be household items such as a coffee brewer or a washing machine, providing information regarding their statuses and remote control possibilities to the connected user. Other examples of IoT-things might be industrial equipment such as sensors and actuators, again providing information and control opportunities to either a user or to a controller such as a PLC (Programmable Logic Controller).

13 14 Theory

3.3 Cloud- and fog computing

The term Cloud computing refers to computational processes that occur in entities formed by hardware resources in aggregated architectures, often available through services pro- vided. Cloud services are often provided over the public Internet in Public Clouds, hosted at data centres by Cloud Service Providers. Cloud services may also be available in Pri- vate Clouds, hosted on private servers for enterprises and corporations. While cloud services are often associated with providing mainly data storage, there are many cloud service providers that offer a large variety of services. Apart from data storage and other Infrastructure as a Service (IaaS) services, there are many web applications such as management, billing, corporational and public sector softwares, often referred to as Software as a Service (SaaS) [6], that are available as cloud services. Many cloud ser- vice providers also offer Platform as a Service (PaaS) services, which provide complete environments and infrastructures (IaaS) for purposes such as developing and deploying applications, building and hosting databases, performing analyses and more. It is often possible to select the services and resources that are needed and pay for only those, rather than paying for a complete package. This concept is called pay-as-you-go. [7] The main benefits of using Cloud services are that they are easily accessible from any location, and enables users and corporations to perform heavy processing- and storage operations without having to acquire the hardware or software resources for it themselves.

Fog computing is a variant of cloud computing which can be seen as an extension of the cloud towards the edge of the network. As Cloud computing is generally very centralized and great for processing large amounts of data, it is however not suitable for operations that are latency-critical. Such operations could be real-time decision making based on sensed data, or networks with distributed devices that control processes. The fog is characterized by decentralized data processing using a large number of nodes that may be distributed over a geographical location or facility. This enables for data processing and communication with low latency. As the fog can be seen as an extension of the cloud, it may also be used to enable cloud interoperability for edge devices. [8]

3.4 Industrial automation systems

This section addresses some concepts, standards, and systems used within industrial automation that are fundamental to this thesis and may be encountered later.

3.4.1 ISA-95 Which development began in the 1990s [9], ISA-95 is a standardized approach for inte- grating industrial- and enterprise control systems [10]. ISA-95 is widely used by manufac- turers today and has become a de facto standard when designing and deploying industrial 3.4. Industrial automation systems 15 computer systems [11, p. 4]. ISA-95 is an architecture based on a hierarchical structure, which typically divides the computer systems into the following five levels [9]: • Level 4 - Business Planning and Logistics level: Plant and process scheduling, supervision of material usage, deliveries and shipping. ERP systems are used here (Enterprise Resource Control).

• Level 3 - Manufacturing Operations Management level: Control of operation and process flow, analyzes and optimizes the process. MES systems are used here (Manufacturing Execution System).

• Level 2 - Monitoring and control level: Monitoring, supervisory control, and automated direct control of the process. Dis- tributed control- and SCADA systems are used here (Supervisory Control and Data Acquisition).

• Level 1 - Process level: Sensors and actuators that sense and manipulate the process.

• Level 0: The actual process that is monitored and controlled. This type of hierarchical structure within industrial automation is also commonly re- ferred to as automation pyramid, illustrated below in figure 3.1.

Figure 3.1: Illustration of an Automation pyramid. In this illustration, the field level correlate to level 1 in the hierarchy above, and the control- and supervisory levels correlate to level 2 above.

Source: RealPars B.V. 16 Theory

SCADA SCADA, or Supervisory Control and Data Acquisition, is commonly used in industrial systems for observing and controlling industrial processes. Focusing on a supervisory level of control it is essentially a software system that provides monitoring and control over PLCs and other lower-level hardware [12].

MES Manufacturing Execution Systems offer transparency between production level and busi- ness level by collecting and providing data and analysis of the industrial process. This information flow is used for resource management, planning and control of the production process [13].

ERP Residing in the top layer of the hierarchy, above MES, Enterprise Resource Planning is a complete software system used by corporations to monitor the industrial processes. By utilizing the systems from the levels below it provides information used for organization- wide planning of resources, finance, personnel, process control etc. [14].

3.4.2 RAMI 4.0 As industrial automation moves towards industry 4.0 where technologies and standards from many different fields are included, a need for combining the different fields is identi- fied. Reference Architectural Model Industrie 4.0 is a framework created by the Reference Architecture, Standards and Standardization working group within Plattform Industrie 4.0. The objective of RAMI4.0 is to combine the technologies from the different fields within industry 4.0 with their respective standards and identify the need for these. Sim- ilarly to the automation pyramid and ISA-95, the RAMI4.0 model is structured with hi- erarchical levels, but also has layers that compare the life-cycles of different areas within industries with the hierarchical levels. Examples of these areas are factories, equipment, products or orders. As the model has both layers and hierarchical level, the model has gained a three-dimensional structure, illustrated in figure 3.2. Furthermore, two more hierarchical layers have been added relative to ISA-95 and the automation pyramid; the product level, placed at the bottom below the field device level, and the connected world level, placed in the top above the enterprise level. [15, 16]

3.5 OPC and OPC-UA

Released in 1996, OPC stands for Open Communication Platforms and is an interop- erability standard used within industries to more easily enable communication between 3.5. OPC and OPC-UA 17

Figure 3.2: RAMI 4.0 structure visualizing all layers from the automation pyramid along with

Source: Zentralverband Elektrotechnik- und Elektronikindustrie e.V.

different platforms and devices. Originally, OPC was intended to provide a standardized interface for PLC protocols, such as Modbus and Profibus, to enable a more seamless inte- gration of HMI and SCADA systems towards PLCs through offering conversion between device-specific and OPC-generic requests [17]. OPC is divided into different specifica- tions, which today are referred to as OPC Classic specifications [18]:

• OPC Data Access (OPC DA), used for accessing data and transferring information.

• OPC Alarms and Events (OPC AE), used for transmitting alarms and events oc- curring, along with relating data.

• OPC Historical Data Access (OPC HDA), used for querying and analyzing histor- ical data.

Since its initial release, OPC has been further developed to meet stay competitive and meet new needs, and in 2008 the OPC Unified Architecture is released. It is a service- oriented architecture (SOA)1 which builds on the previous OPC standard. By mapping

1More about SOA in section 3.6 18 Theory the individual specifications from OPC classic into one unified architecture, OPC-UA provides the same functionality as before, yet further exceeding their capabilities and providing additional features in terms of extensibility, security, platform independence and information modelling [17, 19].

3.6 Service-oriented architectures

A service-oriented architecture is a type of architecture design developed to allow en- terprises to create expandable infrastructures that are more seamless and streamlined compared to older, more complex architectures usually developed as standalone and iso- lated systems. When using service-oriented architectures, distributed services are used to compose the system, where each service is hosted by a component in the system. A service is a software unit defined for a specific purpose or task, but can be reused and modified to fit similar purposes as they are implementation-independent. The use of services provides greater collaboration- and interoperability possibilities within the system solution [20]. Systems or components within a service-oriented architecture uses these services to perform data exchange between each other. The components are loosely coupled and use late binding when exchanging data. Loose coupling means that the components are not designed to know of each other beforehand, and information regard- ing possible communication endpoints are discovered or acquired during run-time. Late binding means that connections between two communicating components are established first during run-time when data exchange is to occur [11, p. 15].

3.7 Arrowhead Framework

Initiated through ProcessIT.eu in 2013, the Arrowhead project was a collaboration be- tween 78 partners up until 2017. The project focused on finding methods for enabling collaborative automation within manufacturing-, process-, and energy industries. The product of all this is the software framework Arrowhead Framework, developed to inte- grate and enable interoperability and collaboration between heterogeneous automation systems. [21, 22, 23] The framework is intended to address solutions for automation systems within the following five pilot domains: • Production • Smart buildings and infrastructure • Electro mobility • Energy production and end-user services • Virtual market of energy 3.7. Arrowhead Framework 19

As this thesis is performed for the manufacturing process at a factory, the scope of the thesis targets the production domain.

3.7.1 Concept Arrowhead Framework arranges communication between endpoints. These endpoints may be devices or systems within specific automation areas, for instance. The frame- work utilizes local automation clouds, where a local cloud may be purposed for a specific task. Devices and systems designed for these specific tasks are placed within their cor- responding local cloud. Communication then occurs between the devices and systems within the local clouds. Communication between local clouds may also be arranged by the framework. As Arrowhead Framework is a serviced-based architecture, the devices and services within the local clouds communicate and perform data exchange using ser- vices. The devices and systems may produce and consume services from each other by acting as service producers or service consumers. Using service producers or consumers is also the only way devices and systems can interact with Arrowhead Framework. A service producer or consumer is a piece of software, or software unit, designed to provide the product (information) of its device or system as a service to the local cloud or con- sume services from other service producers in the local cloud to its device or system. [11, Ch. 3] Service producers and consumers are connected with loose coupling and late binding, meaning that they do not know of each other beforehand and that connections between them only are established during run-time for each transmission. The approach of utilizing local clouds and the service-oriented architecture provides many benefits in terms of security, engineering time and complexity, scalability, and la- tency, as the clouds only exist locally, where access towards internet and other local clouds may be controlled and restricted. Additional service producers and consumers may easily be created and modified for specific needs or changes by reusing and mod- ifying existing software for services, as the services are implementation-independent as mentioned in section 3.6, thus improving scalability and engineering time. [11, Ch. 1]

3.7.2 Core systems The communication between service producers and service consumers within the local clouds are coordinated by the core systems residing in each local cloud, together co- operating to compose the framework core, where each core system has its own specific role. There are three mandatory core systems that are necessary to achieve fundamental functionality of the framework. Furthermore, there are optional systems, the automation core systems, that may be used to achieve additional functionality for the system. The core systems are listed below, followed by descriptions of the functionalities of the three mandatory core systems. [11, Ch. 3] 20 Theory

Mandatory core systems: Automation support core systems:

• ServiceRegistry System • Configuration System

• Orchestration System • DeviceRegistry System

• Authorization System • EventHandler System

• Gatekeeper System

• Historian System

• PlantDescription System

• QoSManager System

• SystemRegistry System

• Translation System

ServiceRegistry System

The ServiceRegistry stores information of the services available in its local cloud. It provides the ServiceDiscovery service that service providers use to publish their services. If service providers do not use this service, their services will not get registered in the ServiceRegistry, and hence neither available in the local cloud to be consumed by other systems. When a service provider publishes its service for the local cloud, the service is registered in the Service registry. If a service provider is disconnected from the local cloud its services are removed from the ServiceRegistry. [11, p. 59-60]

Orchestration System

The Orchestration System coordinates the communication and service exchange between systems in a local cloud. This is accomplished by storing orchestration requirements and computing orchestration rules. By providing an advanced service discovery, the Orches- tration System allows service consumers to retrieve service consumption patterns and endpoint information regarding produced services that are available, where consumers then may request any assigned services. The Orchestration System provides three services in its operation; the Orcestration- Management service, which provides management for the connection rules of the services, the OrchestrationStore service, which provides orchestration rules to application systems, and the OrchestrationCapabilities service, which provides the number of consumers avail- able for consumption of a specific service type. [11, p. 62-63] 3.7. Arrowhead Framework 21

Authorization System The Authorization system authorizes service exchange within the local cloud. Upon requests from service producers, the Authorization system determines if a particular service consumer is allowed to consume the produced services using a set of authorization- , authentication-, and accounting rules. There are two slightly different Authorization systems that may be used in a local cloud; the AA system and the AAA system. The AA, Authorization Authentication system provides the AuthorizationManagement- and AuthorizationControl services, and is suitable for local clouds containing systems with moderately resourceful hardware. The AAA, Authorization Authentication Accounting system also provide the Authenti- cationID service in addition to the services provided by the AA, and is suitable for local clouds containing systems with limited hardware resources. The AuthorizationManagement service is used for managing access rules for resources and configuring properties of tickets. The AuthorizationControl service is used for con- trolling access to services and resources in the local cloud. The AuthenticationID service is used to authenticate consumers using a challenge-response mechanism. [11, p. 60-61]

Figure 3.3 illustrate how these three mandatory core systems communicate with service providers and consumers.

Figure 3.3: Communication paths between the mandatory core systems, service providers, and service consumers.

Source: IoT Automation: Arrowhead Framework, Delsing 2017 22 Theory

3.7.3 Compliance and maturity levels Arrowhead is virtually compliant with any kind of legacy equipment or system, given certain conditions. For instance, there exist arrowhead compliant sensors on the market to some degree [24], but most sensors and equipment do not have a native support for running Arrowhead systems, meaning they cannot provide or consume services within Arrowhead Framework. However, legacy sensors and systems like these can be integrated to arrowhead by applying adapters to them. As there are different types of legacy systems, there are also different types of adapters suitable for these systems. When speaking about the compliance of legacy application systems and the usage of adapters to enable the systems, three different maturity levels are used to classify their compliance and the adapter type suitable. These different maturity levels are described below. Figure 3.4 illustrates the adapters in relation to the application systems in the different maturity levels. [11, p.84]

Level 3 - Native implementation of AHF The application system is on its own able to implement Arrowhead Framework and produce or consume services within the framework, without any use or support from other equipment or software modules. [11, p.84]

Level 2 - AHF Software component wrapping a legacy system With the use of a software adapter, the legacy application system is able to implement Arrowhead Framework and produce or consume services within the framework. The software adapter, referred to as an Y-adapter, is directly integrated within the application system as a module that interacts with Arrowhead Framework, using no extra hardware or equipment. [11, p.84]

Level 1 - AHF Hardware component wrapping a legacy system With the use of a hardware adapter, the legacy application system is able to implement Arrowhead Framework and produce or consume services within the framework. The hardware adapter, referred to as an X-adapter, contains a system that natively is able to produce or consume Arrowhead services, and interacts with the legacy application system by implementing protocols or interfaces compatible with the application system’s interface. [11, p.85] 3.7. Arrowhead Framework 23

Figure 3.4: Diagram displaying the three different maturity levels, signified by ”ML3”, ”ML2”, and ”ML1”, together with usage of the X- and Y-adapters.

Source: Making system of systems interoperable – The core components of the arrowhead framework [25].

CHAPTER 4 Plant System

This chapter describes the systems and installations at the plant that are concerned in this thesis. Facts regarding these areas are mainly retrieved from knowledgeable employees and factory documents.

4.1 Transportation Buffer

As described in the introduction, the site features a large sequential buffer that stores incoming manufactured products from the preceding manufacturing process and delivers the stored products to the succeeding process in any requested order, as each product may be unique in terms of specifications from customer. The buffer is reasonably large and features two stories, each containing a transportation rail that stretches over 100 meters from inlet to outlet, with storage spaces alongside the transportation rail (figure 4.1).

4.1.1 Transportation Cart

The transportation cart that transfers the products on the rail is powered by an electrical motor on the cart and travels at speeds up to 3.67m/s. The cart is controlled by a PLC and has a control system situated at the end of the rail which it communicates to. Since using a cabled connection between the cart and the control system would be inappropriate on a cart that moves over 100 meters, the control system communicates with the cart using infrared light beams in direct line of sight (figure 4.2).

25 26 System

Figure 4.1: The sequential buffer and lower transportation cart.

Figure 4.2: Close up of the rear end of the transportation cart. Visible is the IR trans- mitter; the green device is situated on the top right side of the cart. 4.2. Alternative Proof of Concept 27

4.1.2 Network structure The factory mainly uses control systems and network infrastructures relating to the automation pyramid, and a wide use of SCADA systems throughout the factory. OPC and OPC-UA are used in some areas and applications within the factory, such as in the proof of concept in section 4.2 below.

4.2 Alternative Proof of Concept

There exists a proof of concept of a IIoT-solution that has been developed by the IT department at the factory. The existence of this proof of concept within the maintenance area was unknown prior to this master thesis. This also contributes as a reason why Arrowhead Framework is chosen to build the solution on, as Arrowhead diverges from this PoC and therefore proposes a possible solution with a different approach towards internet of things. This PoC is focuses on utilizing sensor data that is provided to PLCs, and OPC UA to aggregate and deliver this data to storage- and visualization platforms.

• As PLCs are widely used throughout the factory today, it is the natural chose to use PLCs to collect the sensor data from the edge, allowing a convenient integration with legacy equipment as no extra equipment is needed.

• The sensor data is aggregated using OPC UA to an IoT gateway, hosted on a server running KEPServerEX; an OPC-based connectivity platform.

• There are sensors involved that use wireless communication. These sensors com- municate directly with a wireless IoT gateway.

• Both IoT gateways sends the data to ThingWorx, a visualization platform where all data is collected, analyzed and visualized. The data is visualized in graphs both in real time and from historical data.

• Thingworx then sends the data to Azure where it is stored, where further services offered by Azure may be applied to handle the data.

This proof of concept has been implemented in small scale and evaluated by the IT department, where both positive and negative experiences regarding this system are found and listed. Figure 4.3 show an architectural map of this proof of concept. 28 System

Figure 4.3: Overview of the PoC developed at the company. CHAPTER 5 Solution

This chapter presents the proposed solution composed to be implemented to achieve the goals presented in section 1. The solution is based on IoT-communication between edge equipment and cloud services using Arrowhead Framework. Sensors from IFM are chosen.

5.1 Solution overview

To address the established goals, the following solution is used:

1. Sensors mounted on the equipment provide sensed data.

2. The sensors are connected to devices which receive the sensor data and processes it if necessary.

3. The data is delivered to an adapter customized for allowing communication to and from Arrowhead Framework.

4. Arrowhead Framework orchestrates and arranges for the data to be delivered to an Azure server.

5. The data is sent and stored at the Azure server, where it is available for future analysis, or visualised directly.

6. The platform Thingworx fetches the data from Azure and visualizes it for the user.

The solution utilizes the following equipment:

• Sensors:

– IFM TA2105 temperature sensor.

29 30 Solution

– IFM TA2115 temperature sensor. – IFM VSA005 acceleration sensor (vibration measurements). – IFM O5D100 distance sensor (used for development purposes).

• IFM AL1300 IO-Link master.

• IFM VSE100 diagnostic electronics for vibration sensors.

• 2 pcs. Raspberry Pi 3 model B.

• An Ethernet router with a built in 4G-modem

Figure 5.1: Overview of the system for the proposed solution.

Source: IFM Electronic, RS Components, PTC

5.2 Sensors

The process of selecting which sensors to use in the system was performed in cooperation with employees at the factory. The scope of this thesis do not include determining what parameters of the equipment to be measured, but whatever sensors are chosen are used to form the solution for data acquisition. Therefore it is important to be involved in the 5.2. Sensors 31 process of selecting sensors as the solution shall be designed to suit the selected sensors in terms of compatibility.

As the solution is developed for a cart that transports large size manufactured goods, possible areas of interest for performing measurements of are vibrations, temperatures, oil quality and viscosity, and energy consumption, as they may correlate to the condition of the cart. One area that is of particular interest is vibrations, as they provide vital information that may be directly correlated to the condition of the bearings in the wheels as an example. While several sensor manufacturers are considered, one particular manufacturer is pre- ferred by the factory, partly due to previous relationships between the manufacturer and the factory, and partly due to the manufacturer’s liberal approach towards usage of their equipment piecewise together with other systems than of their own. This manufacturer, IFM, offer a wide assortment from single sensors with different characteristics and for a variety of purposes, up to complete solutions with software for enabling observation and data acquisition from deployed sensors. Meetings are held between representatives from the factory and the manufacturer, who consults and recommends sensors as well as complete data gathering solutions that would fit this purpose. The manufacturer offers vibration sensors that are suitable for measuring vibrations in this application, and that are easy to install compared to solutions and sensors from other manufacturers. Apart from the recommended vibration sensors, many of the sensors and equipment IFM of- fer are compatible with IO-Link, a standardized IO-technology developed for industrial environments and purposes. The factory opts for using sensors and equipment from IFM.

5.2.1 IO-Link sensors IO-Link is a technology developed by the IO-Link Company Community. The technol- ogy is purposed to be used for communicating sensor and actuator data in industrial environments. IO-Link has gained the international standard IEC 61131-9 and is used by numerous manufacturers worldwide who are members in the IO-Link consortium [26]. IO-Link is used as a system of components and IO-Link compatible devices in various scales. A simple setup may consist of one or more sensors of any IO-Link compatible kind, connected to an IO-Link master; a central device that connects sensors and actuators to superior networks or devices. IO-Link masters typically uses 5-pin M12 connectors to which IO-Link devices are screwed on, where sensors generally use 4 pins, and actuators 5 pins. [27] IO-Link masters communicate on networks using Fieldbuses, eg. PROFINET. Since IO-Link theoretically enables cross compatibility between manufacturers, allowing usage of sensors of various brands with an IO-Link master of different brand, the IO-Link technology goes in line with the system requirement of compliance between different kinds of sensors and adjoining systems. Due to the possibilities that IO-Link provide, it 32 Solution is considered to be a highly viable option. It is decided to use two temperature sensors, IFM TA2105 and IFM 2115, together with a IFM AL1300 IO-Link master. The two temperature sensors are suitable to be mounted on the heatsink of the electrical motor on the transportation cart. The sensors have the exact same specifications, apart from the length of the temperature probe, which is 25mm on the TA2105 and 50mm on the TA2115. The AL1300 can connect to up to four IO-Link devices, and has two PROFINET interfaces as well as one TCP/IP JSON interface, allowing communication to devices that do not utilize PROFINET.

5.2.2 Vibration sensors and IFM VSE100 Diagnostic electronic While IO-Link is a great and flexible solution for many applications, there are some ap- plications where it may not be an appropriate solution, or even applicable at all. The vibration sensor of choise, VSA005 acceleration sensor, outputs an analogue signal as it is capable of measuring vibrations up to a frequency of 12kHz. Due to not having any IO-Link interface, the VSA005 cannot be used together with the chosen IO-Link master. Still, the VSA005 is chosen due to its small size and versatility with mounting options, since tests are to be performed on the current system using these sensors. Signal pro- cessing from VSA005 is instead done by a diagnostics device which is able to receive the signals from various vibration sensors and analyze these signals for patterns that may indicate wear and damages on the measured equipment. This device, IFM VSE100 Diag- nostic Electronics, uses an Ethernet interface for network communication and parameter setup, and is able to communicate with industrial systems and devices such as SCADA, and MES, OPC and PLCs, e.g. for visualizing data and sending alarms. To enable communication with VSE100 from the Raspberry Pi adapter running Arrow- head, a utility software featuring a C++ library is acquired from IFM, allowing integration to the Raspberry Pi adapter.

5.3 Arrowhead Framework components

In this solution, one local automation cloud with Arrowhead Framework is utilized where two Raspberry Pi single-board computers are used as endpoints. The first Raspberry Pi hosts the three mandatory Arrowhead core systems and a service consumer. The second Raspberry Pi hosts service providers for the application systems that acquire the sensor data. Both Raspberry Pis run Raspian Strech; a Debian-based operating system developed for Raspberry Pi. Since the application systems with the sensor equipment (the IO-Link master and the vibration diagnostics device) are not Arrowhead compliant in the sense that they on their own are able to host service providers for the local cloud, they are classified as maturity level 1, and therefore need adapters of type Y to provide the data they acquire to the consuming device that is to receive and process this data. The second Raspberry Pi is thus utilized as an adapter for these systems. To communicate with the 5.4. Connectivity towards networks and internet 33

(a) IFM AL1300 IO-Link Master (b) IFM VSE100 Diagnostic Electronics

Figure 5.2: The devices used to connect the sensors to the system.

Source: IFM Electronic

sensor equipment, the adapter uses POST requests to receive sensor data from the IO- Link master, and the C++ library to receive data from the VSE100 vibration diagnostics. The service providers for each application system on the adapter then formats and sends the data in JSON-format to the service consumer on the other Raspberry Pi. When the service consumer receives the data, it is sent as messages to Azure, where the data is stored.

5.4 Connectivity towards networks and internet

Since the transportation cart regularly travel back and forth at distances up to over 100 meters, it is not realistic to use a wired connection between the devices on the cart and the network. Instead, there are WiFi networks at the factory that are considered as an alternative. However, there are two problems that also makes this alternative unusable. The first problem is that the network-connected devices will travel along with the transportation cart, making it very likely for the connection to be unstable as the devices might move in- and out of range to- and from, or between access points. The 34 Solution other problem is that the factory network is considerably restrictive in terms of allowing new devices onto the network. Computers need to run a specific VPN software to gain internet access, and since the Raspberry Pi computers used in this solution run Linux- based operating systems, for which this software is not available, another option needs to be found. Instead of going through the process of manually allowing the devices on the factory network, the factory decides to provide an Ethernet router with a built in 4G-modem to gain internet access for the equipment, as well as allowing local communication between the devices. Another advantage of using this router is that its mobility allows for devel- opment and testing anywhere, as it is not bound to any physical location. This means that the router may travel with the devices on the cart, and that the devices may connect to the router using Ethernet.

5.5 Microsoft Azure

All the data that is acquired need to be stored somewhere. In the project described in section 1.5.3, data is stored in files on a server owned by the company. This alternative is considered for its simplicity. However, as Microsoft Azure is used within the proof of concept in section 4.2, the company already have access to this platform, which also provides more possibilities with data management and additional services. Azure is therefore chosen to store the acquired data. Azure provide many different services and resources, among the many it provides an IoT-Hub, which can be set up to receive and send messages between devices and the hub. The IoT-hub is used in this solution to receive the messages containing the acquired sensor data from the service consumer. Azure uses the ”Pay-as-you-go”-concept and offer several subscription tiers for using the IoT-Hub. Due to the small size of this solution, the free tier, allowing a maximum of 8000 messages to be received a day, is used. When messages are received in the IoT-Hub, they need to be routed to additional services which processes or stores the messages as the IoT-Hub otherwise will discard them. As the sensor data shall be stored in a manageable and observable way, the messages cannot be stored right away as they contain header information apart from the data, which also is formatted in JSON. The data is therefore routed to a Stream Analytics service, which extracts the data from the messages and stores the chosen information as entries in a table storage service hosted on Azure.

5.6 ThingWorx

ThingWorx is a platform that provides services for industrial IoT, such as visualization and analysis services [28]. This platform is used in the proof of concept in section 4.2, and is recommended by the IT department. Since this is not a prioritized area in this 5.6. ThingWorx 35 thesis and as the company already has licenses for ThingWorx, this is chosen to visualize the data stored in Azure.

CHAPTER 6 Results, Evaluation and Future work

6.1 Resulting implementation

Everything described in the solution was not implemented into the resulting system. Due to time limitations resulting from a late start of the implementation, only the IO-Link master and one of the temperature sensors are implemented, with a service provider for this sensor. Unfortunately, the vibration sensor and the VSE100 diagnostics device are not included in the resulting implementation. The ThingWorx visualization platform is not used either, as it is not a prioritized part of the solution. The system mainly consist of a local cloud with Arrowhead Framework, containing one service provider and one service consumer. The system works as explained below. Figure 6.1 provide an overview of the system, visualizing how the data is sent from the sensor up to the cloud.

• The service provider serves as an adapter for the sensor equipment; it sends POST requests via HTTP to the AL1300 IO-Link master every two seconds, which in turn responds with JSON-formatted messages containing the sensor data, represented in hexadecimal values.

• For each message, the sensor value is extracted from the message, converted to a decimal value, and placed in a JSON message that is ready to be sent to the service consumer. The messages constructed by the provider contain the following entries:

– Sensor ID – Sensor name – Unix timestamp 1

1Unix time represents the amount of seconds that has passed since 1 Jan 1970.

37 38 Evaluation

– Sensor value – Unit

• The service consumer requests and receives these messages every 15 seconds from the service provider. The service consumer then saves the message to a file, and executes a python script which reads the JSON message from the file, adds a timestamp of the Unix time converted into UTC time to the message, and sends it to an IoT Hub hosted on Azure.

• When the messages are received in the Azure IoT Hub, the Stream Analytics service is used to parse the JSON messages and place the containing data as entries in a table storage on Azure. Thus, the sensor data stored in the table storage is structured as observed in table 6.1.

The reason for the 15 second time interval between requesting messages is due to the limits of the Azure IoT Hub, where a free subscription tier is used, allowing a maximum of 8000 messages a day to be uploaded to the Hub. This translates to roughly 11 seconds minimum between messages if the limit shall be maintained. To keep a margin towards the message limit, and to more easily be able to monitor the amount of messages received by the IoT Hub during testing, 15 seconds is chosen as this means precisely 4 messages per minute. The original intention was to send the messages to the IoT Hub within the service con- sumer, which is written in C++, for a more seamless and uniform application. However, issues arose regarding the Azure libraries for C++, creating time consuming complications for the implementation, which ultimately prevented this. As compatible Azure libraries are available for Python, this is chosen instead in order to be able to finalize the imple- mentation within a reasonable amount of time, even though it makes the implementation less uniform.

Table 6.1: Example of data stored in the table storage on Azure. A more extensive table can be found in appendix A.

Sensor name Sensor ID Unix time UTC time Value Unit IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873487 2019-05-14 22:38 31.1 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873707 2019-05-14 22:41 30.9 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873724 2019-05-14 22:42 30.9 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873774 2019-05-14 22:42 30.8 Celsius

The IO-Link master, the service provider, and the service consumer are all connected to the 4G-router, which provides internet connectivity for the system. The implementation is tested on a different sequential buffer than the one originally targeted, which allows for easier installation of the system as it contains an electrical cabinet with 230V power 6.1. Resulting implementation 39

Figure 6.1: Diagram of the resulting solution. Green arrows highlights the flow of the sensor data from sensor to storage. 40 Evaluation outlets, and an exposed electric motor, which is suitable for mounting a temperature sensor on (figure 6.2). After installation, the system is tested by simply starting it and allowing it to acquire temperature data from the electrical motor for several days without interruption. The Arrowhead systems are automatically initiated by scripts as the devices are powered on. The result is a successful data acquisition, where sensor data is regularly stored in the table storage on Azure. Table 6.1 represents a small selection of data entries from the table storage. As can be observed in the table, sensor values are not received every 15 seconds as specified in the service consumer. Figure A.1 in Appendix A display the amount of messages received per hour during a 48-hour period. An average of roughly 37 messages per hour can be derived from the graph, which translates to about one message every 97 seconds, significantly less than specified.

Figure 6.2: The electrical motor of the buffer the system is tested on. 6.2. Evaluation and discussion 41

6.2 Evaluation and discussion

Even though the resulting implementation is minimal in terms of connected devices and do not include all equipment and services chosen in the solution, the implementation is still considered successful as it is able to acquire data from the sensor on the electrical motor and store this data on the cloud in observable and manageable forms, thus achiev- ing one of the most fundamental goals defined in the problem definition. This goal is also essential for being able to evaluate the system.

Comparing the resulting system to the evaluation criteria established in section 2.1.2 from the fundamental solution goals, the system shall first of all utilize Industry 4.0 technologies, which it does by utilizing Arrowhead Framework. The system is able to acquire data, but only from one source, and the acquisition frequency is questionable regarding that the IoT Hub do not seem to receive a majority of the messages containing the acquired data. If this solution is to be used in applications where acquisition frequency is more critical, this may become a problem that needs to be solved. Regarding the storage criteria, the system has a storage established in Microsoft Azure, where the acquired data first is refined by Azure Stream Analytics and then stored as entries in a table storage. One advantage of utilizing a cloud platform for storage is the flexibility it provides, as there are several different storage types that may be utilized, and that the stored data is easily accessible for exportation for further usages such as visualization and analysis. For instance, as an alternative storage type, it is possible to establish an SQL database within Azure to store the acquired data if so desired. Lastly, While the solution opted for utilizing the ThingWorx visualization platform for visualizing the acquired data, this was left out in the implementation as mentioned in section 6.1. However, Microsoft Azure provides visualization possibilities that are used to some extent. The IoT Hub creates a graph displaying the amount of received IoT- messages per chosen time unit, as can be observed in figure A.1. It is not possible to directly visualize data stored table storage in Azure. It is possible to download the data as comma-separated values and produce a chart in Microsoft Excel to display the acquired data from a historical perspective, as done for figure A.2. However, by utilizing other features in Azure it is possible to visualize incoming data in real time before storing it in the table storage. This makes utilizing ThingWorx redundant for the scope of this thesis. However, ThingWorx may still be preferred by the factory in future implementations if other parts of the factory already use this platform.

Continuing to the criteria established from the system requirements, the solution is based on a generic IoT-platform in the sense that it enables equipment to be connected to the internet, with no restrictions that bind any part of the system to only use equip- ment from a specific supplier. Cross-compatibility between devices and systems from different suppliers is an important aspect from the factory’s point of view. By utilizing 42 Evaluation appropriate adapters, Arrowhead is theoretically compatible with any legacy equipment and adjoining systems. This solution does not test its compatibility with legacy equip- ment as new equipment was ordered for this solution. However, this equipment was in no sense directly Arrowhead compatible, implying this may represent legacy equip- ment. The system is proven to be practically compliant with the equipment using the adapter/provider, which successfully handles communication with the IO-Link master. At the other end of the local cloud, the consumer interacts with the Azure platform, further displaying compliance with adjoining systems. As the local cloud in this implementation only possesses two devices, the terms of scalability and flexibility regarding expanding the system with additional sensors, dif- ferent kinds of sensors or applications, or changing and upgrading sensors has neither been tested nor directly evaluated. However, by implementing this solution featuring Arrowhead Framework, the framework and its properties have been explored and thus a conception of what is possible to achieve using the framework has been established. Regarding the size-property of scalability, the code for the service- providers and con- sumers, as well as adapters, has a very high reusability. Meaning that if the system is to be expanded with similar sensors, it would be rather easy to reuse the existing code to create e.g. additional producers or adapters for these new sensors by just editing some parameters in the code for communication and identification of those sensors. Then, by registering the services for those new sensors within the local cloud, a correctly designed service consumer would be able to consume the new services along with the current ones and upload the data to the cloud. As for the functional property of scalability, the pro- cess would be similar. If sensors acquiring and providing data of a completely different structure are added, the changes made to connection and identification of the sensors would be similar as before, implying the usage of adapters if needed. Furthermore, the handling of the acquired data would have to be modified with respect to the structure of it. And if needed, additional consumers could be added to be able to cover the new data structures, unless the providers or adapters convert the data before providing it to the local cloud. Lastly, considering the generational property of scalability, if any sensor would be changed or upgraded, existing service provider and possible adapter could still be used. However, the code would need to be audited to make sure that this new sensor is handled properly by its service producer or adapter. Also worth mentioning, as the IO-Link master may connect additional sensors to its ports, only a digit in the HTTP-address for the POST request on the service provider needs to be changed in order to access a different port on the IO-Link master. This also suggests scalability of the system regarding size, functions, and generations, as any kind of IO-Link sensors would be handled by the IO-Link master, minimizing the adaptation effort required by the Arrowhead adapter or service provider.

Arrowhead displays a lot of potential for this kind of application. There are many different properties of the equipment at the factory that can be measured using sensors 6.3. Future work 43 of various types and brands. Considering the properties explained above, Arrowhead Framework may therefore be a suitable choice to establish local clouds for data acquisi- tion and automation distributed around the factory. The possibility to create components specifically tailored for each type of equipment provides a significant versatility to the framework. The reusability of framework components reduces the engineering time for new components as soon as fundamental systems and components are established. Fur- thermore, when new components are created, it is fairly easy to integrate these into the system as it is only needed to register the service for any new component in the service registry, and the core systems will then acknowledge the existence of the component and its services. However, some extent of programming skill is required to implement a system with Ar- rowhead framework as the development of components involve programming, and as the framework feature no graphical user interface today. Furthermore, it is not obvious how to get started with setting up the framework, as it was challenging to find proper docu- mentation for doing so. There is a wiki for the framework which contains documentation and forums, but the community at the wiki is somewhat small, and accessing relevant information and documents here required some effort. The learning curve of Arrowhead Framework may therefore be steep, as it may be hard to find help if problems arise, as this is the only community at the time. This is something that is important to recognize when considering implementation of Arrowhead, as the factory may not want to spend resources on developing the system on their own. It may therefore be easier and more practical from the factory’s point of view to purchase a complete solution or construct a solution using compatible products and services provided from other companies, such as in the proof of concept in chapter 4. One possibility would be to appoint consultants to develop and implement a tailored system for the factory, using Arrowhead Framework. Important to have in mind, though, is that the development of Arrowhead Framework is still continuing even though releases have been made, and that things stated here may change in the future.

6.3 Future work

This thesis has only scratched the surface of what is possible to do and achieve with Arrowhead Framework. Even though the resulting implementation is successful as a data acquisition solution, there is still much more that can be done to justify Arrowhead Framework and prove its full potential. For instance, there is a set of core systems not utilized in this implementation. Developing a much larger, site-wide system featuring several local automation clouds that together utilizes all of these core systems would be outstanding, but considering the time and resources for the scope of this thesis, this is evidently not a realistic goal. To further explore Arrowhead in a realistic way, there are some next steps that can be made, described in section 6.3.1 below. 44 Evaluation

6.3.1 Sensors and framework components If the implementation of this solution and framework is to continue, the next logical step would be to implement the parts of the solution that were left out. This would mean implementation of an adapter and service provider for the VSE100 diagnostics device using the C++ library provided by IFM. Mounted on the sequential buffer used for testing the implementation is also the IFM O5D100 distance sensor. One of the maintenance engineers is to continue with this solution and attempt to implement the sensor, as this will help to further explore the scalability and engineering time properties of the framework from the factory’s point of view.

6.3.2 Cloud services and analysis As of now the solution stores the acquired data in tables on Azure. An alternative that may be preferred is to establish an SQL database, which may provide better management and usability of the stored data for the future, such as analysis and visualization. Regarding visualization of data, Azure does have services for visualizing data, but as ThingWorx is preferred and already used for other systems in the factory, it would be natural to implement ThingWorx to visualize the acquired data in this solution as well, just to make the system more complete.

Lastly, the underlying reason behind this is the interest for condition based mainte- nance. The data acquired needs to be analyzed to achieve this, where models for wear of parts of the equipment may be derived from the data, given that data from sufficient parameters of the equipment is acquired. APPENDIX A Tables and Graphs

Figure A.1: Amount of messages received per hour by the Azure IoT Hub during a 48-hour period.

45 46

Table A.1: Selection of sensor values sent to the cloud during a one-hour period.

Sensor name Sensor ID Unix time UTC time Value Unit IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873196 2019-05-14 22:33 31.3 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873230 2019-05-14 22:33 31.3 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873282 2019-05-14 22:34 31.2 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873298 2019-05-14 22:34 31.2 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873487 2019-05-14 22:38 31.1 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873707 2019-05-14 22:41 30.9 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873724 2019-05-14 22:42 30.9 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873774 2019-05-14 22:42 30.8 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873928 2019-05-14 22:45 30.7 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873962 2019-05-14 22:46 30.6 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557873997 2019-05-14 22:46 30.6 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557874013 2019-05-14 22:46 30.6 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557874575 2019-05-14 22:56 30.1 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557874609 2019-05-14 22:56 30.1 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557874711 2019-05-14 22:58 30.0 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557874797 2019-05-14 22:59 30.0 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557874832 2019-05-14 23:00 29.9 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557874932 2019-05-14 23:02 29.8 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557875000 2019-05-14 23:03 29.8 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557875189 2019-05-14 23:06 29.6 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557875392 2019-05-14 23:09 29.5 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557875460 2019-05-14 23:11 29.4 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557875733 2019-05-14 23:15 29.2 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557875785 2019-05-14 23:16 29.2 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557875869 2019-05-14 23:17 29.2 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557875919 2019-05-14 23:18 29.1 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876022 2019-05-14 23:20 29.0 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876261 2019-05-14 23:24 28.9 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876329 2019-05-14 23:25 28.8 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876431 2019-05-14 23:27 28.7 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876516 2019-05-14 23:28 28.7 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876618 2019-05-14 23:30 28.6 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876634 2019-05-14 23:30 28.6 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876652 2019-05-14 23:30 28.6 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876686 2019-05-14 23:31 28.6 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876702 2019-05-14 23:31 28.6 Celsius IFM TA2115 Temperature Sensor Temperature Sensor 1 1557876959 2019-05-14 23:35 28.4 Celsius 47

Figure A.2: Temperature data of the electrical motor acquired during the test of the implementation, downloaded from Azure and visualized using Microsoft Excel.

REFERENCES

[1] M. Ljung, “Examensarbete industry 4.0,” b. thesis in computer science and engi- neering, Lund University, 2018. [2] D. H¨astbacka, E. Jantunen, M. Karaila, and L. Barna, “Service-based condition monitoring for cloud-enabled maintenance operations,” in IECON 2016 - 42nd An- nual Conference of the IEEE Industrial Electronics Society, pp. 5289–5295, Oct 2016. [3] T. Latvala, “Deployment of a service-oriented automation platform for integrating smart city applications,” ms. thesis, Tampere Univercity of Technology, February 2016. [4] H. Kagermann, W. Wahlster, and J. Helbig, “Recommendations for implementing the strategic initiative industrie 4.0 – securing the future of german manufactur- ing industry,” final report of the industrie 4.0 working group, acatech – National Academy of Science and Engineering, M¨unchen, apr 2013. [5] European Commision, “Germany: Industrie 4.0,” p. 3, 2017. [6] Armbrust, Michael, A. Fox, Armando, Griffith, Rean, Joseph, A. D, R. Katz, R. H, A. Konwinski, Andrew, G. Lee, Gunho, Patterson, D. A, Rabkin, Ariel, Stoica, and Matei, “Above the clouds: A berkeley view of cloud computing,” p. 4, February 2009. [7] Microsoft, “What is paas?.” [Online:] https://azure.microsoft.com/en-us/ overview/what-is-paas/?cdn=disable, 2019. [Accessed April 24, 2019]. [8] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and its role in the internet of things,” in Proceedings of the First Edition of the MCC Workshop on Mobile Cloud Computing, MCC ’12, (New York, NY, USA), pp. 13–16, ACM, 2012. [9] P. Dalwalla, E. Delahostria, D. Noller, L. Childress, A. Boyd, B. Scholten, M. Schnei- der, J. Vieille, and C. Pipero, The Hitchhiker’s Guide to Manufacturing Operations Management: ISA-95 Best Practices Book 1.0. ISA, 2007.

49 50

[10] B. Scholten, The Road to Integration: A Guide to Applying the ISA-95 Standard in Manufacturing. ISA, 2007.

[11] J. Delsing, IoT Automation: Arrowhead Framework. CRC Press, 2017.

[12] A. Daneels and W. Salter, “What is SCADA?,” in Accelerator and large experimental physics control systems. Proceedings, 7th International Conference, ICALEPCS’99, Trieste, Italy, October 4-8, 1999, vol. C991004, pp. 339–343, 1999.

[13] R. Elliott, “Manufacturing Execution System (MES) An Examination of Implemen- tation Strategy,” thesis, California Polytechnic State University, June 2013.

[14] F. F.-H. Nah, J. L.-S. Lau, and J. Kuang, “Critical factors for successful implemen- tation of enterprise systems,” Business Process Management Journal, vol. 7, no. 3, pp. 285 – 296, 2001.

[15] Christian Mosch, VDMA, “Rami 4.0 and industrie 4.0 components.” [Online:] https://industrie40.vdma.org/en/viewer/-/v2article/render/15557415. [Accessed May 24, 2019].

[16] Gunther Koschnick, Zentralverband Elektrotechnik- und Elektronikindustrie e.V., “The reference architectural model rami 4.0 and the industrie 4.0 com- ponent.” [Online:] https://www.zvei.org/en/subjects/industrie-4-0/ the-reference-architectural-model-rami-40-and-the-industrie-40-component/. [Accessed May 24, 2019].

[17] OPC Foundation, “What is opc?.” [Online:] https://opcfoundation.org/about/ what-is-opc/. [Accessed May 26, 2019].

[18] OPC Foundation, “Opc classic.” [Online:] https://opcfoundation.org/about/ opc-technologies/opc-classic/. [Accessed May 26, 2019].

[19] OPC Foundation, “Opc unified architecture.” [Online:] https://opcfoundation. org/about/opc-technologies/opc-ua/. [Accessed May 26, 2019].

[20] M. R. Mehta, S. Lee, and J. R. Shah, “Service-oriented architecture: Concepts and implementation,” January 2006.

[21] ProcessIT.eu, “Closure for successful arrowhead project.” [Online:] http://www. processit.eu/closure-for-successful-arrowhead-project, 2017. [Accessed March 4, 2019].

[22] Arrowhead.eu, “Arrowhead general overview.” [Online:] http://www.arrowhead. eu/about/general-overview/. [Accessed March 4, 2019]. 51

[23] Arrowhead Wiki, “Arrowhead wiki - arrowhead.” [Online:] https://forge.soa4d. org/plugins/mediawiki/wiki/arrowhead-f/index.php/Arrowhead. [Accessed March 4, 2019].

[24] Jerker Delsing, “Arrowhead framework - a local cloud approach to au- tomation.” [Online:] https://www.iaria.org/conferences2015/filesSMART15/ DataSys_keynote_150623.pdf. [Accessed June 4, 2019].

[25] P. Varga, F. Blomstedt, L. L. Ferreira, J. Eliasson, M. Johansson, J. Delsing, and I. M. de Soria, “Making system of systems interoperable – the core components of the arrowhead framework,” Journal of Network and Computer Applications, vol. 81, pp. 85 – 95, 2017.

[26] IO-Link, “Io-link members.” [Online:] https://www.io-link.com/en/ WirUeberUns/Manufacturer.php, 2019. [Accessed April 24, 2019].

[27] I.-L. C. Community, “Io-link system description.” [Online:] http://www. processit.eu/closure-for-successful-arrowhead-project, July 2013. [Ac- cessed April 22, 2019].

[28] PTC, “Thingworx.” [Online:] https://www.ptc.com/en/products/iot, 2019. [Ac- cessed May 20, 2019].