Enabling Effective Data Collection for Industry 4.0 Technical Solution for Collecting and Transferring Shop Floor Data Master’s thesis in Production Engineering Alexander Andersson Carl Lund Department of Industrial and materials science CHALMERS UNIVERSITY OF TECHNOLOGY Gothenburg, Sweden 2023 www.chalmers.se www.chalmers.se Master’s thesis 2023 Enabling Effective Data Collection for Industry 4.0 Technical Solution for Collecting and Transferring Shop Floor Data Alexander Andersson Carl Lund Department of Industrial and materials science Chalmers University of Technology Gothenburg, Sweden 2023 Enabling Effective Data Collection for Industry 4.0 Technical Solution for Collecting and Transferring Shop Floor Data ALEXANDER ANDERSSON CARL LUND © ALEXANDER ANDERSSON & CARL LUND, 2023. Supervisor: Xiaoxia Chen, Doctoral Student at Production Systems Supervisor: Qi Fang, Doctoral Student at Production Systems Supervisor: Helene Askros, Senior Business Analyst at Aurobay Examiner: Mélanie Despeisse, Associate Professor at Production Systems Master’s Thesis 2023 Department of Industrial and materials science Division of Production Engineering Chalmers University of Technology SE-412 96 Gothenburg Telephone +46 31 772 1000 Cover: Aurobay logo Typeset in LATEX, template by Kyriaki Antoniadou-Plytaria Printed by Chalmers Reproservice Gothenburg, Sweden 2023 iv Enabling Effective Data Collection for Industry 4.0 Technical Solution for Collecting and Transferring Shop Floor Data ALEXANDER ANDERSSON CARL LUND Department of Industrial and materials science Chalmers University of Technology Abstract The manufacturing industry is moving towards Industry 4.0, this requires that the right information is available to reach the full potential of the various Industry 4.0 technologies such as Digital Twin, Cloud computing, advanced analytics, Artificial Intelligence, Internet of Things, and Machine Learning. To obtain the right infor- mation, a system for gathering and transferring data in real time is required. To be able to make this connection, Edge device is usually used. Edge devices are devices that can collect data in production. The purpose of this thesis is to find and evaluate suitable technical solutions to collect and transfer data. The work is carried out in three steps, identifying the data collection challenges, a literature study to find technical solutions, and evaluating technical solutions. The findings show that there are technical solutions on the market to collect and transfer the data that the case company request. Further research should ensure that the technical solutions work by doing tests in a lab environment or by trying to implement them on a workstation. Keywords: Collecting Data, Data Acquisition System, Data Logging, Data Security, Edge Device, Industry 4.0, Internet of Things, Real-time Monitoring, Transferring Data. v Acknowledgements There are many people whom we would like to thank who have played a vital role to make this thesis possible. First, we would like to thank our supervisors from Chalmers Xiaoxia Chen, and Qi Fang, for their support, guidance, and encourage- ment during our master’s thesis. Their advice has been an essential help in shaping our research. We would also like to thank Mélanie Despeisse, our examiner, for her expertise, contributions and especially that she has challenged our academic process. At Aurobay we would like to thank our supervisor Helene Askros who has helped us with finding information, setting up meetings with the right persons, and answering all other questions that have been related (or not related) to the company. We also want to thank everyone we interviewed at Aurobay who has taken the time to answer our questions and contributed essential information to the project. And lastly, we would also like to thank all the other staff at Aurobay who welcomed us and helped us with everything else needed to get through the day. Alexander Andersson and Carl Lund, Gothenburg, May 2023 vii List of Acronyms Below is the list of acronyms that have been used throughout this thesis listed in alphabetical order: AI Artificial Intelligence CBM Condition Based Maintenance CPS Cyber-Physical Systems D2D Device-to-device HMI Human-Machine Interface I/O Input/Output IIoT Industrial Internet of Things IPC Industrial PC IP Internet Protocol IoT Internet of Things IT Information Technology KPIs Key Performance Indicators LAN Local Area Network LTE Long-Term Evolution M2M Machine-to-machine ML Machine Learning MQTT Message Queuing Telemetry Transport OASIS Organization for the Advancement of Structured Information Stan- dards OPC UA Open Platform Communications Unified Architecture OEE Overall Equipment Effectiveness PdM Predictive Maintenance PLC Programmable Logic Controller RQ Research Question USB Universal Serial Bus VD Virtual Device VDcom_v2 Virtual Device Communication Version 2 WLAN Wireless Local Area Network WWAN Wireless Wide Area Network ix Contents List of Acronyms ix List of Figures xv List of Tables xvii 1 Introduction 1 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Case Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5 Scope and Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Theoretical Framework 7 2.1 Production Related Framework . . . . . . . . . . . . . . . . . . . . . 7 2.1.1 Industry 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2 IoT - Internet of Things . . . . . . . . . . . . . . . . . . . . . 8 2.1.3 CBM - Condition Based Maintenance . . . . . . . . . . . . . . 8 2.1.4 Brownfield vs Greenfield . . . . . . . . . . . . . . . . . . . . . 8 2.1.5 Edge Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2 Research Related Framework . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1 Choosing Stakeholder Analysis Participants . . . . . . . . . . 9 2.2.2 Stakeholder Analysis and Stakeholder Participation . . . . . . 9 2.2.3 The Interview Protocol Refinement Framework . . . . . . . . 10 2.2.4 Gemba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.5 Snowballing Procedure . . . . . . . . . . . . . . . . . . . . . . 12 2.2.6 Pugh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Introduction to Technical Solutions . . . . . . . . . . . . . . . . . . . 14 2.3.1 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2 Hardware Solutions . . . . . . . . . . . . . . . . . . . . . . . . 14 3 Methodology 17 3.1 Identifying the Data Collection Challenges . . . . . . . . . . . . . . . 18 3.1.1 Setting Goals and scope . . . . . . . . . . . . . . . . . . . . . 18 3.1.2 Current State Analysis . . . . . . . . . . . . . . . . . . . . . . 18 3.1.3 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.4 Interviews with Stakeholders . . . . . . . . . . . . . . . . . . . 20 xi Contents 3.1.5 Evaluation Cases . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.6 Set Requirements on Technical Solution . . . . . . . . . . . . 22 3.2 Literature Study to Evaluate Technical Solutions . . . . . . . . . . . 22 3.2.1 Find Technical Solutions . . . . . . . . . . . . . . . . . . . . . 22 3.2.2 Literature study based on snowballing & technical specifica- tions to find information . . . . . . . . . . . . . . . . . . . . . 23 3.2.3 Evaluate technical solutions based on requirements and define which met the requirements . . . . . . . . . . . . . . . . . . . 23 3.3 Recommend Technical Solutions . . . . . . . . . . . . . . . . . . . . . 23 3.3.1 Define criteria for evaluation . . . . . . . . . . . . . . . . . . . 24 3.3.2 Analysis of the technical solutions . . . . . . . . . . . . . . . . 24 3.3.3 Outcome of the analysis . . . . . . . . . . . . . . . . . . . . . 25 4 Result 27 4.1 Identifying the Data Collection Challenges . . . . . . . . . . . . . . . 27 4.1.1 Current State Analysis . . . . . . . . . . . . . . . . . . . . . . 27 4.1.2 Stakeholder Identification & Analysis . . . . . . . . . . . . . . 29 4.1.3 Interview to Make Requirements Specification . . . . . . . . . 31 4.2 Literature Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3 Recommend Technical Solutions . . . . . . . . . . . . . . . . . . . . . 39 4.4 Final Recommendation to the Case Company . . . . . . . . . . . . . 42 5 Discussion 43 5.1 Technical Solutions That Fulfills Requirement Specification . . . . . . 43 5.2 Evaluate Chosen Technical Solutions . . . . . . . . . . . . . . . . . . 44 5.3 Sustainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6 Conclusion 47 Bibliography 51 A Identification & Analysis of Primary and Secondary Stakeholders I A.1 Stakeholder Identification . . . . . . . . . . . . . . . . . . . . . . . . I A.2 Analysis of Primary and Secondary Stakeholders . . . . . . . . . . . II A.2.1 Primary stakeholders . . . . . . . . . . . . . . . . . . . . . . . II A.2.2 Secondary Stakeholders . . . . . . . . . . . . . . . . . . . . . . III B Literature Study to Evaluate Technical Solutions V B.1 OPC UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V B.2 MQTT - Message Queuing Telemetry Transport . . . . . . . . . . . . VI B.3 ExpertLogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VIII B.4 IXON Cloud IOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX B.5 Sparkplug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X B.6 MachineMetrics Edge Hardware . . . . . . . . . . . . . . . . . . . . . XI B.7 ioLogik E1200 Series . . . . . . . . . . . . . . . . . . . . . . . . . . . XII B.8 s7-1200 OPC UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII xii Contents B.9 Brownfield Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . XIV C Interview with Stakeholders and Evaluation Cases XVII C.1 Interview with Department of Intelligent Factory . . . . . . . . . . . XVII C.2 Interview with Machining Department . . . . . . . . . . . . . . . . . XVII C.3 Interview with Assembly Department . . . . . . . . . . . . . . . . . . XVIII C.4 Interview with Energy Simulation Engineers . . . . . . . . . . . . . . XIX C.5 Interview with It-security . . . . . . . . . . . . . . . . . . . . . . . . . XIX C.6 Interview with Software Developers – PLC . . . . . . . . . . . . . . . XX C.7 Machining Evaluation Case . . . . . . . . . . . . . . . . . . . . . . . XXI C.8 Assembly Evaluation Case . . . . . . . . . . . . . . . . . . . . . . . . XXIV C.9 Energy Simulation Evaluation Case . . . . . . . . . . . . . . . . . . . XXIV xiii Contents xiv List of Figures 2.1 Step guide for Gemba . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Snowballing Procedure [65] . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 Explanation of Applied Research Approach . . . . . . . . . . . . . . 17 4.1 Structure of Result Chapter . . . . . . . . . . . . . . . . . . . . . . . 27 4.2 Simplification of data flow at Aurobay . . . . . . . . . . . . . . . . . 28 4.3 Simplification of the new data flow Aurobay is requesting . . . . . . . 28 4.4 Stakeholder Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 C.1 Overaview of It Security . . . . . . . . . . . . . . . . . . . . . . . . . XX C.2 Overall view of the pumps that pressurize detergent to the lance . . . XXII C.3 pressure sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXIII xv List of Figures xvi List of Tables 2.1 Explanation of Pugh Matrix . . . . . . . . . . . . . . . . . . . . . . . 13 4.1 Identified Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2 Merge 1 of Requirements and Wishes . . . . . . . . . . . . . . . . . . 33 4.3 Merge 2 of Requirements and Wishes . . . . . . . . . . . . . . . . . . 34 4.4 Requirements Specification for Technical Solutions . . . . . . . . . . . 35 4.5 Evaluating Technical Solutions Based on Requirements Specification . 37 4.6 Pugh with IoLogik E1200 Series as Reference . . . . . . . . . . . . . . 41 4.7 Pugh with MachineMetrics Edge Hardware as Reference . . . . . . . 41 A.1 Identified Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . II xvii List of Tables xviii 1 Introduction The introduction will present the foundation for the problem that is to be researched in this thesis. The problem formulation and the case company as well as background to the importance of this topic. Overall, this chapter will provide the basis for un- derstanding the importance of the thesis and the potential impact it can have on case companies’ operations and society. 1.1 Background The rapid advancements in industrialization and informatization techniques have resulted in significant progress toward the development of the next generation of manufacturing technology. As a result, the industry is on the edge toward the fourth industrial revolution, also known as industry 4.0[66]. The progress of IoT is largely supported by four primary drivers: Sensors, Big data analytics, Cloud computing, and Machine-to-machine (M2M) or Device-to-device (D2D) communication. By combining these drivers, remote control and intelligent systems applications can be developed. [22] Machine Learning (ML) has emerged as a powerful tool in the field of artificial intelligence (AI) for developing intelligent predictive algorithms. With its ability to forecast outcomes based on trained models and historical input data, ML has gained significant attention and has become a widely researched area. There are many problems that prevent companies from implementing Machine learning (ML), some of these can be e.g. Lack of connected machines, Unclear evidence of data that provides value, Without input data, it is not possible to run ML algorithm, and safety risks with connecting machines etc.[71] The utilization of data mining techniques in manufacturing databases has emerged as a crucial means of acquiring knowledge [70]. The data mining techniques need data from the production system to give insight and knowledge about the production system. An integrated analysis of big data in manufacturing offers benefits across all aspects of the manufacturing process [52]. This shows that taking decisions based on data improves the manufacturing process. 1 1. Introduction The Internet of Things has introduced brand-new capabilities for manufacturers to detect and address areas that are affecting Overall Equipment Effectiveness (OEE). By using instrumentation and analytics to gain a comprehensive understanding of equipment performance, issues can be identified and resolved in three ways[29]: • Monitoring key performance indicators (KPIs) for a production line in real- time • Providing advance warnings of potential equipment degradation or failure to prevent unscheduled downtime • Analyzing historical process and performance data to optimize maintenance planning, schedules, and resources, resulting in decreased maintenance costs, reduced usage of materials and supplies, and increased equipment availability In order to perform predictive maintenance (PdM), it is required that there is suffi- cient useful data that can be used to perform analysis. The more data there is, the more possibilities there are for applying machine learning algorithms. The reason why businesses should investigate PdM is that there can be great economic benefits from implementing it in the business. [71] To take a step towards Industry 4,0 technologies, such as (Digital Twin, Cloud computing, advanced analytics, Artificial Intelligence, Internet of Things (IoT), and Machine Learning) data with satisfactory quality is needed. The devices closest to the machines and products are called edge devices. This paper aims to put fur- ther light on the problem to collect real-time data in a complex production system through a case study to validate if the commercial market can solve the challenges with the new demand for real-time data. 1.2 Aim The first aim is to provide a technical solution that can both gather real-time data and collect data that the stakeholder’s request but are not possible to gather in the previous technical solution. This technical solution will be an enabler for example condition-based maintenance, industry 4.0, and Internet of Things. The second aim is to find processes to collect and transfer data. This creates of optimal production processes that can lead to increased efficiency from both an environmental and eco- nomic perspective. The aim leads to two research questions. Defining the research question is likely the most important step to do in a research study[69]. Question one is formulated to investigate which stakeholders exist, what requirements and wishes they have on the technical solution, and which solutions achieve those requirements and wishes. 1. What technical solutions are available on the market that fulfills the requirements and wishes of the stakeholders? 2 1. Introduction Question two is chosen to, in an evidence-based way, compare the technical solutions that meet the requirements and to recommend which technical solution is best for Aurobay. 2. How to evaluate the chosen technical solutions based on the requirement specifi- cation? 1.3 Objective The objective of the master thesis is to compile a list of different technical solu- tions that can collect and transfer data. The technical solution should also meet the requirements of the stakeholders at case companies and give recommendations on which technical solution is optimal for their operations. The objectives will be presented to both the Manufacturing Engineering - management team and the de- partment of Manufacturing Engineering – Intelligent Factory. Various activities that must be conducted to achieve the objective are stated below: • Identify stakeholders and make a stakeholder analysis regarding data collec- tion. • Analyse the requirements and wishes that the stakeholders have on the tech- nical solution for gathering data and compile it in a requirement specification. • Find and analyze suitable evaluation cases that generate requirements to the requirement specification. • Find different technical solutions that can transfer collected data. • Evaluate if the technical solutions meet the requirement specification by con- ducting a literature study. • Find a method for ranking the technical solutions that meet all the require- ments in the requirement specification. • Evaluate and recommend which technical solution is most suitable for Aurobay with the found method. 1.4 Case Description Aurobay has developed and produced powertrain solutions for the car industry for over 100 years, the company separated from Volvo cars in 2021 and become a leader in developing and producing powertrains[14]. The case is conducted in the Aurobay plant located in Skövde which has Machining processes, automatic assembly, and manual assembly. Aurobay, like many other manufacturing companies, is currently investigating the possibility to make more data-driven decisions by collecting valuable data. For ex- ample, an initiative called Unlocking Plant Floor Data is currently investigating the possibility to adopt PdM. One challenge for the project is that some data are not 3 1. Introduction automatically collected into a database. One of the core enablers of PdM is that one has a continuous flow of data. Aurobay has a legacy system for collecting and transferring shop floor data, it has been developed, updated, and adapted in several rounds over decades. A simpli- fication of their data system is that: the system is currently able to handle data for Industry 3.0. Aurobay wants a new technical solution that can transform into industry 4.0. The current system is pushed to its limit and they now want a parallel system that can collect large amounts of data to take their manufacturing process to the next level. Aurobay wants to take further steps in IoT (Internet of Things) to make this pos- sible they need to collect real-time data. One of the advantages of working with real-time and historical data at the system and component level is that it can make algorithms for rule-based supervision in real-time possible[54]. In this thesis, the main task is to find a technical solution for Aurobay’s challenges. When technical solutions are mentioned it refers to a system with both hardware and software solutions that can work together to collect and transfer shop floor data to their database. The new technical solution should meet the requirements of the stakeholders. The technical solutions will be relatively ranked based on the require- ments and wishes of the stakeholders. Simulation engineers at Aurobay currently working to enhance the simulation mod- els with better energy consumption data. With more real-time data as input, it will be possible to validate their models. They use generic data to calculate energy con- sumption and lack the opportunity to confirm the model. If Aurobay could gather energy-related data with a new technical solution, this could be used as input in the simulations model to get a prediction of the energy consumption for a produc- tion line but also validate the model when the simulation becomes reality. Energy consumption is a trending topic that could exemplify the data usage, the data cov- ered in this study should however not be limited to just energy consumption. This example shows that the collected shop floor data can be an enabler to make more, and better data-driven decisions. Today some of the data for KPI analysis is missing and some are manually collected, this leads to delays and requires large efforts to compile. A technical solution that can handle continuous data flows will ease and expand the possibilities to analyze KPIs. 1.5 Scope and Delimitations This thesis work will investigate the types of data collection equipment and concepts available on the market that are suitable for Aurobay’s existing but also future pro- duction systems. The work will develop boundaries by having interviews with key 4 1. Introduction personnel and setting the requirements for the new technical solution. A literature study will then be carried out to deeper understand how others solved similar prob- lems and what technical solutions are available on the market. This project will not deal with any actual collection or analysis of data. The project should not focus on which kinds of KPIs the data should be used for, and no physical implementation will be made in the factory. 5 1. Introduction 6 2 Theoretical Framework In this chapter relevant information regarding different terms and methods will be presented. The chapter is divided into three parts, the first deals with various production-related terms, the second part deals with research methods and the third part handles a brief introduction to various technical solutions that is relevant to understanding and will be used to answer the research questions 2.1 Production Related Framework In this section, a comprehensive range of techniques and concepts related to produc- tion will presented and explained, equipping the reader with a profound understand- ing of the subject matter. The section will give a context to the thesis, it explains terms that are surrounding the field that will be addressed. 2.1.1 Industry 4.0 Identifying and implementing Industry 4.0 scenarios can be challenging for compa- nies due to the term, industry 4.0, being unclear[31]. Industry 4.0 is an umbrella term Including various of the latest concepts that cannot be precisely categorized within a specific discipline or differentiated from one another in certain cases[49]. Essentially, it indicates a set of, primarily, IT-driven transformations in manufac- turing systems[49]. The fourth industrial revolution involves a shift from centrally controlled to decen- tralized production processes, which is made possible by the communication among people, machines, and resources. In this paradigm shift, smart products have knowl- edge of their production history, current state, and target state, and are capable of actively guiding themselves through the production process. They achieve this by instructing machines to perform manufacturing tasks and by directing conveyors to transport them to the next production stage.[31] Industry 4.0 has, for example, led to a rise in digitization, as seen in the adoption of Cyber-Physical Systems (CPS) in manufacturing. These systems involve intercon- nected networks of humans and robots that collaborate and exchange information, aided by big data and cloud computing, along the entire industrial value chain.[44] 7 2. Theoretical Framework 2.1.2 IoT - Internet of Things IoT involves machine-to-machine communication without human intervention, with a network of devices connected to a computer system, each having a unique iden- tification. These devices can be remotely controlled with exceptional accuracy and efficiency, thus making the system smart. [55] IoT is a wide term and has some different definitions, for example, one definition found in the literature is: It (IoT) focuses on integration of the physical assets of manufacturing with the cyberspace to form cyber-physical systems.[41] 2.1.3 CBM - Condition Based Maintenance Condition-Based Maintenance is also referred to as predictive maintenance (PdM). Condition-Based Maintenance (CBM) utilizes data collected through condition mon- itoring to suggest maintenance decisions. CBM comprises three primary steps: data acquisition, data processing, and maintenance decision-making. Two crucial ad- vantages of CBM are the ability to make diagnostics and prognostics on the data collected from a production system.[36] Sensors and other measuring devices have the ability to provide significant knowl- edge of how the machine performs. By using various types of sensors, it becomes possible to continuously monitor and measure key parameters that are essential for performance evaluation.[68] 2.1.4 Brownfield vs Greenfield Within the industry, greenfield and brownfield refer to if a system is new or already existing, whereas Greenfield refers to a factory or part of a factory being rebuilt and where modern technologies can be implemented directly into the production facility. Brownfield aims at facilities that have machines and systems that are of different ages and different interfaces. In a Brownfield solution, newer types of systems for data collection are required to coexist with the older systems required for produc- tion.[23] 2.1.5 Edge Device An edge device is a device that communicates between the local network and the physical machine, for example in a production facility [9]. An edge device can collect many different types of data which are then forwarded to the product system where it can be analyzed. An edge device is essential in IIoT as it enables more information acquisition, but it is only used to collect data, it therefore does not interfere with production but only monitors it. 8 2. Theoretical Framework 2.2 Research Related Framework In this section, a number of methodologies that revolves around the subject of this thesis will be presented. The aim is to empower the reader with valuable insights into this domain and a better understanding of the different methods used. This is purely theoretical information this is to create a basic understanding of how the various methods are structured, no focus is placed on how they are applied in the project. How and why the methods are used is explained in the method chapter. 2.2.1 Choosing Stakeholder Analysis Participants Choosing stakeholder analysis participants is a method for identifying stakeholders [18]. The method starts with step 1 and can then be canceled when enough stake- holders are found. The steps are as follows: 1. Small group makes a preliminary stakeholder analysis with the help of for example, The basic stakeholder analysis technique. 2. The potential stakeholders from step 1 are gathered in a brainstorming session to find other potential stakeholders. In the case of Aurobay this can be prob- lematic due to schedule reasons and the sessions can be divided into different sessions to save time in the project. 3. Then the group of potential stakeholders should reflect on who is not attending the group, and who should attend the following meetings. 4. After this the group is complete, however, one needs to go through the earlier steps update and correct the analysis based on the new group. 5. Last step, divide the group into the roles they will have in the project, for example, sponsors and champions, coordinating group, planning team, and various advisory or support groups. 2.2.2 Stakeholder Analysis and Stakeholder Participation The method is based on the following three steps: [11]: Step 1: Define stakeholders and categorize them based on primary, sec- ondary, and key The first part of this step is to find and define the stakeholders. The second part is to categorize the stakeholders. They are categorized into primary and secondary stakeholders. Primary stakeholders are the stakeholders who are directly affected positively or negatively by the results of this project. Secondary stakeholders are for example the stakeholders that implement and monitor the project but could also be governments and their regulations. Step 2: Make a stakeholder table The second step is to create a stakeholder table to visually compare the stakeholders. The table could for example have an influence on the x-axis and power on the y-axis. 9 2. Theoretical Framework The points below are used as a basis for a brainstorming session to break down the stakeholders. • Interests that are in relation to the objectives and problems of the project should be identified. • Rank stakeholders depending on how important it is that they are satisfied with the project. • The impact that the project likely will have on each of the stakeholder’s in- terests(positive, negative, or unknown). • The project’s relative priority among the stakeholder’s interests should be presented. The ranking of influence is based on the question: for which stakeholders does the project place a priority on meeting their needs, in- terests, and expectations? The ranking of power is based on the authority to affect the direction of the project. Step 3: Risk and assumptions that can affect the outcome of the project should be identified The third step is to determine the potential risks and assumptions that will impact the project’s design and define the criteria for achieving success. 2.2.3 The Interview Protocol Refinement Framework To ensure the quality of the interviews a process for refinement is used. The inter- view protocol refinement is a process of four steps [19]. Below the four steps from the method are explained. Step 1: Ensuring Interview Questions Align with Research Questions By focusing on the alignment between interview questions and the research ques- tions in the first phase, the usefulness of interview questions in the research process can be enhanced by confirming their relevance, while eliminating unnecessary ones to ensure their importance for the study. Step 2: Constructing an Inquiry-based Conversation The interview questions are not the same as the research questions, but they are connected, they should be open-ended, relevant, and focused on the research topic. The interview must follow social rules for a normal conversation. There should be a variety of questions with likely follow-up questions. Step 3: Receiving Feedback on Interview Protocols Hand out the protocol for feedback from someone with knowledge of the project to enhance its reliability as a research tool. Step 4: Piloting the Interview Protocol During the first interview, extra attention should be paid to ensure that the questions 10 2. Theoretical Framework are interpreted correctly and that things flow smoothly. It should also be ensured that the interview provides as much information as expected. 2.2.4 Gemba Gemba, a term derived from Japanese, is employed by Toyota to refer to the spe- cific location within an organization where value-added work takes place. Gemba emphasizes the act of physically walking the process and observing firsthand where the value-creating tasks are performed.[37] Below a six-step guide for conducting Gemba is displayed. The guide put emphasis on meeting the operators in the production and engaging in the problem with them, where the problem arises. Figure 2.1: Step guide for Gemba 11 2. Theoretical Framework 2.2.5 Snowballing Procedure Snowballing procedure (also known as systematic literature review) is a method for conducting a literature study [65]. The method is presented in figure 2.2. Figure 2.2: Snowballing Procedure [65] The first step is to find relevant articles that provide a broad and nuanced approach to the field. Start by analyzing and reading all the articles included in the initial set of papers. The second step is to do backward snowballing, which means listing and checking the reference list among the initial papers. The checking includes that the paper needs to meet a basic requirement, which for example could be: • Language, they need to be written in English. • Publication year. • Has not been analyzed before in the study. After this the abstract and other key areas are read, one read until you get an idea of whether the paper should be included or excluded in the literature study. Forward snowballing means checking who has cited the paper that is being examined. Otherwise, the procedure of sorting out the sources is similar to that in backward snowballing. The new paper that is included after the first iteration of snowballing is used as the basis for the next iteration of snowballing, this can be repeated as many times as needed. 12 2. Theoretical Framework 2.2.6 Pugh The Pugh matrix is based on different criteria from the stakeholders, design param- eters, or project goals to evaluate different products, services, or processes. These criteria should be objective and take out the guesswork when evaluating the different solutions.[35] Once the criteria are determined, assign weights to each criterion based on its impor- tance. This weighting process helps prioritize the criteria and evaluates accurately reflects their significance. Additionally, select one alternative as the baseline, which can be the current method or model or any other alternative chosen.[35] To evaluate the alternatives, compare each one to the baseline. Assess whether an alternative is better, worse, or about the same as the baseline in terms of the identified criteria. The symbols "+," "++," "-", "–," or "=" to represent the scores. The number of positive, negative, and equal are summed up and used to scores for each alternative. Multiply these scores by the respective weights assigned to each criterion and calculate the weighted sums vertically.[35] Finally, one more iteration is made and refine the analysis. The strongest solution is identified based on the evaluation results. If the results are confirmed, proceed with the selected solution. If not, continue analyzing and improving the alternatives until a strong solution emerges. By conducting multiple iterations and refining the solutions, one can achieve controlled convergence and arrive at a better solution that effectively meets the project goals.[35] An example of how the matrix looks can be seen below: Table 2.1: Explanation of Pugh Matrix 13 2. Theoretical Framework 2.3 Introduction to Technical Solutions A brief description of the various technical solutions that will be evaluated in the project is provided. This information is important since it provides knowledge about the technical solutions and protocols that are analyzed in the report to answer RQ1 and RQ2. The section is divided into two subsections, one for protocols and one for hardware solutions. The different technical solutions send the data using different protocols. These protocols have slightly different characteristics that make it worth treating them separately from the hardware. 2.3.1 Protocols OPC UA OPC UA stands for Open Platform Communications Unified Architecture. The OPC Foundation developed the OPC UA protocol as an advanced, platform-independent, service-oriented architecture that offers capabilities beyond the basics, including dis- covery, address space, data modeling, and security. OPC UA uses a standard client- server mechanism, with the server featuring an information model that organizes data in a structured format.[67] MQTT MQTT is an open message protocol that positions itself as an extremely lightweight publish/subscribe machine-to-machine and Internet of Things connectivity proto- col. It prioritizes a small code footprint and low network bandwidth usage while being capable of handling high latency or poor network connections, making it ideal for communication between sensors via satellite link. Since 2013, MQTT has been standardized by the Organization for the Advancement of Structured Informa- tion Standards (OASIS) as the protocol for the Internet of Things. In MQTT, an MQTT-Server, also known as a broker, stores the complete data of all communica- tion partners. Small devices report data to the broker, eliminating the need to store the data themselves.[40] 2.3.2 Hardware Solutions ExperLogger Accurate measurement data can be acquired, stored independently, and transmit- ted to the internet or a PC for evaluation using USB, LAN, WLAN, or LTE with MQTT. When using WWAN (wireless wide area network), data can be accessed in real-time.[7] IXON Cloud IOT IXON is a cloud-based industrial automation and IoT platform that provides a com- 14 2. Theoretical Framework prehensive solution for remote access, monitoring, and data collection. One of the features of the IXON platform is its ability to collect and analyze data from various industrial devices and machines. The IXON Cloud IOT is capable of generating and transferring data in real time.[38][17] Sparkplug Sparkplug is an open-source software specification that provides MQTT clients with a framework to seamlessly integrate data originating from their applications, sensors, devices, and gateways into the MQTT Infrastructure. The utilization of Sparkplug facilitates the incorporation of data from various sources into the MQTT infrastruc- ture in a consistent manner.[26] MachineMetrics Edge Hardware The MachineMetrics Edge Platform presents an easily scalable answer for manufac- turers, which they can self-install to effortlessly gather data from any machinery and promptly obtain valuable machine insights. The platform supports universal data collection through Plug-and-Play functionality for PLCs that use open protocols.[47] ioLogik E1200 Series With support for commonly used protocols (including OPC UA) for retrieving I/O data, the ioLogik E1200 Series is capable of handling a diverse range of applications. This series retrieves I/O data and converts it into OPC UA protocol, enabling easy and seamless connectivity for data applications.[32] s7-1200 OPC UA In this technical solution, the OPC UA(described above) is combined with a SIMATIC S7-1200 controller by Siemens. These controllers are compact automation solutions that offer extended communication options and integrated technology functions. They are highly flexible and efficient, suitable for automating tasks in the lower to medium performance range. Additionally, they come equipped with a wide range of technological functions, integrated communication capabilities, and a space-saving design.[59] Brownfield Connectivity Siemens Brownfield Connectivity is a connectivity solution offered by Siemens, it is designed for existing industrial facilities or systems, known as brownfield installa- tions (see section 2.1.4). Siemens Brownfield Connectivity solutions aim to bridge the gap between existing industrial infrastructures and the digital era, enabling com- panies to leverage the benefits of Industry 4.0 and digital transformation without the need for complete system overhauls. Siemens Brownfield Connectivity.[60] 15 2. Theoretical Framework 16 3 Methodology This chapter will include the diffident methods that are used to carry out the thesis work. The chapter begins with an overview of how the project will be carried out and then provides more in-depth descriptions of the various sub-tasks To reach the aim of the project, several different methods are used. This is to finally be able to answer the research questions. The research approach is divided into three steps, Identifying the data collection challenges, Literature study to evaluate technical solutions, and Recommend technical solutions. The goal of the two first steps is to answer research question 1 and the third one is to answer research question 2. Figure 3.1: Explanation of Applied Research Approach The study began with Identifying the Data Collection Challenges which was a plan- ning phase that focused on setting goals and forming a scope for the project, which was documented in the form of a planning report. After that, stakeholders had to be identified and analyzed, and they became the basis of the current state analysis. More interviews were held with the stakeholders in this phase. Afterward, the focus was then to compile requirements and wishes into a requirement specification. The requirement specification also included requirements from evaluation cases that were 17 3. Methodology chosen with the help of the stakeholders. The second step was a Literature Study to Evaluate Technical Solutions, the techni- cal solutions are found by searching on the internet and by consultation with internal stakeholders. A literature study based on the snowballing procedure is carried out to investigate which technical solutions meet the requirements in the requirements specification. To complete the gaps that exist after snowballing, technical specifica- tions are used to find more information. When all information is gathered regarding which requirements are met, a final answer to research question 1 can be made. Finally, the last step Recommend Technical Solutions was done. A method for evaluating and recommending the technical solutions that met all the requirements was then developed and used to give Aurobay recommendations. The evaluation was done based on the criteria. When the technical solutions were analyzed, a comparison among the analyses was made. This was the answer to research question 2. 3.1 Identifying the Data Collection Challenges 3.1.1 Setting Goals and scope This was part of the preparatory work, a preliminary method was set for the project as well as a schedule for the course of the project. Objectives regarding how far along the project should be at different time stages were defined. During this part, the focus was to define the problem and the aim, this was done in consultation with the case company and the supervisors from Chalmers. 3.1.2 Current State Analysis In order to create a deep understanding of this complex data system and its chal- lenges, it was required that information was gathered about the data handling sys- tems. Understanding today’s system was vital to being able to understand how a new system could improve data collection. The current state analysis will focus on how, and what type of data is collected today. This will mainly be done through qualitative interviews with key person- nel that is working with data today. The current state analysis should although not limit the evaluation of different concepts, it could be seen as a knowledge acquisition to gain a deeper understanding of the problem from both those who “produce” the data in the factory and those who want to use the data for different types of analysis. 3.1.3 Stakeholders Stakeholder inputs are important as it is an effective way of gathering information that can be difficult to obtain in other ways[10]. Stakeholder identification and anal- 18 3. Methodology ysis were carried out to bring in key persons who could contribute information that helped the project forward. Stakeholder Identification Stakeholder identification is important since it identifies the people and departments that are dependent on the system and has great knowledge about it. This means that information is obtained from the people who have in-depth knowledge of the current system, but they are also the same people who likely will be affected by the new system. The method chosen is developed to gain information, build political acceptance and approach important questions concerning legitimacy, representation, and credibility [18]. The stakeholders were primarily identified through a version of a five-step method called "Choosing stakeholder analysis participants" [18]. The names of personnel are changed to codenames. A challenge in the project was that the case company had many production lines that were similar to each other. In order to limit the stakeholders, a selection needed to be made where different types of production lines were represented. This was done to provide a wider selection without increasing the number of stakeholders. First, a small group was conducted for the first brainstorming session. The brain- storming was held in a conference room and all participants had time to prepare before the meeting. The meeting time was set to one hour. The outcome was two new stakeholders. The new stakeholders, together with the old stakeholders, conducted one more brain- storming session under the same circumstances, with the exception that an extra 30 minutes were added since more people attended the meeting. The outcome of the session was 4 new stakeholders. The total number of stakeholders in the analysis became seven. Stakeholder Analysis In order to get an idea of who in the company would be affected by the imple- mentation and on what level, a stakeholder analysis is done to take into account their demands and wishes regarding the new technical solution. Another important aspect is that they must understand what the project’s goals are, in order to free up time for the employees to, for example, participate in interviews for the project [11]. The method used for stakeholder analysis is Stakeholder analysis and stakeholder participation, which is a 3-step model[19]. The first part in Step 1 is to find the stakeholders, this is done earlier in section 3.1.3. The second part of the first step is to categorize them and the second step is to identify if there are any interests that are in relation to the objectives and problems of the project. All stakeholders from 19 3. Methodology the stakeholder identification are reviewed according to steps 1 and 2. 3.1.4 Interviews with Stakeholders By having semi-structured interviews with stakeholders at the case company, an understanding of the requirements and wishes of the stakeholders was gained. The names of the interviewees are changed to codenames. The Interview Protocol Re- finement Framework was used to improve the quality of the interview, which likely led to better information being gathered during the interview [19]. The interviews were combined with the current state interviews, aiming to mini- mize the working time that the employees needed to use for the interviews. The time allocated for the interviews was 30 minutes. When performing the interviews, one person focuses on asking questions, and the other takes notes. The interviews are held in both Swedish and English, depending on what the interviewee prefers, and then the interviews are translated into English. The interviews were done at the: Department of Intelligent factory, Unlocking Plant Floor Data, Assembly line, Machining line, Software developers – PLC, Energy consumption simulation and IT security. The steps in the Interview Protocol Refinement Framework is used: Step 1: Ensuring interview questions align with research questions To obtain a better understanding of the current state, the first two interview ques- tions were formulated. These questions are formulated to provide a better overview and insight into the current state of the systems and what data is missing today. Question three is formulated so information about what is critical to think of when looking at implementing a new data collection and what a new solution should not affect. This is asked to get a better understanding of what is critical in the produc- tion. Question four is asked to get information on what the people that are working with data collection think is important when looking into new solutions on how data can be collected. This question will provide information about the requirements for the new technical solutions. Additionally, to gather valuable input from the stakeholders on evaluation cases, the last question where formulated. The intention behind this question is to obtain specific suggestions for evaluation cases that would be suitable for the evaluation of the new technical solution. all the questions are presented below. 1. What kind of data could facilitate your workload? 2. What do you feel is the biggest problem with Aurobay’s data collection today? 3. What consequences must the data collection process not have on your depart- 20 3. Methodology ment? 4. Do you have any other requirements or wishes regarding the data collection? 5. Do you have any suggestions on specific evaluation cases that could be good for evaluating the technical solution? Step 2: Constructing an inquiry-based conversation Questions 1 and 2 are connected to the research since it adds information to the current state analysis which is important for the project. Questions 3 and 4 are di- rectly connected to the research question. All questions are open-ended and focused to give information to gain valuable information. Step 3: Receiving feedback on interview protocols The supervisor’s feedback on the interview protocol is used to enhance its reliability as a research tool. Feedback was obtained by sending the protocol to the supervisor and getting the chance to leave feedback. Step 4: Piloting the interview protocol The first interview has held with the supervisor from the case company, after the interview, she had the possibility to leave feedback on the questions and it was also ensured that the questions were correctly interpreted. 3.1.5 Evaluation Cases Evaluation cases were real-case scenarios from the case company where the technical solution could be used. To validate the technical solution in a practical real sce- nario, the evaluation cases were chosen in cooperation with the stakeholders. This was done to create a more realistic requirement specification. Identify Evaluation Case The evaluation cases were identified through discussions with the stakeholders. Based on what the stakeholders identified as cases that could be improved with the help of data collection. To make it doable in the time span of the thesis, three cases were chosen among the recommended cases from stakeholders. The chosen cases should not be similar but rather capture various problems in production. Find Requirements from Evaluation Cases The requirements were set by doing Gemba in the production and conducting inter- views. Gemba was chosen because it enabled a focus on actual production problems and a clear connection to real everyday problems for the staff. It led to more spe- cific requirements based on knowledge from those who work closest to the machinery and knew which data was critical. The method for Gemba used in this project is explained in figure 2.1. The Gemba was done at the Processing line of the cylinder heads, assembly line of inner and outer components, and various energy-consuming machines in the produc- tion. The time booked for the Gemba was 1 hour, which was more than what was 21 3. Methodology needed. This was to create time to discuss and reflect without feeling time pressure. During the Gemba, notes and photos were taken for further analysis. 3.1.6 Set Requirements on Technical Solution In this section, the requirements specified from the interviews with stakeholders and from the evaluation cases were compiled into one table. The duplicates and similar requirements and wishes were merged into one requirement or wish. 3.2 Literature Study to Evaluate Technical Solu- tions The literature study was used as a tool to find source-critical information about vari- ous technical solutions. By going through literature that contains technical solutions for data collection, one could also come across new technical solutions that were rel- evant to the problem. The purpose of the literature study was to find information regarding the technical solutions and to evaluate if they met the requirements set by stakeholders and evaluation cases. The range of literature regarding technical solutions varied widely and often de- pended on how established the solution was on the market and how long it had been on the market. To analyze new and less established technical solutions, a mixed literature study was used. The first approach involved finding information through a modified version of snowballing[65]. If the information could not be found through snowballing, the following step was to search for technical specifications from the company that produces or sells the solution, if the information could not be obtained through snowballing. However, it is important to note that the latter approach may present biased information since it comes directly from the company with a commercial interest, while snowballing often involves information from third- party academic sources. 3.2.1 Find Technical Solutions The technical solutions were identified through a combination of targeted keyword searches on internet-based search engines and consultation with internal stakehold- ers. Several technical solutions came from internal stakeholders, during the inter- views, who encountered the solutions during previous work experiences. Potential solutions were sourced by identifying companies that provide relevant technical prod- ucts or services. Different combinations of keywords were used, examples of keywords included: Edge device production, IoT communication protocols, and Industrial data logging solutions. 22 3. Methodology 3.2.2 Literature study based on snowballing & technical specifications to find information The main method chosen for the literature study is a modified version of the snow- balling procedure (also known as systematic literature review). A key benefit of snowballing is that it initiates the research process with relevant papers and subse- quently utilizes them to guide further study [65]. The problem with a conventional literature study in this project was that relevant keywords resulted in a large number of articles, but the proportion of relevant articles was low. To find the initial papers for the snowballing, different combinations of the product name and the company names were used as keywords in Scopus and Google Scholar. The modification was made to streamline the process of conducting the snowballing literature study, and a task-specific stopping criterion was employed. The goal of this literature study was to determine whether the technical solutions meet the re- quirements outlined in the requirement specification. If it was discovered that a particular technical solution failed to meet any of the requirements, the literature study for that solution was stopped. So the stopping criterion was that if the tech- nical solution did not meet one of the requirements or had met all requirements, the literature study for the unique technical solution was stopped. Technical specifications are also used to find information by searching on the com- pany web pages, one can often find technical specifications and information regarding the technical solution. There are also often data sheets or catalogs about the tech- nical solution that can be used as a basis for the literature study. This information can be used as input when evaluating technical solutions. 3.2.3 Evaluate technical solutions based on requirements and define which met the requirements By compiling a table with the requirements and wishes in the first column and the technical solutions in the first row an easy overview of the technical solutions that met the requirements can be done. With the help of this table, one can then define which technical solutions reached the requirements shown in the requirements spec- ification. 3.3 Recommend Technical Solutions This section of the report is dedicated to describing methods to answer research question 2: How to evaluate the chosen technical solutions based on the requirement specification? The technical solutions that met the requirements in the requirements specification must be further analyzed to find the pros and cons of the solutions. Previously, all requirements were evaluated, and in this analysis, new criteria will 23 3. Methodology be evaluated. The Pugh matrix is a valuable tool for evaluating potential solutions by systemati- cally assessing their strengths and weaknesses. It allows for a structured comparison of alternatives and identifies strengths and weaknesses. Through iterative analysis, the matrix convergence towards an optimal solution. It provides a comprehensive view of the relative merits of different alternatives, guiding the decision-making process and promoting the development of an improved solution that aligns with project objectives. By actively considering and addressing the strengths and weak- nesses of each option, the Pugh matrix helps to achieve a more robust and effective solution.[35] Since Pugh is a systematic way of comparing different concepts and generates con- vergence towards the most optimal solution, it is suitable for answering RQ2. Pugh helps to objectify complex problems with multiple parameters so that the "guess- ing game" is minimized, this is good because the problem analyzed in the report is complex and multidisciplinary. 3.3.1 Define criteria for evaluation The first step when doing a Pugh matrix is to find evaluation criteria. A meeting of 1 hour was booked with the supervisor at the company to discuss the criteria to use in the Pugh matrix. The meeting was in the form of a brainstorming session where important criteria to evaluate the technical solutions were identified. The weight of the criteria where also discussed and set. The criteria capture some of the most important aspects that should be compared. The criteria used in the Pugh matrix are listed below with respective weight: 1. 25%: The solution is not dependent on PLC to work 2. 15%: Installation & Configuration 3. 10%: Stability of the company 4. 10%: Product maturity 5. 40%: It-Security level 3.3.2 Analysis of the technical solutions The technical solutions that made it thru the requirement specification are the ones that will be evaluated in the Pugh matrix. They are evaluated based on the criteria that are mentioned in the previous section. This evaluation is done in two iterations to make sure the evaluation is valid and will end up with the same result regardless of which technical solution is set as the reference. 24 3. Methodology 3.3.3 Outcome of the analysis The result in the Pugh matrix is then analyzed. The different iterations are com- pared to each other, and patterns and other observations are commented on. This is the final result that gets presented to the case company and the answer to RQ2. 25 3. Methodology 26 4 Result In this chapter, the result will be presented and it will be divided into three sections. Section 4.1 will handle what the current system looks like and what challenges there are with it are presented. In section 4.2, RQ1 will be answered and the findings from the literature study presented. In the final section 4.3, an evaluation of the technical solutions will be presented and answer RQ2. How the chapter is structured is shown below. Figure 4.1: Structure of Result Chapter 4.1 Identifying the Data Collection Challenges In this section information about what today’s system looks like and how data is collected today, a large part of the information collection is done through interviews. this information will be used for identifying both stakeholders to a new technical solution and to understand the limitations that exist with today’s system. 4.1.1 Current State Analysis Today telegram-based technical solutions are used for gathering data in different manufacturing engineering cases. This becomes a problem since it’s communicating with the PLC program which must be custom-made for each system. The cus- tomization is a communication module and function block that is added to the PLC called VDcom_v2 which sends data to a system called Virtual Device, VD. The VDcom_v2 block only works with Siemens PLC. 27 4. Result VD is used for manufacturing orders, control information, and results. The system can be custom-made for different machines to gather other types of data. Since Aurobay has many different machines and devices, they have to make a lot of cus- tomizations to collect the data by telegram in the VDCom_v2-system, another disadvantage is that the VDCom_v2-system sends a large amount of data, and one cannot request only one type of data. Some of the data is not possible to collect in an automated way and needs to be collected manually via a USB stick. The figure below shows a simplification of the current data flow in Aurobay’s production. In the example two databases are shown, however, there are more databases. Figure 4.2: Simplification of data flow at Aurobay Aurobay wants to eliminate manual data collection by using some kind of technical solution that can, in an automated way, collect data. Aurobay wants a standardized technical solution that should be able to collect different kinds of production data, examples of types of data will be analyzed in the current stat analysis to make sure that the requirements and wishes of the stakeholders are met. The reason for using a standardized technical solution is that the VDCom_v2-system can’t handle all types of data and needs the PLC to be custom-made for the requested data. It is more efficient to maintain the system if it is standardized and the same solution is used to collect data. Another advantage of a standardized technical solution is that it is easier and more cost-effective to implement the system for data collection. Figure 4.3: Simplification of the new data flow Aurobay is requesting 28 4. Result VD (Virtual device) VD is a server that handles and redirects large parts of the data that comes from production today. The data gets sent to VD-system which can then perform op- erations and divide the data and then send it to several different databases. PLC normally has a low data power and therefore calculations and divisions are made in the VD-system because it is a server with considerably more data power. VDcom_v2 VDcom_v2 is a function block and communication module that is implemented in the PLC for the various equipment in the production system which communicates with VD-system. Telegrams are sent to the VD system when various events in the PLC are triggered. 4.1.2 Stakeholder Identification & Analysis Throughout the stakeholder identification, seven different stakeholders were identi- fied, for more in-depth knowledge see appendix A.1. The categorization of primary and secondary stakeholders is explained in detail in appendix A.2. Table 4.1: Identified Stakeholders Stakeholder Short description Primary/ Secondary Department of Intelligent factory Initiated this master’s thesis since they have identified a need for an extended collection of real-time data Secondary Unlocking Plant Floor Data Project for adopting condition-based maintenance Secondary Assembly line Typical assembly line at case company Primary Machining line Typical machining line at case company Primary Software developers – PLC Developers who are responsible for the current system Secondary Energy consumption simulation Simulation engineer who wants data to make better simulations Secondary IT security Provides information regarding policies for data security Secondary Stakeholder Table First, a ranking based on the importance to satisfy the stakeholders is done to break down the stakeholders. The Department of Intelligent factory gets the highest rank- ing since they have initiated the project and the technical solution must full fill their 29 4. Result requirements, they have much power over the project. They also get a high ranking on influence because it will affect how they work with live data. Machining & assembly ends up in shared second place, they do not have the same power to control the project as the department of intelligent factory, but is impor- tant to get all the information required to implement the new technical solution. They get a high ranking on the influence scale since they will be affected by the newly collected data in their everyday work. IT security is ranked in 3rd place because the project has to follow the rules and requirements that the company has when it comes to handling data. They are not influenced by the project and are therefore placed low on the influence scale, but because the project must comply with the rules and requirements they set, they get a relatively high ranking on the power scale The other stakeholders are seen as sources of information for the project and do not have much requirement on how the data will be collected. The reason why they are identified as stakeholders is that they have a lot of information that is required to evaluate the new technical solution. Unlocking Plant Floor Data is ranked above the Energy consumption simulation since it can potentially have a greater impact than the simulations. Software devel- opers – PLC has the lowest power and influence since the outcome of the project would not affect them, it should work in parallel with the already existing systems. The stakeholders’ importance to be satisfied is indicated in the list below: 1. Department of Intelligent factory 2. Machining & Assembly line 3. IT security 4. Unlocking Plant Floor Data 5. Energy consumption simulation 6. Software developers – PLC The power and influence of the stakeholders are visualized in figure 4.4. The power represents how much a stakeholder can control the project with inputs and re- quirements, the Influence is how much the project can be expected to influence a stakeholder in their work 30 4. Result Figure 4.4: Stakeholder Table Risks and Assumptions The third step is carried out below: One risk is that the departments of machining and assembly will directly affect the department, this could be both positive and negative depending on the technical solution. This could have the effect that they leave information that can affect their work tasks in a beneficial way. Aurobay has several production departments and a complex production unit, so it is difficult to ensure that all different types of stakeholders have had their say. For example, a machining department has been interviewed, but since all machining departments are different, there is a risk of missing information. However, not in- terviewing everyone is necessary in order to limit the scope to a reasonable level for the time of the project. This makes it difficult to ensure that the analysis was successful, in the event of a possible implementation, it may be discovered that im- portant stakeholders have been missed, but before implementation, it is difficult to say whether the analysis was successful. 4.1.3 Interview to Make Requirements Specification Key Takeaways from Interviews Notes from the interviews with the stakeholder are provided in the appendix C.1- C.6. The most relevant answer to the interview questions will be mentioned below: 1. What kind of data could facilitate your workload? When talking to Energy Simulation Engineer he stated that there is an information 31 4. Result gap regarding the consumption of individual equipment and machines. For exam- ple, there is no automated way to collect energy consumption data, they need to request an electrician to go and measure for some hours and manually collect the data. They also lack data regarding average time between failures and mean time to repair. As a simulation engineer, he wishes that this type of data was based on statistics from the production. 2. What do you feel is the biggest problem with Aurobay’s data collec- tion today? The software developers state that one of the biggest problems with data collection is their use of a telegram-based solution. This method restricts them from collecting continuous data or images, which are sometimes required. Additionally, telegrams are limited to 8000 bytes each. If the data exceeds this limit, it needs to be split into multiple telegrams, making it complex and impractical for the receiver to arrange the data. 3. What consequences must the data collection process not have on your department? The IT security department marks clearly that messages can not be sent in an un- encrypted form (excluding messages within the industrial network). This is a part of the IT security policy and something that must be fulfilled. In the interview with the Assembly Department, he marks that it is vital that the technical solution must not affect the takt time on the assembly line. Affecting the flow negatively creates negative consequences with a large impact. 4. Do you have any other requirements or wishes regarding the data collection? Askros,Department of Intelligent Factory, emphasized that the technical solution should not negatively impact production takt time. It was also explicitly stated that the system should be considered a complement to VDcomv_2. 5. Do you have any suggestions on specific evaluation cases that could be good for evaluating the technical solution During the interview at Machining Department they recommended contacting a Line technician in the processing line of the cylinder heads to identify and create an evaluation case concerning the washing of components. The interviewee at Assembly Department addressed the problem of conducting alarm logs, the problem is that they need to manually the data via USB at the machine, this is done once a week, and he wants this to happen automatically in real-time. Regarding the interview with Energy Simulation Engineers, a contact person was recommended who works as an Energy optimizer, to gain a more tangible under- standing of measuring and recording energy data. Key Takeaways from Evaluation Cases 32 4. Result The three evaluation cases that were identified: machining evaluation case, as- sembly evaluation case and energy simulation evaluation case (detailed analysis in appendix C.7, C.8 and C.9. The name of the case indicates which stakeholder has recommended the case. One common takeaway from the machining and energy simulation cases is that they require measuring and transferring an output current of 4 to 20 mA from a sensor. Another requirement was that the solution required to automatically and in real- time collect alarm logs from the PLC. The Machining evaluation cases states that is important that the technical solution should not consume time or disrupt machining production. This can be rephrased as it should not affect the takt time. Another requirement is they want to easily visualize a graph depicting pressure across multiple cycles. Merge of Requirements In appendix C all the requirements and wishes of each stakeholder can be found. The merges are shown in table 4.2 & 4.3 and are done based on the factor that the requirements and wishes are similar and that requirements are weighted higher than wishes. Instead of having four requirements/wishes regarding real-time data, this is combined into one requirement that takes into account all four requirements/wishes (table 4.2). The same is done regarding takt time effects in table 4.3. The requirement, Easily be able to see a graph with the pressure over several cycles from interviews with the machining department, ends up outside our scope as it is more about how and where the data is presented rather than how it is collected. So it is not something that will be included in the requirements specification. Table 4.2: Merge 1 of Requirements and Wishes The interviewee The requirements/wishes from the interviewee interview machining department Wish: Real-time production data from sensors in the machining production Interview assembly department Wish: Real-time production data from sensors in the assembly line Interview energy consumption case Wish: Real-time data of energy consumption Interview department of intelligent factories Requirement: Can handle real-time production data from sensors in the production Merged Requirement: Can handle real-time production data from sensors in the production. 33 4. Result Table 4.3: Merge 2 of Requirements and Wishes The interviewee The requirements/wishes from the interviewee Interview machining department Requirement: Must not negatively affect the takt time on the machining line Machining evaluation case factories Requirement: Must not take time or disturb the machining production Interview assembly department Requirement: Must not negatively affect the takt time on the assembly line Merged Requirement: Must not negatively affect the takt time in the production Requirements Specification for Technical Solutions The requirements from the interviews with the stakeholders and the requirements from the evaluation cases are combined in the table presented below (see appendix C). In table 4.4 all the requirements are organized and given a shorten, for example, Requirement 1 becomes R1. 34 4. Result Table 4.4: Requirements Specification for Technical Solutions Requirement Which stakeholder? R1: Can handle real-time production data from sensors in the production Machining Department Assembly Department Department of Intelligent Factory R2: Must not negatively affect the takt time in the production Machining Department Assembly Department Department of Intelligent Factory R3: Standard solution developed by another company and only needs to be adapted to Aurobay’s production Department of Intelligent Factory R:4 The technical solution should not be limited to Siemens PLC system Department of Intelligent Factory R5:Should be able to handle the output current of 4 to 20mA from the pressure sensor and transfer it through the technical solution Machining Department R6: Automatically in real-time be able to collect alarm logs from PLC. Assembly Department R7: Be able to obtain energy consumption data from different machines Simulations of Energy Consumption R8:Should be able to handle the output current of 4 to 20 mA from the current sensor measuring 100 A Simulations of Energy Consumption R9: DMZ proxy: is a zone located between the local network of an organization and the world beyond it. IT-security Department R10:The messages sent must be encrypted (excluding messages within industrial network) IT-security Department R11: The solution must contain authentication (excluding messages within the industrial network) IT-security Department 35 4. Result 4.2 Literature Study In this section, research question 1 will be answered: What technical solutions are available on the market that fulfills the requirements and wishes of the stakeholders? The methods used are described in Chapter 3. The result will be prescribed in an evaluation matrix where all solutions are compared to the requirements that have been set. From table 4.5, it is possible to conclude which of the technical solutions achieves the requirements in the requirement specification (table 4.4), which is the answer to RQ1. Table 4.5 first row shows that lists the technical solutions to be evaluated and the first column shows all the requirements that are evaluated. The cells are color- coded with green for yes, yellow for probably and not found, and red for no. This gives a clear overview of which solutions meet which requirements. An introduction to the technical solutions can be read in section 2.3. A deeper analysis of how the results in the table were conducted can be seen in Appendix B. 36 4. Result Table 4.5: Evaluating Technical Solutions Based on Requirements Specification Requirement O P C U A M Q T T E xp er tL og ge r IX O N C lo ud IO T Sp ar kp lu g M ac hi ne M et ri cs E dg e H ar dw ar e io L og ik E 12 00 Se ri es s7 -1 20 0 O P C U A B ro w nfi el d C on ne ct iv it y R1: Can handle real-time production data from sensors in the production Y [53] Y [13] Y [7] Y [17] Y [20] Y [48] Y [34] Y [12] Y [63] R2: Must not negatively affect the takt time in the production - - Y [6] P [38] NF Y [46] Y [33] Y [12] Y [56] R:3 standard solution developed by another company and only needs to be adapted to Aurobay’s production Y [21] Y [1] Y* [6] Y [38][16] Y [28] Y [47] Y [33] Y [21] Y [57] R:4 The technical solution should not be limited to Siemens PLC system Y [21] Y [40] Y [6] Y [38][16] Y [26] Y [47] Y [33] N [60] Y [15] R5:Should be able to handle the output current of 4 to 20mA from the pressure sensor and transfer it through the technical solution - - Y [6] Y [17] Y [26] Y [46] Y [32] Y [60] Y [63] R6: Automatically in real-time be able to collect alarm logs from PLC NF NF NF NF NF P [45] NF NF NF R7: Be able to obtain energy consumption data from different machines - - Y [6] Y [17] Y [26] Y [46] Y [32] Y [12] Y [63] R8:Should be able to handle the output current of 4 to 20mA from the current sensor measuring 100 A - - Y [6] Y [17] Y [26] Y [46] Y [32] Y [60] Y [63] R9: DMZ proxy: is a zone located between the local network of an organization and the world beyond it. Y [24] Y [64] Y* [6] Y** [16] Y** [64] Y* [47] Y* [33] Y* Y [56] R10:The messages sent must be encrypted (excluding messages within the industrial network) Y [24] Y [64] Y* [6] Y** [16] Y** [64] Y* [47] Y* [33] Y* Y [56] R11: The solution must contain authentication (excluding messages within the industrial network) Y [24] Y [64] Y* [6] Y** [16] Y** [64] Y* [47] Y* [33] Y* Y [56] *The technical solution is based on the OPC UA protocol which is analyzed in the table and the analysis can be partly transferred to the technical solution. **The technical solution is based on the MQTT protocol which is analyzed in the table and the analysis can be partly transferred to the technical solution. Y - Yes. N - No. NF - Not found, a valid and reliable answer could not be found. P - Probably, no reliable answer found, sources indicate a possible solution. 37 4. Result The requirements R1 and R3 handle requirements regarding collecting real-time data from sensors and that the solution should be developed by another company, these requirements are met by all the different technical solutions. Requirement R2 on IXON Cloud IOT is set as P (probably) technical solution is connected directly to the PLC[38], there is a possibility that it affects the cycle time of the PLC program when it has to send data. To find out if it disturbs the takt time, a deeper investigation of the product and more knowledge of how the PLC processes data are required. The requirement R4, the technical solutions should not be limited to Siemens PLC are met by all technical solutions except the s7-1200 OPC UA. Requirements R5 and R8 are both regarding transferring data from an analog input of 4 to 20 mA. This requirement is met by all technical solutions except OPC UA and MQTT. This is challenging since OPC UA and MQTT are different protocols for data transmission and necessitate hardware to supplement it with the actual data acquisition solution. Hence, it is not feasible to credibly determine how the following requirements are affected: R2, R5, R7, and R8. Requirement 6, Automatically in real-time be able to collect alarm logs from PLC was in some cases hard to evaluate. Aurobay’s main supplier of PLC is made by Siemens and that is where the extraction of alarm logs should be done. The problem is that Siemens has difficulty in being able to clearly defining what is required to extract the alarm log from the PLC automatically in real time. This leads to the fact that it is difficult to check whether the requirement has been achieved because the requirement is difficult to define. To make sure that the requirement is achieved a test in reality for each unique technical solution needs to be done. Doing this is time and resource intensive and was not feasible in the project. Regarding R6 MachineMetrics Edge Hardware, on the company’s webpage, they state that it is possible to send and store alarms from the PLC to their server so that it is possible to monitor the alarms in real-time[45]. But since there is no in- formation about this requirement, it cannot be ensured that it works at the case company. The requirement R7 is about being able to collect energy consumption data, this is possible for all technical solutions except OPC UA and MQTT. All requirements regarding IT-security (R9, R10, R11) are met by all the technical solutions that are evaluated in the test. All the technical solutions are based on either the protocol OPC UA or MQTT which meets the requirements set by the IT-security department. Technical Solutions That Fulfill the Requirements Below the technical solutions that guaranteed fulfill all the requirements if one ig- 38 4. Result nores R6 (since it is not properly defined and hard to evaluate) are listed, which is the main takeaway from table 4.5. The technical solutions that may fulfill all the requirements if one sees probably and not found are ignored since they can’t be guaranteed to fulfill the requirements. • OPC UA • MQTT • ExpertLogger • MachineMetrics Edge Hardware • ioLogik E1200 Series • Brownfield Connectivity 4.3 Recommend Technical Solutions In this section, the final recommendation to the case company will be made, and an answer to RQ2 will be given. The evaluation of the technical solutions will be based on criteria. First, all technical solutions will be analyzed in each criterion and secondly, they will be compared to each other in a Pugh matrix. In the Pugh matrices, the four technical solutions that have passed the requirement specification are evaluated. The protocols(OPC UA & MQTT) are not included in the matrix as it is the hardware solutions that are evaluated, but they are reflected through IT-security level criteria. The hardware includes the protocols. Solution is Independent on PLC to Work Brownfield connectivity has the possibility to extract data directly from sensors but also through the PLC[56]. MachineMetrics Edge Hardware also has the possibility to go through PLC or take the value directly from the sensor [46]. This also applies to ioLogik E1200 Series[33]. Expertlogger can’t connect to the PLC and needs to be connected directly to the sensor[6]. Installation & Configuration ExpertLogger mainly markets itself against: environmental measurement technol- ogy, product testing, measurement data diagnosis, lab data acquisition, trials & tests and also energy optimization[7]. This can indicate that it is not developed as an easy installation and configuration solution for production since this should have been mentioned if they see it as a market segment. MachineMetrics Edge Hardware Plug & play adapters make data tag mapping and standardization unnecessary, allowing for universal data collection in PLCs that support open protocols [47]. This shows that it has a strong focus on Plug & play. On ioLogik E1200 Series and Brownfield Connectivity company websites, there is no documentation that indicates that the solution is plug & play, nor that it is a quick and simple installation process. 39 4. Result Stability of Company Brownfield Connectivity is a product from Siemens. Siemens has 313,000 employees worldwide[58]. It is the next largest company in Germany when it comes to market capitalization, they have a market capitalization of 102 billion U.S. dollars[62]. This is a large and stable company. ExpertLogger is developed by Delphin Technology AG. Delphin Technology AG was founded in 1980[4]. The company is based in Germany and it is hard to find in- formation about the company’s finances. No credible source was found, but it is claimed that they have a revenue of $6.2M[42]. On LinkedIn, they say they have 11-50 employees[5]. This indicates that it is a smaller company. Machinemetrics is a relatively small company with about 70 employees and it was founded in 2014, the head office is in Northampton, USA. The company has an annual profit of 14.7M USD.[43] MOXA, which sells the ioLogik E1200, was founded in 1987 and has over 1,000 employees. It is a well-established company that has been in the industry for over 35 years[50] Product Maturity Expertlogger was released in 2015, the product has been on the market for about 8 years and uses the technology that is relevant today[8]. Machinemetrics was founded in 2014 and they only work with data collection and platforms for data analyses. No source was found regarding when MachineMetrics Edge Hardware was released, it can’t be earlier than 2014 since this is when the company was started. A release date was not found for MOXA’s iLogick E1200, however, updates of the firmware were found that were made in 2011, which indicates that the product was launched before 2011. This means that this product has been on the market for about 12 years.[51] Siemens released Brownfield connectivity in 2019, this makes it a relatively new and unproven product that has not been implemented and tested for a long time at companies.[15] It-Security Level Compared to MQTT, OPC UA offers a more comprehensive security approach. It includes a dedicated security framework that encompasses user security, based on X.509, session security based on AAA, and transport security that relies on message encryption.[61] The OPC UA versus MQTT is a relevant comparison since these protocols are used as a base in the different technical solutions. ExpertLogger, IoLogik E1200 Series, and MachineMetrics Edge Hardware are only using OPC UA [6][47][34]. Brownfield Connectivity on the other hand is utilizing both OPC UA and MQTT [56]. This 40 4. Result shows that the solutions that have OPC UA as the protocol has a higher security standard. Pugh matrices The knowledge presented in this section is used to make the Pugh matrices shown below. The table is color-coded to get a better overview with "++" as dark green, "+" as light green, "=" as yellow, "-" as light red, and "–" being dark red. In the first iteration (table 4.6) MachineMetrics Edge Hardware gets the best result with a small margin compared to ioLogik E1200 Series, the MachineMetrics Edge Hardware, therefore, becomes the reference in the second iteration of the Pugh matrix (table 4.7). Table 4.6: Pugh with IoLogik E1200 Series as Reference Table 4.7: Pugh with MachineMetrics Edge Hardware as Reference Even when MachineMetrics Edge Hardware is used as a reference, it wins over the ioLogik E1200 Series by a small margin. The other two solutions perform signifi- 41 4. Result cantly worse, although it can be seen that Brownfield Connectivity performs better than ExpertLogger. 4.4 Final Recommendation to the Case Company Both the ioLogik E1200 Series and MachineMetrics Edge Hardware have made it through the requirements set by stakeholders. They have performed well in the further analysis of technical solutions. MachineMetrics Edge Hardware performed marginally better than the ioLogik E1200 Series. Our further recommendation to the company is to do small-scale tests where they try to implement both solutions in parallel in either a "lab environment" or directly towards the production line. This will generate a deeper understanding of the solutions and be able to guide companies in which system to potentially choose for their data collection in production. 42 5 Discussion The discussion will be based around the research questions, section 5.1 will handle research question one, section 5.2 will handle research question two, and section 5.3 will focus on how the return rate affects sustainability. 5.1 Technical Solutions That Fulfills Requirement Specification RQ1 - What technical solutions are available on the market that fulfills the require- ments and wishes of the stakeholders? The requirements from the it-security department could be called "hygiene require- ments". They reflect the most important parts of IT security, but you could, for ex- ample, match all technical solutions against Aurobay’s IT policy, IT time-consuming work that could exclude certain technical solutions. If one analyses the requirements in general, there may be indications that tougher requirements could have been used, for example, most of the technical solutions passed all the requirements. This could be because we only received the "basic requirements" from stakeholders, by "basic requirements" we refer here to the requirements that are seen as self-evident and a must-have for this type of technical solution. It is reasonable to assume that most players in the market meet customers’ general basic requirements. The fact that stakeholders were not able to specify requirements that could be considered only found in the "premium technical solutions" could be because they do not use the product today and don’t know what they want. A problem that arose when the requirements were to be put together was that no one could help us define the requirements required for a technical solution to send alarm logs from the PLC. The problem may seem simple but is complex, one can simply say that different alarm codes are used in different places in the system. Siemens is the supplier of the PLC system that is used today and they had no clear directives. They stated that their solution, Brownfield connectivity, could send most types of alarm logs. Indications were also found regarding MachineMetrics Edge Hardware being able to send the alarm log, however, this was difficult to guarantee as the requirement from the PLC was ambiguous. 43 5. Discussion 5.2 Evaluate Chosen Technical Solutions RQ2 - How to evaluate the chosen technical solutions based on the requirement spec- ification? Depending on how the criteria are chosen and how they are weighted against each other in the Pugh matrix, the end result can vary, it can therefore give a different end result if other criteria are chosen and other parameters are weighted in a different way. The analysis that is done is based on what we, together with our supervisor, value as important criteria, but if another person with different experiences does the same analysis, it may end up with a different result. To further evaluate the technical solutions, practical tests can be carried out in a lab environment to find additional weaknesses or strengths with the various solu- tions, and to ensure that they work in a way that makes it possible to implement in the case company’s production. After these tests, it can be established whether a technical solution works in practice, which we have not had the time or resources to do 5.3 Sustainability An aspect that is worth noting when it comes to sustainability is how much of the data that is collected is actually used, there is a lot of focus on collecting data so that it could be used to improve production, but if the data is not used both environmental and economic resources has been used unnecessarily. It is therefore important that there is a clear purpose for what the data will be used, otherwise, there is a chance that resources are used to collect data that will never be used. However, with the help of data collection and analysis of that data, it is possible to improve the sustainability of the production. By maximizing the utilization of ma- chines and tools so that they are not idle or that the tools are replaced before their entire useful life is used up, it is possible to get better durability without actually making any major changes in production [39]. It is possible to collect both valuable and non-valuable data with the technical so- lution that was analyzed, it is up to the user to make smart decisions about which data to collect, it is the user who must utilize the tools in a rational and efficient way. 5.4 Limitations A source that generates uncertainty is the fact that the case company is large with approximately 1300 employees in the factory that was analyzed in this report, this led to a selection among the production lines to limit the number of stakeholders 44 5. Discussion and interviews. There may be other requirements that we have not encountered. Another method of solving the problem could have given a broader analysis. How- ever, it could likely have taken more resources to do it with another broader method. A typical problem with this type of analysis is that they become outdated relatively quickly. Analyzing technical solutions in a field that is upcoming means that the solutions quickly change and improve. This means that within a few years, the anal- ysis that has been done will be outdated since the solutions and software that has analyzed have been updated and improved several times. The method of tackling a multidisciplinary problem is relevant and will remain so. The method is written generically and could potentially be used to solve other similar problems. This phe- nomenon shows that the validity of the result is most valid at its first publication; however, its validity gradually decreases over time. Collecting data in production is a large commercial area and there is a large number of players in the market. It is unlikely that all technical solutions on the market have been found. But a range of technical solutions that use different techniques to collect data have been found. Relying solely on the information provided by companies regarding their technical solutions can be risky for evaluating if they meet requirements. Ideally, the technical solutions would just be evaluated based on scientific articles. Scientific articles are considered more credible than the information presented on a company’s website or technical specifications. Companies have an incentive to promote the positive aspects of their products, which can lead to incomplete or misleading information being presented. Greater transparency and disclosure from companies are needed to address these risks. If one were to only analyze solutions that are analyzed in articles, one would have had to focus the analysis on the largest companies and many small and potentially good solutions would have been overlooked simply be- cause they are not established enough to have received academic analyses. However, this risks the validity of the result as the source of information can be seen as biased. 45 5. Discussion 46 6 Conclusion The project was carried out in three stages, the first stage was to identify how the data collection is done today and who are the stakeholders for the new technical solution. The second step was to identify which solutions were on the market that fulfilled the requirements that the case company’s internal stakeholders placed on the technical solution. The third and last step was to evaluate the solutions that met all the requirements and finally give a recommendation. RQ1 - What technical solutions are available on the market that fulfills the requirements and wishes of the stakeholders? Seven stakeholders were identified, analyzed, and interviewed, the primary stake- holders were: Assembly line and Machining line. The secondary stakeholders were: Department of Intelligent factory, Unlocking Plant Floor Data, Software developers – PLC, and IT security. The stakeholders gave recommendations for 3 evaluation cases: Machining evaluation case, Assembly evaluation case, and Energy simulation evaluation case. The interviews and the evaluation cases resulted in 11 requirements: 1. Can handle real-time production data from sensors in the production 2. Must not negatively affect the takt time in the production 3. Standard solution developed by another company and only needs to be adapted to Aurobay’s production 4. The technical solution should not be limited to Siemens PLC system 5. Should be able to handle the output current of 4 to 20mA from the pressure sensor and transfer it through the technical solution 6. Automatically in real-time be able to collect alarm logs from PLC 7. Be able to obtain energy consumption data from different machines 8. Should be able to handle the output current of 4 to 20 mA from the current sensor measuring 100 A 9. DMZ proxy: is a zone located between the local network of an organization and the world beyond it 10. The messages sent must be encrypted (excluding messages within industrial network) 11. The solution must contain authentication (excluding messages within the in- dustrial network) In total nine technical solutions were analyzed through a literature study to evaluate if they meet the requirements of the stakeholders. In total six of the nine technical solutions meet the requirements and are therefore the answer to RQ2, these solu- 47 6. Conclusion tions are listed below: • OPC UA • MQTT • ExpertLogger • MachineMetrics Edge Hardware • ioLogik E1200 Series • Brownfield Connectivity RQ2 - How to evaluate the chosen technical solutions based on the re- quirement specification? The evaluation of the six technical solutions that meet the requirements was done using a Pugh matrix, the criteria and weighting for evaluation were: 1. 40%: It-Security level 2. 25%: The solution is not dependent on PLC to work 3. 15%: Installation & Configuration 4. 10%: Stability of the company 5. 10%: Product maturity The Pugh matrix underwent two iterations, resulting in the answer to RQ2. The outcome was that MachineMetrics Edge Hardware proved to be marginally superior to the ioLogik E1200 Series, making it one of the two most optimal solutions. With these two technical solutions, the case company will have the capability to acquire real-time data and collect data with the stakeholders’ specific requirements. The technical solutions have a process where data is both collected and transferred according to the requirements of the case company. With this, the aim of the project is fulfilled. External Influence: • IoT is driven by four primary drivers, two of which are Sensors and Big data[22]. This project has provided a method where a company can further develop its data acquisition system to collect and transfer sensor data in real- time, which if done correctly, can lead to IoT. The method can be seen as a step guide to how companies can further develop their data collection. • By streamlining production, it is possible to achieve better sustainability both financially and environment