In this research project, modularization will be investigated in the field of different engineering disciplines and in its interdisciplinary impact. Various experts are interviewed to reconcile academic research and modularization in practice as part of this research project. On the one hand, different strategies and tools are presented and on the other hand, metrics for the optimization of modular architectures are shown. This research project aims at the comparison of different modularization approaches and the discussion of interdisciplinary modularization supported by views from several experts.
The challenges of customizing production, meeting shorter innovation cycles, anticipating volatility in demand patterns that are diffcult to predict, and selling products at competitive production costs in different local markets are forcing companies to adopt innovative production concepts. Modularization is an essential way to reduce internal complexity and costs and represents a central strategy for today's companies by dividing a whole into parts called modules. The increasing diversity in production and the growing influence and interconnectedness of different engineering disciplines within the product architecture make modularization a multidimensional optimization problem. Numerous different strategies and tools come into the picture during the formation of modular product structures.
Index
1 Introduction
1.1 Context and Motivation
1.2 Problem Statement
1.3 Research Objective and Goals
1.4 Contribution and Expected Results
1.5 Structure of the Work
2 Foundations of Modularization
2.1 Variant Management
2.2 System Architecture
2.3 Modular and Integral Product Architecture
2.4 Types of Modularity
2.4.1 Functional and Physical Independence
2.4.2 Interface and Main Unit
2.5 Module Concept in Different Engineering Disciplines
3 Goals and Chances of Modularization
3.1 General Requirements for Modularization
3.2 General Possible Advantages and Disadvantages of Modularization
4 Expert Interview and Modularization in Practice
4.1 BasicInformation
4.2 Evaluation of the Expert Interview
5 Methods and Strategies for Optimization of Modularization
5.1 Abstract Procedure for Modularization
5.2 DesignStructureMatrix(DSM)
5.3 Modular Function Deployment (MFD)
5.4 Management Engineering Tool for Unified Systems (METUS)
5.5 PuLSE-Eco for Assisting Modularization
5.6 Further Assistance Tools
5.6.1 Change Impact Analysis
5.6.2 Complexity Management
5.6.3 VariantTree
5.6.4 Roadmapping
6 Metrics and Performance Indicators in Interdisciplinary Mod ularization
6.1 Hardware Modularization
6.1.1 Important Areas of Application
6.1.2 Typical Metrics
6.1.2.1 CPI/CPN-Method
6.1.2.2 Coupling Index (CI)
6.2 Software Modularization
6.2.1 Important Areas of Application
6.2.2 TypicalSoftwareMetrics
6.2.2.1 RelatedWork
6.2.2.2 Hiding and Inheritance Factors
6.2.2.3 Coupling Factor
6.3 Interdisciplinary Modularization
7 Conclusion
7.1 Summary and Assessment of Contribution
7.2 Suggestions Future Processing
Appendix
References
The appendix has been removed by the editors for copyright reasons
Abstract
The challenges of customizing production, meeting shorter innovation cycles, anticipating volatility in demand patterns that are difficult to predict, and selling products at competitive production costs in different local markets are forcing companies to adopt innovative production concepts. Modularization is an essential way to reduce internal complexity and costs and represents a central strategy for today's companies by dividing a whole into parts called modules. The increasing diversity in production and the growing influence and interconnectedness of different engineering disciplines within the product architecture make modularization a multidimensional optimization problem. Numerous different strategies and tools come into the picture during the formation of modular product structures. In this research project, modularization will be investigated in the field of different engineering disciplines and in its interdisciplinary impact. Various experts are interviewed to reconcile academic research and modularization in practice as part of this research project. On the one hand, different strategies and tools are presented and on the other hand, metrics for the optimization of modular architectures are shown. This research project aims at the comparison of different modularization approaches and the discussion of interdisciplinary modularization supported by views from several experts.
1 Introduction
1.1 Context and Motivation
The increasing globalization in dynamic competitive environments and the continual entry of new competitors require progressive changes with adaptations of products and production processes. Constant differentiation of customer wishes requires manufacturers to offer an even greater and greater variety of products. New technology and simplified production processes also promote increasing variety in today's products 1. Customers often want to configure their products themselves, making efficient production more difficult due to a greater number of possible configurations. A deliberate expansion in the range of products and services, as well as the associated increase in innovation dynamics, is consequently occurring 2. This variety in the product range demonstrates the necessity of a holistic and continuous examination of the product architecture. It becomes necessary to manage the product architecture in such a way that the internal process complexity is kept as low as possible.
Manufacturers aim to produce as many different end products as possible with as few different individual basic components as possible. Following mass customization, individual customer needs should be served, with production costs only slightly higher than those of producing a standard product. Individualization is achieved by varying a small number of features of the product, which are nevertheless decisive from the customer's point of view. From few combinable building blocks, called modules, the task is to create a large number of similar products during the process of modularization. Nevertheless, the primal objective is to create many product variants with the lowest possible development and production effort and cost 3. For reasons of cost and time, it is typically not feasible for developers to develop a new variant from scratch for every new product and therefore, it is necessary to reuse what has already been developed. The product line belongs to one of the powerful reuse approaches and refers to a set of products that share several characteristics 4. Individual products within the product line are considered as variants. The more variability a product line has, the more flexible the development of customer-specific products is and the more different products can be developed 4. For reasonable variant decisions, a company needs a sophisticated variant management with a control instrument to meet the risk of increasing complexity and associated costs 2. This results in individual requirements for the design of the product architecture. Modular product architecture is the basis for a product range that is both rich in variety and cost-effective to implement. The great challenge during the production process, which is characterized by changes and uncertainties, is to master the complexity of the product 5. A fundamental approach to managing complexity in product design is reducing the number of different elements through modular product architectures without sacrificing economies of scale 5.
Increasing product diversity in the market as a result of competitive pressure has led to more complexity 6. Since today's products and systems interact not only with mechanical and electrical components but also via software, human-machine interfaces and the Internet of Things (IoT), the term multi-disciplinary complexity describes the scene aptly 7. Influences from various engineering disciplines make systems engineering challenging to master and represents a critical success factor for companies' competitive advantage. Each field of science and engineering defines and views complexity in different ways 5. Multi-disciplinarity causes problems that were non-existing when products were mono-disciplinary because multi-disciplinarity not only significantly increases the complexity of products but also the product development process 5. Furthermore, the increase of electronic components and associated embedded software enable a variety of functions but further complicate the product architecture and thus the process of modularization 2. Hence it is imperative to manage product structures appropriately. In particular, concepts of modularity have been advanced as effective strategies to offset some of the increasing complexity 5. In the context of this work, the modularization process consists of designing and optimizing suitable modular product architectures.
1.2 Problem Statement
The modularization process typically involves different engineering perspectives, i.e., mechanics, electrics/electronics and software. Therefore modularization must be considered in a context-related manner and brought into a coherent overall view. The multitude of disciplines such as mechanics, electrics/electronics and software in today's innovative products with their interactions complicate the process of modularization. Modularization is subject to different requirements, and the optimization process of modular structures typically differs between hardware and software. Improving and optimizing product architecture for the modularization process involves changing, merging, splitting modules, redesigning and standardizing interfaces 8. The implementation of a modular product architecture requires a high level of technical expertise, a great deal of coordination and is usually much more costly in the early steps of development compared to a classic design 9. During modular structures development, especially architecturerelevant requirements must be prioritized, documented and constantly checked for fulfillment 10. Companies also face the challenge of integrating the extensive use of modules into the development process and the necessary acceptance and understanding among employees in organizational terms. Companies must develop modular product architectures from numerous possible approaches and strategies while considering various aspects and restrictions. Thus, it is essential to present the different requirements for modularization and also present possible approaches and strategies for addressing and solving this problem.
The central point of this work is to give an overview and clarity about different engineering disciplines with their approaches to modularization. In particular, it is interesting how an interdisciplinary approach for modularization, respective building modular structures should look like. Furthermore, various experts are interviewed in this research project to provide possible solutions concerning this problem.
1.3 Research Objective and Goals
Now that the problem statement has been clarified, we want to derive the research questions. To ensure a sustainably stable modular product architecture, it is necessary to understand the process of modularization, including its methods and strategies for different engineering disciplines as well as their interdisciplinarity and their interfaces. In this work, modularization is investigated, in particular between hardware and software areas. On the one hand, we will see different methods and tools which determine the process of modularization. On the other hand, different metrics will be shown that evaluate and optimize modular product architectures in the hardware and software domains.
The following research questions (RQ) form the crystallization point of the research project and reflect the inspiration for this work:
- RQ1: What methods and strategies of modularization exist in different engineering disciplines?
- RQ2: How to evaluate and optimize modularization in hardware and software components?
- RQ3: What is essential in an interdisciplinary optimization of modularization?
1.4 Contribution and Expected Results
Based on the identified research questions the expected results of the project are described in detail next. The following points summarize the contribution of this research project:
- A summary is given of several expert interviews that discuss the problem mentioned above.
- Furthermore, an overview of different methods and strategies of modularization in different engineering disciplines is given.
- Various metrics and performance indicators for modularization are presented for the hardware and software area. In particular, a categorical overview of numerous metrics in the software domain is presented.
- In addition, the PuLSE-Eco approach developed by IESE (ger.: FraunhoferInstitut für Experimentelles Software Engineering) in Kaiserslautern is used as an assistance tool for modularization procedures.
- A proposal for an interdisciplinary modularization approach is also part of this research project.
Thus, this project's primary goal is to understand and bring together different approaches, strategies, and methods for building modular structures from various engineering disciplines. To enable the reader to follow the contribution and expected results, a rough outline of the work is given in the following.
1.5 Structure of the Work
The present work has the following structure. In Chapter 2, we regard the variant management with the resulting necessity of describing the system and product architecture. Modular product architecture will be distinguished from integral product architecture and the term module is specified for different engineering disciplines. Furthermore, we will see different classification approaches for modular structures. Chapter 3 shows general requirements for successful modularization with possible available advantages and disadvantages of these modular structures. In this context, we will address the relationship between the formation of modules and the resulting complexity of the system. The next chapter presents the results of expert interviews to provide a practical reference. Concerning RQ1, in the fifth chapter, we will see various methods and strategies for modularization in the engineering disciplines. The MFD (Modular Function Deployment) approach and the METUS (Management Engineering Tool for Unified Systems) approach will be topics. In addition, IESE's PuLSE-Eco (Product Line Software Engineering - Economic Scoping) approach is shown as a support tool for the modularization process. Chapter 6 will show how to evaluate and optimize modular product architectures in hardware and software areas to address the second research question. We will present various metrics that can assess and optimize modular product architectures. Since modules in practice often consist of hardware and software components, interdisciplinary modularization is discussed at the end of this research project to answer RQ3.
2 Foundations of Modularization
The second chapter describes essential basic terms in the field of modularization, respectively the formation of modular structures. According to the research project's aim, the focus is on the detection of optimization potential in modularization. Consequently, it is necessary to research and understand the concept of modularization first. Product architecture is specified and a distinction between modular and integral architectures is explained. Furthermore, we will learn about different modularization types and which engineering disciplines are generally decisive for building modular structures.
2.1 Variant Management
The growing global market must always be competitive and offer goods and services that differ in design and innovation. As a result, products range from the simplest to the most extensive and most complicated products such as household appliances, vehicles and airplanes. The extreme increase of product variants in recent times is due to various causes. External causes, such as society changes, technical progress and changing market conditions, as well as internal causes, likewise competitive strategy, information deficits or organizational deficits, lead to an expansion of the spectrum of variants 11. Variety is not always worthwhile because developing many variants often leads to a deterioration of the cost structure. An increase in variant diversity results in complexity costs and quantity degression effects dwindle, with eventually variant-induced disproportionate overall cost increases 11. Variety management plays a significant role for companies that pursue a differentiation strategy and offer various variants that drive complexity and costs 12.
In this way, variant management tries to find the right variants that exactly matches the needs and customer requirements. Design for variety is a design strategy to satisfy individual consumer demands, gain market share, and stay competitive despite increased product variety 7. It includes many structured methods to reduce the impact of variety during the design process of a product 13. Modern systems and products have many thousands of parts and become more complex with the number of variants. To understand these numerous variants, a precise description of systems respective products and their architecture is necessary. It is worth noting that the terms system and product architecture can be found in the literature, but they mean the same to each other 93 and can therefore be used synonymously.
2.2 System Architecture
A system is an abstract, specific and explicitly from its environment separated object 14. The part that is not in the system is the environment and interfaces separate system and environment. An interface is a boundary across which two independent entities interact and communicate with each other 15. An interface contains operations that the component provides for the environment (exported) or uses by the environment (imported). Systems compose system components or subsystems that can have various relationships with each other and with the environment. Systems can be decomposed to any extent with increasing effort and growing complexity. Elements are basic components of a system that cannot be further decomposed. The respective objective of the system formation determines the degree of decomposition. In material systems, the limit of decomposition is at the subatomic level, where no further distinguishment is possible 16.
Thus, the decomposition makes it possible to establish a hierarchy of subsystems and elements and reveal the system's basic structure. Underlying relationships and hierarchical structures determine the structure of the system, known as system architecture. The architecture enables the development of a system based on a division of labor 17. The objective of architecture is to guarantee that the system meets the requirements, is robust to changes and communicates its function through its form 18. The software architecture for a software system describes software components and their visible properties and relationships among them. A system architecture comprises the software architecture and additionally describes the carrier system's structures, i.e., hardware, networks, operating systems and other runtime environments involved 17.
Industrial products are also kind of systems. Mechanical engineering, electrical engineering and electronics have different methods of development, but their commonality, as well as their origin, lies in the physical world. Software is an independent functional carrier in the overall system and is taking on an increasing share. Nowadays, we often talk about cyber-physical systems, as components from different disciplines interact in a product. The system architecture describes the linkage of the functional and physical description of technical systems (products) and determines considerably characteristics such as weight, mountability and the interchangeability of individual components 19 20. The concept of the system architecture specifies the assignment of partial functions to components of a product and their hierarchical arrangement within the function and product structure. The design of the system architecture is of great importance because it determines product functions and central product properties, the module structure, and the product's future variance. These decisions directly impact the costs and efficiency of processing at all subsequent stages of the value chain. The right product architecture enables the reuse of components, reduces the number of variants, reduces assembly costs and leads to efficient supplier structures. Furthermore, it increases profitability and is decisive for the successful process of modularization 21. In the further part of this work, modularization generally refers to products.
2.3 Modular and Integral Product Architecture
Product architectures usually aim at strong relationships within subsystems and weak connections between subsystems. We call product architectures with such a characteristic modular and the subsystems, modules, which are relatively autonomous. The module as a subsystem is mainly independent of changes at higher or lower system levels 22. The internal relationships within a module should be much more developed than their connections to other subsystems.
Components in a modular product architecture should be both functionally and physically relatively independent of each other. A component's functional independence means that they fulfill exactly one function and the interfaces are standardized 23. Physical independence refers to the fact that the components can be physically separated by an appropriate interface design. The integral product architecture has specific interfaces and many complex assignments between functions and components, that are relatively strongly coupled 24. Figure 1 shows the structural difference between an integral and modular product architecture.
Abbildung in dieser Leseprobe nicht enthalten
Figure 1 - Integral and Modular Product Architecture (adapted from 20)
2.4 Types of Modularity
From a technical point of view, there are different possibilities to systematize modular product structures. In the following, we will look at two popular classification approaches.
2.4.1 Functional and Physical Independence
A possible distinction of modular product architectures results when considering the two dimensions of functional and physical independence. Functional independence means that a component performs a specific function independently of the other components. Physical independence describes the fact that interfaces can separate components physically. Four cases can arise with regard to low and high functional or physical independence (Figure 2).
Abbildung in dieser Leseprobe nicht enthalten
Figure 2 - Functional and Physical Independence in Product Architectures (adapted from 94)
Modular product architecture comprises closed units that are both physically and functionally independent. A typical modular product is the traditional personal computer. Here, various components such as the screen, keyboard and hard drive each represent relatively functionally and physically independent units. The integral product architecture is the opposite of the modular product architecture. Components of integral products show strong functional and physical dependencies. Product components each fulfill several functions and have interfaces that are difficult to separate. The tablet computer is an excellent example of such an integral product. Here, the screen performs several functions and it is usually not possible to separate the components physically. In the physical modular product architecture, the product has separable interfaces and functions can only result from the interaction of the components. When components have a strong physical connection, but the functions are relatively independent, a functional- modular product architecture is present. Multifunctional tools typically exhibit this phenomenon. The bottle opener of a Swiss Army knife can be used as a screwdriver at the same time.
2.4.2 Interface and Main Unit
The modular product architecture can also be classified in terms of interfaces and according to a main body part 25. A possible systematic regarding the interface's appearance and an existing main unit leads to four different cases (Figure 3).
Abbildung in dieser Leseprobe nicht enthalten
Figure 3 - Classification by Interface Property and a Main Component (adapted from 25)
With slot modularity, the interfaces between the components are different in each case and the components are therefore not interchangeable in any desired way. A radio unit in a vehicle is such an example. It performs precisely one function and is also physically separated from most other components with a unique interface. Bus Modularity requires a common main unit to which identical interfaces connect all other components. We can see this phenomenon in the computer industry, where plug-in cards such as graphics cards or sound cards can be easily replaced via connectors in the plug-in socket. If there is no common basis to which all components are connected but identical interfaces, this is known as selectional-modular product architecture. Here any part can be connected to any other part and there is no main unit. Thus the entire product architecture is very flexible in selectional-modular product architectures. Lego bricks are an example of such modularity types. If the interfaces are also not identical in addition to a missing main unit, a mix-modularity product architecture is present. This phenomenon occurs in paint production, where many different colors can be produced from just a few raw materials.
2.5 Module Concept in Different Engineering Disciplines
Nowadays, we see the term module in numerous engineering contexts. It has its origins in ancient architecture, defined as a measurement unit for half the lower diameter of a pillar 26. Even in the context of engineering, there exist different definitions for the term module. There are even representatives who reject the definition of the term module 27. With the focus on hardware, a module is an independent, reusable, interchangeable functionally and physically relatively independent unit, with clearly defined interfaces 21. According to software engineering, a module is a group of programs and data structures that collaborate to add expected services to the software 28. Especially in software engineering, the aim is to design modules as ready-to-install, pre-assembled units with a clearly defined functionality 21.
Within the individual disciplines, respective mechanical engineering, electrical/- electronic engineering and information technology, slightly different views influence the term module. Accordingly, there are also different modularization approaches and strategies with different targets. In particular, there are various metrics to evaluate the modularization process depending on the pursued goal. Today's products and systems are becoming more complex and increasingly require interdisciplinary engineering 29. Consequently, it is necessary to consider and discuss modularization in an interdisciplinary way, what is done in Chapter 6.3.
3 Goals and Chances of Modularization
This chapter deals with the general requirements for successful modularization processes at first. For a company, it is always important to represent a comprehensive and attractive basis for business activities. The modularization process, which usually leads to changes of these business activities, needs a lot of planning and has some requirements 30. Especially the specification of the product and the processes acting within modular structures' development are decisive for success.
3.1 General Requirements for Modularization
Modular thinking usually requires new ways of working and paradigm shifts that spread through various business and value creation processes and change existing organizational structures 31. In order to enable the success of modularization, several requirements also seen as success factors are necessary (Figure 4).
Abbildung in dieser Leseprobe nicht enthalten
Figure 4 – Abstract Requirements for Modularization
The business model must ensure that the product portfolio impacted by modularization remains financially worthwhile in the long term. Effects on the target markets and the sales structure and training for the sales staff should be kept in focus all the time. Documentation for the costs during the modularization process is also necessary to guarantee success. It is essential to find a balance in the product portfolio and consolidate as many products as possible in a modular system. In doing so, too diverse requirement profiles should not be combined in one module to avoid performance and cost losses. The business model should also be designed flexibly to enable a long-term service life for the modularized products. Often modularization requires frontloading and may only prove useful over the long term, which means that it is not suitable for all situations 32.
For successful modularization, the production process must also fulfill several requirements. The production process should be standardized and enable a wide range of products with high configurability, high repetition rates and reduced lead times 32. Overall, the production process should have high productivity and high quality. Economies of scale and learning curve effects should be apparent and imply low error rates even after using modular structures 1. The production process should also be expandable through minor production engineering changes and repair processes should be simplified by replacing defective modules 1.
Another important factor for the successful implementation of modularization is the employees. Sufficient employees with adequate expertise in the product must be available who can develop a whole modular system. Before the introduction of modular design, a developer's job is typically more specialized and fragmented 21. The development process becomes more complex through modularization because the developer must be able to combine various requirements in a specific module and have a deep insight into the entire system 33. In particular, knowhow from different engineering disciplines is usually required.
The sales market also plays a decisive role in successful modularization. It is necessary to determine and analyze market requirements concerning customers, competitors, suppliers and value creation processes and incorporate them into product design 31. Converting the customer's voice into solution and variant determining requirement parameters is essential for the successful design of product architectures and product portfolios in the sense of modularization. Such a prediction for the future development of requirements is not easy but necessary to increase the modular system's lifetime. Understanding the sales market is therefore essential to modularize promising technology.
The monitoring of modularization includes the definition of metrics, a set of rules, a reporting system, and consistent controlling of the implementation 31. Modularization leads to changes in business processes and thus requires an expansion to include release and utilization processes, which lead to organizational restructuring 31. Especially IT systems like ERP (Enterprise Resource Planning) and CRM (Customer-Relationship-Management) have to be adapted effectively and early to the changes. Conway's law explains that the communication structure and organizational structure within the organization have a significant influence on the structures of the designed system 33. Thus the design of the interfaces between separate modules is not monolithic but depends on who implemented it. Accordingly, the required system should not be adapted to the organizational structure, but the organizational structure must be adapted to the desired system.
3.2 General Possible Advantages and Disadvantages of Modularization
As the previous requirements for modular product architectures made clear, modularization can offer various advantages, as shown in Figure 5.
Abbildung in dieser Leseprobe nicht enthalten
Figure 5 – Possible Advantages for Modularization
The primary benefits of successful modularization are reduced costs and production times. Development expenditure, as well as the configuration expenditure and the effort for function tests, are expected to be smaller with a meaningful modularization 21. In the area of software engineering, the development costs for releases and program expansions are typically smaller by using modular structures 32. More flexibility is expected, because according to the divide and conquer principle, modules allow an isolated view of the overall system. Especially software systems can be better observed, discussed and tested through a modular structure 21. Besides, reviews can be better targeted and assist the quality assurance 34. The distribution of work is also encouraged by modular structures, as several developers can work on different modules in parallel and in a specialized manner. Extensibility is also a positive point in modular product architectures because relevant points can be easier focused without affecting other components. In particular, this promotes scalability, as learning curve effects coupled with lower error rates usually occur. The same applies to the system's maintainability, where it is possible to handle components independently of one another. Interchangeability, especially for repairs and rework, is also regularly made more manageable in this way. Reuse is another key advantage, as modules can be extracted from one system and used in other projects.
Besides these advantages, modular product architectures also entail shortcomings. The boundary between advantage and disadvantage in the sense of modularization is often very tight. A positive expected effect can even become harmful depending on the degree of modularization and how module product architectures are developed. Typical disadvantages that can occur with modular product architectures are illustrated in Figure 6.
Abbildung in dieser Leseprobe nicht enthalten
Figure 6 - Possible Disadvantages for Modularization
Overmodularization is one of the significant problems since the products often show insufficient differentiation among each other. Often the products are only optimized functionally, while production and procurement views are not sufficiently included in the process of modularization 35. Too many and too small modules that barely have any functions worth mentioning have a negative effect. Overmodularization can also occur in the depth of the product structures. Due to numerous vague defined interfaces across several structural levels, technical and functional instability makes the overall system unmanageable. Furthermore, modularization can lead to suboptimal overall product function since the components' optimal interaction does not run without problems. Also, individual testing of the modules does not guarantee the expected functioning of the overall system. Thus, verification and validation are usually more difficult for modular product architectures 35.
Particularly in the software area, modularization can lead to performance losses. Programming language constructs such as subprograms hide details if they follow a modular structure. References are used to reuse information in other places but need memory and lead to higher computing times. Especially in real-time applications and in critical areas, this can lead to problems 32. In the C++ programming language, pointers are an example of such behaviors. Modularization can also impair performance in the case of physical products. The modularization process often makes products too heavy, large, unwieldy, or energy inefficient 36. The system may also require more resources to remain functional due to modularization. It is also possible that the system becomes increasingly complex with longer communication paths, which reduces controllability and flexibility.
The complex construction and specification of standardized interfaces in modularization can initially result in significantly higher costs than integral product architectures. Typically maintenance and servicing of a modular system can also be complex and costly 21 37. Since modules usually have to cover a considerable number of product requirements, a comparatively more tremendous coordination effort is required. Modularization may also require significant subsequent development (e.g., servo technology). Using modular structures can also result in a new distribution of tasks, which leads to additional workload 32. At least the accumulated cost or effort in modularization context should be lower so that modularization remains appropriate.
Many systems have essential parts whose malfunction automatically leads to a failure of the entire system (single point of failure) 38. In the case of a defect, these cannot easily be replaced either, making the system vulnerable at these parts. A potential danger exists in too extensive modularization with numerous interfaces, where components interfere strongly with each other, which can have a detrimental effect on the overall system.
In the area of software systems, modularization can also cause cross-cutting concerns 39. These are specific requirements whose functionality is implemented repeatedly in several modules. In this case, utterly different core functionalities confront the application in the overall function 39. Cross-cutting concerns can spread and become entangled concerns across all modules 40. Logging is such an example since it must be done in functions and modules, even though logging has little to do with them. Logging thus becomes entangled with these modules. Other examples for cross-cutting concerns include authentication or transaction integrity checking 39.
4 Expert Interview and Modularization in Practice
In the context of this research project, an expert interview is conducted as a qualitative research method. The aim is to achieve new insights and to confirm existing correlations. The expert interview address in particular the research questions RQ1, RQ2 and RQ3 from chapter one. For reasons of better legibility, we use the generic masculine for the interviewed experts. Female and other gender identities are explicitly included as far as it is necessary for the statement.
4.1 Basic Information
The expert interview is a method for answering research questions in a very specific area. Here, the expert can detach himself from the question and surprise or fascinate with details. We will see a question-answer guide with 17 questions. The first part explains the view about the modularization of the expert. During the second part, various questions about modularization are discussed in the expert's activity background. The focus is always on the research questions shown to the expert at the beginning of the interview. The key questions of the interview (excluding the company-specific questions) are shown in the following. For the entire expert interview, please refer to the appendix.
6. How do you define the term module in the context of engineering?
7. What advantages and opportunities do you see in modularization?
8. What challenges and success factors do you see in modularization?
9. Which engineering disciplines are typically involved in modularization?
10. At which level of the product structure does modularization usually take place?
11. Which tools (strategies, approaches, ...) do you use for modularization?
12. How do you evaluate a module or modularization for a product?
13. Is Model-Based Systems Engineering (MBSE) a helpful approach for interdisciplinary modularization?
14. What are the challenges of interdisciplinary modularization? Are there best practices here?
15. Where do you see the main difference between software and hardware modularization?
16. What new issues and questions arise for modularization due to the increasing share of software?
17. Which helpful material / ongoing initiatives do you see, that addresses the topic of interdisciplinary modularization?
4.2 Evaluation of the Expert Interview
Regarding the experts who were interviewed, there are two different kinds of experts. Firstly, there are consultants who advise numerous companies. Secondly, there are experts who work for a specific company. The surveyed experts all have many years of experience and have mostly worked in various sectors of industry. One expert works as a system engineer for a major company in the field of agriculture. This expert emphasized that the term module is used in different ways in the context of his occupation. A product developer from the aerospace sector was also interviewed that sees a module as an easily replaced and decoupled part of the system. In his opinion a module need clear interfaces and should enable exchange and reuse. Most of the experts said that it is essential to distinguish modular understanding in hardware and software. The experts clarified that a module should have very strong interdependencies internally and standard external interfaces between modules. Another respondent explained according to his background that the term module can describe the functionality of different domain layers. A module would combine at least two different domain layers and is less complex than the highest layer. Furthermore, he emphasized that a distinguishment is necessary because there are different understandings in different engineering domains.
Concerning possible advantages, the experts have different opinions, according to their respective activity and application area. Numerous potential benefits were outlined during the interviews, most of them consistent with those from chapter 3. Effort, costs and further development were mentioned at the top of the list. They agreed that the types of benefits for the modularization depend on the domain and the customers, especially the kind of industry or within the specific project. Furthermore, they confirmed that there are many different types of modularization with various possible advantages. At this moment, the specific goal influences which advantage is more important. On the one hand, the experts emphasized the encapsulation of components in different directions by avoiding changes with impacts and reusing the modules in future developments. Moreover, the guaranteed quality and the decreasing development effort expected in terms of modularization are crucial factors. One expert explained that the use of modules in the production process creates confidence and security. People usually already have experience with the relevant area of modules. Thus this can reduce complexity and helps to understand the overall process more deeply. Another reason was the upgrade perspective with clear interfaces and sub-assemblies extracted and attached to the system more efficiently.
[...]
-
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X.