Lifecycle management and smart manufacturing: Modelling and implementation to utilize the digital twin

By Chengxue Huang and Hampus Wranér

Master thesis TPRMM 2018 Kungliga Tekniska Högskolan – Industrial Engineering and Management Department of Production Engineering SE-100 44 Stockholm

Acknowledgements

Thanks to both our families, for supporting us throughout this work and during our studies at the Royal Institute of Technology. A special thanks to our two supervisors at both the Royal Institute of Technology – Dr. Gunilla Sivard, and at Eurostep AB – Torbjörn Holm, for pushing us, acting as support during the tough times and for asking tough questions which enriched the content of this work. Thanks to Xin Ye, for answering a lot of questions during the early stages of the thesis and for providing courses for us in the area – without whose help, this work would never have been possible. Thanks to Thomas Dilts, for help with debugging and implementing the solution on the DigIn platform, and helping in making the implementation function as intended in ShareAspace. Thanks to Mattias Larsson for courses in modelling and general training in the area of PLM. Thanks to Dr. Jonas Rosén, for checking the models, and for providing expertise in the area of information modelling. Thanks to Dr. Thomas Lundholm for discussing the content of the report and the results in regard to smart manufacturing. Thanks to Sebastian Uddén, Peter Winther and Viktor Ulug for help when problems with our server occurred. Thanks to Scania CV AB for allowing us to visit the Pedal Car Factory in Södertälje. Thanks to everyone else at Eurostep AB for the immense support we have received during this work. This work was conducted as a part of the ongoing research project DigIn, part of the Strategic Innovation Program Produktion2030, a joint venture of VINNOVA, Formas and the Swedish Energy Agency.

Chengxue Huang & Hampus Wranér Stockholm, June 2018

iii

Abstract

Smart manufacturing – smart factories creating smart products – is a topic which has arisen in the academic as well as business community. This thesis covers smart manufacturing in the context of lifecycle management. The thesis investigated how the standard Product Life Cycle Support (PLCS) could be used to support smart manufacturing and mainly how to develop the underlying system and information infrastructure. Standards, reports and specifications for smart manufacturing were investigated. Several information models were created from these publications which could be used for implementing a proposed solution for the infrastructure. The implementation concerned a use case in the ongoing research project DigIn, and used the developed models to implement a proposed solution in the product lifecycle management software ShareAspace. This was done in order to evaluate how to use the functionality of PLCS and ShareAspace to utilize the solution to support smart manufacturing and update the digital twin. In parallel to this thesis, a sub- project part of the DigIn project was conducted which connected the database to other software in the system as well as to the factory shop floor. The solution used the plant service bus Kafka and REST APIs in order to establish the connection. The functionality of the system regarding the specified required functionality in the publications was then investigated. The solution was found to meet most of the requirements of the publications regarding, among others, lifecycle management, service oriented architecture, non-hierarchical structures and communication capabilities. Keywords: PLCS, Smart manufacturing, Digital Twin, Standards Disclaimer: All presented views and reflections in this report are solely those of the authors. It does not reflect the views of any of the affected and/or presented companies or organizations within this report except if explicitly specified.

v

Sammanfattning

Smart tillverkning – smarta fabriker som skapar smarta produkter – är ett ämne som inom det akademiska och affärsmässiga området förekommer alltmer frekvent. Denna uppsats behandlar smart tillverkning i kontexten av Product Life Cycle Support (PLCS). Uppsatsen undersökte hur PLCS kunde utnyttjas för att möjliggöra smart tillverkning, med huvudsakligt fokus på möjliggörandet av den bakomliggande system- och informationsinfrastrukturen för smart tillverkning. Standarder, rapporter och specifikationer för smart tillverkning undersöktes. Flertalet informationsmodeller skapades utifrån dessa publikationer vilka kunde användas för att implementera ett förslag för infrastrukturen. Implementationen hade sin bas i det pågående forskningsprojektet DigIn, och använde de utvecklade modellerna för att implementera en föreslagen lösning i produktlivscykel-mjukvaran ShareAspace. Detta gjordes för att utvärdera hur funktionaliteten i ShareAspace och PLCS skulle kunna användas för att stödja smart tillverkning och uppdatera den digitala tvillingen. Parallellt med denna implementation genomfördes i DigIn ett projekt vilka kopplade samman databasen med annan mjukvara i systemet samt fabriksgolvet. Lösningen använde en Plant Service Bus (Kafka) och REST APIer för att koppla samman dessa. Funktionaliteten av systemet rörande specificerade krav som återfanns i publikationerna undersöktes sedan. Lösningen fanns möta de flesta av de krav som lades fram i de undersökta publikationerna rörande, bland annat, livscykelshantering, tjänsteorienterad arkitektur, icke-hierarkiska strukturer samt kommunikationsmöjligheter. Nyckelord: PLCS, Smart tillverkning, Digital tvilling, Standarder Dementi: Alla åsikter och reflektioner presenterade i denna rapport är till fullo författarnas egna. Dessa åsikter reflekterar inte de berörda och/eller presenterade organisationernas eller företagens åsikter förutom om detta är explicit uttryckt.

vii

Content

ACKNOWLEDGEMENTS ...... III ABSTRACT ...... V SAMMANFATTNING ...... VII CONTENT ...... VIII LIST OF FIGURES ...... X LIST OF TABLES ...... XII LIST OF ACRONYMS AND ABBREVIATIONS ...... XIV CHAPTER 1 INTRODUCTION ...... 3

1.1. BACKGROUND ...... 3 1.2. SCOPE, PURPOSE AND DELIMITATIONS ...... 6 1.3. RESEARCH QUESTIONS ...... 7 1.4. APPROACH ...... 7 CHAPTER 2 METHOD ...... 9

2.1. INTRODUCTION ...... 9 2.2. PRE-ANALYSIS ...... 10 2.3. INVESTIGATE STANDARDS AND DEVELOP CONCEPT MODEL ...... 11 2.4. IMPLEMENTATION IN SHAREASPACE AND VERIFICATION ...... 12 2.5. INVESTIGATE SYSTEM FUNCTIONALITY ...... 13 CHAPTER 3 LITERATURE REVIEW ...... 15

3.1 INTRODUCTION AND DEFINING “SMART” ...... 15 3.2 DIGITAL TWIN AND DIGITAL THREAD ...... 16 3.3 ISO 10303-239/PLCS ...... 17 3.4 NISTIR 8107/NIST SMART MANUFACTURING ECOSYSTEM MODEL ...... 21

viii

3.5 IEC 62264/ISA-95 ...... 25 3.6 IEC PAS 63088/RAMI4.0 ...... 27 3.7 UML AND SYSML ...... 32 3.8 EUROSTEP AB AND SHAREASPACE ...... 33 3.9 OTHER EXISTING MODELS AND TECHNOLOGIES FOR SMART MANUFACTURING...... 35 CHAPTER 4 RESULTS AND ANALYSIS ...... 41

4.1 INTRODUCTION ...... 41 4.2 CONCEPT MODELS ...... 42 4.3 BUSINESS OBJECT MODEL – FOR IMPLEMENTATION AND VERIFICATION ...... 51 4.4 INSTANCE DIAGRAM – FOR IMPLEMENTATION AND VERIFICATION ...... 54 4.5 MAPPING THE BUSINESS OBJECT MODEL TO THE SHAREASPACE INFORMATION MODEL ...... 56 4.6 IMPLEMENTATION IN SHAREASPACE ...... 58 4.7 LIFECYCLE MANAGEMENT OF DIGITAL TWINS IN SHAREASPACE ...... 65 4.8 DATA COMMUNICATION AND CONSOLIDATION IN SHAREASPACE ...... 66 4.9 RESULTS ACHIEVED IN PARALLEL PROJECTS...... 67 4.10 ANALYSIS OF THE ADMINISTRATION SHELL REQUIREMENTS ...... 68 4.11 ANALYSIS OF INFORMATION HUB FOR SMART MANUFACTURING ...... 71 CHAPTER 5 DISCUSSION ...... 73

5.1 RESULT IN CONTEXT ...... 73 5.2 PLCS BASED SOFTWARE TO ENABLE SMART MANUFACTURING ...... 74 5.3 THE MAPPING OF OBJECTS, AND ITS EFFECT ON THE RESULT ...... 77 5.4 THE EFFECT THE CHOSEN METHOD HAS ON THE RESULT ...... 78 CHAPTER 6 CONCLUSIONS ...... 79 CHAPTER 7 PROPOSED FUTURE WORK ...... 81 CITED SOURCES ...... 83 APPENDIX A – SOFTTYPE MAPPING ...... A

ix

List of figures

FIGURE 1-1. GRAPHICAL REPRESENTATION OF NEED FOR STUDY ...... 5 FIGURE 2-1. GRAPHICAL REPRESENTATION OF METHOD ...... 10 FIGURE 2-2. DIGIN SCENARIO ILLUSTRATION ...... 12 FIGURE 3-1. DIGITAL TWIN FOR MANUFACTURING [2] ...... 17 FIGURE 3-2. PLCS VISION [32] ...... 19 FIGURE 3-3. PLCS CONCEPT MODEL [33] ...... 19 FIGURE 3-4. EXAMPLE OF DEX BREAKDOWNS IN PLCS [31] ...... 20 FIGURE 3-5. NIST SMART MANUFACTURING ECOSYSTEM MODEL [1, P. 4] ...... 21 FIGURE 3-6. PRODUCT LIFECYCLE [1, P. 8] ...... 22 FIGURE 3-7. PRODUCTION SYSTEM LIFECYCLE [1, P. 12] ...... 23 FIGURE 3-8. FUNCTIONAL HIERARCHY [36, P. 18] ...... 25 FIGURE 3-9. ROLE-BASED EQUIPMENT HIERARCHY [36, P. 23] ...... 26 FIGURE 3-10. RAMI4.0 [38] ...... 28 FIGURE 3-11. CLASSIFICATION OF COMMUNICATION CAPABILITIES FOR ASSETS [38]...... 29 FIGURE 3-12. VIEWS AND ADMINISTRATION SHELLS [41] ...... 30 FIGURE 3-13. GENERAL FUNCTION OF AN ADMINISTRATION SHELL [41] ...... 30 FIGURE 3-14. REQUIREMENTS FOR ADMINISTRATION SHELLS (1) [41, P. 24] ...... 31 FIGURE 3-15. REQUIREMENTS FOR ADMINISTRATION SHELLS (2) [41, P. 28] ...... 31 FIGURE 3-16. UML AND SYSML ...... 32 FIGURE 3-17. MAPPING BETWEEN MODELS ...... 33 FIGURE 3-18. THE NIST MODEL WITH CPS [1]...... 36 FIGURE 3-19. IOT CONCEPTUAL MODEL [52] ...... 37 FIGURE 3-20. SMART MANUFACTURING STANDARDIZATION REFERENCE MODEL OF CHINA [54, P. 19] ...... 38 FIGURE 3-21. JAPANESE MODEL FOR SMART MANUFACTURING [55] ...... 39 FIGURE 3-22. JAPANESE MODEL FOR SMART MANUFACTURING – FUNCTION BLOCKS [55] ...... 39 FIGURE 3-23. JAPANESE MODEL GOING FROM SPECIFIC TO GENERAL [55]...... 40 FIGURE 4-1. CONCEPT MODEL FOR SMART PRODUCT ...... 46 FIGURE 4-2. CONCEPT MODEL FOR SMART FACTORY ...... 50 FIGURE 4-3. BUSINESS OBJECT MODEL FOR IMPLEMENTATION ...... 53

x

FIGURE 4-4. INSTANCE DIAGRAM EXAMPLE TO EXPLAIN IMPLEMENTATION ...... 55 FIGURE 4-5. IMPLEMENTED DIGIN USE CASE ...... 59 FIGURE 4-6. THE FRONT PAGE OF SHAREASPACE ...... 59 FIGURE 4-7. CREATED SOFTTYPE QUERIES AS SHOWN IN SHAREASPACE ...... 59 FIGURE 4-8. IDEA OF SYSTEM FUNCTIONALITY ...... 60 FIGURE 4-9. A SOFTTYPE CREATE WINDOW ...... 61 FIGURE 4-10. VIEWS IN SHAREASPACE ...... 62 FIGURE 4-11. A SOFTTYPE (REALIZED PRODUCT) AS SHOWN IN “READ” IN SHAREASPACE ...... 62 FIGURE 4-12. ENUMERATIONS AS IMPLEMENTED IN SHAREASPACE ...... 63 FIGURE 4-13. A STRUCTURE OF A REALIZED PRODUCT AND IT'S COMPONENTS (PARTS) ...... 63 FIGURE 4-14. DATED EFFECTIVITY AND TRACEABILITY (1) ...... 64 FIGURE 4-15. DATED EFFECTIVITY AND TRACEABILITY (2) ...... 64 FIGURE 4-16. PARTICIPANTS AND ROLES ...... 65 FIGURE 4-17. EXCEL IMPORT RESULTS ...... 66 FIGURE 4-18. A JSON-MESSAGE FROM STATION 1 ASKING FOR THE NEXT TASK TO PERFORM [17] ...... 67 FIGURE 4-19. A JSON-MESSAGE FROM SHAREASPACE TO STATION 1 AS A REPLY ON THE REQUEST [17] ...... 67

xi

List of tables

TABLE 1. DESCRIPTION OF BASETYPES AND CONNECTION TO PLCS ...... 34 TABLE 2. LEGEND FOR SYMBOLS IN SYSML-MODELLING ...... 43 TABLE 3. KEY CONCEPTS FOR SMART PRODUCTS ...... 44 TABLE 4. KEY CONCEPTS FOR SMART FACTORIES ...... 47 TABLE 5. COLORS OF CLASSES ...... 51 TABLE 6. SOFTTYPES MAPPING ...... 57 TABLE 7. REQUIREMENTS OF ADMINISTRATION SHELLS ...... 71

xii

List of acronyms and abbreviations

Acronym/Abbreviation Meaning AI Artificial Intelligence AP Application Protocol API Application Programming Interface AS Administration Shell CAD Computer Aided Design CP Communication/Presentation CPS Cyber-Physical System CRM Customer Relationship Management DEX Data Exchange specification ERP Enterprise Resource Planning GD&T Geometrical Dimension and Tolerancing I4.0 Industry 4.0 ID Identifier IEC International Electrotechnical Commission IoT Internet of Things IP International Protection Marking ISO International Organization of Standardization IT Information Technology JSON JavaScript Object Notation MBSE Model-Based System Engineering MES Manufacturing Execution System MIIT The Ministry of Industry and Information Technology of China MOM Manufacturing Operations Management NIST National Institute of Standards and Technology O&M Operation & Maintenance PCF Pedal Car Factory PLCS Product Lifecycle Support

xiv

PLM Product Lifecycle Management RAMI4.0 Reference Architecture Model Industry 4.0 RDL Reference Data Library ResCoM Resource Conservative Manufacturing REST Representational State Transfer RFID Radio-Frequency IDentification SAC Standardization Administration of China SCM Supply Chain Management SOA Service Oriented Architecture STEP Standard for the Exchange of Product model data SysML System Modeling Language UML Unified Modeling Language XML Extensible Markup Language

xv

xvi

Chapter 1

Introduction

This chapter aims to give an overview over the thesis, why the thesis was conducted, what is aimed to be achieved with the thesis, and how the thesis is dispositioned

1.1. Background

The manufacturing industry is today experiencing a major reformation, with the introduction of several new and innovative concepts and practices. The common denominator in many of these concepts is digitalization, where new IT tools and support systems are developed to meet the new emerging requirements. In the scientific community and academia, there has been a lot of research in these fields for a long time. The standardization community is also greatly involved in this research since standards are the fundamental enabler of the manufacturing of the future and its different concepts [1]. One of these new concepts is the concept of digital twins, which can be described as

“an evolving digital profile of the historical and current behavior of a physical object or process that helps optimize business performance”. [2, p. 3] In essence, the digital twin can be said to be a digital replica of a physical entity, with all information necessary to describe states of the entity easily accessible in an IT system.

3 (86) Chapter 1 Introduction

There are tools in the market today that can be used together with the digital twin concept. One of many tools which can be utilized is Kafka, which has been well adopted in the manufacturing industry. Kafka is an open-source software platform developed by the Apache Software Foundation. It can be seen as a “pipeline” that has the abilities to stream data in real-time with high reliability and consistency between applications and systems, and react to that data as it happens [3]. These capabilities are valuable in the sense of enabling the communication to update the digital twin based on the data stream from various sources. Smart manufacturing is another concept which has gained more attention recently. Some of the expected benefits of implementing and using smart manufacturing is the optimization of several important and high cost business areas, such as labor, material management and energy consumption [1]. In addition, the use of smart manufacturing enables the possibility to adapt the production more quickly according to market demand and produce high-quality products for the consumer to less cost [1]. Basically, the smart manufacturing paradigm is combining previous manufacturing paradigms and their benefits covering areas from lean- to digital manufacturing [1]. The digital twin, as presented previously, can be argued to be one of the enablers to smart manufacturing, since it allows for efficient information management about objects or products in the IT-system. It enables the management and exchange of data and information which is stated in [1] as a support for the aforementioned benefits. When technology develops into more complex issues, questions on cooperation between organizations and actors arises. It is beneficial for all actors that everyone conforms to the same rules and speak the same language [4]. By doing so, complex projects might avoid costly misunderstandings stemming from miscommunication or from re-creating already existing solutions to some common problems [4]. Standards are an answer to these issues and can be seen as a way of identifying “what's the best way of doing this?” [5]. In addition, standards are a big part of the value stream of companies. As an example, an approximate 80 % of the world’s produced goods are affected in some way by standards during trade [6]. There are several standardization organizations focusing on developing national and/or international standards in several areas to achieve conformity and establish a best practice for the business. In the standardization community, several models and architectures describing the concept of smart manufacturing have been developed and are in development. The German developed model Reference Architecture Model Industry 4.0 (RAMI4.0) and the American developed model NISTIR 8107 (the NIST – National Institute of Standards and Technology – model) are two examples of models and architectures developed to meet the increasing need for standardized ways of describing smart manufacturing. From a business perspective, it is of greatest interest to investigate how these models and architectures could be combined and utilized [7]. Especially, a focus on the used semantics and terminology used in these standards should be used, since that is a key factor in enabling future manufacturing trends [8]. One of the major problems facing smart manufacturing is how to integrate information and data in an efficient way. When integrating resources used in production (whether systems or shop floor resources), there is a possibility the information is not sufficiently integrated into the complex network of connected assets, and instead is only stored or visualized locally – creating islands of information not being accessed [9]. Some organizations talk about “information silos” [8, pp. 60-62] and states that they are one of the major problems for them [8]. Overbridging this gap is thus one of the key enablers of smart manufacturing. Another aspect crucial for smart manufacturing is that the latest information is used when making decisions, this requires efficient transmittal of real time data and demands that systems affected by this data can acquire it fast and reliably [9]. Product Life Cycle support, PLCS, is a Product Lifecycle Management (PLM) standard which is built around lifecycle information with the objective to provide product support, and Microsoft has stated that PLCS is a standard which could be used to meet the arising requirements in smart manufacturing [10].

4 (86) Chapter 1 Introduction

Thus, it is of great interest to investigate how PLCS can be utilized/exploited to realize smart lifecycle support in the context of smart manufacturing. Von Euler-Chelpin [11] investigated whether PLCS could be utilized in order to describe production equipment (a machine center). The conclusion was that in theory it could, however the author emphasized that the generic structure of the PLCS standard lead to a need for well-defined uses and instantiations of concepts regarding the machine center [11]. It is therefore interesting to investigate if standardized ways of expressing concepts on a higher level, such as smart manufacturing, can be realized in a PLCS based IT system. Eurostep AB, a supplier of the PLM software ShareAspace Nova (based on the PLCS standard), has its aim on utilizing its software to meet the new requirements of digitalization regarding the digital twin. Work has been conducted in regard to smart manufacturing in the sense that previous studies have shown that ShareAspace Nova was capable of handling streamed data using Kafka [12]. The next step is to evaluate how to use this functionality and utilize the solution to enable smart manufacturing and update the digital twin when events happen in order to make sure the twin is a replica of the physical world. This can be illustrated in Figure 1-1, where the use of ShareAspace in the solution is what is interesting to be detailed and evaluated. To do so, one or several models need to be developed which can describe a smart product/smart factory (smart manufacturing), that can be used in order to meet the future need of lifecycle based information for smart manufacturing. For example, one should be able to trace a product through its entire life and follow all states (such as in planning, in production, in use) in which information is created and associated with the product. By being able to do so, improvements for both the product and production system should be able to be achieved. Other reports have been created on similar topics to this thesis. For example, in [13] a Resource Description Framework (RDF) model was created based on RAMI4.0 and based its vocabulary on the ISA-95 (IEC 62264) standard. The model contained relations between different concepts in the standards – albeit a very limited number of concepts. This thesis however, has a wider scope and includes other processes in the developed models which are part of the production- as well as product lifecycles.

Figure 1-1. Graphical representation of need for study

5 (86) Chapter 1 Introduction

1.2. Scope, purpose and delimitations

The purpose of this thesis is to study how to implement the concept of smart manufacturing in a PLCS context as a means for establishing smart product and production system lifecycle support. Business reports/standards for smart manufacturing are investigated and simplified information models are created to get a comprehensive understanding of the possibilities PLCS has in regard to enabling smart manufacturing lifecycle management. The main focus is on the models and whether PLCS can be used to support the traceability between products and production systems throughout their lifecycles. Issues concerning realizing other PLM functionalities in the system, such as access rights and authorization, are considered out of scope. A proof of concept is to be done that implements the solution in a PLCS software to verify the models in an infrastructure for smart manufacturing use case (the DigIn project). The thesis will solely consider how the PLCS standard can be used to integrate lifecycle support in smart manufacturing using the ShareAspace Nova product. No other PLCS based products will be used. The term smart is limited to the definition of “smart” as presented in the thesis. The main focus is on the infrastructure of the smart system and digital twin. AI and automation of decisions are not considered in this report. The specifications and reports from the standardization community which are considered in this report are:

• IEC PAS 63088 (RAMI4.0) • NISTIR 8107 (the NIST model) The supporting standards to these specifications/reports which have been considered are:

• ISO 10303-239 (PLCS) • Unified Modeling Language (UML) • IEC 62264 (ANSI/ISA-95) • System Modeling Language (SysML) • IEC 61512 (ANSI/ISA-88)

These standards/specifications/reports are either used directly or indirectly in the investigative study or used as a reference. No other standards or specifications are considered unless explicitly stated. The developed models are limited to concepts within level 4 and level 3 according to the classification from IEC 62264 (ANSI/ISA-95). Furthermore, out of the different parts available for IEC 62264, the definitions in IEC 62264-1 and IEC 62264-3 are the ones used for this work.

• IEC 62264-2 contains object models and attributes of certain objects from IEC 62264-1, which is considered out of scope for this work since no investigation on the required attributes of each identified class to be implemented will be done. However, it contains some information, such as the division of used objects into ordered and performed (actuals) during manufacturing which are in scope, but this is covered by ISO 10303-239. • IEC 62264-4 contains models which are used to connect different enterprise activities with certain activities in order to control processes. This is out of scope, since it is looking at a very detailed level of some of the objects from IEC 62264-3. • IEC 62264-5 contains transaction models which are used to define information transactions as defined by IEC 62264-2 and IEC 62264-4. Since the latter two are out of scope, their transaction models of are also out of scope. In IEC 61512, only the definitions that are referenced by RAMI4.0 in IEC 61512-1 [14] are used. No other parts of the standard are used. RAMI4.0 is a reference architecture with several new concepts and terminology which is of interest for smart manufacturing. The NIST model is however an investigation over the current standard landscape and proposes new ways of combining and utilizing the standards to enable smart manufacturing. Thus,

6 (86) Chapter 1 Introduction these documents have different views and can be used in different ways when investigating how the standards community view smart manufacturing. This is the reason why these two have been selected for this work – to enable two viewpoints into a very complex problem. The concept models will be developed with both the product and production system’s lifecycle in mind. The focus is however on the production system, since this report focuses on the establishment of an underlying infrastructure for smart manufacturing, where the verification is on a smart factory, not on smart products. This is also one of the reasons why the digital twins in the implementation are simplified, and only attributes which are currently measured in the DigIn project are used. As mentioned previously, for the purpose of evaluating the solution, the on-going DigIn project will provide a scenario (use case) which can be used to showcase if the solution meets the requirements of a smart manufacturing system. The DigIn project is a research project with the aim to create a digital infrastructure in a pedal car factory at Scania [15]. The result in this thesis will be used together with results from parallel projects to demonstrate a first iteration of the underlying infrastructure.

1.3. Research questions

Based on the background and the goals and requirements of the study, an overlying research question was formed: How can PLCS be utilized/exploited to realize smart lifecycle support in the context of smart manufacturing, and how can it be implemented on the PLCS based software ShareAspace? The question was narrowed down into the following sub-questions: Question 1: Can the concepts used in relevant smart manufacturing standards together with concepts from PLCS represent lifecycle support in the context of smart manufacturing? Question 2: Can these concepts be implemented on a PLCS-based software? Question 3: Does the proposed solution meet the requirements of smart manufacturing as expressed by the standardization community?

1.4. Approach

The approach of this thesis was to:

• Investigate smart manufacturing specifications/reports/standards to select a standardized terminology to use in the smart manufacturing use case of this thesis. • Use the terminology to develop UML/SysML (Unified Modeling Language/System Modeling Language) models which can be used to enable an infrastructure for smart manufacturing using the PLCS based software ShareAspace. • Implement the suggested solution based on the information models in ShareAspace. • Verify the usability of the solution by attempting to utilize it to represent the data in the smart manufacturing infrastructure project DigIn (the DigIn use case). • Compare the suggested solution with the requirements of the smart manufacturing standards on system functionality to evaluate to what extent PLCS and ShareAspace can be used to enable smart manufacturing.

7 (86)

Chapter 2

Method

This chapter aims to give an overview over the methods used in the thesis

2.1. Introduction

The method is based on a qualitative approach where conclusions are drawn based on reasoning rather than data. In short, the method is divided into nine steps, c.f. Figure 2-1, which are all considered to be crucial to achieve a good end result. A pre-study was conducted which laid the ground for the main study and the thesis. The second step include a study and identification on common terminology/semantics used in the smart manufacturing and PLM standards with the aim to develop information models for implementation. In addition, some general lifecycle aspects were taken into consideration during the study. The outcome of these studies was used when implementing a proof of concept solution in the ShareAspace software in the context of the DigIn use case. A more thorough description of the method will follow.

9 (86) Chapter 2 Method

Figure 2-1. Graphical representation of method

2.2. Pre-analysis

In order to get an extensive overview over the area of investigation, a thorough analysis over several key business standards was conducted. The study was then used in order to formulate the research questions and to set an aim for the thesis. In order to limit the number of used standards in the thesis, a selection of standards was done based on the potential impact these standards were reasoned to have on the end result of the thesis. The following standards, reference architectures or specifications were concluded to be of crucial interest;

• ISO 10303-239 (PLCS) • IEC PAS 63088 (RAMI4.0) • IEC 62264 (ANSI/ISA-95) • IEC 61512 (ANSI/ISA-88) • NISTIR 8107 (the NIST model) The underlying principles of work within the thesis was then investigated. UML and SysML are the modelling languages used in this report to create models for the adaptation of the software. Courses on the two languages were taken to get an underlying understanding of the method to use. The method is greatly affected by the use of the DigIn use case as a reference when deciding what concepts that are necessary to model in smart manufacturing.

10 (86) Chapter 2 Method

2.3. Investigate standards and develop concept model

After the standards of interest were singled out, a more thorough study of the selected standards was conducted. From this study, a set of concepts was identified to be key in order to describe a smart factory and smart products from the focus of the DigIn use case. Only concepts with well-defined definitions was used, due to the desire to avoid ambiguity. These concepts were then used to create concept models, showing the concepts and the interconnections. The concept models were developed based on the authors’ interpretation of the concept definitions, their importance to describe smart manufacturing and their interconnections. The models were based on the UML and SysML modelling languages. By using the DigIn project as a framework, a decision on what concepts should be included or not could be made. The investigated standards contain more concepts than the ones used in this report, and is thus selected based on the impact these concepts are believed to have on the end result.

The DigIn scenario The DigIn project, which are used in order to verify the content of the developed models, is necessary to be described from an implementation scenario. The scenario reflects automotive production which is complex with high demands on quality and lead time. In addition, changes are introduced continuously and production of one type of product might be performed in many different plants. The idea is to reflect the level of complexity of order based truck production and while the use case concerns the considerably less complex assembly of a pedal car, it is still relevant as a use case. [15] One means to manage the complexity is by planning ahead while adapting to changes. Thus, during the design and preparation phases, the types of products, tasks and tools are planned without details which may vary without changing the general plan. At the time of order, these details are settled based on the current versions of components, choice of suppliers of material, tools etc. Thus, it is important to differentiate between a type of product/process/resource, their detailed specification at time of order, and their physical realization. Figure 2-2 illustrates the principle of separating information concerning types, specifications and realized entities. For exact models of how this was implemented in the use case, see chapter 4.6. In the implementation, before an order is placed, the products and production system have been prepared and information about the production system and product configurations with planned tasks to execute for each configuration and parts to assemble in each task is already residing in the database. This data is used to make up all information necessary to manufacture products on a type level and to order the manufacturing of products on the instance level. When an order is placed, information about the specific order – for example what unique/modified product configuration is to be manufactured and what consumables and tools to use to assemble it – is created. For example, the order-based task includes information about the required torque for a torque tool which is used to tighten the assembly of mud guards on the pedal car. When the unique product has been ordered and manufacturing has begun, this information is published on request from the stations via the service bus Kafka. The resulting torque is measured and the information is published to be saved in the realized task model as an actual performance value.

11 (86) Chapter 2 Method

Figure 2-2. DigIn scenario illustration

2.4. Implementation in ShareAspace and verification

Based on the concept model, a mapping (translation) of the concept model to a business object model was done. The business object model is in short, a model showing business objects and their relations which are to be implemented in the software. By studying what was necessary in order to describe a smart factory and a smart product (smart manufacturing), reasoning was performed regarding how and in what way the identified concepts could be represented in a business object model. The business object model was created to be able to use it as a basis for implementation in the software ShareAspace Nova. Concepts which were believed to only be abstract and not something one would instantiate was not included in the business object model. Only those concepts that were believed to be necessary to instantiate (create) were included. ShareAspace is a well-established software, and already has information models based on the PLCS standard which the software is built on. When developing solutions to be implemented, it is necessary to map (translate) the implementation models to the already existing ShareAspace information models. Thus, a mapping was done between the identified concepts in the business object model and the ShareAspace data model using Microsoft Excel. The mapping shows what business object is mapped to what ShareAspace concept and what ports (connections) are used to assign relations and/or attributes to the object. The concepts in the ShareAspace information model is in turn already mapped into PLCS concepts. This way, each concept as they were defined in the developed business object model could get a translation in the PLCS (ShareAspace) domain. The mapping is necessary in order to describe how the proposed solution is meant to be implemented. In order to verify that the developed solution could represent the necessary information used today, and thus could be used to utilize the shop floor data, the DigIn project provided a simple example of the Pedal Car Factory (PCF) at Scania. The PCF involves several systems which need to be integrated and information in the different systems is to be consolidated in ShareAspace. The reasoning was that if the model could represent the basic information in the PCF, it could be utilized as a broker between systems and consolidate information in the different systems into a purposeful and easily accessible information hub, solving the problem of the islands of information as mentioned previously. This is beneficial not only for smart manufacturing, but for manufacturing in general, since systems that do not cooperate and communicate information efficiently (effectively creating islands of information), is one of the main sources of quality issues and production errors [16], and this solution would thus reduce these problems. Since ShareAspace has proven capabilities of handling streamed data using Kafka [17] it should thus also be able to handle the functionality requirements of smart manufacturing.

12 (86) Chapter 2 Method

Thus, in order to verify the representations, implementation objects were created in ShareAspace in order to exemplify the solution based on the business object model and the information from the DigIn use case. Furthermore, an instance diagram was developed to showcase how instances of objects were to be instantiated in the database.

2.5. Investigate system functionality

Based on the developed models and implemented solution and the objects in it, a study of the system functionality was done. What was investigated was whether the proposed solution and infrastructure could meet the requirements on system functionality that is described in the investigated business reports and standards. Requirements regarding key functionality of a smart manufacturing system was compared to the functionality in the system in order to draw conclusions on whether the system and PLCS was suitable to use for implementing smart manufacturing. From this, a proposal of further work was developed, and recommendations on how to utilize the PLCS standard for smart manufacturing was presented.

13 (86)

Chapter 3

Literature review

This chapter aim to provide a holistic view over the area of investigation by investigating standards and methods used in business today

3.1 Introduction and defining “smart”

In business today, there are multiple standards which aim to simplify the way companies work and interact. However, the vast standard landscapes might make it hard to get a holistic overview over the area. With the introduction of Industry 4.0 and concepts such as smart manufacturing and smart products, the standard landscape shift. Several models, reference architectures or recommendations on how to implement smart manufacturing has been developed in the standards community. Two of these are RAMI4.0 (IEC PAS 63088) and the NIST model (NISTIR 8107). These publications have different viewpoints and can be combined and used to provide insight into how the different standardization organizations view the complex concept of smart manufacturing. In addition, adapting to two different viewpoints is likely to extend the usability of any potential solution to the problems described in the publications as long as the recommendations do not contradict each other. One interesting thing to note is that the NIST model concluded several gaps in the available standards in order to fully describe smart manufacturing – one of which being the PLM/MES/ERP/SCM/CRM integrations [1]. By using the commonly referred standards in the previously mentioned documents and combine them with the established PLM-standard ISO 10303 (STEP) AP 239 – a standard which NIST

15 (86) Chapter 3 Literature review mentions in their report [1] – it would be interesting to investigate whether the PLM integration would be possible using already existing standards.

Defining “smart” The term “smart” is something which might from an academic and business perspective cause a lot of debate. What one organization or person defines as smart might not be a “true” definition. Therefore, it is important to define what this thesis regards as “smart” when talking about smart manufacturing, -factories and -products. Definition 3.1. “A Smart Factory is a manufacturing solution that provides such flexible and adaptive production processes that will solve problems arising on a production facility with dynamic and rapidly changing boundary conditions in a world of increasing complexity” [18, p. 1187] Definition 3.2. “Smart products are cyber-physical products/systems (CPS) which additionally use and integrate internet-based services in order to perform a required functionality.” [19] In essence, the focus in this thesis is not on Artificial Intelligence (AI) and products/systems being able to automatically evaluate data and adapt accordingly, but instead on the communication capabilities and the interconnection of products and systems into an interconnected web of entities supporting required functionality. Smart manufacturing is defined based on the findings of the investigation regarding the standards later in the thesis. AI and automated data evaluation is left as a subject of investigation for the future.

3.2 Digital Twin and Digital Thread

The digital twin is a concept which has been discussed both in industry and academia. Depending on the industrial practice and what software vendor one asks, there are different views of what the “digital twin” really is. Though, one can observe some common characteristics. For PTC, the digital twin is the link between the physical product and the digital product model; Tesla aims to use the digital twin in order to enable synchronous data transfers between the car and factory; and for General Electric, the digital twin is what enables forecasts of health and performance of products over their complete lifespan [20]. As with most of the concepts and terms in this thesis, it is necessary to define the meaning of the concept. The digital twin can be defined as Definition 3.3. “an evolving digital profile of the historical and current behavior of a physical object or process that helps optimize business performance” [2, p. 3] Regarding the connection between PLCS and the digital twin, PLCS is said to be a standard which could be utilized in the system architecture of the digital twin [10]. However, in order to fully understand what the digital twin is and how PLCS can contribute, it is important to understand what the end-goal of using a digital twin is. According to [21], the vision of the digital twin refers to

“…a comprehensive physical and functional description of a component, product or system, which includes more or less all information which could be useful in all – the current and subsequent – lifecycle phases”. [21, p. 59]

16 (86) Chapter 3 Literature review

Figure 3-1. Digital twin for manufacturing [2]

This vision can to some extent also be considered to be a definition of the digital twin. Consequently, the digital twin is of great interest from a lifecycle perspective. The utilization of the concept in the PLM domain (using PLCS) would therefore not only be of greatest interest, but also crucial in order to consolidate information in all stages of a products’ lifecycle. A graphical representation of a digital twin is shown in Figure 3-1. A digital thread is a communication framework that enables an integrated view of data as well as the connected flow of data for each asset throughout the manufacturing lifecycle [22]. In the military aircraft industry, the digital thread concept is crucial and has been the key enabler to improve future programs’ performance [23]. By creating and using digital cross-domain representations of a system, a dynamic and real-time evaluation of the current and future capabilities in the system can be achieved [23]. Some of the benefits when utilizing digital thread mentioned in [23] are, first, that the development time can be reduced by 25%, and second, it simplifies decision making processes by evaluating the in-depth data obtained through the digital thread, hence the risk can be quantified. These are some of the enablers needed in order to provide agility for rapid development and deployment [23]. The main objective of the digital thread concept is to use all available information (the digital twin) to make well balanced decisions throughout a system’s lifecycle [23]. The ultimate goal of the digital thread is to deliver “the right information to the right place at the right time” [24]. The digital twin contains all the essential data associated to the product, and the digital thread enhance the digital twin throughout a product’s entire lifecycle where data can be transferred from one life stage to another which enables the possibilities for different actors to access data from one stage in order to provide feedback to another [25].

3.3 ISO 10303-239/PLCS

ISO 10303-239, or more commonly referred to as PLCS (Product Lifecycle Support), is since 2004 a STEP standard focusing on providing information about products throughout the complete product lifecycle [26]. The main idea is to combine information and data created in different stages of the development, production and life of products in order to provide support capabilities throughout the products’ lifecycle [27]. PLCS require two main concepts in order to function as intended, a Data Exchange specification (DEX) and a Reference Data Library (RDL) [27].

17 (86) Chapter 3 Literature review

PLCS is a very generic standard, with a low number of rules stating how to map (translate) objects into the information model – this is deliberate, since it is then possible to utilize PLCS in a lot of different businesses and allow for easier cooperation between companies [28]. PLCS is currently under revision, and a new edition (3) is under development in a (at the time of the thesis) preparatory state [29]. In a white paper, [27], with the aim to add to the third edition of PLCS, it was said that ISO 10303-242 recently added so called business object models to the standard, and this was said to enable the use of language and semantics existing/being used in businesses, simplifying the understanding for users in each specific domain. The business object model is something Eurostep AB and ShareAspace already utilize [30], thus the company is at the forefront of development in the PLCS business. By utilizing ShareAspace Nova to investigate whether smart manufacturing can be represented in a PLCS-based software, would give an indication of whether the future PLCS standard is capable of these representations. In order to fully comprehend the scope of the PLCS standard, it is necessary to understand the underlying principle behind the standard, thus a thorough explanation of the vision and concept model of PLCS is necessary.

PLCS Vision and Concept Model PLCS was developed to help companies tackle some existing business problems. Companies that have high complexity assets, i.e. planes and submarines, could face challenges regarding management of information of its assets. In order to retain competitiveness in the after-market, the ability to manage complex information associated to the product and activities related to the product is a key requirement. The vision of PLCS, which is illustrated in Figure 3-2, is to create a standardized information model that helps the company to manage information exchange of its assets through its lifecycle, regardless of complexity. [26] To describe the basic data item in the PLCS vision, the PLCS concept model provides a holistic view over the key information models that are supported by PLCS. The concept model is shown in Figure 3-3.

Data Exchange Specifications As mentioned, the core in the communication of information in the PLCS standard is the Data Exchange Specifications (DEXs). The DEX is an information model showing communicated information, divided into subsets depending on the use of the information. By using DEXs, a visual image over the communicating data can be displayed. [31] A representation of a DEX is shown in Figure 3-4.

18 (86) Chapter 3 Literature review

Figure 3-2. PLCS vision [32]

Figure 3-3. PLCS Concept Model [33]

19 (86) Chapter 3 Literature review

Figure 3-4. Example of DEX breakdowns in PLCS [31]

Reference data library The second important concept necessary for PLCS is the Reference data library, or RDL. According to Oasis, the RDL is “[…] a managed collection of Classes and Individuals that are specified separate to and referenced from a data exchange file.” [34], where the Reference data itself is defined as: “[…] data that represents information about classes or individuals which are common to many users.” [34]. In short, RDL specializes the concepts that are presented in the PLCS information models. In other words, the RDL is what contain information about the classes in the UML/SysML-model, both their properties and their relations.

Previous research on PLCS and manufacturing Some previous research has been conducted in the field of PLCS and manufacturing. Von Euler-Chelpin [11] conducted information modelling in the context of the manufacturing lifecycle for PLCS. When modelling a machine center, it was concluded that the generic structure of the PLCS standard posed several difficulties, mainly in the decision on how to map different concepts in the machine to PLCS concepts [11]. However, it was concluded that PLCS had the most potential to model a manufacturing system due to its scope (out of the standards AP214 and AP239) [11]. In addition, Von Euler-Chelpin [11] argued that runtime data in an as-is model was to be automatically updated by the asset itself through sensors since the increased digitalization of products and resources would not only enable this, but also require it due to the vast amount of data that would be generated. Standards was seen as crucial in order to allow suppliers, users and producers to use a common terminology in this scenario since it would shift the requirements on keeping information about the as- is asset from the user to the manufacturer of the asset or resource [11]. Von Euler-Chelpin’s thesis revolved around several of the concepts that this thesis concerns. From information modelling to the discussion of assets/resources that is capable of handling their information on their own. Worth noting is that this is close to the description about the digital twin as previously presented. In addition, Von-Euler Chelpin’s statement that standards are necessary in order to enable the communication of information about the assets/resources is to some extent what this thesis seeks to do.

20 (86) Chapter 3 Literature review

3.4 NISTIR 8107/NIST Smart Manufacturing Ecosystem Model

The NIST (National Institute of Standards and Technology) Smart Manufacturing Ecosystem model, as shown in Figure 3-5, describes the manufacturing business from a lifecycle perspective with three key dimensions – product, production and business. Each dimension is presented within its own lifecycle and will be converged and integrated in the core of the Smart Manufacturing Ecosystem which is described as the Manufacturing Pyramid. As illustrated in Figure 3-5, each of the dimensions are heavily relying on the information exchange with each other. In order to utilize the maximum capabilities of Smart Manufacturing, i.e. productivity, agility, quality and sustainability, it is required to have established integration and tighter synchronization across the three dimensions – the digital thread [1]. Standards are required in order to support smart manufacturing capabilities and enable effective and repeatable information exchanges, which provides a standardized method for each actor within their respective area to conduct well- organized activities [1]. The NIST report [1] presents an examination of the current standards landscape of the respective dimension from the smart manufacturing aspect. This thesis is primarily focusing on the product- and production lifecycle dimensions.

Figure 3-5. NIST Smart Manufacturing Ecosystem Model [1, p. 4]

21 (86) Chapter 3 Literature review

Product Lifecycle The management of the production lifecycle is crucial in the aspect of smart manufacturing, since each individual product should contain the information of “how, when, and where they were manufactured” [1, p. 27], as well as the history data through their lifecycle. The product lifecycle dimension is mainly consisting of 6 phases, which are “Design, Process Planning, Production Engineering, Manufacturing, Use and Service, and End-of-Life and Recycling” [1, p. 8]. The information data within each phase are defined by one or multiple suites of standards that enable the information exchange between each phase within the product lifecycle c.f. Figure 3-6. [1] These set of standards can be classified into five categories [1]: 1. Modeling Practice Standards 2. Product Model & Data Exchange Standards 3. Manufacturing Model Data Standards 4. Product Catalog Data Standards 5. Product Lifecycle Data Management Standards Modeling practice standards are the standards for definition and documentation of the technical and geometrical requirements within 2D drawings and 3D models for the digital product. For instance, the Geometrical Dimension and Tolerancing (GD&T) and Surface Texture Symbols are two of the key information carriers that are supported by modeling practice standards [1]. Product model and data exchange standards are mainly focusing on the representations and engineering information of CAD models and how to simplify the data exchange between different CAD software from different vendors [1].

Figure 3-6. Product Lifecycle [1, p. 8]

22 (86) Chapter 3 Literature review

Manufacturing model data standards specify the data required in order to execute manufacturing processes from a design perspective. The aim is to define the connection between manufacturing processes and the design data from CAD models [1]. Product catalog data standards aim to describe the instances or properties of products or parts in a way that is consistent and regardless of the selected supplier [1]. Product lifecycle data management standards are essential and covers the entire six phases over the lifetime of a product. The main objective is to deliver proper information data created during these life phases in order to increase the maintenance capabilities and simplify the sharing of information in a collaborative environment [1].

Production System Lifecycle The production system includes all the manufacturing subsystems with a collection of machines, equipment and manpower required to design, produce, distribute and service the product. The production lifecycle dimension has a scope over “Design, Build, Commission, O&M [Operation & Maintenance], and Decommission” [1, p. 11]. In most cases, the lifecycle of the production system is longer than the product lifecycle, hence why the need for continuous reconfiguration and maintenance is a fundamental part of a smart manufacturing system [1]. There are many existing standards supporting the complex production system regarding modeling, system engineering information, automation and maintenance c.f. Figure 3-7. These suites of standards can be divided into 4 categories [1]: 1. Production System Model Data & Practice Standards 2. Production System Engineering Standards 3. Production System Maintenance Standards 4. Production Lifecycle Data Management Standards

Figure 3-7. Production System Lifecycle [1, p. 12]

23 (86) Chapter 3 Literature review

As illustrated in Figure 3-7, the O&M phase is the longest phase of a production system’s lifecycle, it is also the phase that has the most interaction with the other dimensions. Hence, the standards for O&M are of particular interest from the perspective in this report. Production system model data and practice standards can be divided into two categories which are “manufacturing resource and process, and building/facility modeling” [1, p. 13] with focus on providing information models for the equipment/asset within the factory [1]. An example on one of the standards is ISA 95, which will be mentioned in Chapter 3.5. Production system engineering standards cover tools within areas such as “system engineering, mechanical plant engineering, electrical design, process engineering […]” [1, p. 14] and how these tools can be connected and used together. Production system maintenance standards are used to evaluate and improve production system conditions and performances [1]. Production lifecycle data management standards provide a standardized and repeatable method to facilitate the sharing and integration of system data for production facilities throughout their lifecycles [1].

The lifecycle perspective in NISTIR 8107 In the product lifecycle, the PLCS standard, due to its capability of handling the information created during the use and maintenance of a product for life-long support, is stated as the “best-known” [1, p. 11] standard for product lifecycle management [1]. As mentioned before, a study conducted by Von Euler-Chelpin [11] showed that the PLCS standard has potential when it comes to representing the complete lifecycle of the manufacturing system. In addition, an EU funded project ResCoM, short for Resource Conservative Manufacturing, has also defined and implemented ResCoM data models based on the PLCS standard for the purpose of not just managing all the product-related information from a single lifecycle, but also to utilize and store this information properly in order to support closed-loop manufacturing [35]. There are other standards that complement PLCS, such as ISO 15926, a standard designed for lifecycle information management in the process plants. This is just one of the standards that have been widely used in the manufacturing industry together with PLCS. [1] This emphasize the need for this study on how PLCS can be utilized to integrate product lifecycle data with the production system lifecycle.

24 (86) Chapter 3 Literature review

3.5 IEC 62264/ISA-95

ISA-95, also known as ANSI/ISA-95 Enterprise-Control System Integration, is a standard developed by the International Society of Automation for the purpose of defining and integrating the activities and information within the manufacturing enterprise [36]. IEC 62264 is a standard developed by the International Electrotechnical Commission based on ISA-95. Within the ISA-95 standard, the manufacturing enterprise system can be divided into five levels from the functional perspective with specific time frames, c.f. Figure 3-8 [36]. The functional hierarchy is also described as the Manufacturing Pyramid in Figure 3-5, where it is the core of the NIST Smart Manufacturing Ecosystem where the product lifecycle, production lifecycle and business lifecycle are unified [1]. The functional hierarchy address the area of responsibilities within each level. In the standard, a role- based equipment hierarchy model to further describe the information exchange between objects within level 4 and level 3 was presented, c.f. Figure 3-9 [36]. An enterprise is considered to be part of the top- level of the equipment hierarchy (level 4). Level 4 activities, such as managing what, where and when the product will be manufactured, are normally taking place in the enterprise and site levels. A site is said to be “a physical, geographical, or logical grouping determined by the enterprise” [36, p. 24] and it consists of areas. Some of the typical level 4 activities involved within the site level are management and scheduling for production within the areas. An area is identified by its “production capability and geographical location” [36, p. 24]. Within an area there is a collection or combination of work centers such as process cells, production lines and production units. A work center is a grouping of work units and a work unit is the lowest level that performs the manufacturing functions in the equipment hierarchy. [36] An example of the role-based equipment hierarchy can be that Company A (Enterprise) have facilities at Location B (Site) which consists of a foundry, engine assembly and logistics department (Area). Within the engine assembly there are a couple of stations (Work Centers) and each station is made up of equipment such as robots and screw drivers (Work Units).

Figure 3-8. Functional Hierarchy [36, p. 18]

25 (86) Chapter 3 Literature review

Figure 3-9. Role-based equipment hierarchy [36, p. 23]

The IEC 62264 standard was divided into separate parts which was developed based on the ISA-95 standard [36]:

• Part 1: Models and terminology • Part 2: Objects and attributes for enterprise-control system integration • Part 3: Activity models of manufacturing operations management • Part 4: Object model attributes for manufacturing operations management integration • Part 5: Business to manufacturing transactions This thesis has mainly focused on part 1 [36] and to some extent part 3 [37] of the IEC 62264 standard. The terminologies in level 2, 1, and 0 of the functional hierarchy represents the Manufacturing Operations and Control (MO&C) domain, such as line supervision and operation functions and process control, are not mentioned in the IEC 62264 standard. One of the purposes of the IEC 62264 standard is to define definitions of the activities and objects within the manufacturing operations management (MOM) domain [1]. Compared to the content of the NIST report, ISA-95/IEC 62264 is an established standard within the manufacturing industry and provides clearly defined models and terminologies when it comes to describing the assets in the manufacturing enterprise.

26 (86) Chapter 3 Literature review

3.6 IEC PAS 63088/RAMI4.0

RAMI4.0 stands for Reference Architecture Model Industry 4.0 and is a three-dimensional model as shown in Figure 3-10. RAMI4.0 is laid out in IEC PAS 63088, a specification which defines the framework for smart manufacturing [38], and how different areas can be supported by existing and required standards. The main idea is to make sure that objects can cooperate in a connected environment, which necessitates accurate digital representations of the products, as well as efficient connections and communication in the interconnection of the products [38]. This requires Industry 4.0 compliant semantics to be used when modelling [38]. As defined in [38], the information or data about assets can be carried in several ways, one of which is using the XML (Extensible Markup Language) format. XML is a flexible and simple text format designed to store and transport data in a way that is human-legible and support a wide variety of applications [39]. Something which is pointed out in [38] is however that even though the information might exist on different information carriers, such as papers, digitally or by humans, the main idea is that the information about the asset is still the same. As noted, the model is three-dimensional, and contains three axes; 1) The layers 2) The hierarchy levels 3) The lifecycle and value stream

The layers The model is divided into 6 layers, which are the IT part of the model. The layers have been divided depending on the needs of the industry 4.0 components content and can be said to represent the different viewpoints of industry 4.0 [40]. The layers are:

• Business o The overhead rules or regulations. Guaranteeing integrity of functions of the system. [40] • Functional o Logic for decision making, describing functions of the system [40]. • Information o Rules for event based logic. Keeps information about the assets. Matches data and events in the system. [40] • Communication o Standardized communication, controls the integration layer [40]. • Integration o Connecting the physical and virtual world. Generates events. Contain physical items such as RFID readers or sensors. [40] • Asset o Representing the physical world. Contain the connecting elements to the virtual worlds such as tags. [40]

The hierarchy levels The hierarchy levels work as a functional division of the content of industry 4.0 elements [40]. It is based on the standards IEC 62264 (ISA-95) and IEC 61512 (ISA-88). Extensions have however been made, where “Product”, “Field Device” and “Connected World” have been added to the model to

27 (86) Chapter 3 Literature review represent the extended scope of industry 4.0 compared to the previously mentioned standards [40]. In short, it is an interconnection of the product and the system which produces it [40].

The lifecycle perspective in RAMI4.0 In the model, the lifecycle of each of the hierarchical levels (based on IEC 62264-1) is existing throughout all layers and is based on a standard in development, IEC 62890 [38]. The main idea is that the lifecycle is divided into two stages, types and instances. The type is before an item is instantiated and the information for the types is valid for all instances of that type, c.f. Figure 3-10. What is important to note is that the lifecycle covers all layers and all hierarchical levels, and must be considered at all times.

Classifications and presentations Each asset can be divided into different levels of presentation depending on the knowledge of the entity, and this is specified in IEC PAS 63088 [38]. The lowest level is when an asset is unknown, the low-mid level is when the asset is anonymously known (meaning it can only be recognized as a certain type at a certain place), top-mid level is when the asset is individually known (meaning that the asset is known by name and can be recognized in the physical world), and the top level is “assets administered as entities” [38, p. 15]. When an asset is administered as an entity it necessitates that information is kept in some way, either by the entity itself or by an overhead IT-system with capabilities of making the information communication I4.0 compliant [38].

Figure 3-10. RAMI4.0 [38]

28 (86) Chapter 3 Literature review

In IEC PAS 63088 [38], assets are further described to have different levels of communication capabilities; on the lowest level it has no capability, on the mid-level it has either passive or active capabilities (passive meaning information can be read passively from the asset like RFID, active meaning the asset communicates directly with the network), on the top level it is called I4.0 compliant. The I4.0 component is an asset fulfilling all requirements from system users in the industry 4.0 environment, has at least passive communication capabilities, and is thus I4.0 compliant [38]. The description of the communication capabilities is true for both physical assets as well as assets in the information domain [38]. In connection to the previous description of the importance of the lifecycle perspective in RAMI4.0, the I4.0 components are said to require each user to be able to make a query about the entity’s state in the lifecycle [38], further demonstrating the necessity of the perspective. The assets can also be classified, similar to the IP protection classifications (International Protection Marking), according to a CP (Communication/Presentation) classification [38], c.f. Figure 3-11. In accordance to the aforementioned communication and presentation of the assets, depending on each respective level on these two factors for the asset, it gets a classification.

Administration shells The administration shell (AS) can be described as a digital shell surrounding the physical asset in which necessary information is kept about the asset from all possible views in which you want to view the asset from [41], c.f. Figure 3-12 and Figure 3-13. Similar to an asset, the AS also have a unique ID which singles the specific AS out [41]. Without an AS, an asset is not I4.0 compliant [38]. According to [41], it is a requirement of the AS that it:

“[…] should be designed such that an internal or external system or organisation can implement an appropriate mapping between different property sets and domains.” [41, p. 21] The AS consists of a header (with information identifying the AS and asset) and a body (in which different information about the asset is kept) in addition to (among other things) an API (Application Programming Interface) [41], c.f. Figure 3-13. The latter should make sure that the information that is kept in the AS can be accessed from the outside, with responsibilities for updating information in the AS as well as for queries for information kept within it [41]. In addition to this, the AS is also capable of handling runtime data directly forwarded from the asset, c.f. Figure 3-13. The AS can be maintained and stored both on the asset and in an overhead IT system depending on the need [38]. In addition, [41] identified some general requirements on the administration shell that is necessary in order for it to be an administration shell. These are shown in Figure 3-14 and Figure 3-15.

Figure 3-11. Classification of communication capabilities for assets [38].

29 (86) Chapter 3 Literature review

Figure 3-12. Views and administration shells [41]

Figure 3-13. General function of an administration shell [41]

30 (86) Chapter 3 Literature review

Figure 3-14. Requirements for Administration shells (1) [41, p. 24]

Figure 3-15. Requirements for Administration shells (2) [41, p. 28]

31 (86) Chapter 3 Literature review

3.7 UML and SysML

Unified Modeling Language, or UML for short, is a generic graphical modeling language which was developed in order to make sure complex systems could be represented in a simple and standardized way [42]. UML consists of sets of diagrams and notations which are used in order to simplify the understanding of objects and models for software and system engineers [42]. Systems Modeling Language, or SysML for short, is an extension of UML and was developed with the system perspective in mind. The main difference between UML and SysML is that SysML was developed to address the System Engineers needs that UML could not meet, by reusing or making changes to some diagrams from UML and extending them with several new diagrams. [38] The relations between UML and SysML are displayed in Figure 3-16. Standardized modeling is an essential part when it comes to presenting and visualizing system information in a consistent way. Through modeling, the complexity of the system can be managed and presented in easily understandable views. The goal of UML and SysML is defined as, according to INCOSE (International Council on System Engineering) and OMG (Object Management Group),

“A standard modelling language for systems engineering to analyze, specify, design, and verify complex systems, is intended to enhance systems quality, improve the ability to exchange systems engineering information amongst tools, and help bridge the semantic gap between systems, software, and other engineering disciplines” [43, p. 2].

Figure 3-16. UML and SysML

32 (86) Chapter 3 Literature review

3.8 Eurostep AB and ShareAspace

ShareAspace Nova is a software developed by Eurostep AB. The core of the software is the PLCS standard, to which the software is mapped [44]. Mapping is when two or more different sets of objects can be described using either of the two sets. For example, a car and a moped (of set A) can both be described as personal vehicles (of set B), and vice versa where the abstraction level of set B is greater than that of set A. The software is mapped on different levels of abstraction between different underlying models. The top level is the business object model, where each specific company presents the data needed to be managed for their business by using their specific semantics. This model is then mapped to the ShareAspace information model. The ShareAspace-model is based on the PLCS information model, c.f. Figure 3-3, however, since the ShareAspace data model is modified compared to the PLCS model, the ShareAspace data model is in turn mapped to the PLCS information model, c.f. Figure 3-17. [30] This way of mapping different models to each other simplifies the semantics, and each layer provide expanded business or scenario unique support.

SoftTypes and BaseTypes A SoftType and the corresponding data about the SoftType is the reference data that is stored in the system as described in the Reference data section for PLCS. When mapping between different models, it is necessary to understand the meaning of each mapped concept. In this work, mapping will mainly be done between the developed business object model and the ShareAspace-model. A BaseType is the base framework required in order to configure the SoftTypes in the system. It is basically what one map the SoftType to. However, it is also important to understand the underlying mapping between the BaseTypes in the ShareAspace-model and the concepts in PLCS. The ShareAspace information model extends the PLCS information model with additional objects and connections, but is still in its nature a model based on PLCS. In Table 1 the mapping between BaseTypes used in the business model to PLCS is shown.

Figure 3-17. Mapping between models

33 (86) Chapter 3 Literature review

Table 1. Description of BaseTypes and connection to PLCS

BaseType Map to PLCS object Definition from source Source ActionExecution ActivityActual [45] “An ActivityActual is a specialization PLCSlib [46] of Activity. It is a record of the occurrence of an Activity.” ActionOrder DirectedActivity [45] “A DirectedActivity is a specialization PLCSlib [46] of Activity. It identifies an activity that is governed by a WorkOrder.” “A WorkOrder is the authorization for one or more Activity instances to be performed.” ActionRequest WorkRequest [45] “A WorkRequest is the solicitation for PLCSlib [46] some work to be done.” Location Location [45] “A Location is a place or position PLCSlib [46] where an activity or event can occur or a product or resource can exist.” Organization Organization [45] “An Organization is an administrative PLCSlib [46] structure in which persons are active.” Part Part [45] “A Part is a specialization of product PLCSlib [46] that collects the definitional information of the versions of either a part or of a non-countable material.” Person Person [45] “A Person is an individual human PLCSlib [46] being.” Plan Scheme [45] “A Scheme is a specialization of PLCSlib [46] ActivityMethod. It provides the Schedule identification and description of an intended course of action to accomplish an objective. A Scheme enables the ordering of entries. Dates and times may be specified for entries and time intervals between entries.” Position Position [45] “A Position is a function or job PLCSlib [46] performed by a person. It defines responsibilities and activities. A position that is not fulfilled by a person is a vacancy.” ProductAsRealized ProductAsRealized “A ProductAsRealized is a PLCSlib [46] [45] specialization of ProductAsIndividualVersion that identifies a revision of an individual artefact that has been made. A product whose properties can only be known by observation or by derivation from observations.” ResourceItem ResourceItem [45] “A ResourceItem is an item that can PLCSlib [46] occur in the role of a resource within the application context.”

TaskMethod TaskMethod [45] “A TaskMethod is a specialization of PLCSlib [46] ActivityMethod.” “An ActivityMethod is a specific way to carry out an activity.”

34 (86) Chapter 3 Literature review

The different information and data models There are several information and data models which can be used when modelling. In this work, concept- and business object models are referenced in addition to the system- and standard specific information models of ShareAspace and PLCS. A concept model is a model showing a system on a conceptual level, specifically illustrating interrelations between concepts, thus providing a deeper understanding on the actual meaning of the concepts [47]. All concepts have names, and the relationships are also named to illustrate in what way the concepts relate to each other. The concept models provide a basis for discussion on how concepts are used in an implementation and are beneficial since the models are influencing the end-result derived from solutions based on the concept model [47]. A business object model contains business objects which forms a sort of vocabulary which a certain business or enterprise use in their day to day business [48]. The difference between the concept model and the business object model is mainly that a concept model might contain a broader vocabulary and more details than the business object model. In addition, the business object model and the concept model might need to be mapped to each other, since there might exists concepts in a concept model which might be called something else in a business object model and vice versa. Also, the business object model has cardinality which is something the concept model lacks.

3.9 Other existing models and technologies for smart manufacturing

This thesis is focused primarily on the use of the ISA-95/IEC 62264, NISTIR 8107/the NIST model and IEC PAS 63088/RAMI4.0 in the context of PLCS. However, there are other interesting existing alternatives to these models when describing smart manufacturing and other concepts concerning smart manufacturing. These models have not been considered when developing the concept model for the sake of simplicity and understandability, but are used as a basis for discussion when evaluating the result. In addition, other technologies that are affecting the analysis to some extent but has not mainly been used to develop the solution, such as Service oriented architecture and Cyber-physical systems, needs to be understood briefly. Service oriented architectures and cyber-physical systems is based on objects or services which is making up the complete system, creating interfaces. It can be said to lay a foundation for how an infrastructure for smart manufacturing is constructed. Thus, it is of great importance to have background knowledge in these areas.

Service oriented architecture (SOA) A service oriented architecture is a distributed system of services which enables the connection and use of several different services in order to provide extended functionality [49]. Each service has a specific function and is independent from other services in the way it functions – however, it has to be able to access other services [49]. The World wide web consortium (W3C) defines SOA as:

“A set of components which can be invoked, and whose interface descriptions can be published and discovered.” [50] The software ShareAspace is using REST [51].

35 (86) Chapter 3 Literature review

Cyber-physical systems (CPS) In [1], Cyber-physical systems (CPSs) are mentioned as a necessity in order to fully be able to utilize smart manufacturing. However, due to the lack of standards in the area, the current NIST model is still based on a hierarchical structure (ISA-95) [1]. In [1], it is also mentioned that information models for smart devices present on the shop floor of manufacturing facilities are necessary in order to fully utilize the potential of smart manufacturing. This is in some sense what this thesis aims to provide on a basic and overhead level. Furthermore, [1] states that products being able to “know” their own how, when and why is an end-goal of smart manufacturing. The CPS can best be described as a web of connected assets which all can communicate efficiently in a non-hierarchical way but instead based on the use of information. The NIST-model reconfigured implementing this kind of architecture would look like Figure 3-18.

IoT reference architecture The ISO/IEC Joint Technical Commission 1/Working group 10 are working on the development of a reference architecture for the Internet of Things (IoT) [52]. The current overall model is shown in Figure 3-19. As can be shown, it is a very specific conceptual model integrating concepts used in the IoT domain.

Figure 3-18. The NIST model with CPS [1].

36 (86) Chapter 3 Literature review

Figure 3-19. IoT Conceptual Model [52]

Chinese model The Chinese Smart Manufacturing Model is developed by The Ministry of Industry and Information Technology of China (MIIT) and Standardization Administration of China (SAC) [53]. The Chinese smart manufacturing architecture, as illustrated in Figure 3-20, describes the related activities, equipment and features involved in smart manufacturing from the perspectives of the following dimensions: 1. Lifecycle 2. System Level 3. Smart Function The main objective is to define the requirements of standards and specify the goals and scopes of smart manufacturing [53]. The model is somewhat similar to the RAMI4.0 model, which also defines smart manufacturing in a three-dimensional approach. The lifecycle axis covers the activities and information throughout the entire lifecycle of the product from product development to end-of-life recycling and remanufacturing, including design, manufacture, logistics, sales and service [53]. The lifecycle axis of the Chinese model shares some similarity compared to the product lifecycle dimension from the NIST model. The system level axis in the Chinese model and the hierarchy levels (ISA-95) of RAMI4.0 are also considered to be comparable. The system levels of the Chinese model refer to the hierarchical structure of the organizational structure related to the manufacturing enterprise activities, including equipment, control, workshop, enterprise and collaboration [53].

37 (86) Chapter 3 Literature review

The smart function axis is the axis that differs from other aforementioned smart manufacturing models. It refers to the hierarchical division based on information and communication technologies that enables one or multiple manufacturing operation to be self-aware, self-learning and self-decision making and self-executing [53].

Figure 3-20. Smart manufacturing standardization reference model of China [54, p. 19]

Japanese model The Japanese model for smart manufacturing is laid out by the Industrial Value Chain Initiative [55]. The model is based around what is referred to as Smart Manufacturing Units (SMUs), c.f. Figure 3-21. These SMUs then have different views from which one can view the SMU. The SMU is also subject to different General Function Blocks (GFBs) as shown in Figure 3-22, where one or more of the functions can be valid for the SMU. Smart manufacturing is described as a “system of systems” [55, p. 6], where different SMUs are interconnected. The model also mentions CPS or CPPS (Cyber Physical Production Systems) as the system where the real, tangible physical world is connected to the more intangible digital world of IT [55]. This is similar to what the NIST model mentions. The Japanese model talks about a concept of “Loosely Defined Standards” [55, p. 12], which basically means that the standards lay out a reference for terms used, making communication easier without hindering each individual actors’ way of expressing themselves [55]. It is said that these more Loosely Defined Standards would make it easier for companies to adopt to the new emerging technologies such as smart manufacturing, since the otherwise strict standards would make it close to impossible to integrate without changes in the business [55]. The terms used would therefore be mapped from a very business specific perspective down to a common model, describing the specifications in a very unified way [55], c.f. Figure 3-23. From this thesis point of view, it is interesting to compare this way of using Loosely Defined Standards to the method of the thesis and implementation of PLCS. This is more or less what is strived for in this work.

38 (86) Chapter 3 Literature review

Figure 3-21. Japanese model for smart manufacturing [55]

Figure 3-22. Japanese model for smart manufacturing – function blocks [55]

39 (86) Chapter 3 Literature review

Figure 3-23. Japanese model going from specific to general [55]

40 (86)

Chapter 4

Results and Analysis

This chapter aims to present the result of the developed models, the mapping and the implementation in an easily understandable way as well as an analysis of the results.

4.1 Introduction

The result of the thesis will be presented in relation to the asked research questions: Question 1: Can the concepts used in relevant smart manufacturing standards together with concepts from PLCS represent lifecycle support in the context of smart manufacturing? Question 2: Can these concepts be implemented on a PLCS-based software? Question 3: Does the proposed solution meet the requirements of smart manufacturing as expressed by the standardization community? Apart from the study of the standards for smart manufacturing, the work resulted in the following: 1. Two information models (concept models) of the concepts for smart manufacturing based on the manufacturing standards and standardization publications. 2. An information model (business object model) showing a case specific terminology and classes to be implemented with cardinality and specified relations. 3. An information model (instance diagram) showing instanced objects and how these relate to each other in the implementation.

41 (86) Chapter 4 Results and Analysis

4. A specified mapping of the classes in the business object model to the ShareAspace information model, which is an extension to the generic PLCS information model (however the core is still the PLCS information model). 5. The implemented solution in ShareAspace 6. An analysis of the developed information models and the system functionality of the implementation with respect to the identified requirements of the standards and publications. What is necessary to stress is the fact that the business object model is what is used in order to verify the usability of the overall developed information models. The business object model was implemented in the DigIn use case in order to verify its applicability as a model for smart manufacturing. Based on the investigation of the business reports and standards, in addition to the traditional concepts, some general ideas affecting the results are the inclusion of the lifecycle perspective and the non- hierarchical structures. The former necessitates the ability to be able to track different “layers” of information for each asset and being able to represent and interrelate information from different lifecycle phases, which in the selected use case were as-planned, as-ordered, as-realized. This affects the developed concept models in the sense that it requires terminology that can describe these sorts of layers. In the cases were that terminology is existing in the standards or reports, that terminology is used. In the cases were the terminology is lacking, the approach is explained in the following sections. The second idea which can be observed (the non-hierarchical structures) requires a standardized terminology, but it also requires system functionality which is not directly dependent on the model representation. However, it affects the concept models in the sense that it requires the bypassing of certain hierarchical boundaries. This is visible in the concept models. The system functionality is investigated but not developed in the thesis. Some functionality is added to the system as part of a subproject to the DigIn use case based on the developed models and implementation.

4.2 Concept models

To answer the first research question, two concept models were created to symbolize the underlying meaning and interrelations of identified concepts from the standards and publications on smart manufacturing. This was done in order to select a terminology to use in implementation of the use case. A standardized terminology is argued to simplify the communication between systems and individuals, and is thus key for the purpose of utilizing future manufacturing trends. Hence, the concept models are key to enable the future technologies that smart manufacturing covers. The developed concept models are shown in Figure 4-1 and Figure 4-2. These two models are argued to be able to describe the concepts included in the two smart manufacturing reference architectures/models on the levels (level 3 and 4) which this thesis is delimited to. A legend over the used objects in the diagrams is shown in Table 2.

42 (86) Chapter 4 Results and Analysis

Table 2. Legend for symbols in SysML-modelling

Symbol Meaning Description Class A class object – to be instantiated.

Abstract class An abstract class object – not to be instantiated (exceptions exists).

Enumeration A class object which poses a fixed selection for another object as one of that object’s attributes.

Directed aggregation One object has a directed connection to another object, meaning the object with the diamond consist of objects of which the arrow is pointing to, but not the other way around.

Directed composition One object has a directed connection to another object, similar to the directed aggregation. However, the object which the arrow is pointing to is co- existing with the object with the filled diamond, meaning if the object with the filled diamond is removed, the object at the end of the arrow is also removed. The opposite is however not true. Generalization One object is a generalization of another object. The object at the start of the arrow is a special class of the object at the end of the arrow.

X..Y Number of possible X is the lowest amount of connections (can be 0 or connections 1), and Y is the highest amount of connections (can be 1 or infinite, symbolized with *) N/A Concept from ISO 10303-239 PLCS

N/A Concept from IEC 62264

N/A Concept from IEC PAS 63088

N/A Concept from IEC 61512

Smart product The following reasoning has been done regarding modeling the concepts and their interrelations (the definition) for Smart product. When referring to the concept definition, the definition used is stated in Figure 4-1. For the full definition, the reader is advised to see each respective standard. Some of the concepts are however of key interest, those are described in Table 3. Product has been considered to consist of Product data and in extension Characteristics. The latter two concepts are never mentioned in the smart manufacturing standards, and one might argue that they can be part of the Product definition. They are however mentioned in PLCS and is reasoned to be of key importance, especially since RAMI4.0 is talking about Administration shells and their inclusion of data about each asset.

43 (86) Chapter 4 Results and Analysis

Table 3. Key concepts for smart products

Concept Definition from source Source Administration Shell “Virtual digital and active representation of an I4.0 IEC PAS 63088 [38] component in the I4.0 system.” Asset “Object which has a value for an organization” IEC PAS 63088 [38] Entity “Uniquely identifiable object which is IEC PAS 63088 [38] administered in the information world due to its importance” Instance “An instance is a specific, unambiguously IEC PAS 63088 [38] identifiable asset that is characterized by the properties of a type. An instance always has an unambiguously relationship to its type”1 Product “Desired output or by-product of the processes of IEC 62264 [36] an enterprise” Resource “Enterprise entity that provides some or all of the IEC 62264 [36] capabilities required by the execution of an enterprise activity and/or business process” Type “The type of an asset defines the sum of the IEC PAS 63088 [38] properties which are characteristic for all instances of that particular asset. The type of an asset is unambiguously identifiable and arises with the initial idea, in other words when it is created, e.g. during the development phase. This means, for example, ordering, development and testing, right up to the initial sample and prototype production. Once all tests required for validation are completed, the type is released for series production, which means that instances of that type can be produced.”

A Product also has Versions which have a Configuration. Each Configuration is specified by a Product Definition, which includes information about all the necessary requirements in order to create the Product. Bill of material and Bill of resources are both parts of the Product Definition and specifies the Resources that is needed to create the Product. The Product Definition also includes references to Production Rules – rules which are specifying how to manufacture that Product. Furthermore, a Product is considered to be an Asset, since it provides a value to the organization. The Asset, from the product’s point of view, is then according to the definition in RAMI4.0 Individually known in the system and is treated as an Entity. The Entity is what has the Administration shell and in extension an API and gets Feedback from the system. The latter term being an addition from PLCS, since it is believed to be necessary in order to make the connection between Events happening in the real world and the API.

1 Note: Eurostep AB does not agree on this definition. The company says that the relation between the instance and the type is ambiguous in some cases, especially when an instance has changed so much that it can not be considered to be of a specific type.

44 (86) Chapter 4 Results and Analysis

An Asset has a State which in turn is connected to Status and Events. An Event can both trigger a change in State and a change in Status, but will always send Feedback to the API and Administration shell. It is however not believed to be necessary that either State or Status changes because of this. For example, say the Event might be wear of a bearing to 50 % of a threshold value, triggering a Feedback message of “Wear 50 %” to the Administration shell, which updates the Physical attributes of the Product. The State might however still be “In operation” and the Status might still be “Running”. An Asset is also an Instance of a Type. The distinction here is that an Instance is a specific occurrence of something, whereas a Type is more of a framework describing all different Instances of that Type. The Product is also said to be able to be represented as a Physical asset which is a specialization of an Asset. If it is a Physical Asset, it has Physical attributes which are specific to that Physical Asset.

45 (86) Chapter 4 Results and Analysis

Figure 4-1. Concept model for Smart Product

46 (86) Chapter 4 Results and Analysis

Smart factory The following reasoning has been done regarding the concepts and their interrelation. When referring to the definition, what definition has been used is stated in Figure 4-2. For the full definition, the reader is advised to see each respective standard. Some of the concepts are however of key interest, those are described in Table 3 and Table 4.

Table 4. Key concepts for smart factories

Concept Definition from source Source Activity “Group of tasks that are classified as having a IEC 62264 [36] common objective” Activity Actual “An Activity Actual is a specialization of Activity. It PLCSlib [46] is a record of the occurrence of an Activity.” Administration Shell “Virtual digital and active representation of an I4.0 IEC PAS 63088 [38] component in the I4.0 system.” Asset “Object which has a value for an organization” IEC PAS 63088 [38] Entity “Uniquely identifiable object which is administered IEC PAS 63088 [38] in the information world due to its importance” Instance “An instance is a specific, unambiguously IEC PAS 63088 [38] identifiable asset that is characterized by the properties of a type. An instance always has an unambiguously relationship to its type” Person Organization “A Person is an individual human being.” PLCSlib [46] “An Organization is an administrative structure in which persons are active.” Product “Desired output or by-product of the processes of an IEC 62264 [36] enterprise” Realized product “Is a specialization of ProductAsIndividualVersion PLCSlib [46] that identifies a revision of an individual artefact that has been made. A product whose properties can only be known by observation or by derivation from observations” Resource “Enterprise entity that provides some or all of the IEC 62264 [36] capabilities required by the execution of an enterprise activity and/or business process” Type “The type of an asset defines the sum of the IEC PAS 63088 [38] properties which are characteristic for all instances of that particular asset. The type of an asset is unambiguously identifiable and arises with the initial idea, in other words when it is created, e.g. during the development phase. This means, for example, ordering, development and testing, right up to the initial sample and prototype production. Once all tests required for validation are completed, the type is released for series production, which means that instances of that type can be produced.” Work Center “Equipment element under an area in a role-based IEC 62264 [36] equipment hierarchy that performs production, storage, material movement, or any other Level 3 or Level 4 scheduled activity” Work Schedule “Detailed schedule that defines production, IEC 62264 [37] maintenance, inventory or quality operations activities, or any combination of the activities”

47 (86) Chapter 4 Results and Analysis

An Enterprise is defined according to ISA-95 as some organizational structure which has a common goal and objective. The Enterprise is considered to be a specialization of the PLCS concept Person Organization, which has been added in order to provide human resources (Persons and Organizations) to the model. An Enterprise has Sites which consists of Areas which both are geographical locations with some logical grouping of lower level Assets. Both Sites and Areas can be defined as a Manufacturing Facility but can also be generic. An Area consists of Work Centers which are either Process Cells, Production Units, Production Lines or Storage Zones. Each Storage Zone consists of Storage Units, each Production Line consists of Work Cells and Process Cells and Production Units consist of Units. Units, Storage Units and Work Cells are also characterized as Work Units. As previously noted, the Person Organization concept was added from PLCS in order to add human resources to the model. Each Person is assigned to some Position. As illustrated in Figure 4-2, the structure from Enterprise to Work Unit might seem hierarchical. This is based on the ISA-95 equipment hierarchy. In order to model a smart factory from a smart manufacturing perspective, it is recommended to avoid a hierarchical control model [1]. In order to take this into consideration, Sites, Areas, Work Centers and Work Units are defined as Resources with the support of the definition in RAMI4.0 – they all provide capabilities to execute some activity in the organization. Since a Resource can consist of other Resources the traditional hierarchical structure is bypassed. A Site could for example in this model be consisting of Storage Units directly. In addition to the aforementioned Resources, Consumables and Person Organizations (and in extension Enterprises) are also considered to be Resources, further eliminating the traditional hierarchical structure. This way of modeling makes it possible to consider everything on one hierarchical level, while simultaneously keeping the traditional terminology and hierarchical structure of the concepts. When a customer wants to order a product, an Order is placed for a Product (as defined in the Smart product model). A Product is either planned or realized. A planned Product references a Work Schedule which defines the order of planned Activities describing generic TaskMethods that must be executed to realize a Product. Each TaskMethod defines what generic Type of Resources to be used in order to execute it and also contains Production Rules which specifies what must be done to execute the TaskMethod. The Activity on the other hand specifies what Instances of Resources (individuals) that must be used to execute the Activity. When an Order is being processed and planned for, a Realized Product is instantiated, which specifies what (planned) Product is supposed to be realized. When the Product is being realized, and Activities are executed, Activity Actuals are created. An Activity Actual is an executed Activity which specifies what Instance of a Type of Resource (individuals) was used. The reason why a distinction between planned and realized Products and Activities have been made is to keep track of the whole lifecycle of the Products and Activities (production systems). If these two steps were to be combined for the sake of brevity and/or simplicity, there would be a gap between the knowledge of how the Activity and/or Product was supposed to be done/finalized, and the actual outcome of the Activity or the actual Product itself. By splitting the stages into two, it is possible to get traceability from the design of the Product (planned Product), to the planned Activity realizing the Product, to the Realized Product taking form, and how that product was realized in Actual Activities. Resources, TaskMethods, Activities, Activity Actuals, Products, Realized Products, Work Schedule and Orders are all considered to be Assets since they are of value for the organization. An Asset can be either Anonymously known or Individually known. If an Asset is Individually known, it has a unique identifier that is known in the information world and thus some sort of identification of the object in the physical world is possible. An Asset is Anonymously known if the Asset can only be recognized indirectly in

48 (86) Chapter 4 Results and Analysis association to a particular event at a particular place. For instance, a screw that has not been installed on a Product is not identifiable (other than as part of a batch), but once it is installed on a Product, it can be indirectly identified by means of the Product and its location. A screw is an example of Consumables and it is classified as an Anonymously Known Asset. As for the Smart Product concept, the Asset in this model also has States, Events, Status, Feedback, Administration Shell, API and Feedback. For the reasoning behind those connections, see the previous chapter.

49 (86) Chapter 4 Results and Analysis

Figure 4-2. Concept model for Smart Factory

50 (86) Chapter 4 Results and Analysis

4.3 Business object model – for implementation and verification

The business object model is an adaptation of the concept model for a specific use case, in this case to verify the model in the DigIn scenario. This requires the use of case specific terminology and connections (in the DigIn verification, this is a standardized terminology), which might remove some or all of the connections between connected concepts from the concept model and might result in the distinction of concepts into more detailed sub-concepts. If connections have been added or removed from the concept model, these changes will be discussed. For the sake of brevity, the reader is referred to the previous chapter for the reasoning behind the individual connections which has not been changed. In this text, what was referred to as concepts in the concept diagram, will now be referred to as classes. Each created class is colored depending on when it is created in the order scenario. The color coding is displayed in Table 5. The business object model lay the foundation for the instantiation diagram, and in extension for the implementation. All non-abstract classes (with names not in italic) and some abstract classes shown in the diagram in Figure 4-3 will be created as a SoftType in ShareAspace. Due to the scope of the thesis having the main focus on the production system lifecycle, the Smart product model is left on the concept model stage, and is not developed as a business object model. In addition, the use case does not provide any way to verify a smart product implementation, hence the omission of the smart product models. The concept model for smart product is however used for reasoning regarding the smart product and its information from a lifecycle perspective. Similar to the concept model, the hierarchical structure of the ISA-95 standard is present in the model, as shown in Figure 4-3. The concept model bypassed this by connecting everything to a concept called Resource. Resources is however an abstract concept, and will not be instantiated. Instead, each of the classes need to have the necessary connections on their own. In this use case, the connections have been limited to those necessary to showcase the DigIn scenario, and the impact this has on the validation will be discussed. A Site and an Area have been given a connection to an enumeration (a fixed selection) where the classes can be selected to be either Generic or a Manufacturing Facility. An Area then consist of the abstract class Work Center consisting of Work Units. The selection of the abstract concepts is made due to the fact that this would include all the different specialized concepts (sub-concepts), without the need to distinguish between them. If necessary, it would be possible to define different SoftTypes for each sub- class (for example a Production Unit), however, this is seen as unnecessary in the use case. The Work Unit is connected to an enumeration, stating what kind of resource it is. In this case, the available selections have been created based on the DigIn use case, and is specified as; (1) Rubber Hammer; (2) Torque Tool; (3) Crowbar; (4) Allen Key.

Table 5. Colors of classes

Symbol Description Created before an order

Created on order

Created when an order is executed

The created product

51 (86) Chapter 4 Results and Analysis

As in the concept model, the connection between the Order and (planned) Product and Realized Product exists. A distinction was made between Products and Generic/Special Components since it is desirable to know the difference between the full Product and the sub-components from a design perspective. The same reasoning was done for the Realized Product. For the planned Products and Generic/Special Components, the classes point to enumerations for the Type of Product, Type of Component and Shape. The Special Component was created with the sole purpose of showcasing how a specialized component could be represented in the implementation. In this case, the Handbrake was selected and could have in theory an unlimited number of possible configurations. Each enumeration was populated by enumeration iterals according to the use case. Similar to the enumeration for the Product and Generic/Special Components, a Consumable also have an enumeration classifying it as either of the two available consumables from the use case. A (planned) Product contains a Generic Work Schedule describing TaskMethods and their sequence. The TaskMethods then contain Production Rules as a property describing how to execute the TaskMethods. As stated in the concept model, the TaskMethod only specifies a Type of a Resource to be used in the TaskMethod, and in the business object model, that corresponds to the TaskMethod pointing to an enumeration of either a Type of Resource or Type of Consumable. The TaskMethod also specifies what Generic/Special Components to use if for example assembly is to be done. For the specific individual Realized Product, Activities are used to realize that specific individual. A Realized Product has a specific Work Schedule, which points to the Generic Work Schedule. The specific Work Schedule contain information about what Activities are used to realize a Product. The Activity also points to Instances (individuals) of certain Consumables (batches), what Resources and planned Components as Realized to be used when assembling/fitting. As for the Activity Actual the reasoning is identical to that of the planned Activity, with the exception that the referenced Resources all were used when executing the Activity. It is of great importance to distinguish between planned and performed Activities, and planned and realized Products, hence the use of multiple classes for the same objects. As seen in the model, several concepts have not been modelled as classes in the business object model, c.f. Figure 4-2 and Figure 4-3. A Resource is seen as an abstract superclass, which was modelled as such due to the desire to remove the hierarchical structure from ISA-95. However, as mentioned previously, it is not included in the business object model, since there is no such thing as a Resource but instead it is the sub-classes of this superclass that is being included in the model. The same way of thinking applies to Asset which also is an abstract superclass for almost all the concepts as shown in the concept model, c.f. Figure 4-2. The terms Individually known, Anonymously known, Instance, and Type are also more abstract descriptions of an Asset. The concepts have been included in the concept model to show how these concepts interrelate, but are excluded from the business object model since they are not objects that needs to be instantiated. The same applies to Entity, Administration Shells, API, Feedback, Event, Status and State which are also concepts included in the standards for smart manufacturing, but from an instantiation point of view is redundant to explain how to implement the model. These concepts are however very interesting to investigate when evaluating the implemented model and its functionality.

52 (86) Chapter 4 Results and Analysis

Figure 4-3. Business object model for implementation

53 (86) Chapter 4 Results and Analysis

4.4 Instance diagram – for implementation and verification

The instance diagram was developed in order to showcase how the implementation is functioning, see Figure 4-4. The color coding follows the same rules as shown in Table 5. The example is very simple, and has intentionally been more simplified than the implemented solution in order to achieve greater levels of understandability. As noted before, the implementation has some more distinctions between components and products, where components can be both generic/special and as realized. Work schedules also have more distinctions, since they can be both generic (valid for a planned set of configurations) and individual (valid for that particular individual). The instance diagram was developed in order to show that the proposed solution (concept model and business object model) was able to be used to create instances of objects that could maintain a traceability and information complexity which is necessary for smart manufacturing. For example, it is shown in the model how a Realized Product easily can access information about the Activity Actual which realized it. In that Activity Actual, it is possible to find information about Activity data as well as what resources was used and what personnel worked on the product. In addition, through the Activity Actuals connection to the planned Activity it is possible to find deviations between the planned and actual Activity data (for example torque value) – making it possible to make decisions regarding where possible errors occur. If the planned torque value must be changed due to errors occurring during some state in the product lifecycle, the production lifecycle is also affected and vice versa. In other words, it is possible to interrelate the product lifecycle with the production system lifecycle through these connections.

54 (86) Chapter 4 Results and Analysis

Figure 4-4. Instance diagram example to explain implementation

55 (86) Chapter 4 Results and Analysis

4.5 Mapping the Business object model to the ShareAspace information model

To address the second question, regarding if the identified and selected concepts could be implemented on a PLCS based software, an implementation based on the information models was done with the aim to verify the applicability of the solution. In order to implement the solution in the software, it was found to be necessary to accurately map the desired SoftTypes to accurate BaseTypes being able to contain all information necessary as well as being able to establish the desired connections. This was of crucial importance in order to establish the necessary functions for the system as well as for making an accurate representation of the smart manufacturing concept. The following reasoning was done in regard to the mapping. An Activity was said to be an ActionOrder, since an ActionOrder in ShareAspace is an Activity_planned in PLCS. The Activity in this implementation was supposed to be a planned activity, thus it was found fitting, and it can connect to the necessary objects. An Activity Actual was instead an ActionExecution, since that is an ActivityActual in PLCS. It also provided the necessary connections to other objects. An Area, Site and Work Center are Locations (both in ShareAspace and in PLCS), since they all are some geographical grouping of assets on lower levels of the hierarchical structure. The focus was on the geographical grouping and Location provides both the geographical demarcation in addition to the possibility to connect to other assets. All these SoftTypes would have been possible to map to the BaseType Organization since they could be argued to be of an organizational structure, but since the focus was on the geographical demarcation in this case, it was found more fitting to map to Location. The Customer Order was mapped to an Action Request. It could also have been mapped to an Order but since the Action Request was more fitting in the sense that it requested actions to be taken in regard to a specific product, it was selected instead. The Product, Generic Component and Special Component was mapped to Part since they all are on the Type level and are something which needs to hold information about the types. A Person and Position was mapped to their respective in ShareAspace, since they are PLCS concepts and are called the same in the ShareAspace information model. A Realized product, and Component as Realized were both mapped to ProductAsRealized since they both need to hold information about some products or components which are realized by the production system. A Working Group was mapped to Organization since they contain persons and to some extent are an administrative structure. In this work, Working Group contained Persons, and are only there to show what groups the persons are active in. A Work Schedule was mapped to Schedule. A Schedule is mapped to the PLCS concept Scheme, which contain entries and allows for specifying order and time intervals for the specific entries in the Scheme. Since the Work Schedule was meant to show the order for which the activities were to be executed in and to specify times for when to execute them, it was found fitting to map to Schedule. A Work Unit was mapped to Resource Item, since it is a resource, and are used in specific Activities to execute some action. A table showing the mapping between the business object model and the ShareAspace information model is shown in Table 6. For a detailed mapping specification, containing all the attributes, see Appendix A.

56 (86) Chapter 4 Results and Analysis

Table 6. SoftTypes mapping

SoftType Title in ShareAspace BaseType (ShareAspace information model) Activity Activity ActionOrder ActivityAsExecuted Activity Actual ActionExecution Area Area Location ComponentAsRealized Component As Realized ProductAsRealized Consumable Consumable Part CustomerOrder Customer Order ActionRequest Enterprise Enterprise Organization GenericComponent Generic Component Part GenericWorkSchedule Generic Work Schedule Plan Person Person Person Position Position Position Product Product Part ProductAsRealized Realized Product ProductAsRealized Site Site Location SpecialComponent Special Component Part TaskMethod Task TaskMethod WorkCenter Work Center Location WorkingGroup Working Group Organization WorkSchedule Work Schedule Schedule WorkUnit Work Unit ResourceItem

The complete mapping, as shown in Appendix A contains information about how the implementation is done in ShareAspace. The first 3 columns are similar to those in Table 6 and those are the most important to understand. The other columns are detailed information which are used when implementing the solution and for other users of the software to know how the mapping and implementation was done. Port is the name of the connection port to other SoftTypes or the name of the attribute of the SoftType. Link is what the relation is called in the ShareAspace information model. To SoftType is a reference to the other SoftType of which one wants a relation to, with a defined port to which one wants the connection to be – this is in the implementation either oid (Object Identifier), vOid (Version Object Identifier) or generalDefinitionOid (General Definition Object Identifier). GenericClass is used if the attribute is an enumeration in the information model, where the GenericClass is specifying what the options are for the enumeration. Property (Instance) is a property value and can be a fixed numeric value, a range of numeric values or a string. The Unit is then specifying the specific unit for that Property (Instance) if necessary.

57 (86) Chapter 4 Results and Analysis

4.6 Implementation in ShareAspace

The DigIn scenario as implemented in the solution is illustrated in Figure 4-5. Compared to Figure 2-2, some minor modifications have been made but the overall concept is still the same. The objects have been changed to the SoftTypes created in the business object model. The implemented solution is a practical implementation of the proposed theoretical solution to provide a proof of concept. The SoftTypes created origin from the created business object model. The front page of the implementation in ShareAspace is shown in Figure 4-6. All the SoftTypes have been organized into three main categories:

• Order/Task/Activity o Activity o ActivityAsExecuted o CustomerOrder o GenericWorkSchedule o TaskMethod o WorkSchedule • Organization o Area o Enterprise o Person o Position o Site o Work Center o Work Unit o Working Group • Part/Docs o Component as Realized o Consumable o Generic Component o Documents o Products o Realized Products o Special Component The SoftTypes grouped under the category are shown in Figure 4-7. The created SoftTypes all have the same name as in the business object model apart from Working Group, which has been added (is an Organization)

58 (86) Chapter 4 Results and Analysis

Figure 4-5. Implemented DigIn use case

Figure 4-6. The front page of ShareAspace

Figure 4-7. Created SoftType queries as shown in ShareAspace

59 (86) Chapter 4 Results and Analysis

The goal is to automatically create SoftType instances and relations based on messages from the systems being transferred through the service bus used in the DigIn use case, Kafka. If an order enters the system, an order instance with corresponding ordered instanced Products, Work schedules and assignments of resources are instantiated and connected automatically without user interaction. Furthermore, when real- time events happen, this is also automatically fed into the system through the message based communication, c.f. Figure 4-8. The established connection of the message system was done in a parallel project and is described later in detail. However, automated creation of SoftTypes can also be done using Microsoft Excel and is a simple test on how to create the SoftTypes in an automated way, this is also explained later. The main issue with this thesis is to provide the necessary information models and connections to be used in an implementation of smart manufacturing, not to implement the software architecture. Manual entering of information is possible using created “Views” in the software. The information necessary to be entered has been added to the view in order for the user to get a good understanding on what information that is needed, c.f. Figure 4-9.

Figure 4-8. Idea of system functionality

60 (86) Chapter 4 Results and Analysis

Figure 4-9. A SoftType create window

Views are used in ShareAspace and is in the implementation shown under the tab “Open in”, where the different views of an object are accessible, c.f. Figure 4-10. The views can be anything from a design view to a business view to a structure, and hold information necessary for that view. All information is however stored on the same object. An ordinary “Read” view, which in this case contains all information about a Realized Product is shown in Figure 4-11. The views are not limited to showcase a specific set of information, but can be adapted to show what the administrator wants the users to be able to see in certain views. Depending on the case, this can thus range from being able to access CAD-models in certain views by certain users to accessing business related information about price for a certain product for other users.

61 (86) Chapter 4 Results and Analysis

Figure 4-10. Views in ShareAspace

Figure 4-11. A SoftType (Realized Product) as shown in “Read” in ShareAspace

Relations between different SoftTypes can be created in different views, for example in a structure or in a create view. The relation is created by first specifying what kind of relation should be done when configuring the software (what SoftType connects to what), and then choosing the right instanced object when creating the actual relation. These are shown as blue “links” in Figure 4-11. To specify the Types of some of the objects, for example Consumables and Work units, enumerations was specified in the business object model. These are implemented by creating a dropdown list from which the user is specified to only be able to select a defined set of values, c.f. Figure 4-12. One special kind of View is a structure, which has been created to showcase a structure of parts or some other kind of hierarchy where a parent has children. Structures have been created for Products, Realized Products, Enterprises and WorkSchedules. The hierarchical structure exists in the business object model, either as hierarchical relations or as a parent/child relation. A structure as implemented in ShareAspace is shown in Figure 4-13.

62 (86) Chapter 4 Results and Analysis

Traceability is also possible to achieve. For example, if an update is done, for example changing a Work Center in one site, this creates time stamps on when the change is happening, c.f. Figure 4-14 and Figure 4-15. As showed in the figures, when the information is updated, time stamps are created in startDefinition and endDefinition, showing the dated effectivity of the information.

Figure 4-12. Enumerations as implemented in ShareAspace

Figure 4-13. A structure of a realized product and it's components (parts)

63 (86) Chapter 4 Results and Analysis

Figure 4-14. Dated Effectivity and traceability (1)

Figure 4-15. Dated Effectivity and traceability (2)

64 (86) Chapter 4 Results and Analysis

4.7 Lifecycle management of digital twins in ShareAspace

Since ShareAspace is a PLCS based software, every object created in the developed model is capable of being assigned to a specific lifecycle and/or lifecycle phase. A lifecycle is also known as the Maturity System in ShareAspace. A typical example of a Maturity System for a document is consisting of three states, New, InReview and Established. For each state, approver participants with specific roles have been granted a certain access right to the information and the ability to execute actions, such as promote, approve or access the information from a certain view. In the current solution, there are only a limited number of participants and roles that are being implemented for the sake of simplifying solution and proof of concept, see Figure 4-16. The Maturity System has not been applied to all the objects created in ShareAspace, since there were no clearly specified required lifecycle states for each object in the DigIn use case. The existing solution still shows the capability by combining the built-in Maturity System together with time stamps which specify the dated effectivity, enables the lifecycle perspective for the digital twins with traceability.

Figure 4-16. Participants and roles

65 (86) Chapter 4 Results and Analysis

4.8 Data communication and consolidation in ShareAspace

There are several ways that information can be communicated to ShareAspace. In this work, Microsoft Excel has been used to import large amounts of data. In Excel, data can be entered and connections are made which then gets imported to the space in ShareAspace – adding the information into the database. Furthermore, the data is consolidated on import. A picture over the results from an import into ShareAspace is shown in Figure 4-17. Apart from this, using the built in REST API in ShareAspace, information can be communicated using, for example, XML or JSON (JavaScript Object Notation). In the ongoing DigIn project, large XML- files containing information from other software have been created and a framework for JSON-messages have been established. This was however out of scope for this thesis (thus not done), but the functionality is necessary in order to establish the full functionality of the infrastructure for smart manufacturing, consequently it is included in the following chapter.

Figure 4-17. Excel Import results

66 (86) Chapter 4 Results and Analysis

4.9 Results achieved in parallel projects

This thesis was done in close cooperation with the DigIn project. Work was performed in parallel with this thesis, among others the connection between the plant service bus Kafka and ShareAspace. The connection was successful and established a message based system where short JSON messages or XML files could be sent and received through Kafka. All work was done by Thomas Dilts at Eurostep AB [17]. The message contained information which was read by a script and used to instantiate SoftTypes or observations (events) in ShareAspace and to establish connections between instanced objects. Examples of JSON messages are shown in Figure 4-18 and Figure 4-19. The script worked through the built in REST API in ShareAspace, thus all communication through Kafka was done using the REST API. The message based system was able to automate the creation of SoftTypes, relations and could receive real-time data, such as measured torque or other events happening in the real world. The work was connected to the developed models in this thesis. The scripts that read the messages used the implementation to instantiate the SoftTypes using the connections and properties established in the models.

{ "tagid": "12", "station": "Station 1", "timestamp": "2014-09-02T00:00:00Z", "sequence": 0 }

Figure 4-18. A JSON-message from Station 1 asking for the next task to perform [17]

{ "tagid": "12", "station": "Station 1", "timestamp": "2014-09-02T00:00:00Z", "sequence": 0, "tasks": [ { "id": "Station 1 Task 1", "parentName": "Station 1", "versionId": "1", "totalTime": { "value": "25.92" }, "sequenceHint": { "value": 1.0 } } ] }

Figure 4-19. A JSON-message from ShareAspace to Station 1 as a reply on the request [17]

67 (86) Chapter 4 Results and Analysis

4.10 Analysis of the administration shell requirements

Regarding the third research question, concerning requirements on smart manufacturing, an analysis of the proposed solution is necessary to draw conclusions whether the implementation meets these requirements or not. The following two chapters covers some analysis, but is complemented in the subsequent Chapter 5. As stated previously, the administration shell was identified as having a set of requirements, (a)-(s), which are necessary to be fulfilled. After implementing the solution and investigating the functionality, the following can be stated regarding the different requirements; Requirement a) “The Administration Shell consists of body and header” [41, p. 24] If one interprets the body and header as an abstract concept, which isn’t necessarily separated, but instead is more a notion on how to divide the content of the administration shell, one could argue requirement (a) and (b) is met. The content of the header and body is not really divided per se but the content of them both is existing in the proposed solution, since all instances and types of objects have unique identifiers and have necessary information stored on them. Requirement b) “The body contains information about the respective asset” [41, p. 24] See a). Requirement c) “The header contains information about utilisation of the asset” [41, p. 24] The software ShareAspace have REST APIs which uses uri:s (a sort of identifier) to connect to the different SoftTypes. Whenever the user or system asks for information, a request goes through the REST API to access the information. The SoftType then responds with the requested information. This was used in the previously mentioned work in the DigIn project were the REST API was the gateway through which the JSON-messages could request information. This is used throughout the software. Whenever the user request to view or change something, the request goes through the REST API through some basic functions (put/get). This is thus meeting requirements (c), (e) and (h). Requirement d) “It consists of the Manifest and Component Manager” [41, p. 24] The authors believe it is unclear whether the Manifest and Component manager is separate functions or services that the administration shell utilizes, or if it is something more abstract, similar to the reasoning on the header/body in a). The functionality exists, since one can request information about the content of an instance using the views in ShareAspace and update the information. However, due to the unclearness of the requirement, no conclusions can be drawn. Requirement e) “The information in the Administration Shell is accessible by means of a service-oriented architecture (API)” [41, p. 24] See c). Requirement f) “It represents information about different application aspects of the asset” [41, p. 24] As mentioned under the Results, each SoftType could have multiple views depending on the scenario. In this work, it was shown that a Product could have multiple views, one being an ordinary read view,

68 (86) Chapter 4 Results and Analysis one being a design structure view and one being a business view, were each view had different properties being shown. It is not limited to a set of views either, but the user could define new views whenever needed and could show different properties in those views. However, the views do not hold all the functions that is described for requirement f). For example, no calculations or diagnosis can be done by using built in functions in the views which is a major drawback. However, it is argued that calculations can be done using the information in the views existing in the system. This is thus argued to not fully meet the requirements of the “views” in the administration shell, requirement (f) and (g). Requirement g) “Structuring according to views (pursuant to MES ISO/IEC81346, Digital Factory BCFLP, …)” [41, p. 24] See f). Requirement h) “The Administration Shell has an unique ID” [41, p. 24] See c). Requirement i) “The asset has an unique ID” [41, p. 24] Each SoftType, as they are modelled in this work, have identifiers pointing to the SoftType itself. Each instance of a SoftType gets a unique ID in the system. It can also add new IDs depending on need, for example a serial number or batch-ID. This way of utilizing identifiers and not limit the number of identifiers to the identifier for the instance in ShareAspace, is argued to meet the requirements of the Header’s content in the Administration shell, since it is not limiting the number of identifiers and could hold multiple identifier to real-world assets (for example, one could have n number of batch-IDs for one SoftType), thus meeting requirement (i) as well as (c). Requirement j) “Also a factory is an asset, it has an Administration Shell and is accessible by means of ID” [41, p. 24] In the implementation, the factory (or site/area) is treated as an asset, the same way a work unit or work center is an asset, fulfilling requirement (j). Requirement k) “Types and instances must be identified as such” [41, p. 24] In the work, types and instances have been separated. It would be possible to rename the SoftTypes to TYPE or INSTANCE in the SoftType name, to clarify what is what, however it is not seen as necessary in this work. However, it is possible, meaning it would meet requirement (k). Requirement l) “The Administration Shell can include references to other Administration Shells or I4.0 information” [41, p. 24] All created SoftTypes can reference other SoftTypes or data within the system, meeting requirement (l). Requirement m) “Additional properties, e. g. manufacturer-specific, must be possible” [41, p. 24] The number of properties is not limited, and multiple different properties can be added with different contexts, meeting requirement (m). Requirement n) “A reliable minimum number of properties must be defined for each Administration Shell” [41, p. 24]

69 (86) Chapter 4 Results and Analysis

The authors believe requirement n) is not clear in the sense that the minimum number of properties is benighted. It is not specified exactly what properties should be included, but instead what is proposed is that these properties should be logical and be filled in for all administration shells of a certain class. What this means is unclear, thus no conclusions or reasoning can be done. Requirement o) “The properties and other elements of information in the Administration Shell must be suitable for types and instances” [41, p. 28] Each type and instance can have different properties. For example, a Type might have data which is Type-specific while the Instance of an object might have data that is Instance-specific. For example, a Product, can hold information that is valid for all Pedal cars, while a Realized Product holds information that is true for just that particular instance of the Product, perhaps changing from a default value valid for the Type to be unique for this Instance. This is argued to meet requirement (o). Requirement p) “There must be a capability of hierarchical and countable structuring of the properties” [41, p. 28] The different sub models of the Administration shell are argued to be able to be represented in the implementation. Each SoftType can have multiple groupings based on its functionality which is called group ports. Each group port can have properties or have relations to other SoftTypes with properties assigned to those relations in a hierarchical manner. In this way, the group port can be considered or treated as a sub model, since the grouping has some functional meaning. In a practical example, a group port called “Work Units” can exist where the SoftType can have a group of properties to this group such as possible torque values, maximum running time etc., and also relate to instances of Work Units allowing the connection between their administration shells. This is argued to meet requirement (p). Requirement q) “Properties must be able to reference other properties, also in other Administration Shells” [41, p. 28] In ShareAspace, each instance/object is able to reference information in instances/objects it is in a relation to. However, this is not recommended in PLCS, since it creates duplications of information which from a storage based point of view is non-desirable since it takes up unnecessary space. In this regard, one can argue that requirement q) is not fulfilled at the moment since it is not recommended and might cause issues. Requirement r) “Properties must be able to reference data and functions of (or at least within) the Administration Shell” [41, p. 28] The objects/instances contain properties which reference input data, either from the user or automatically generated data such as ids. As mentioned before, the functionality is however where the questions arise whether the requirement is completely fulfilled or not. Thus, requirement r) is not considered to be completely fulfilled. Requirement s) “Properties must take into account aspects of information security by means of a graduated guarantee of availability, integrity, confidentiality, visibility and authenticity” [41, p. 28] The last requirement is argued to be fulfilled and met by default using PLCS, since this is the very nature of PLCS. Each user gets granted different levels of access to different views and functions and SoftTypes, meaning the data is kept safe. This is meeting requirement (s). The analysis can be concluded in Table 7.

70 (86) Chapter 4 Results and Analysis

Table 7. Requirements of Administration shells

Requirement Fulfilled No Conclusion Drawn Not Fulfilled A X B X C X D X E X F X G X H X I X J X K X L X M X N X O X P X Q X R X S X

4.11 Analysis of information hub for smart manufacturing

As noted in [9], the integration of information is one of the key enablers of smart manufacturing. In this work, data coming from different systems as well as real time data coming from the shop floor is forwarded through Kafka and retrieved by ShareAspace – efficiently updating the information in the database. The solution can be argued to function as an information hub, which bridges the gap between different islands of information. This is because other systems rely on information coming directly from ShareAspace, and when the information is updated in the database, all other systems accessing or requesting information from ShareAspace will always have the latest available information. In addition, the possibility to keep track of history makes it possible to also see the history of the data, and trace changes back in time. The ability to use real time data which updates the information in the database is also an enabler of smart manufacturing in itself in the sense that it enables the updating of the digital twins of certain high- importance assets (such as the product). This was also said in [9] to be of key importance regarding smart manufacturing. It enables information to be written in real time to a certain asset which can be used to make decisions regarding improvements. By using standardized terminology, the ability to bridge the gap is simplified in the sense that it enables easier understandability for users and systems to acquire the necessary information. When information is forwarded and entered into the system, using a standardized terminology makes it easier to find the corresponding information, and less requirements on translations are needed. For example, calling a Work Center a station as in the project, requires translation when integrating the data. One extended step would be to integrate the used terminology for all actors (and systems) in the DigIn project.

71 (86)

Chapter 5

Discussion

This chapter will put the result in context, and the results from the implementation will be put in relation to the standards’ requirements. The developed models will also be analyzed and the method chosen will also be critically evaluated.

5.1 Result in context

The developed models are in some way an expression of how the authors interpret the concepts in the literature and standards. A discussion on the impact the art of modelling and the impact the selection of concepts has on the work is conducted later in this chapter. In order to create a comprehensive concept model, it was necessary that established terminology able to cover such a broad concept as smart manufacturing was used. RAMI4.0 and the NIST model were believed not to include the necessary terminology or concepts as needed for this work on their own. Thus, the two were combined and used together, and extended with terminology from ISA-95, ISA-88 and PLCS which complemented the models. Using ISA-95 was a natural step since it is mentioned in both reference architectures or models as either the hierarchy to use (RAMI4.0) or for the manufacturing pyramid (the NIST model). ISA-88 and PLCS was mentioned in either RAMI4.0 (ISA-88) or in the NIST report (PLCS) and was found to be needed to cover the terminology and concepts needed for the work – especially the use of PLCS to make the model include the lifecycle perspective and variant handling.

73 (86) Chapter 5 Discussion

Even though both PLCS and ISA-95 are used in the work, those are not standards developed to be exclusively used in the smart manufacturing environment, but instead was developed for other areas primarily. Consequently, there was a need to be selective on the terminology used from these standards. For example, ISA-95 covers a lot of key concepts for the manufacturing enterprise which the authors believed were not necessary in order to describe smart manufacturing from a lifecycle perspective. In order to delimit the work, only concepts that were believed to be encompassed and be verifiable by the DigIn project were used. This led to a slimmer model compared to if all ISA-95 concepts would be used, but was necessary in order to verify the applicability of the model. The same applied to PLCS. Since the concept of smart manufacturing is very broad, and to make a comprehensive model for the concept, smart manufacturing as such was divided into two separate areas – (1) smart factories creating (2) smart products. These two sub-concepts are then what was being modelled in the separate models. The aim was to be able to combine and use the two separate models, creating a model for smart manufacturing. Since the developed concept model(s) were to be implemented, it was crucial to use terminology that was necessary in order to describe the objects in the implementation. Therefore, some deviation from the main models (RAMI4.0 and the NIST model) was necessary. In this case, ISA-95 concepts were instead used, since they are established business concepts. Mainly, this was the issue when trying to include the functional hierarchy from RAMI4.0 in the concept model. For example, Control Device, Station and Field Device lacked sufficient definitions in RAMI4.0, thus, they were excluded from the model. In addition, many necessary concepts from an implementation point of view was lacking, and thus the main IEC 62264 and IEC 61512 concepts was instead used. The concept models focus on both the production system lifecycle as well as the product lifecycle. This is evident if one studies the models in Figure 4-1 and Figure 4-2 where the smart product and smart factory both have states and could be represented in their respective lifecycle. The implementation was done mainly to verify the work, that the data could represent the necessary information in a smart manufacturing use case (the DigIn use case) and to use it as a basis for analysis of the system functionality.

5.2 PLCS based software to enable smart manufacturing

In the NIST report NISTIR 8107, it is said that PLCS (ISO 10303-239) is one of the PLM standards which could support smart manufacturing. In addition, one of the many suggestions in the report is the creation and integration of so called cyber-physical production systems. ShareAspace is based on the PLCS standard and could thus be considered to represent some of the capabilities a PLCS based software could possess. With the combination of ShareAspace and Kafka, it could be argued that this enables cyber-physical production systems to some degree. Since the different assets, such as robots or tools, can communicate regardless of hierarchical structures or locations, through Kafka via ShareAspace, it is likely that this enables the web of assets that the CPPS is built upon. However, no studies have been done in regard to CPPS and if there are reference architectures stating functionality of the CPPS. Therefore, extensive conclusions are not possible, but it is of great interest to investigate in the future. NIST further stated in the NISTIR 8107 report that the combination of Product lifecycle data and manufacturing process data is the key enabler of improvements to quality, productivity and sustainability. This work proved that the PLCS based software ShareAspace can combine these two categories of data into a competent representation of them both which could be utilized to analyze the

74 (86) Chapter 5 Discussion system performance and product during their respective lifecycles. A simple example of this is the tolerance limits for torque which could be set on a planned activity in the production system which was to be used to manufacture a specific product. During production, a second set of data was created – the actual torque value. This was then referencing both the planned activity and the product which was realized, making it possible to trace if an error occurs in the realized product back to the actual activity, and finally back to the planned activity in the production system. In addition, since PLCS and ShareAspace is mostly focused on the product and its lifecycle, the combination of these two datasets enables the analysis of errors during both production and life of products and makes it possible to trace the errors to its source to make improvements.

The smart product and IoT The smart product and IoT as presented in the background of this thesis is interesting to investigate and put into context. Due to the focus of the thesis being on the production system, and no verification regarding the smart product part of the models could be done, no major conclusions is possible to draw regarding this topic. Regardless of whether the products are smart or not, what is important is the interconnection of the product and the production system lifecycle for the smart manufacturing perspective. Hence, it does not matter whether the smart product models are verifiable or not, since those models are not the main focus. What could be stated however is that many of the concepts as they were presented in the concept model for smart products are possible to find in the implementation. Attributes, both physical and non-physical (Product data/Characteristics), could be stored in the system about the products. In addition, a BoM (Bill of Materials) was created. This is however expected, since the software ShareAspace is a PLM system which is able to handle these requirements. Still, the smart products do require a lifecycle perspective, as it is important to be able to draw conclusions on the state and status of the products from both the current and historical perspective. The lifecycle perspective adds an extra dimension, which is argued to be met by the integration of a PLM system working in co-operation with the smart products (in this thesis it is ShareAspace). As seen in the results, it is possible to follow a product from its order to how it was realized, when it was realized, and follow the different “layers” of information back to the planned product which was ordered. This was the main idea of the products in the smart manufacturing domain as noted in the NIST report. This is argued to be the main functionality required on the PLM software from the smart products perspective. What is however necessary is to verify that the smart product can use a possible connection to ShareAspace and use these extended layers in order to provide the necessary functionality. Though, it is important to be cautious in drawing conclusions from this. The smart product goes beyond the mere concepts from the concept models. It is important that these products can communicate through some sort of standardized information model and communication channel, as Kafka for the production system, and that the products are capable of functionality considered to be smart – see Definition 3.2. The lack of these abilities in the tested case is what limits the verification of this part, and is the main reason why the smart product concept was not investigated further. This is thus left as future work. The IoT part is also something which was omitted in this thesis, but is necessary to include in the future. As noted in the background, there are existing models for IoT that has a terminology that would be interesting to include in the system. It would be interesting to investigate how these concepts and these models could be integrated in the developed models and implementation. This is however left as future work.

The digital twin and digital thread A digital twin can be described as a digital replica of an asset, existing in the digital world. The twin should be able to be constantly updated with live data from a variety of sources and activities in order

75 (86) Chapter 5 Discussion to analyze data and provide support to improve the system or created products. A reasonable question is whether this is the case in the proposed solution or not. The current solution is striving to achieve the concept of the digital twin in a simplified manner. Properties (such as the current location) which can be measured by sensors should be possible to feed into the system (c.f. Figure 4-11) thus providing the ability to track the actual product and its location in time. However, any more advanced properties of digital twins, such as the ability to see current speed, tire pressure etc. are left for future work. When implementing the solution in ShareAspace, it was assumed that the system can manage objects with lifecycle perspectives – the maturity system – since ShareAspace is designed to manage product information through its life and provide the agility for sharing of data between partners. Each object created in the developed models is capable of having its own complete lifecycle where a distinction has been made between types and instances of objects and planned and realized objects. In addition, the lifecycle stages enable the possibility to trace each individual instance or type throughout its lifespan. This way of modelling creates a “digital thread” where it is possible for different participants in the system to access the information and to trace the products or production systems life from idea to finished product. In the current solution the participants in ShareAspace have been assigned with roles with certain access right to e.g. create, read, update and delete specific information, hence the concept of digital thread is proved to be achievable. For the sake of simplicity, most of the objects’ lifecycles in ShareAspace have not been modeled or considered, but it is possible to implement lifecycles (Maturity Systems) for every object in the same way as the previously explained processes. For instance, an enterprise could go through lifecycle stages, and this is especially true for the lower levels of the production system, where a Work Center could go through lifecycle stages whenever a machine or tool would be changed. This is also traceable in the system where changes are traceable and a current state of a work center or other form of location is viewable.

Administration shells The administration shell was stated in IEC PAS 63088 as having some key functionality. For example, it is said that the administration shell should be able to handle runtime data, have APIs, have different views, be able to keep track of both the asset and the administration shell itself and have different models. In the parallel work in the DigIn project, it was shown that ShareAspace could handle runtime data through XML-files, JSON-messages and scripts writing data to ShareAspace. If an asset in the physical world communicates data in a JSON-format through some sort of communication bus (in the implementation it was Kafka), the software could thus import runtime data and write it to the specific SoftType. This meets the requirements of handling runtime data; however, the frequency of the updates has not been considered and is thus left for future work. As stated in chapter 4.10, many of the requirements are fulfilled by the implemented solution. However, a lot of ambiguity due to the vagueness of the requirements make it possible that some requirements have been misunderstood. In the cases where the vagueness has been too severe, no conclusions were drawn.

System functionality As noted, the presented solution meets most of the requirements on the system functionality that has been laid out in RAMI4.0. In addition, several of the requirements from the NIST report is also met. It is also interesting to investigate whether the system is able to meet some of the requirements on the system functionality which are laid out in the Chinese and Japanese models for smart manufacturing.

76 (86) Chapter 5 Discussion

Due to the similarities of the Chinese model to RAMI4.0, both in the lifecycle axis and system level axis, it is argued that the models can be comparable in those regards. The Chinese model differs in the smart function axis, where it is said that the assets must be self-adapting. This must incorporate AI or automated decision making and can be said to be a step further than RAMI4.0 went regarding describing the requirements on the functions. Since this thesis has not considered these aspects, no conclusions can be drawn, but instead must be investigated in order to draw any conclusions from it. The Japanese model is similar to both the Chinese model as well as RAMI4.0 in the sense that it is three- dimensional. However. In addition to each individual unit (SMU) having a three-dimensional approach, each unit also exist in an environment that is also portraited as three-dimensional – the function blocks (GFBs). The GFBs are what is most similar to the other models (RAMI4.0/Chinese model/the NIST model). The SMU on the other hand is focusing more on each unit and can be said to lay a greater focus on the individual asset and its functionality in the Plan-Do-Check-Act-cycle (PDCA-cycle). As previously mentioned, the Japanese model mentions loosely defined standards, which is something this work is greatly concerned with. It is argued that the method of this thesis, of mapping different layers of information from less to more generic models, is close to or equivalent to the way the loosely defined standards was laid out in the Japanese model.

5.3 The mapping of objects, and its effect on the result

The mapping of the SoftTypes to the different BaseTypes (and consequently to the PLCS concepts) will affect the result greatly. When mapping, there are several possible ways that one can map, and the presented solution is just one of many ways of mapping the concepts. As noted by Von Euler-Chelpin, the generic structure of the PLCS standard and the lack of rules on how to map objects creates ambiguity which was argued could cause issues. In this work, the ambiguity is present, as is visible in chapter 4.5, but thanks to the standardized definitions for the concepts, there is often just one BaseType which is the most suitable. The ambiguity is also something which is deliberate, as noted by Oasis, due to a desire to be able to utilize PLCS in many different contexts. It is thus possible to map business objects from many different areas into the PLCS model. It can be argued this is beneficial from a smart manufacturing perspective, since the smart manufacturing domain requires information on more areas than just pure manufacturing. The system must be able to cope with information from many areas, ranging from the product to the business and user data, and utilize it into a competent representation which can be utilized to make decisions on several levels of the enterprise. A too specific model would lead to issues when it comes to the implementation – one of which would be pools of data not being used or data being stocked up in separate locations due to issues in the transferal. This argument is also supported when looking at one of the other models for smart manufacturing – the Japanese model. The use of ‘loosely defined standards’ is something which is highlighted in that model. This is something which could be said is used throughout in this work. By using a very specific model (the concept model) and use it to create a detailed use case model (the business object model) enables the mapping to a more generic model (the ShareAspace information model) which in turn is mapped to an even more generic model (the PLCS information model). The use case model is specific for a specific case (there can exist multiple models), and can change depending on the requirements on the system or any other factor (which might not be considered in this thesis). The ShareAspace-model is more unique, but is still more specific than the PLCS model, which is a very generic model that can map many different objects to it.

77 (86) Chapter 5 Discussion

5.4 The effect the chosen method has on the result

The selected method is to a great extent affecting the outcome of the result. Modelling requires the modeler to make decisions on how to connect the different objects in the model, and what objects to include – this is one of the fundamental aspects of modelling. Almost all models are unique, there might however be some similarities between models. The solution will thus be unique and another individual creating a similar model with the same goal would most likely create a different model, however with some similarities. Since the developed models to a great extent is a result of the authors’ interpretation it is important for the reader to evaluate the reasoning behind the creation of different connections and the inclusion of certain concepts or terminology. It is also important to note that the proposed solution is just one of many possible solutions. The result showed that it was possible to meet most requirements in the current scenario with the delimitations and conditions applicable in this case. If the delimitations and conditions were to change, it is possible the solution would not work, meaning that the solution must be tested in more scenarios in order to be completely verified. This is left as future work. In addition, it is necessary to debate whether the proposed DigIn example is suitable for verification or not. Since the DigIn project is working with the end goal to develop a digital infrastructure for smart manufacturing, it is reasoned that it at least provides some functionality and requirements that is argued to be of use in a smart manufacturing environment. In addition, a necessary question to ask is if the proposed solution integrates smart manufacturing or not. The answer to that depends on what one mean by “smart”. Since this study considered AI or automation on decision making or automated improvements to be out of scope, it has not been included in this thesis. If one instead means that the system should provide the possibility to make decisions on several areas in manufacturing (product/production/business) and interconnect these areas into a competent representation, and provide a standardized way of storing and communicating data and information through less hierarchical structures, it is argued it is possible to conclude that the functionality of the proposed solution meets these requirements. The inclusion of AI and automated decision making is left as future work, but would be interesting to investigate using the proposed solution. Lastly, another notable aspect is whether the functionality of the proposed solution meet the requirements thanks to the software or thanks to the standard (PLCS). One must ask what functionality is thanks to PLCS and what is thanks to the software. The generic nature of the mapping is thanks to both PLCS and the software, where the software adds an extra dimension and layer to the mapping. In addition, the models provide the necessary functionality of being able to distinguish between different layers of information (as-planned, as-ordered, as-realized) and to interconnect the lifecycles of products and production systems. However, the solution (models and mapping) would still be very similar if no extra layer would have been added. The connection to Kafka and the use of REST APIs however are thanks to the software, and it is not certain other software provide the same or similar functionality.

78 (86)

Chapter 6

Conclusions

This chapter aims to conclude the thesis and the answers to the research questions .

In order to enable the benefits of smart manufacturing – shorter development times, improved quality and reduced cost to name a few – it is necessary to adopt a lifecycle perspective of both products and production systems. This thesis covered smart manufacturing in the context of Product Life Cycle Support (PLCS) – how to utilize PLCS to enable or support smart manufacturing. By studying several specifications/reports/standards for smart manufacturing, multiple models were created in order to be able to implement a suggested solution in the PLCS software ShareAspace. The suggested solution was then implemented on the software, and tested by trying to represent the data necessary for the DigIn use case – a project focusing on developing an infrastructure for smart manufacturing. The implementation was shown to meet most of the requirements of a smart manufacturing system. A set of research questions were formed in the beginning of the thesis. The conclusions to these questions are as follows: Question 1: Can the concepts used in relevant smart manufacturing standards together with concepts from PLCS represent lifecycle support in the context of smart manufacturing? Answer 1: The use of the terminology in the standards used for smart manufacturing in this thesis (IEC PAS 63088/RAMI4.0, NISTIR 8107/the NIST model, IEC 62264/ISA-95) is believed to support the representation of information necessary to provide lifecycle support in the case of smart manufacturing for the DigIn use case. However, these standards lack some terminology, mainly in

79 (86) Chapter 6 Conclusions

the sense of the different “layers” of information where the different stages in the lifecycle would be needed to be represented – for example “as-planned”/”as-ordered”/”as-executed”. In this sense, PLCS was found to cover the gaps. In other words, the standards for smart manufacturing used in this thesis in combination with PLCS was found to be able to support the representation of necessary information for lifecycle support in the context of smart manufacturing. Question 2: Can these concepts be implemented on a PLCS-based software? Answer 2: The use of terminology and concepts found in the standards could be implemented in the software ShareAspace after the information models was created. However, it was found that the implementation might result in ambiguity due to the lack of pre-defined rules when mapping concepts. Though, this is considered a strength rather than weakness, since the implementation then can be easily adapted to each use case rather than each use case having to adapt. In the sense of smart manufacturing, this is desirable since it requires the incorporation of information from the extended enterprise (integrating suppliers/customers and their vocabulary). Question 3: Does the proposed solution meet the requirements of smart manufacturing as expressed by the standardization community? Answer 3: The proposed solution meets most of the identified requirements on what RAMI4.0 is referring to as administration shells which is a requirement for I4.0 components (smart components). In addition, the infrastructure which has been proposed in the thesis meets close to all requirements in forms of system functionality and ability to bypass most hierarchical boundaries thanks to the use of the service bus Kafka and REST APIs. The answer to these questions also answers the overlying research question: How can PLCS be utilized/exploited to realize smart lifecycle support in the context of smart manufacturing, and how can it be implemented on the PLCS based software ShareAspace? To conclude, the implemented solution showed that the PLCS based solution could support the representation of data necessary from the lifecycle perspective of smart manufacturing – where some of the focus is on types and instances of objects. The different layers of information, from as-planned, via as-ordered to as-executed was implemented, not just for the product, but also for the production system. In addition, the connection of the message based system Kafka to the implemented solution showed that the solution could handle streamed data that updated the models in the system whenever an event happened in the real world based on a service-oriented architecture. This allowed for easy information exchange across hierarchical boundaries and the possibility to use ShareAspace as an information exchange hub where data is consolidated for different systems acting in the smart manufacturing environment in the DigIn use case.

80 (86)

Chapter 7

Proposed future work

This chapter aims to describe potential future areas of work within the area, which has been considered to be of great interest for this work.

This thesis has not considered automated decision making and AI, but has instead focused on the underlying infrastructure to realize the smart manufacturing concept. It would be interesting to investigate how the proposed solution for the infrastructure could support automated decision making and AI technology. ISO is preparing to release a new reference model called IoT Reference model. The working draft contains several interesting concept models which could be used similar to the proposed concept models. These models are likely to affect this work and would be interesting to investigate further. This work included the predefined configurations of the pedal cars. In the future, it is however recommended to include ISO STEP 242 and use that standard to filter variants. In that way, all possible variants of a product “Pedal car” could be stored in the system with links to all tasks etc. that is necessary to realize the product. When a customer customizes their product, the specific variant is filtered, automatically creating all necessary information. In addition, one area which is of great interest and can be seen as a continuation of this thesis is to investigate in what way the information in the system and the proposed infrastructure can be used in order to improve products and processes.

81 (86) Chapter 7 Proposed future work

An extension of this is to also verify the Smart Product concept model by developing business object models and investigate whether the system can handle Smart Products as they are defined. This also includes expanding the model and investigating to what extent the concepts and models for IoT and IoT- devices can be integrated in the proposed models and solution which was mentioned before regarding the IoT Reference model. The issue of security for the whole system is also something worth considering. Especially when it comes to integrating IoT-devices. The integration of these sort of devices requires extended security needs and a solution for that is necessary. ShareAspace has built in security for enterprises and to make sure that the sharing of data can be done in a secure way. It is however still necessary to consider the complete chain of systems to see whether there are security compromises in any of the links to ensure integrity of data. It is also recommended that one consider the business lifecycle more thoroughly as presented in the NIST report. That axis was out of scope for this work, but is still an axis that is necessary to consider from the NIST perspective. The axis is to some extent argued to be somewhat embedded in the presented solution, however it is still recommended that thorough studies of it is conducted. Finally, in order to fully verify the work, more tests on the applicability of the model is required. More use cases must be tested in order to either verify or reject the findings of this thesis.

82 (86)

Cited sources

[1] Y. Lu, K. Morris and S. Frechette, "Current Standards Landscape for Smart Manufacturing Systems," National Institute of Standards and Technology (NIST), 2016.

[2] A. Parrot and L. Warshaw, "Industry 4.0 and the digital twin," Deloitte University Press, 2017.

[3] Apache Software Foundation, "Introduction - Apache Kafka is a distributed streaming platform. What exactly does that mean?," 2017. [Online]. Available: https://kafka.apache.org/intro. [Accessed 18 April 2018].

[4] Swedish Standards Institute, "Vad är en standard?," [Online]. Available: https://www.sis.se/standarder/vad-ar-en-standard/. [Accessed 21 May 2018].

[5] International Organization for Standardization, "The main benefits of ISO standards," [Online]. Available: https://www.iso.org/benefits-of-standards.html. [Accessed 21 May 2018].

[6] D. A. L. B. Jr., "Standards and Infrastructure: Forum on New Directions in Manufacturing," NIST, 2003. [Online]. Available: https://www.nist.gov/speech-testimony/standards-and- infrastructure-forum-new-directions-manufacturing. [Accessed 2018 05 14].

[7] T. Holm (Director Business Development), Interviewee, PLCS and standards. [Interview]. 16 February 2017.

[8] J. Ahrén and E. Winberg, "Industry 4.0 from a technology adoption perspective (to be published)," Kungliga Tekniska Högskolan, Stockholm, 2018.

83 (86)

[9] P. Zheng, Z. Sang, H. Wang and X. Xu, "Smart manufacturing systems for Industry 4.0: Conceptual framework, scenarios, and future perspectives," Frontiers of Mechanical Engineering, pp. 1-14, 2018.

[10] S. Floyd, "Digital Twin: An Industry Perspective," Microsoft, 2017.

[11] A. Von Euler-Chelpin, "Information modelling for the manufacturing system life cycle," Kungliga Tekniska Högskolan - Department of Production Engineering, Stockholm, 2008.

[12] DigIn Project meeting, DigIn Workshop, Stockholm, 2017.

[13] I. Grangel-González, L. Halilaj, S. Auer, S. Lohmann, C. Lange and D. Collarana, "An RDF- based Approach for Implementing Industry 4.0 Components with Administration Shells," in 2016 IEEE 21st Internation Conference on Emerging Technologies and Factory Automation, Berlin, 2016.

[14] IEC International Electrotechnical Commission, "Satsstyrning - Del 1: Modeller och terminologi (SS-EN 61512-1)," SEK Svensk Elstandard, 1999.

[15] Produktion 2030, "Digital infrastructure for smart manufacturing – DigIn," [Online]. Available: http://produktion2030.se/projekt/digin-digital-infrastructure-for-smart-manufacturing-2/. [Accessed 18 April 2018].

[16] International Society of Automation, "Bill of Materials," 01 May 2003. [Online]. Available: https://www.isa.org/standards-and-publications/isa-publications/intech- magazine/2003/may/bill-of-materials/. [Accessed 21 May 2018].

[17] T. Dilts, Director, KTH DigIn Nova Scenario. [Film]. Sweden.2017.

[18] A. Radziwon, A. Bilberg, M. Bogers and E. S. Madsen, "The Smart Factory: Exploring Adaptive and Flexible Manufacturing Solutions," Proceedia Engineering, no. 69, pp. 1184-1190, 2014.

[19] M. Abramovici, "Smart Products In: The International Academy for Produ, Laperrière L., Reinhart G. (eds) CIRP Encyclopedia of Production Engineering," Springer, Berlin, Heidelberg, 2015.

[20] B. Schleich, N. Anwer, L. Mathieu and S. Wartzack, "Shaping the digital twin for design and production engineering," CIRP Annals - Manufacturing Technology 66, vol. 1, no. 66, pp. 141- 144, 2017.

[21] S. Boschert and R. Rosen, "Digital Twin – The Simulation Aspect," Mechatronic Futures, pp. 59-74, 2016.

[22] Eurostep AB, "A Digital Thread is for Life - not just Manufacturing," [Online]. Available: http://content.eurostep.com/a_digital_thread_is_for_life_not_just_manufacturing-0- 0?ads_cmpid=932238601&ads_adid=52218729572&ads_matchtype=e&ads_network=g&ads_ creative=225516530856&utm_term=digital%20thread&ads_targetid=kwd- 363627658548&utm_campaign=&utm_. [Accessed 4 April 2018].

[23] U.S. AIR FORCE, "Global Horizons - Final Report," U.S. AIR FORCE, 2013.

[24] C. Leiva, "What is Digital Thread?," iBaset, 23 December 2017. [Online]. Available: www.ibaset.com/blog/what-is-the-digital-thread/. [Accessed 4 April 2018].

84 (86)

[25] B. Buntz, "A digital thread to link the physical and virtual manufacturing worlds," 22 November 2017. [Online]. Available: http://www.ioti.com/industrial-iot-iiot/digital-thread-link-physical- and-virtual-manufacturing-worlds. [Accessed 4 April 2018].

[26] PLCSlib, "PLCSlib," [Online]. Available: http://www.plcs.org/plcslib/plcslib/help/plcs_intro_content.html. [Accessed 06 02 2018].

[27] ASD Stretegic Standardization Group, "White Paper ISO 10303 (STEP) AP 239 edition 3 Application Protocol For Product Life Cycle Support (PLCS)," 2015.

[28] Oasis, "Oasis Open," [Online]. Available: http://docs.oasis- open.org/plcs/plcslib/v1.0/cs01/help/techdes_rdl_content.html. [Accessed 27 03 2018].

[29] ISO, "ISO/AWI 10303-239," [Online]. Available: https://www.iso.org/standard/70696.html. [Accessed 06 February 2017].

[30] X. Ye, Interviewee, ShareAspace and PLCS models. [Interview]. 26 January 2018.

[31] OASIS, "Data Exchange Specifications," [Online]. Available: https://docs.oasis- open.org/plcs/dexlib/cs01/help/dex/techdes_dex.htm. [Accessed 22 01 2018].

[32] Eurostep Group, "PLCSlib: PLCS Business Overview," 5 January 2010. [Online]. Available: http://docs.oasis-open.org/plcs/plcslib/v1.0/cs01/help/plcs_intro_content.html. [Accessed 22 January 2018].

[33] Eurostep Group, "PLCS: Concept Model," 5 January 2010. [Online]. Available: http://www.plcs.org/plcslib/plcslib/data/PLCS/concept_model/model_base.html. [Accessed 22 January 2018].

[34] Oasis, "Oasis Open," 15 October 2013. [Online]. Available: http://docs.oasis- open.org/plcs/plcslib/v1.0/cs01/help/techdes_rdl_content.html. [Accessed 26 Mars 2018].

[35] X. Ye, "ResCoM collaborative software platform - D5.2 Final standard data model," ResCom, 2017.

[36] IEC Internation Electrotechnical Commission, "Integrering av processtyrning och affärssystem – Del 1: Modeller och terminologi (SS-EN 62264-1)," SEK Svensk Elstandard, 2013.

[37] IEC International Electrotechnical Commission, "Integrering av processtyrning och affärssystem - Del 3: Aktivitetsmodeller för produktionsstyrning (SS-EN 62264-3)," SEK Svensk Elstandard, 2017.

[38] IEC International Electrotechnical Commission, "Smart manufacturing – Reference architecture model industry 4.0 (RAMI4.0): SEK TR 63088," SEK Svensk Elstandard, Kista, 2017.

[39] W3C, "Extensible Markup Language (XML) 1.0 (Fifth Edition)," 26 November 2008. [Online]. Available: https://www.w3.org/TR/REC-xml/#sec-origin-goals. [Accessed 2 May 2018].

[40] Bitkom e.V., VDMA e.V., ZVEI e.V., "Implementation Strategy Plattform Industrie 4.0 Results Report," Bitkom e.V., VDMA e.V., ZVEI e.V., Berlin, 2016.

[41] P. Adolphs, S. Auer, H. Bedenbender, M. Billmann, M. Hankel, R. Heidel, M. Hoffmeister, H. Huhle, M. Jochem, M. Kiele-Dunsche, G. Koschnick, H. Koziolek, L. Linke, R. Pichler, F.

85 (86)

Schewe, K. Scneider and B. Waser, "Structure of the Administration Shell," Federal Ministry for Economic Affairs and Energy (BMWi), Berlin, 2016.

[42] Object Management Group, "What is UML," July 2005. [Online]. Available: http://www.uml.org/what-is-uml.htm. [Accessed 29 01 2018].

[43] G. Finance, "SysML Modelling Language explained," Object Management Group, 2010.

[44] M. Larsson, Interviewee, PLCS and ShareAspace. [Interview]. 23 January 2018.

[45] J. Rosén, Interviewee, Diskussion om mappning. [Interview]. 17 Maj 2018.

[46] PLCSlib, "PLCSlib PSM Model definitions," [Online]. Available: http://www.plcs.org/plcslib/plcslib/data/PLCS/psm_model/model_base.html. [Accessed 2018 January 05].

[47] S. Robinson, G. A. L. G. Birta, A. Tolk and G. Wagner, "Conceptual Modeling: Definition, Purpose and Benefits," in Winter Simulation Conference, 2015.

[49] IBM, "Service-oriented architecture (SOA)," [Online]. Available: https://www.ibm.com/support/knowledgecenter/en/SSMQ79_9.5.1/com.ibm.egl.pg.doc/topics/ pegl_serv_overview.html#pegl_serv_overview__introsoa. [Accessed 16 April 2018].

[50] H. Haas and A. Brown, "W3C Web Services Glossary," 11 Febraury 2004. [Online]. Available: https://www.w3.org/TR/ws-gloss/. [Accessed 16 April 2018].

[51] T. Holm, Interviewee, Generell diskussion om ShareAspace. [Interview]. 20 April 2018.

[52] ISO/IEC JTC 1/WG 10, "Information technology – Internet of Things Reference Architecture (IoT RA)," ISO, Switzerland, 2016.

[53] MIIT & SAC, "国家智能制造标准体系建设指南," Beijing, 2018.

[54] Q. Li, H. Jiang, Q. Tang, Y. Chen, J. Li and J. Zhou, "Smart Manufacturing Standardization: Reference Model and Standards Framework," Springer International Publishing AG, Beijing, 2017.

[55] Industrial Value Chain Initiative, "Industrial Value Chain Reference Architecture (IVRA)," Industrial Value Chain Initiative, 2016.

86 (86)

Appendix A – SoftType mapping

This appendix displays the mapping of SoftTypes to different objects in the ShareAspace information mode l as well as the relations between different SoftTypes and properties for the SoftType.

1 (10)

No SoftType BaseType Port Link To SoftType GenericClass Property Unit (Instances) (Instance) (instances)

1 Activity ActionOrder n/a Identifier n/a

n/a Name n/a

task ReferenceIntendedTask TaskMethod: vOid

consumable RequiredResourceAssignment Consumables: oid quantity: PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eString) workUnit WorkUnit: oid desiredFeedba ckLower: PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eString)

desiredFeedba ckValue: PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eString)

2 (10)

desiredFeedba ckUpper: PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eString) useComponent ComponentAsRealize quantity: d: vOid PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eString) assignedWorkGroup WorkingGroup: oid

performedInWorkCent LocationReference WorkCenter: oid er sequence PropertyValueAssignment n/a 2 ActivityActual ActionExecu n/a Identifier n/a

tion n/a Name n/a

workUnit ResourceAsRealizedAssignme WorkUnit: oid feedbackValue nt : PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eString) performedInWorkCent WorkCenter: oid er

3 (10)

assignedPersonnel Person: oid

consumable ActivityInputReference Consumable: vOid quantity: PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eString) inputComponent ComponentAsRealize quantity: d: vOid PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eString) 3 Area Location n/a Identifier n/a

n/a Name n/a

locationType ClassificationReference TypeOfLocation: oid locationType: - Generic - ManufacturingF acility hasWorkCenters ResourceAsRealizedAssignme WorkCenter: oid nt 4 ComponentAs ProductAsRe n/a Identifier n/a

Realized alized n/a Name n/a

n/a VersionIdentifier n/a

plannedAsGenCom ProductasRealizedVersion: GenericComponent: ItemVersionReference vOid plannedAsSpecCom SpecialComponent: Void location IndividualDefinition: WorkCenter: oid LocationReference

4 (10)

5 Consumable Part n/a Identifier (idString: id) n/a

n/a Identifier (idString: batchid) n/a

n/a Name n/a

n/a VersionIdentifier n/a comsumableType PartViewDefinition: TypeOfConsumable: comsumableTyp ClassificationReference oid e: - Screw - Nut 6 CustomerOrd ActionReque n/a Identifier n/a

er st n/a Name n/a

productIndividual ResourceAsRealizedAssignme ProductAsRealized: nt vOid orderProduct Product: vOid

orderDescription Descriptor n/a

customerInfo n/a

batchSize n/a

startDate DateTimeAssignment n/a endDate n/a 7 Enterprise Organization n/a Identifier n/a

n/a Name n/a

contactInfo Descriptor n/a

childEnterprise OrganizationHierarchy Enterprise: oid ownsSite LocationReference Site: oid 8 GenericComp Part n/a Identifier n/a

onent n/a Name n/a

n/a VersionIdentifier n/a

5 (10)

componentType commonDefinitionOid: TypeOfComponent: componentType PartViewDefinition: Oid : Classification - MudguardRight - MudguardLeft - RearFrame - FrontFrame document designDefinitionOid: Document: PartViewDefinition: generalDefinitionOid DocumentReference 9 GenericWorkS Plan n/a Identifier n/a

chedule n/a Name n/a

n/a VersionIdentifier n/a tasks PlanDefinition: PlanEntry: TaskMethod: vOid PlanEntryreference 10 Person Person n/a Identifier n/a

n/a Name n/a firstName

n/a n/a lastName

position PersonOrganizationReference Position: oid InWorkingGroup WorkingGroup: oid 11 Position Position n/a Identifier n/a

n/a Name n/a positionDescription Descriptor n/a 12 Product Part n/a Identifier n/a

n/a Name n/a

n/a VersionIdentifier n/a

productType PartViewDefinition: TypeOfProduct: oid productType: ClassificationReference - RedPedalCar - BluePedalCar - BlackPedalCar

6 (10)

consumableType TypeOfConsumable: comsumableTyp quantity: oid e: PropertyValue - Screw Assignment - Nut - assignedPrope rtyAssignment (PropertyValu eNumeric) genericComponent PartViewDefinition: GenericComponent: color: NextAssemblyUsage vOid ClassificationRef erence - Red - Blu -Black quantity: Pieces PropertyValue Assignment - assignedPrope rtyAssignment (PropertyValu eNumeric) specialComponent SpecialComponent: quantity: Pieces Void PropertyValue Assignment - assignedPrope rtyAssignment (PropertyValu eNumeric) schedule PartViewDefinition: GenericWorkSchedul PlanSubjectReference e: vOid 13 ProductAsRea ProductAsRe n/a Identifier n/a

lized alized n/a Name n/a

n/a VersionIdentifier n/a

7 (10)

tagID ProductasRealizedVersion: n/a Descriptor plannedAsProduct ItemVersionReference Product: vOid

childComponentAsReal IndividualDefinition: ComponentAsRealize quantity: ized RealizedAssemblyRelationship d: vOid PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eString) consumableAsRealized Consumable: vOid quantity: PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eString) location IndividualDefinition: WorkCenter: oid LocationReference workSchedule IndividualDefinition: workSchedule: vOid ScheduleSubjectReference 14 Site Location n/a Identifier n/a

n/a Name n/a

locationType ClassificationReference TypeOfLocation: oid locationType: - Generic - ManufacturingF acility siteDescription Descriptor n/a ownsArea ResourceAsRealizedAssignme Area: oid nt 15 Part n/a Identifier n/a

8 (10)

SpecialCompo n/a Name n/a nent n/a VersionIdentifier n/a

shape PartViewDefinition: Shape: oid Shape: Classification - Rounded - Square - Triangular - Zshape - Straight

16 TaskMethod TaskMethod n/a Identifier n/a

n/a Name n/a

n/a VersionIdentifier n/a

instruction TaskMethodVersion: n/a Descriptor requiredComponentTy GenericComponent: pe vOid requiredSpecialCompo SpecialComponent: nentType vOid performInWorkCente TaskMethodDefinition: WorkCenter: oid sequence: LocationReference PropertyValue Assignment - assignedPrope rtyValue (PropertyValu eNumeric) workUnitType TaskMethodDefinition: TypeOfWorkUnit: oid workUnitType: ClassificationReference - RubberHammer - TorqueTool - CrowBar - AllenKey - Fixture

9 (10)

consumableType TypeOfConsumable: comsumableTyp oid e: - Screw - Nut elementSheet TaskMethodDefinition: Document: DocumentReference generalDefinitionOid 17 WorkCenter Location n/a Identifier n/a

n/a Name n/a

n/a Descriptor n/a

workUnits ResourceAsRealizedAssignme WorkUnit: oid assignedWorkGroup nt WorkingGroup: oid 18 WorkingGrou Organization n/a Identifier n/a

p n/a Name n/a workingGroupDescripti Descriptor n/a on 19 WorkSchedul Schedule n/a Identifier n/a

e n/a Name n/a

n/a VersionIdentifier n/a

plan ScheduleDefinition: GenericWorkSchedul ScheduleImplementsPlan e: vOid activities ScheduleDefinition: Activity_ActionOrder: ScheduleEntry: oid ScheduleEntryReference 20 WorkUnit ResourceIte n/a Identifier n/a

m n/a Name n/a workUnitType ClassificationReference TypeOfWorkUnit: oid workUnitType: - RubberHammer - TorqueTool - Crowbar - AllenKey

10 (10)