A preliminary study of Models for Manufacturing to define aeronautical assembly lines in 3DExperience

Equation Chapter 1 Section 1 Master Thesis Aeronautical Engineering A preliminary study of Models for Manufacturing to define aeronautical assembly lines in 3DExperience Author: Guillermo Álvarez Murcia Tutor: Domingo Morales Palma Dpto. Ingeniería Mecánica y Fabricación Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 Master Thesis Aeronautical Engineering A preliminary study of Models for Manufacturing to define aeronautical assembly lines in 3DExperience Author: Guillermo Álvarez Murcia Tutor: Domingo Morales Palma Profesor Contratado Doctor Dpto. Ingeniería Mecánica y Fabricación Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 Master Thesis: A preliminary study of Models for Manufacturing to define aeronautical assembly lines in 3DExperience Autor: Guillermo Álvarez Murcia Tutor: Domingo Morales Palma El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2021 El Secretario del Tribunal For my friends and family, Acknowledgements I want to thank to everyone who have made this project possible, directly or not. First, I would like to thank Domingo Morales Palma, for its mentoring, supervision, patience, and knowledge, for trusting me and giving me the chance of doing this, and his big help even in these extraordinary and difficult circumstances. I want to thank my family too, my parents and sister, for cheering me up during the whole project development, encourage me so as to never give up, and hugely contribute to being myself nowadays. Finally, I want to sincerely thank my friends, for their company and support whenever was needed, even during difficult times. Thanks to all. Guillermo Álvarez Murcia Sevilla, 2021 OBJECTIVES his work aims to collaborate in the development of the MfM methodology and to carry out an application focused on the design of assembly lines for aeronautical products. It tries to be an ultimate demonstration of the viability and robustness of the methodology in terms of Ontology building and its practical applicability to complex real-world scenarios. In order to do so, the following objectives have been established: • Develop a solid methodology to create Ontologies from scratch, as part of the Ontology layer inside 3LM method. In particular, it is intended to develop a knowledge representation scheme for the Behavior model, not yet implemented in the MfM methodology. • Develop an application of the MfM methodology for the aeronautical assembly line design process. The application will be implemented through simple models, easy to understand and use, made with open-source and user-friendly software. • Prove the model practical application instancing a specific aeronautical use case. This would be done in two complexity levels, a simple case instanced directly on the model structure, and a more complex one using the commercial collaborative platform 3DExperience, as a result of a hypothetical application of the fully developed methodology. T Table of contents Acknowledgements ix Abstract xi Resumen xii Motivation xiv Objectives xvi Table of contents xviii List of figures xx 1 Introduction 1 1.1 Model-Based Systems Engineering (MBSE) 1 1.2 Ontologies 2 1.3 MBSE Initiatives for manufacturing 3 1.4 Models for Manufacturing (MfM) Methodology 4 1.4.1 3-Layers Model (3LM) 4 1.4.2 Ontology layer 4 1.4.3 Scope model 5 1.4.4 Data model 6 1.4.5 Behavior model 7 1.4.6 Semantic model 7 1.4.7 State of the art of MfM methodology 7 2 3LM Ontology layer building process 9 2.1 Scope Model using IDEF0 Diagrams 9 2.1.1 IDEF0 building blocks 10 2.1.2 Software for IDEF0 diagrams: RAMUS 10 2.2 Data Model using Concept maps 15 2.2.1 Software for concept maps: CMap Tools and Graphviz DOT 15 2.2.2 Data Model enrichment 20 2.2.3 Data Model instancing simulation 21 2.3 Behavior Model using behavior diagrams 23 2.3.1 Software for behavior diagrams: Graphviz DOT 24 2.4 Layers interaction 26 3 Use case: aeronautical assembly line design and planification 27 3.1 Introduction 27 3.2 The product: left wingbox of an aircraft 28 3.3 The wingbox assembly process and resources 32 3.3.1 Stage 0: Components preparation 33 3.3.2 Stage 1: Main assembly 35 3.3.3 Stage 2: Spar riveting 36 3.3.4 Stage 3: Ribs and panels riveting and closure 36 3.3.5 Stage 4: Aerodynamic surfaces assembly and final tests 37 3.4 MfM methodology using 3DExperience 38 3.4.1 3DExperience basics 38 3.4.2 3DExperience as PLM 39 3.4.3 3DExperience as process planning software 39 4 Summary, conclusions and future research 57 4.1 Summary 57 4.2 Conclusions 59 4.3 Future research 59 References 60 Appendix A: Behavior Diagrams 62 Appendix B: Resumen ampliado en español 64 1. Introducción 64 2. La metodología MfM 65 3. Construcción de la capa de Ontología 66 4. Caso práctico: Diseño y planificación de una línea de ensamblaje aeronáutico 71 5. Conclusiones 74 6. Trabajos futuros 74 LIST OF FIGURES Figure 1. 3-Layers Model (3LM) 4 Figure 2. IDEF0 diagram example 5 Figure 3. Concept maps example made using CMap tools (left) and DOT programming (right) 6 Figure 4. IDEF0 building block. 10 Figure 5. Top Level IDEF0 diagram 11 Figure 6. First level IDEF0 diagram, A0: ‘Design the Assembly Line.’ 11 Figure 7. IDEF0 diagram A1: ‘Define As-Planned.’ 12 Figure 8. IDEF0 diagram A2: ‘Define As-Prepared.’ 12 Figure 9. IDEF0 diagram A21: ‘Define Assembly Line.’ 13 Figure 10. IDEF0 diagram A22: Assign resources 13 Figure 11. IDEF0 diagrams hierarchy overview 14 Figure 12. DOT script defining the data model. 15 Figure 13. Concept map for the Data model, compiled from the DOT script. 16 Figure 14. As-Designed definition of the Data model 17 Figure 15. As-Planned definition of the Data model 17 Figure 16. As-Prepared Definition of the Data model 18 Figure 17. Feasibility and Balancing of the Data model 19 Figure 18. CMap Example 19 Figure 19. Enriched data model using DOT 20 Figure 20. Example of Data model instance. 21 Figure 21. Example of Data model instance: detail of As-Designed and As-Planned. 21 Figure 22. Example of Data model instance: detail of As-Prepared. 22 Figure 23. Behavior diagram basic example 23 Figure 24. Behavior diagram for activity “A12 Define the Assembly Sequence.” 24 Figure 25. Behavior diagram for activity “A211 Define Operations.” 25 Figure 26. Behavior diagram for activity “A213 Analyze Operations Feasibility.” 25 Figure 27. Left wingbox 3D view (courtesy by Nogales [16]). 28 Figure 28.Top panel overview and its mechanical unions (red) (courtesy by Nogales [16]) 28 Figure 29. Manhole access example (courtesy by Nogales [16]). 29 Figure 30. Bottom panel overview and its unions (red) (courtesy by Nogales [16]) 29 Figure 31. Front spar (courtesy by Nogales [16]) 29 Figure 32. Rear Spar (courtesy by Nogales [16]) 29 Figure 33. Box insides (courtesy by Nogales [16]). 30 Figure 34. Wingtip Rib detail (courtesy by Nogales [16]). 30 Figure 35. Trusses on the Bottom panel (courtesy by Nogales [16]). 31 Figure 36. Flap fairing (courtesy by Nogales [16]). 31 Figure 37. A400M HTP assembly (courtesy by Benasuly [17]). 32 Figure 38. Panels tooling station detail (courtesy by Benasuly [17]). 33 Figure 39. Panels tooling station (courtesy by Benasuly [17]). 34 Figure 40. Spar tooling station (courtesy by Benasuly [17]). 34 Figure 41. Stage 1 tooling station main frame (upper left), mounted bottom panel (upper right) and blades detail (down) (courtesy by Benasuly [17]). 35 Figure 42. Stage 2 tooling station (courtesy by Benasuly [17]). 36 Figure 43. Stage 3 tooling station (courtesy by Benasuly [17]). 36 Figure 44. FOD detection tooling machine (courtesy by Benasuly [17]). 37 Figure 45. 3DX main groups 38 Figure 46. PPSR Tree. 40 Figure 47. Scope link clarification. 41 Figure 48. As-Planned close-up. 42 Figure 49. Full MBOM. 43 Figure 50. MBOM detail. 43 Figure 51. As-Prepared close-up. 44 Figure 52. Process planning elements. 45 Figure 53. Operation creation detail. 46 Figure 54. Equipment Allocation tooling overview. 46 Figure 55. Workload balancing tool. 47 Figure 56.As-Planned behavior diagrams: MBOM (A11, up) and Assembly Sequence definition (A12, down) 48 Figure 57. Manufacturing tile (and types) command 49 Figure 58. Scope link definition command. 49 Figure 59. Assignment Manager command and interface. 50 Figure 60.Precendence constraint command. 51 Figure 61. A211 and A212 behavior diagrams 52 Figure 62. Workplan creation command. 52 Figure 63. Operation creation command. 53 Figure 64. From left to right, Product Flow, Precedence Link, and Tree Reordering commands. 53 Figure 65. Analysis tools. From left to right, Time Analysis, Workload Balancing, and Premises Usage. 54 Figure 66. A221 behavior diagram. 54 Figure 67. Resource tyopes insertion commands and other useful ones. 55 Figure 68. Resource Analysis tools. 56 Figure 69. Behavior diagram for activity “A3 Generate Documentation.” 62 Figure 70. Behavior diagram for activity “A222 Define Industrial Means.” 62 Figure 71. Behavior diagram for activity “A223 Assign Workers.” 63 Figure 72. Behavior diagram for activity “A224 Analyze Resources Feasibility.” 63 1 INTRODUCTION his chapter introduces the Model-Based Systems Engineering (MBSE) concept, and its implications in the industry. Besides, the Ontology concept and a brief state of art are developed, in order to provide some context in which Models for Manufacturing (MfM) is originated. This methodology is then developed, focusing on the three-layer model (3LM) and its different components. Finally, prior 3LM approaches are acknowkedged. 1.1 Model-Based Systems Engineering (MBSE) According to Ramos et al. [2], Model-Based Systems Engineering “is an emerging approach in the Systems Engineering (SE) field and can be described as the formalized application of modeling principles, methods, languages, and tools to the entire lifecycle of large, complex, interdisciplinary, sociotechnical systems.” A simpler definition is provided by Mellor et al. [3] as “...is simply the notion that we can construct a model of a system that we can transform into the real thing.”. This model-centered approach, which main asset is (usually) a 3D model of the system being developed, contrasts with the traditional document-based methodology. This paradigm shift in how modelling is being made was possible thanks to the emergence and quick improvement of computers. MBSE is currently being applied to several engineering disciplines, from mechanical to electrical, and specially to complex, multidisciplinary projects, such as those accomplished in automotive or aeronautical industries. Ramos et al. [2] also assures that “In the next decade, it is expected that MBSE will play an increasing role in the practice of SE and that will extend its application modeling domains beyond hardware and software systems, including social, economical, environmental, and human-performance components.” MBSE is a methodology that has got more and more important over the past decade and continues to be improved nowadays. One of the main goals of MBSE is to substitute the classic 3D-centric approach and document-oriented information in favor of a simulated model-oriented definition that has several advantages: • The model is the core of the development, in terms of requisites, design, and manufacturing. • Ability to manage complexity and to capture knowledge. • Analysis and trade-off and early detection of issues. T Manufacturing is more than just putting parts together. It’s coming up with ideas, testing principles and perfecting the engineering as well as final assembly. - James Dyson - Introduction 2 2 • Keep consistency between requisites along the lifecycle. • Allow flexibility when changes appear. All in all, it could be said that this model-based approach, unlike the document-based one, allows a much higher level of communication and collaboration between stakeholders and team members, improves design precision and integrity avoiding potential data loss, grants better information traceability, and greatly reduces development risks. Hence, MBSE is an attempt to store the Company knowledge about a specific project into a model, rather than documents, with the cited benefits that this implies. The main disadvantages of this concept are that models are usually developed within a specific software framework, and thus are limited and dependent to the software provider, and that they are also usually made individually for a specific project, not being easily applied to other projects of similar areas. These issues have caused the apparition of the three-layer model (3LM) concept among Models for Manufacturing, which will be detailed later. 1.2 Ontologies In computer science and information science, an ontology encompasses a representation, formal naming and definition of the categories, properties and relations between the concepts, data and entities that substantiate one, many or all domains of discourse. More simply, an ontology is a way of showing the properties of a subject area and how they are related, by defining a set of concepts and categories that represent the subject. Ontologies are, thus, in the core of MBSE methodology. According to Uschold and Gruninger [4], ontology is the term used to refer to the shared understanding of some domain of interest which embodies some sort of world view with respect to the given domain. Every academic discipline or field creates ontologies to limit its complexity and organize data into information and knowledge. New ontologies help to improve problem solving within that domain. Ontology model development is today a global research topic and ontology engineering (also known as ontology building) refers to the set of tasks related to the ontology development process and the ontology lifecycle, the methods and methodologies for building ontologies, and the tool suites and languages that support them. It aims to make explicit the knowledge contained in software applications, and organizational procedures for a particular domain. Ontology engineering offers a direction for overcoming semantic obstacles, such as those related to the definitions of business terms and software classes. In order to assist in the creation, modification or manipulation of ontologies, specific applications, known as ontology editors, have been developed. They commonly use one or several ontology languages, such as OWL (Ontology Web Language). Cited languages are not always intuitive and easy to work with form scratch. So as to be able to fulfil this project, other applications have been used to make the modelling, such as RAMUS, for IDEF0 diagrams, or CMAP Tools for concept maps. This model will then be converted into an ontology language, such as the previously stated OWL. Cited halfway software tools will be treated in depth in the following pages, looking into both functioning and worthiness points of view. 1.3 MBSE Initiatives for manufacturing MBSE has been globally accepted by the aerospace and automotive industry during the last few years, with lots of development and deployment in the Functional Design processes, specially emphasized in the area of systems design. Several research, developments, deployments, and projects has been conducted using MBSE, but only recently the interest is also being redirected to manufacturing. Industrial Design of the product, manufacturing and assembly, balancing lines, resources, configuration and change management, and many other tasks performed during the serial production phase of the lifecycle are now taking the attention of the researchers. The following lines collect some of the first initiatives for such application. Bergenthal [5] defines MBE (Model Based Engineering) in the Model Based Engineering final report for US NDIA (National Defense Industrial Association): “an approach to engineering that uses models as an integral part of the technical baseline that includes the requirements, analysis, design, implementation, and verification of a capability, system, and product throughout the lifecycle ”, already including the manufacturing side of the lifecycle into the MBSE concept. Friedenthal et al. [6] proposed a 2010 status and a 2020 vision on MBSE. Some topics selected for the 2020 vision are applied to manufacturing: • Extends to domains beyond engineering to support complex areas. • Enable the engineer to focus on abstract modeling of the user domain. • Modeling standards supporting high fidelity simulation and real representations. • Extensive reuse of model libraries, taxonomies, and design patterns. • Standards supporting integration and management across a distributed repository. Kulvatunyou et al. [7] present several ontologies for industrial problems that have been a topic of research for several years, most of the projects in the EU Horizon 2020 program have adopted ontology as a component and similarly, in the US NIST (National Institute of Standards and Technology), manufacturing projects also have ontology as a component. Actually, it reinforces the concept of commonality between the ontologies, long term interoperability between the different engineering, manufacturing, and supply chain disciplines. NIST [8] organized a workshop to explore the idea of a framework for curating ontologies, an IOF (Industrial Ontologies Foundry). The goal for the workshop was to identify industry needs, to develop consensus and to identify the issues that need to be addressed to move forward. Workshop participants reported the main reason in seeing an industrial ontology foundry is interoperability, information linking, and formalization of requirements through information constraints, incorporation of business process aspects, and quality and traceability. Several authors are researching on the development and deployment of MBSE methodologies and tools in manufacturing. Aspects like process planning, human resources, robotics, IoT (Internet of Things) among others are recently research topics. 3LM Ontology layer building process 10 10 2.1.1 IDEF0 building blocks The result of applying IDEF0 to a system is a model that consists of a hierarchical series of diagrams which are interrelated. The two primary modeling components are functions (represented on a diagram by boxes) and the data and objects that connect those functions (represented by arrows). Figure 4. IDEF0 building block. Figure 4 shows a single block, in which a Function is represented in the middle and one of each type of data connect it. Each activity is described by a verb-based label placed in a box. Coming from the left, inputs feed the Function. These are data that are used by the function in order to produce the output, being transformed throughout the process. On the upper section come the control elements. These are objects that help when specifying how the inputs turn into outputs, and they remain unaltered during this transformation. Coming from the bottom part there is the mechanism arrow. As is clarified in the figure itself, this kind of data are the resources used in order to produce the outputs. These can be industrial, manufacturing, human or software resources, among others. The logical output is shown as an exiting arrow on the right side, which will then feed the next block or blocks. These are new data generated by the function using all prior objects. The IDEF0 process starts with the identification of the prime function to be decomposed. This function is identified on a “Top Level Context Diagram,” that defines the scope of the particular IDEF0 analysis. From this diagram lower-level diagrams are generated. So as to be able to quickly identify the function’s hierarchy, a coded number is given to each one. 2.1.2 Software for IDEF0 diagrams: RAMUS The selected tool to create IDEF0 diagrams is RAMUS. Its educational version offers a simple and opensource software. It is really intuitive and easy to use, elements are inserted with a single command, and so are the arrows between them. Both Top Level and “child” diagrams are shown in the full IDEF0 anaylisis made on the wingbox assembly case of use, Figure 5-10. Figure 5. Top Level IDEF0 diagram Figure 6. First level IDEF0 diagram, A0: ‘Design the Assembly Line.’ In order to design an assembly line (see Figure 5 and 6), having the As-Design as a beginning point, and taking into account the Company know-how and customer specifications, as well as the Company resources (Manufacturing, CAx software and Quality management) As-Planned and As-Prepared need to be planified. Other parallel activities need to be done, such as generate respective documentation or send change requests in case any issues are detected. 3LM Ontology layer building process 12 12 Figure 7. IDEF0 diagram A1: ‘Define As-Planned.’ As-Planned is modelled with two main tasks, as can be seen in Figure 7: defining the manufacturing bill of material (MBOM) and the assembly sequence, conditioned by the change request proposal, if triggered. Figure 8. IDEF0 diagram A2: ‘Define As-Prepared.’ Figure 9. IDEF0 diagram A21: ‘Define Assembly Line.’ As-Prepared uses As-Planned and the assembly manuals to define the assembly line, its resources and its balancing, as depicted in Figure 8. These also produces the change request proposal. The assembly line is built defining the different manufacturing operations (see Figure 9), that are then grouped in several stations, which need to be configured and sorted. Besides, feasibility need to be analyzed, both operation and station-level, being important in determining the change request conditions. Every of these is again conditioned by the possibility of a former change request trigger. Figure 10. IDEF0 diagram A22: Assign resources 3LM Ontology layer building process 14 14 Resource assignment is made defining each of the different resources (see Figure 10), i. e., Jigs&Tools, industrial means and workers, as well as determining their requirements. Feasibility of these requirements is again needed, being a key factor when launching a change request. As can be seen in Figures Figure 5-10, a detailed scope and boundaries are defined for the practical case presented. Transformation processes, resource and control definition, and feedback mechanisms are presented. In order to better clarify the hierarchy between diagrams, Figure 11 presents an overview of all IDEF0 diagrams. Figure 11. IDEF0 diagrams hierarchy overview 2.2 Data Model using Concept maps Once the scope is set, the next step is building the Ontology core, that is, the Data model. All the Company knowledge is now embodied into the Ontology, via several general concepts and their relations between each other. Because of the desired structure for the Data model, concept maps are chosen as the most suitable option. These diagrams have the same structure as the one pursued in Data model and are easily understandable by anyone no matter its relationship with the Company, nor its previous knowledge about ontologies. 2.2.1 Software for concept maps: CMap Tools and Graphviz DOT As has been said before, two different approaches were made when building the Data model, due to major differences between the two software tools used. At first, CMap Tools was used. Its drag&drop behavior is intuitive and user friendly, and the results achieved are consistent and visually attractive when developing a simple model. The first disadvantage found is its lack of agility when working between iterations. This induced the use of DOT library in Notepad++. DOT is a text-based graphical tool, i.e., the graphs are automatically generated from a text code with the corresponding instructions. While results are still pretty good, its usage is much more advanced. Using DOT means losing some flexibility in the final diagram, in exchange of a much more powerful tool making changes rapidly between iterations. This complementary character between both tools makes them ideal for its serial exploit. First, DOT is used to go through iterations until reaching the desired configuration. Then, so as to present the final result in a prettier way, CMap Tools is used. DOT needs the user to be familiarized with its language. Once the specific commands are learned, its usage is as simple as typing the desired structure for the diagram onto a text file and then compiled and executed by DOT. Therefore, just rearranging code and executing it again lots of diagram variants can be generated immediately, being now remarkable the great value of this tool when iterating the model. One example of DOT scripting and its result can be seen in Figure 12 and Figure 13. Figure 12. DOT script defining the data model. 3LM Ontology layer building process 16 16 Figure 13. Concept map for the Data model, compiled from the DOT script. As can be seen, there is some loss of flexibility, since arrows are automatically connected and cannot be rerouted, but results are quite good. As well as CMap, DOT has some customization features, such as independent background colors for subsections or box coloring, which will be shown in the model enrichment point. The model presented is divided in four different sections, which mostly match the main activities previously shown in IDEF0 main diagrams. These are As-Designed, As-Planned and As-Prepared definition, and an extra module named as Feasibility and Balancing. Figure 14. As-Designed definition of the Data model As-Designed definition process is shown in Figure 14. It is an object made of the Engineering Bill of Material (EBOM), the Assembly Manuals needed to sort said EBOM, and the parts themselves constituting the final product. How these items are related is explained over the concept map itself. Figure 15. As-Planned definition of the Data model As-Planned (Figure 15) is even simpler, at least by itself. It is just the sum of the Manufacturing Bill of Material (MBOM), obtained from the EBOM, and the Manufacturing Sequence used to carry out the Assembly. 3LM Ontology layer building process 18 18 Figure 16. As-Prepared Definition of the Data model As-Prepared (Figure 16) can be a bit more complex, due to the variety of objects involved. As-Prepared embodies all different operations made in order to fulfill the Assembly process. These operations are grouped in stations. The final sorted set of stations constitute the final assembly line. Both operations and stations are responsible for defining the resource requirements, that is, which specific investments are needed to be done so as to perform the different assembly steps. Resources have been grouped in three different categories: Jigs&Tools, Workers (manpower) and Industrial means. Figure 17. Feasibility and Balancing of the Data model As have been said before, one extra module was needed to complete the whole concept map. This is the Feasibility and Balancing one (Figure 17). As can be seen, it is really simple, and is used only to ensure that change requests are triggered, and thus, iterations are made during the assembly line definition development. Change requests can be triggered due to issues regarding the line evaluation itself (non-feasible operations or sequences because of ergonomic reasons, for example) or due to balancing aspects (changing some operations or switching sequences may improve assembly time, for instance). All these sections presented before are not self-isolated, but connected between each other, so that each different module feeds the other. The whole concept map has been presented in Figure 13. CMap tools is, as said before and mainly, easy to use. When opening a new project, it is very fast to introduce the several concept boxes, and so is connecting them using arrows. Blanks are automatically placed and then easily filled. Once every single object is created, they can be rearranged simply by dragging and dropping them in the desired locations. Some customization options are available, such as changing boxes color and outline, arrows type, text font and size or background color for diferenciating sections. An early diagram is shown in Figure 18. Figure 18. CMap Example 3LM Ontology layer building process 26 26 Figure 26 is an example of a parallel task diagram. When analyzing operations feasibility, several aspects need to be considered at the same time before arriving to any conclusion. Three different groups were considered in this case: ergonomics, issues associated to geometrical constraints, and bound to sequence steps. As can be seen, there is a wide variety of diagrams depending on the activity chosen, as well as major differences between rules. Some are mere indications, while others (like the ones on Figure 26) include instanced examples for more clarification. It must be remarked that some of the elements included in these diagrams are not presented in their respective IDEF0 representations (for instance, the CAPP software included in every behavior diagram). This is because once the different models are being developed, new considerations are being taken into account and a refining process begins. In order to build this Ontology properly, an iterative process should start now, iterating around Scope, Data and Behavior model, so that each model feeds the other back, until reaching the final solution. This iterative improvement strategy is out of the scope of this project and should be considered in future research. 2.4 Layers interaction This section aims to explain what a theoretical fully functional 3LM model would do, and how the three different layers would interact between each other. As has been explained during the last chapter, the core of the 3LM is the Ontology layer. It can be thought as a ‘cloud’ in which all the Company knowledge is stored. But this collective knowledge needs to be embodied physically, becoming something tangible. That is what Data layer is meant for. It can be thought, if making an analogy, as if the Ontology is going from the abstract ‘cloud’ storage concept to a tangible ‘hard drive’ one, being now physically stored in databases. And as well as a real hard drive, all this stored information needs to be accessed. Data layer also develops tools so that the Service layer can communicate with the stored data, via interfaces or legacy applications. Finally, Service layer holds software as authoring and simulation tools, visualizers, data analytics and dashboard and space design exploration tools. It uses all the Company knowledge collected in the Ontology layer and stored and served by the Data layer in order to create specific applications and use cases, previously defined as instances. Due to the nature and structure of this model, each layer is decoupled from the others, which in this case allows Service layer to be independent from them. This implies that the Company knowledge would be accesible no matter which software or program is desired to be used, being this one of the strongest advantages of the 3LM modelling philosophy. Due to the huge complexity that developing a fully functional model involves, this work has always and only focused on developing more in depth the Ontology layer. The last functioning dynamic explained is merely academic and should be revised and expanded in future research. 3 USE CASE: AERONAUTICAL ASSEMBLY LINE DESIGN AND PLANIFICATION suming that the whole 3LM model is made, this chapter recreates what an instance made by the Service layer would look like. In future work, different tests will be required using a specific tool that can really demonstrate the viability of MfM in real use cases. Having this purpose on mind, it has been chosen a commercial program that has a close relationship with the aerospace industry and also because of its powerful different tools. Cited software is 3DExperience (from now on, 3DX), by Dassault Systèmes. The use case is already presented, an assembly line design and planification for an aeronautical component, specifically speaking, a wingbox assembly process. A more in-depth depiction of both 3DX and the use case selected will be presented during this chapter. 3.1 Introduction As has been stated before, MfM methodology is currently being implemented and developed from an academical point of view. Several concepts have been tested and refined using Aras Innovator, an open-source PLM software. ARAS, an American developer and publisher of product development software, are dedicated to providing a new approach to enterprise PLM that is as flexible and innovative as the products it helps to create. Aras Innovator is a PLM and PDM solution that will helps bringing innovative products to market quickly and support them throughout the product lifecycle. Aras Innovator is based on a unique, service-oriented architecture that was built from the ground up to be flexible, scalable, and upgradable. It can be easily customized to align with every unique business need and can be seamlessly integrated with the software systems that the Company is already using. It is because of these key characteristics, plus its open-source nature, that was first selected as the playground for carrying out the different tests needed in order to make progress on the MfM field and the 3LM methodology. However, it was also required to prove that MfM models and 3LM methodology are feasible and profitable not only under the academic scope, but on a real use case level. In order to achieve that, a professional, reliable PLM software, widely used in the industry and close enough to the specific use case sector was needed. All these considerations, plus its innovative character, led to choose 3DX as the perfect candidate for such task. It is worth noting that how the implementation of the methodology using 3DX would be made is yet far from A You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete. - Buckminster Fuller - Use case: aeronautical assembly line design and planification 28 28 being sorted out, and the following model presented must be seen as an example used by future research to continue with testing and finally achieve some solid and automatic way of translating the Ontology owned by the Company into a fully functional model-based system. 3.2 The product: left wingbox of an aircraft The use case in this project has not been chosen randomly, but because of its advantages when focusing just on modelling the manufacturing side of the whole work. Both components (left wingbox parts) and tooling were already CAD designed and facilitated, which translates in having already a complete As-Designed and avoiding to incur in extra time and effort. These models have been given directly from aeronautical sources, which is a guarantee that every part of the subassembly, as well as tooling and jigs, are geometrically precise and correct. These files have been modified to delete parts that were not going to be used and enlighten file weights, which means less computing time when working with 3DX and cleaner trees and diagrams for better comprehension. The product is shown in Figure 27, and is going to be disassembled so that the different key components can be shown and detailed. Figure 27. Left wingbox 3D view (courtesy by Nogales [16]). The most user-friendly way of doing such dismantling is removing the very top section, known as the Top panel. This component is made of smaller panels, mechanically joined between each other, shown in Figure 28. These unions are just set, not needing any sort of riveting. Figure 28.Top panel overview and its mechanical unions (red) (courtesy by Nogales [16]) As can be seen, this panel presents several manholes, for an easy access of workers during the main fuel tanks maintenance tasks, structural inspections, etc. So as to remark the space limitation and potential issues concerning workers’ ergonomy, safety and health during its worktime, Figure 29 is presented. Most manholes have edge-protection mechanisms or are supplied via specific tooling. Figure 29. Manhole access example (courtesy by Nogales [16]). Similar to what have been already presented, the Bottom panel, opposed to the Top one, is also made of several smaller subcomponents. Unlike the Top panel, this one presents riveted unions between its parts, being also strengthened using gussets so as to get extra stiffness for the whole assembly. The Bottom panel, as well as its unions, is presented in Figure 30. Figure 30. Bottom panel overview and its unions (red) (courtesy by Nogales [16]) In this case, there are only manholes placed on the outer half of the wing (see Figure 30). Unlike cited parts, Spars are machined from a single preform with stiffners, edges, fillets, supports and accesses. They must take the airflow, facing the bigger loads. Taking into account their relative position in the assembly, they are named as Front Spar, placed on the leading edge, and Rear Spar, located before the high-lift devices. Both spars are shown in Figure 31 and Figure 32. Figure 31. Front spar (courtesy by Nogales [16]) Figure 32. Rear Spar (courtesy by Nogales [16]) These four pieces constitue the so called wingbox, but it needs to be filled with other parts in order to be rigid and stable. These are the Rib, being this wing made of 6 sheet-metal ribs located throughout its span. It is worth noting that this does not mean a total of 12 ribs along the full aircraft span, because the main ribs, the ones joining wings to the aircraft fuselage, are not being taken into account. Figure 33 shows that, as most common aircraft, ribs are enlightened and have some bulkheads used to allocate Use case: aeronautical assembly line design and planification 30 30 systems interfaces. Supports and gussets are shown in blue. These allow a high-precision assembly between Front Spar and Ribs, not being present in the unions with the Rear Spar. Besides, the second rib also has a reinforcement in its union with the Bottom panel, presumably because of its closeness to the wingbox geometric centre. Figure 33. Box insides (courtesy by Nogales [16]). This model also presents the wingtip rib, which is structurally similar to the previous ones, but is bigger in shape and exceeds the Rear Spar, so as to be used as a guide when positioning the spoiler. The spoiler rail is included in the assembly, screwed to the wingtip rib (in grey on Figure 34). This must not be put in place until the whole box is assembled in order to avoid possible damage, and it is not needed until the spoiler assembly and regulation. The wingtip rib has an external support used when mounting the wingtip fairing, is also enlightened and has a bulkhead, possibly so that is possible to do the wiring to the wingtip luminous signaling system. The wingtip rib is shown in Figure 34. Figure 34. Wingtip Rib detail (courtesy by Nogales [16]). In order to solve weight limitations and fuel tank accessibility issues, 13 trusses are added between the ribs (hidden in previous figures). Each truss, made of triangular structures, sums an extra stiffness to the product, while simultaneously letting some flexibility to the structure due to the riveting between truss bars and panels. These bars, their number and lengths, depend on the location of each truss. Figure 35 shows every truss in place on the Bottom panel. Only two of them (marked in red) were facilitated, being the remaining 11 modelled after the model acquisition in a previous work [16]. Figure 35. Trusses on the Bottom panel (courtesy by Nogales [16]). All the previous parts constitute the assembly of the whole wingbox, save the area closest to the fuselage. Due to the assembly procedure, the 3D model also includes a structural mount for the flap movement. The Flap Fairing is a pyramid-shaped support placed in the Rear Spar, being the flap resting on it during take off and landing maneuvers. The fairing is also used as a supporting and sheltering device for the electromechanic actuators, in charge of the movement of the high-lift device on its rail (in grey on Figure 36). Unlike what happens with the spoiler rail, added on the final steps of the assembly procedure, the flap rail is assembled with the fairing. That is because the flap fairing is an independent sub assembly and it is also added at the end of the procedure. This Fairing can be seen in Figure 36. Figure 36. Flap fairing (courtesy by Nogales [16]). Use case: aeronautical assembly line design and planification 32 32 3.3 The wingbox assembly process and resources Once the final product has been shown, the different assembly strategies made, as well as the final approach selected, are presented. Similarly to what happened between the academic example used for making the As- Designed in Figure 20 and the final product previously presented, there is a big difference in complexity between the original assembly procedure used in the academic use in Figure 20 and the final configuration that is going to be developed on the next pages. This is due to the fact that, as has been said before, an aeronautical use case was needed in order to fully demonstrate the benefits and potential improvements that applying MfM implies. Before reaching the final configuration, an initial hypothesis was made, and it has been wanted to have it collected here. This first approach was more typical of an aeronautical common use case, thus seemed reasonable at first. However, key issues appeared and forced to think of a different strategy when making the assembly procedure, that will be presented shortly. At first, it was thought that the very first step consisted of joining both spars and ribs, which would make the ‘skeleton’ of the wingbox. Then, both panels would be riveted to the spars and ribs. In order to exemplify this kind of assembly procedure, Figure 37 is added. As can be seen, both front and rear spars are in place and several ribs are fitted between them. Due to the lack of the panels in this stage of the assembly process, no trusses are mounted yet. After this skeletal structure is made, panels are drilled and riveted to it from the outer side, i.e., riveting direction is defined from the panel to the rib. Figure 37. A400M HTP assembly (courtesy by Benasuly [17]). Howevcr, it can be clearly seen in the 3D model that these kind of procedure does not match with the wingbox nor the industrial means used in the assembly. A number of discrepancies found in both wingbox and tooling are labelled now: • There is physical interference concerning the Rear Spar and the tooling used for positioning the ribs, which indicates that is unfeasible assembling both spars at the beginning of the process. • The trusses’ bars are not able to be riveted from the outside. • Ribs are internally riveted to the panels’ reinforcements and stifffners. These issues led to change the original approach for a new one, that was then developed in much more detail, being made of four different stages, plus a ‘zero’ phase used as a pre-stage. 3.3.1 Stage 0: Components preparation The first one, labelled as stage 0, is the preparation stage. During this one, both panels and spars are being prepared for their latter union. Panels are assembled in their own tooling, their main parts, systems and support devices. These tooling stations (one for the left wing panels and one for the right ones) are symmetrical, being placed in front of each other and only separated by a central corridor. Each tooling station has a section for the bottom panel and another for the top one. A vacuum system is used to position every panel using the control jigs as guide. The tooling station has different tools supports, air supply, electric power and systems control panel. To carry out the riveting in the bottom panel, a semi-automatic drilling machine is installed. This configuration and specifications are clarified in Figure 38 and Figure 39. Figure 38. Panels tooling station detail (courtesy by Benasuly [17]). Use case: aeronautical assembly line design and planification 34 34 Figure 39. Panels tooling station (courtesy by Benasuly [17]). Spars and their supports for flight and electric systems are assembled in their own tooling, being prepared for stage 1. Due to the fact that Rear spars are the component used as a reference for the whole assembly, this preparation stage may sometimes include deburring and final adjustments in said spar. Same as what has been said for the panels tooling, the spars one is symmetrical and is set in the same layout. Unlike panels, that are needed at the same time during the assembly procedure, spars are joined in different moments throughout the sequence, meaning it is possible to use this tooling station at half its capacity, both in terms of manpower and time consumption. A real spar tooling station is presented in Figure 40. Figure 40. Spar tooling station (courtesy by Benasuly [17]). 3.3.2 Stage 1: Main assembly Once the main components are prepared, the main phase is started. In this one, both panels, rear spar, ribs, wingtip and the flap rails are positioned, drilled and riveted. Hydraulic pipes for the flight control system are also added in this stage. The tooling station used in this phase has a main structure (frame) used as a guide for positioning all the different ribs and the wingtip. This frame remains static, while two more mobile structures hold both panels via vacuum and put them in place, using some devices known as ‘blades’ for their positioning. This tooling can be seen in Figure 41. Figure 41. Stage 1 tooling station main frame (upper left), mounted bottom panel (upper right) and blades detail (down) (courtesy by Benasuly [17]). Use case: aeronautical assembly line design and planification 42 42 Figure 48. As-Planned close-up. The necessity of creating a Manufacturing part from the As-Designed part or Manufacturing manuals from the Assmbly ones is justified with Figure 47. This relations are automatically covered once the scope link is created. Speaking of the As-Planned definition itself, Figure 49 shows a full MBOM created using cited app. As can be seen, not only the part list has been created, but also the precedence relations between them, forming at the same time the assembly (manufacturing) sequence. Once the full sequence is created, its components are also defined, that is, every step, and every manufacturing part. Manuals can also be included in this app using the catalog function. Some detail can be also seen in Figure 50. Figure 49. Full MBOM. Figure 50. MBOM detail. Figure 50 is used to explain this dual functioning of the app as both MBOM and sequence definition. Concerning MBOM, it can be seen that there are different icons on the top left of each of the tiles conforming the diagram. These represent the type of manufacturing part that each tile is (one of the object’s attribute, see Figure 48). Both panels are product assemblies, rear spar is a provided part, and wingtip, ribs and trusses are manufacturing kits. Thus, it can be concluded that 3DX can completely define, using just this specific module (as well as its own data structure) the As-Planned Data Model, both objects and their attributes. Now moving on to the As-Prepared definition, Figure 51 (also a close-up of Figure 19) shows its key components, being the definition of the Assebly line, and the Resource Requirements determination. The first one can be created in 3DX using the Process Planning app, while the latter is defined via the Equipment Allocation app. Use case: aeronautical assembly line design and planification 44 44 Figure 51. As-Prepared close-up. First, a close look to the Process Planning app is going to be taken. The assembly line definition implies creating the different operations in the productive chain, grouping them into procedures inside stations, and organizing them to complete the full line. Each of these components need to be defined by specifying their names, types, and times. The Process Planning app is presented in Figure 52. The application allows to create several lines, and insert stations inside them, filling the stations also with operations, and defining the precedence links between both operations and stations. However, not every group of operations (procedure) correspond to a station, nor every operation needs to be inside a station (Figure 52 shows that transportation operations can be considered on their own). Figure 52. Process planning elements. The operation creation process, their definition, time assignment and sorting is shown in Figure 53. This specific model is quite linear, due to the linear character that most aeronautical processes have, but parallel dynamics can also be modelled. Figure 52 also shows that the Process Planning app allows to create different types of operation (general operations, loading, unloading drilling and riveting ones shown), assign them an estimated or calculated time (number under each of them) and sort them creating a product flow. Once every operation is created, the grouping task of them can be made easily, thus creating the procedures, stations and ultimately line presented in Figure 52. Their estimated times are computed just by the sum of each operation time. Use case: aeronautical assembly line design and planification 46 46 Figure 53. Operation creation detail. Now moving on to the resource definition, the Equipment Allocation app is used. Figure 54 shows this app, in which have been represented one of the tooling stations described in Figure 41. The app tree shows more different types of resources, that although were not physically modeled, allow to demonstrate the ability of the softwate of creating different kind of resources, as well as their properties (attributes). Every resource type considered in Figure 51 are created in the app: Jigs&Tools (tooling station MTGR shown), Industrial Means (manufacturing cells) and Workers (both worker and transport created). These resources can be created for each station, and analysis tools (such as workshift creation, workload balancing, and others) can also be applied, allowing to define the Feasibility and Balancing objects in Figure 17. An example of this is presented in Figure 55. Figure 54. Equipment Allocation tooling overview. Figure 55. Workload balancing tool. So, it can be concluded that using both Process Planning and Equipment Allocation apps, the As-Prepared modelling can be fully implemented, as well as the balancing and feasibility analysis objects. Although no more model objects are going to be put here so as to avoid the overextension, it has been checked that the rest of the objects, their attributes and links between them can also be implemented with 3DX apps, and thus, the whole Data Model can be stored using 3DX as the software in charge of the Service Layer. 3.4.3.3 Behavior Model relations This section aims to follow the same model-3DX objects comparison made in the previous one, this time focusing on the Behavior Model. The equivalent behavior diagrams for the As-Planned, As-Prepared (both assembly line and resource assignment) and balancing and feasibility analysis are considered. Behavior models are centered about the dynamics of the process, the ‘how’ things are made. Thus, it seems logic to compare behavior diagrams with the different commands and tools inside the 3DX apps, for they are used to carry out the different actions. The consecution of these actions allows to transform the model’s inputs into its outputs. It is worth noting that due to one of the key requirements proposed for the 3LM models, that is, the ability to be independent of the software used as a Service layer, they are quite vague. This ultimately means that one single activity put in the diagram could sometimes translate into several activites/commands inside 3DX, or the need to accomplish previous activities in 3DX before beginning the 3LM model creation. In the same way as when talking about the Data Model, the first comparison made is focused on the As- Planned. The behavior diagrams concerning this are activities A11 and A12. Both are presented next (although activity A12 was already shown in Figure 24). Use case: aeronautical assembly line design and planification 48 48 Figure 56.As-Planned behavior diagrams: MBOM (A11, up) and Assembly Sequence definition (A12, down) The most immediate comparison, seeing Figure 56, is the mechanism used in each diagram, marked in green. Both diagrams note that their whole behavior needs to be done using a CAE/CAPP software, respectively. It has already been stated that 3DX can be used as both, and much more. So, both mechanism labels could be fulfilled with 3DX. Due to the dual character of the Manufacturing Item Definition app, which defines MBOM and Sequence at the same time, a joint comparison of some of the key activities, noted in red, is going to be made. First, empty manufacturing tiles need to be created, each of them corresponding to a manufacturing part and step. This is an example of what was commented before, an intermediate step when creating the model that is not collected in the activity diagram, because of the general character of said diagrams. The creation of these tiles also defines their type, being them provided parts, assemblies, manufacturing kits, among others, detailed when explaining Figure 50. Tiles creation is simple, just using the corresponding command. Figure 57. Manufacturing tile (and types) command Once tiles are made, on one hand, parts and material list (A11) are gotten via the direct link existing between process and product, which has previously defined as a scope link. This also allows to get the information of the As-Designed (A12). The scope link creation process is simple, being made just by clicking its command, then selecting both process and product nodes in the PPSR tree (Figure 58). Figure 58. Scope link definition command. Use case: aeronautical assembly line design and planification 50 50 Once the scope is created, product information can be exported to the MBOM/sequence definition just by assigning one or more different parts to each tile created. This can be made just by drag&drop or using the assignment manager command (Figure 59). Figure 59. Assignment Manager command and interface. Manuals information can be exported using catalogs and independent 3DX modules, but have not been fully explored, and so they will be excluded for now. Tasks organization is made easily, by drag&drop mechanics, which allow an immediate rearrangement of the different tiles. Once rearranged, precedence links, and thus assembly sequence itself definition, are created using the precedence constraint command, which introduces the blue arrows seen in Figure 49 and Figure 50. Figure 60.Precendence constraint command. Following this procedure and using the commands shown, a full MBOM/Sequence (i.e, the As-Planned as it has been conceived) is generated completely. It can thus be concluded that 3DX allows the execution of the As-Planned Behavior Model using just the Manufacturing Item Definition app. Moving on to the As-Prepared definition, in this case much more diagrams are needed to its full determination. Due to their similarity and intending not to overextend the comparisons, only a few of them are going to be studied. As have been said before, all different diagrams are collected in the Annex, in case they are required. Chosen diagrams for this comparison are also the main ones: Define Operations (A211), Define and Configure Stations (A212), and Define Jigs&Tools (A221). The former two are part of the Assembly line definition and are going to be implemented using the Process Planning app, while the latter is inside the Resource Assignment, and will be implemented with the Equipment Allocation Module. Operations and Stations definition, while initially conceived as separate activities, are carried out simultaneously in the Process Planning app in 3DX, in the same way as MBOM and Sequence are created in Manufacturing Item Definition in the As-Planned. Again, behavior diagrams were designed to be very general so as to not be tied by the use of a single software and need to be slightly modified or adapted when using a specific program when on the Service layer. The procedure followed for this comparison will be identical as the one adopted for the As-Planned. Both behavior diagrams are presented in Figure 61. Summary, conclusions and future research 58 58 aesthetical reasons. Behavior Model tries to save all the activities needed in order to perform certain tasks, the way every concept inside Data Model behaves, the ‘how’ when things are made. Different approaches when building Behavior Models were considered, finally designing a new type of diagram specifically for the MfM methodology. Different color-coded maps were used and named as behavior diagrams, trying to collect the different behaviors of the objects in the models. Behavior diagrams were developed using DOT. Some obstacles were faced during the Ontology building process. Scope Model was developed without major difficulties, but Data Model proved to be really time consuming due to the way concept maps creation process was. This was what motivated the use of a quicker, more dynamic software which allowed to make minor changes with ease, before adopting a final configuration. DOT came to solve this problem, and concept maps definition speed was greatly improved, allowing a larger number of iterations before arriving to the final map desired. Behavior Model was also an issue. A lot of considerations were taken into account when trying to determine how a model which stores object’s behavior should look like. Some much more complex approaches were discarded because they were really difficult to understand if not used to seeing them, and even when creating these models, their degree of abstraction made them useless once some certain amount of time had passed without being in close touch with them. This led to develop an easier approach, trying to keep things simple without impacting in the model accuracy. Behavior diagrams were conceived, and although they have quite improvement margin, they have proved to be good enough for this preliminary study. All these models were created for a specific subject, that is, designing an assembly line. Once models were developed, it was necessary for them to be applied and check their effectiveness. This was done instancing the models into a use case, the assembly of a wingbox. This example was considered due to its aeronautical character, plus its balance between simplicity and understandability. A small number of components was chosen so that the diagrams were not so complex, and estimated values were assigned to the different objects’ attributes. This exercise allowed to have a preliminar, academic instance to demonstrate the model viability. Once this preliminar instance was made, a real instance was developed. This tries to be the theoretical result of what a fully implemented MfM methodology would return. Ontology knowledge, physically stored in the Data layer, would be accessed by any software inside the Service layer, and any desired instance could be made using said software. For this example, due to its closeness to the aeronautic sector, as well as its powerful and versatile tools, 3DExperience was used as the program inside the Service layer. 3DExperience is a very powerful software that can be used both as a PLM program and a process planning one. Due to its particular data structure, it is not clear yet if its structure could be adapted to match MfM one and thus could be used as PLM software. Only its process planning side was explored in this project. The use case selected was now much more complex, aiming to demonstrate the model robustness when working with ‘real’ cases. A much larger number of components, steps and procedures was considered, both in the product and the processes needed for its assembly. All the different tools inside 3DExperience proved to be able to embody all the models, as well as any instance created from them. This demonstration was made by comparison between each object inside the models and functions or characteristics inside the program. 4.2 Conclusions As far as it has been seen, the Ontology building meta-model proposed is solid, versatile, and easy to carry out and understand. It is based on four different models, which is a middle point between complexity and accuracy when modelling. These models are also easy to understand, modify and exploit, without losing their inherent value. The meta-model can be adapted to any degree of detail desired, implemented no matter which software is used, and capable of producing instances with several degrees of complexity. This was proven delivering two different instances, varying their complexity in terms of number of components of the assembly, its steps and resource management. Each instance was modelled using different software, simple tools for the preliminar instance, and a powerful suite for the more complex one. Both instances resulted to be satisfactory in terms of these objectives. Models were made using open-source, clear, simple, and user-friendly programs, and possible integration with powerful commercial software has also proven to be possible. All software shown in this project meet these requirements, and last chapter demonstrates that a powerful set of commercial tools, such as 3DX, is able to completely implement the whole meta-model and the instances generated. 4.3 Future research After the developing of this work, some lines of future research have been opened. It is expected that this project can be a starting point for future projects and more in-depth studies about some of the concepts mentioned in this document. First, Semantic Model was left out of scope in this work, but it is believed that it should not be underestimated when building the Ontology. Having a common glossary so that the different stakeholders can understand each other, avoid concept errors and misunderstandings, and keep pace with the rest of the team when developing new technologies are key for the sake of the Company. A future research should study how this Semantic Model is going to be made, and thus complete the Ontology building meta-model. As have been said before, 3DExperience was chosen, among other reasons, because of its ability to be used as a PLM as well as a process planning software. Although the latter was proved to work when embodying and instancing the models, the former depends on the capability of adapting its own data structure to the MfM one, or the creation of specific interfaces that could translate one into another. A thorough investigation needs to be done so as to check if this is possible and achievable. As a side note, previous CATIA versions have this function, allowing advanced users to create their own applications and adapt them to their very own necessitites. Hence, it is reasonable to think that 3DExperience should have a similar feature. On the other hand, a really complex and accurate model and instance was made when evaluating 3DExperience usage as Service layer software. In order to avoid this great effort to be wasted, more future tests should be made using this instance, achieving new milestones in this MfM development. Finally, during the development of this work it has been noticed that there is an even greater iterative character in building ontologies and its meta-model. Big iterative processes were carried out when refining Data and Behavior Models, but it was also realized that some models changed the perception of how previous models should have been made. This feedback between models suggests a bigger loop of iteration, which was not made in this project. A more in-depth revision of all the models as a whole unit, as well as its refining via iterations, should be made so as to achieve a solid, coherent and accurate Ontology building meta-model. References 60 60 REFERENCES [1] G. Álvarez, Planificación con 3DExperience del proceso de ensamblaje de las compuertas del tren de aterrizaje del Airbus A380, Sevilla: Degree Final Project (in Spanish), University of Seville, 2018. [2] A. Ramos, J. Ferreira and J. Barceló, "Model-Based Systems Engineering: An Emerging Approach for Modern Systems," IEEE Transactions on Systems, Man, and Cybernetics, vol. 42, no. 1, 2012., vol. 42, no. 1, 2012. [3] S. Mellor, A. Clark and T. Futagami, "Modern driven development," IEEE Softw., vol. 20, no. 5, pp. 14- 18, Sep./Oct. 2003. [4] M. Uschold and M. Gruninger, "Ontologies: principles, methods and applications," Knowledge Engineering Review, vol. 11, no. 2, 1996. [5] J. Bergenthal, «Final Report Model Based Engineering (MBE) Subcommittee. NDIA Systems Engineering Division, M&S Committee,» 2011. [Online]. Available: https://www.ndia.org/- /media/sites/ndia/meetings-and-events/3187-sullivan/divisions/systems-engineering/modelingandsimulation/reports/model-based-engineering.ashx. [Last access: November 2020]. [6] S. Friedenthal, R. Griego and M. Sampson, "INCOSE model based systems engineering (MBSE) initiative," INCOSE International Symposium, 2007. [7] N. Ivezic, B. Kulvatuyou, D. Brandl, H. Cho and L. Yan, "Drilling down on Smart Manufacturing - enabling composable apps," Manufacturing Letters, vol. 10, pp. 14-17, Oct. 2016. [8] N. Ivezic, B. Kulvatunyou, Y. Lu, Y. Lee and J. Lee, OAGi/NIST Workshop on Open Cloud Architecture for Smart Manufacturing. Report Number: NISTIR 8124. [9] F. Mas, J. Ríos, L. Menéndez and A. Gómez, "A process-oriented approach to modeling the conceptual," The International Journal of Advanced Manufacturing Technology, vol. 67, pp. 1-4, Jul. 2013. [10] F. Mas, J. Racero, M. Oliva and D. Morales-Palma, "A Preliminary Methodological Approach to Models for Manufacturing (MfM)," in Product Lifecycle Management to Support Industry 4.0, Turin, Jul. 2018, pp. 273-283. [11] R. Rizzi Starr and J. Parente de Oliveira, "Concept maps as the first step in an ontology construction method," Information Systems, vol. 38, no. 5, pp. 771-783, May. 2012. [12] M. Austin, P. Delgoshaei and A. Nguyen, "Distributed System Behavior Modeling with Ontologies, Rules, and Message Passing Mechanisms," Procedia Computer Science, vol. 44, pp. 373-382, 2015. [13] A. Szejka, O. C. Jr. y F. Mas, «A Preliminary Method to Support the Semantic Interoperability in Models of Manufacturing (MfM) Based on an Ontological Approach,» de Product Lifecycle Management in the Digital Twin Era, Moscow, Springer, 2020, pp. 116-125. [14] D. Morales-Palma, F. Mas, J. Racero and C. Vallellano, "A Preliminary Study of Models for Manufacturing (MfM) Applied to Incremental Sheet Forming," in Product Lifecycle Management to Support Industry 4.0, Turin, Jul. 2018, pp. 284-293. [15] F. Mas, J. Racero, M. Oliva and D. Morales-Palma, "Preliminary ontology definition for aerospace assembly lines in Airbus using Models for Manufacturing methodology," Procedia Manufacturing, vol. 28, pp. 207-213, 2019. [16] R. Nogales del Valle, Definición con 3DExperience de la secuencia de montaje del cajón del ala de una aeronave, Sevilla: Degree Final Project (in Spanish), University of Seville, 2020. [17] S. Benasuly Labuz, Utillaje de Montaje, ETSI, Seville, Mar. 2017. [18] J. Ríos, F. Mas and J. Menéndez, "A review of the A400M Final Assembly Line Balancing Methodology," in AIP Conference Proceedings - 4th Manufacturing Eng. Society Intl. Conf., Cádiz, Sep. 2011. [19] R. Pinquié, L. Rivest, F. Segonds and P. Véron, "An illustrated glossary of ambiguous PLM terms used in discrete manufacturing," International Journal of Product Lifecycle Management, vol. 8, no. 2, pp. 142- 171, Jul. 2015. Appendix A: Behavior Diagrams 62 62 APPENDIX A: BEHAVIOR DIAGRAMS All behavior diagrams not shown in this work are collected here, for any reader to consult. Figure 69. Behavior diagram for activity “A3 Generate Documentation.” Figure 70. Behavior diagram for activity “A222 Define Industrial Means.” Figure 71. Behavior diagram for activity “A223 Assign Workers.” Figure 72. Behavior diagram for activity “A224 Analyze Resources Feasibility.” Appendix B: Resumen ampliado en español 64 64 APPENDIX B: RESUMEN AMPLIADO EN ESPAÑOL 1. Introducción Models for Manufacturing (MfM) es una aproximación preliminar hacia una metodología que pretende suministrar una serie de procesos, métodos y herramientas asociadas para ayudar a los ingenieros a cimentar la disciplina de la fabricación en un contexto basado en modelos. Es una propuesta de un equipo multidisciplinar de la Universidad de Sevila, en colaboración con profesionales del sector aeronáutico. El MfM está actualmente en fases tempranas de desarrollo. La metodología MfM recae en el desarrollo de un marco de referencia, el 3LM (3-Layers Model: capas Data, Ontology y Service), basado en la definición de una ontología de fabricación y habilitando las capacidades de simulación, comportamiento y análisis, priorizando el conocimiento de la empresa. La capa de Ontología es el núcleo del modelo. Contiene todos los procesos de la compañía y su alcance, los modelos de datos y semántica, y las simulaciones asociadas y requisitos de comportamiento. Antes de la realización de este trabajo existían propuestas para los modelos Scope y Data, pero no para los Behavior y Semantic. Este proyecto pretende colaborar en el desarrollo de la metodología MfM. Las principales contribuciones en este trabajo son: (1) se propone un esquema de representación de conocimiento para modelar el comportamiento del sistema bajo estudio; (2) se analiza la aplicación de la metodología al proceso de diseño de una línea de ensamblaje aeronáutico, y (3) se construye un modelo del proceso de ensamblaje de un cajón de ala de una aeronave en 3DExperience, para que pueda ser usado en futuras pruebas de rendimiento de la metodología MfM. Como se ha comentado, la metodología MfM surge como una modificación a los enfoques clásicos de la ingeniería de sistemas basada en modelos (MBSE), siempre centrada en los procesos de diseño, orientándose en este caso hacia la fabricación. Esto permite tener una metodología de aplicación durante todas las fases del ciclo de vida del producto, en contraposición al MBSE, solo usable durante el diseño funcional: Diseño Industrial, Producción/Fabricación en serie, y Soporte en servicio. En productos como una aeronave típica, estas fases pueden suponer más del 75% de su ciclo de vida total. Durante el mencionado ciclo de vida, en el mundo aeronáutico se emplean cuatro tipos de software diferentes para generar, modificar, gestionar o emplear los datos: Computer Aided applications (CAx), Product Lifecycle Management (PLM), Enterprise Resource Planning (ERP) y Manufacturing Execution System (MES). Toda esta información se encuentra dispersa en bases de datos propias de cada programa. Aunque cada uno de ellos garantiza la consistencia de sus datos, no puede decirse lo mismo de los datos empleados entre distintos softwares. Hoy en día, la mayoría de los programas empleados necesitan de interfaces intermedias para su interoperación, a menudo de terceros, o mediante hojas de cálculo de Excel, lo que compromete en gran medida la robustez de los datos empleados y las simulaciones llevadas a cabo. La solución que se propone pasa por emplear el marco 3LM dentro de la metodología MfM. Se pretende crear una Ontología común para definir, gestionar y mantener el conocimiento de la empresa, así como el metamodelo que permite generar la metodología para la construcción de dicha ontología. Dicha línea está en fases tempranas de desarrollo, y ha sido aplicada con cierto éxito en algunos escenarios industriales, obteniéndose resultados prometedores. 2. La metodología MfM La metodología MfM propuesta se basa en un modelo de tres capas, el 3-Layer Model. Este modelo garantiza la independencia entre capas, consiguiendo que las capas de Datos y Ontología puedan quedar aisladas, lo que implica la capacidad de definir la ontología sin ninguna interacción con las capas de Datos o Servicios. Esto se traduce finalmente en la obtención de una ontología que puede ser operada, modificada y preservada con independencia del software que se quiera emplear para su consulta, lo que dota al modelo de una enorme flexibilidad e interoperabilidad. En resumen: • La capa de Datos recoge todas las bases de datos e interfaces, nubes, y varios otros. Dentro de ella están las bases de datos que almacenan la información instanciada usando la capa de Ontología. • La capa central es la de Ontología, y es el núcleo del modelo. Recoge todo el conocimiento de la compañía, sus procesos, alcance, modelos de datos y semánticos, y las simulaciones asociadas y requisitos de comportamiento. Debido a su importancia, el proyecto se ha centrado en desarrollar esta capa, profundizando en la definición de cada uno de sus componentes, y dejando las capas de Datos y Servicios para trabajos futuros. Dicho proceso se realiza haciendo uso de las aplicaciones definidas anteriormente. • La capa de Servicios comprende los programas, herramientas, softwares, simuladores, analizadores de datos, o dashboards empleados. Estos servicios se usan gracias a la información almacenada en la capa de Datos, instanciada según la capa de Ontología. Modelar el know how completo de una empresa no es una tarea fácil, ya que es de gran complejidad y grado de abstracción. Para poder almacenar este conocimiento, se ha dividido el modelo de la ontología en cuatro componentes principales: Scope model, que pretende definir el marco de referencia de la ontología, así como sus reglas básicas; Data model, que recoge los diferentes conceptos conocidos por la empresa, y las relaciones que existen entre ellos; Behavior model, que da a estos conceptos y relaciones un carácter dinámico, como se comportan, y su evolución en el tiempo; y Semantic model, que busca crear un glosario de términos técnicos común que evite los malentendidos causados por las diferentes interpretaciones del lenguaje y las distintas acepciones de algunos conceptos clave en los campos de interés. • Scope Model Para poder crear una ontología acerca de cualquier campo, lo primero es definir su scope, esto es, su alcance, cuales van a ser sus limites y el grado de detalle que se va a dar a los contenidos de la ontología. Esto asegura que cada una de las partes interesadas trabaja bajo un mismo marco de referencia cuando se construye la ontología, y evita la persecución de cada vez más detalle en los modelos, concepto conocido en desarrollo del producto como feature creep y que en este caso podría llamarse detail creep. La definición del Scope model se ha hecho con diagramas IDEF0, porque permite crear diagramas simples, limpios, claros y fáciles de entender a simple vista. • Data Model Después de crear el Scope Model, se crea el llamado modelo de datos o Data Model. En este modelo es en el que se almacena como tal la información que posee la compañía. La técnica más común para esto es usando representaciones gráficas, es decir, haciendo uso de la teoría de grafos, concretamente usando mapas conceptuales. De este modo, los diferentes conceptos se guardan dentro de formas, y las relaciones entre ellos se señalan visualmente incluyendo flechas que los conectan. Normalmente a dichas flechas se añade un conector (habitualmente un verbo), que dotan de mayor información a la conexión. Para que estas representaciones sean efectivas, es necesario crear primero una codificación de colores y formas dentro del mapa conceptual. Inicialmente, el software empleado fue CMAP tools. No obstante, debido al alto carácter iterativo que presenta la creación del modelo de datos, con el fin de agilizar dichas iteraciones, se optó por emplear de forma complementaria DOT. Mientras que el primero es un programa basado en una interfaz (GUI) y mecánicas drag&drop, que lo hacen fácil de usar y altamente personalizable, el segundo es un compilador de gráficos basado en texto. Si bien su personalización de los mapas es algo más limitada, permite generar mapas de calidad suficiente sin más que escribir un pequeño script, y lo que es más importante, realizar modificaciones sobre ellos con muy poco esfuerzo, lo que ha permitido que las Appendix B: Resumen ampliado en español 66 66 iteraciones entre versiones del modelo de datos se lleven a cabo con gran rapidez, algo impensable empleando CMAP Tools. Tras la creación del modelo de datos, este puede ser desarrollado en más detalle. Se dice entonces que el modelo se ha enriquecido con nueva información. Puede añadirse cuanta se desee, siempre teniendo en cuenta no sobrepasar lo establecido anteriormente en el Scope Model. Este enriquecimiento pasa por añadir nuevos conceptos que, aunque inicialmente no se creen necesarios para la definición del modelo, pueden aportar información extra a la hora de dotar de detalles. Además, dichos conceptos pueden poseer atributos, propiedades usadas para definir mejor cada concepto. • Behavior model El Data Model agrupa muchos conceptos y sus relaciones, conformando el conocimiento de la compañía. Sin embargo, estos conceptos y sus relaciones causales deben ordenarse de acuerdo a algún criterio. Por ejemplo, pensando en un proceso de ensamblaje, aparte de conocer qué partes han de ensamblarse y sus posiciones relativas, también ha de saberse la secuencia de ensamblaje, esto es, el orden temporal en el que las piezas se unen entre sí, y también cómo se llevan a cabo exactamente las operaciones de ensamblaje. Estos “cuándos” y “cómos”, entre otras cosas, se recogen en el modelo de comportamiento o Behavior Model. En esencia, almacena cómo se comporta cada concepto y relación dentro del Data Model, con respecto a sí mismo y a otros. Por tanto, el modelo de comportamiento debe ser una evolución del modelo de datos, y utilizar a este último como punto de partida. Se han seguido diferentes estrategias para obtener un modelo de comportamiento que, si bien fuese simple y fácil de entender, permitiese también cumplir los objetivos marcados para el mismo. Finalmente se opta por lo que se ha denominado diagrama de comportamiento. Debido a sus similitudes, se ha empleado DOT como herramienta para modelar estos diagramas, al igual que con los mapas conceptuales. • Semantic model Es necesario crear un modelo semántico al construir una ontología. Como se ha comentado, el principal objetivo de crear una ontología es preservar el conocimiento de la compañía de forma que pueda ser empleado por cualquiera, desde cualquier lugar, haciendo uso de cualquier software. Para garantizar eso, es imprescindible desarrollar un lenguaje común de forma que miembro del equipo que vaya a usar la ontología entienda del mismo modo (tenga la misma acepción) de cada concepto y definición cuando se hable de cualquier tema. El modelo semántico pretende conseguir un total entendimiento entre las partes interesadas, evitando que los malentendidos se produzcan y proporcionando un marco semántico común. Este modelo se queda fuera del alcance del proyecto, y debe ser desarrollado en trabajos futuros para completar el modelo de la ontología. 3. Construcción de la capa de Ontología El resultado de aplicar IDEF0 a un sistema es un modelo que consiste en una serie jerarquizada de diagramas interrelacionados. Los diagramas están compuestos por funciones (cajas) y los datos y objetos que las conectan (flechas). Cada función dentro del diagrama puede tener varias conexiones. Desde la izquierda, las entradas son empleadas para producir las salidas, que aparecen a la derecha. Desde arriba, los controladores ayudan a especificar como las entradas se convierten en salidas, pero permanecen inalteradas durante el proceso. Desde abajo, los mecanismos son los recursos empleados para producir las salidas a partir de las entradas. Estos recursos pueden ser industriales, humanos, software, etc. Los diagramas IDEF0 se encuentran anidados, de forma que un diagrama padre puede albergar varios hijos, y así sucesivamente, en varios niveles de complejidad. El conjunto completo de los diagramas desarrollados en el Scope model se presenta seguidamente. Appendix B: Resumen ampliado en español 74 74 • Relaciones en el Behavior Model Los modelos de comportamiento se centran en la dinámica del proceso, el “como” se hacen las cosas. Por tanto, parece lógico compararlos con los diferentes comandos y herramientas dentro de 3DExperience, ya que son los que se usan para llevar a cabo las diferentes acciones. La concatenación de estas acciones permite transformar las entradas del modelo en sus respectivas salidas. Cabe destacar que debido a uno de los requisitos fundamentales propuestos para los modelos 3LM, esto es, la capacidad de ser independientes del software que después sea empleado en la capa de Servicios, estos modelos son muy vagos. Esto significa en última instancia que una sola actividad del diagrama puede traducirse en ocasiones en varias actividades o comandos dentro del programa, o necesitan de tareas previas antes de ser acometidas. Puede decirse que la plataforma es capaz de ejecutar a la perfección el modelo de comportamiento del As- Prepared en su totalidad, siendo la conclusión final que 3DExperience puede implementar el modelo completo de Ontología (Scope, Data y Behavior) solamente usando algunas de sus aplicaciones. El uso de herramientas más avanzadas y su funcionamiento conjunto podría definir los distintos modelos con más precisión, detalle y complejidad, pero es algo que se deja para trabajos futuros. 5. Conclusiones El metamodelo de construcción de ontologías es sólido, versátil, y fácil de llevar a cabo y entender. Está basado en cuatro modelos diferentes, lo que está a medio camino entre la complejidad y la precisión cuando se modela. Estos submodelos también son fáciles de entender, modificar y emplear, sin perder por ello su valor. El metamodelo puede ser adaptado a cualquier grado de detalle que se desee, implementado sin importar el software empleado, y capaz de producir instancias de distintos grados de complejidad. Esto se ha demostrado generando dos instancias distintas, variando su complejidad en términos de su número de partes, pasos, y gestión de recursos. Cada instancia se ha modelado usando software distinto, herramientas simples para la instancia preliminar, y una plataforma potente para el más complejo. Ambas instancias han resultado satisfactorias en términos de los objetivos citados. Los modelos se han hecho usando programas open source, claros, sencillos y amigables, y la posible integración con software comercial más potente también ha quedado constatada. Todo el software mostrado en este trabajo cumple estos requisitos, y el trabajo demuestra que una serie de herramientas potentes, como las que posee 3DExperience, es capaz de implementar el metamodelo completo y las instancias generadas a partir de él. 6. Trabajos futuros Tras el desarrollo de este trabajo, se abren nuevas líneas de investigación, que se espera empleen este documento como punto de partida. En primer lugar, el modelo semántico ha quedado fuera del alcance de este proyecto, pero se cree que no debería ser subestimado al crear una ontología. Tener un glosario común que permita evitar malentendidos entre las partes al desarrollar cualquier tecnología se antoja clave para cualquier empresa. Futuros trabajos deberían estudiar cómo realizar este modelo, y completar así el metamodelo de la construcción de ontologías. Como ya se ha dicho, se eligió 3DExperience, entre otras razones, debido a su capacidad de ser empleado tanto como PLM como CAx. Aunque ha podido comprobarse la correcta integración de esta última vertiente a la hora de contener e instanciar los modelos, la primera depende de la capacidad de adaptar la estructura de datos de la plataforma a la especifica que necesita MfM, o bien la creación de una interfaz que actúe como puente entre ambas. Debe llevarse a cabo una investigación exhaustiva para ver si esto es posible o no. Como comentario aparte, se sabe que versiones anteriores de CATIA sí daban la posibilidad de hacer esto, permitiendo a usuarios más avanzados crear sus propias aplicaciones y adaptarlas a sus propias necesidades. Por ello, parece razonable pensar que 3DExperience debe contar con una función similar. Por otro lado, se ha desarrollado un modelo e instancia muy complejos y precisos, a la hora de evaluar el uso de 3DExperience como software para la capa de Servicios. Se espera que este esfuerzo sea aprovechado y que puedan llevarse a cabo futuras pruebas usando esta instancia, con el fin de alcanzar nuevos hitos en el desarrollo del MfM. Finalmente, durante el desarrollo de este trabajo, se comprobó que existe un carácter iterativo aún mayor del inicialmente supuesto a la hora de construir ontologías y su metamodelo. Se llevaron a cabo grandes procesos iterativos cuando se refinaron los modelos de datos y comportamiento, pero también se pudo constatar que algunos modelos cambiaban la percepción de como modelos anteriores deberían haberse hecho. Esta retroalimentación entre modelos sugiere la existencia de un bucle de iteración mayor, que comprende al resto, y que no ha sido incluido en este proyecto. Debería llevarse a cabo una revisión en profundidad de todos los modelos como un todo, así como refinarlo mediante iteraciones. De esta formas, se conseguiría un metamodelo mas sólido, coherente y preciso a la hora de crear ontologías.