Three adjacent, modular machines from a product family consisting of the same configurable modules. Different machine versions were created by configuring the modules differently.
by

Modular strategy - challenges and solutions for the development sector in mechanical engineering

Summary

A few years ago, the topic of modular systems was one of the most important strategic goals for many companies. As current topics such as digital transformation and AI are based on existing data, processes and methods, it is important to critically examine how consistently the idea of the mechatronic modular system has actually been implemented and whether there is a need for action. After all, the introduction of a cross-discipline and cross-location modular strategy changes the way the company works in many respects. The module-based shared use according to the single-source-of-truth approach leads to low-redundancy data structures and, in addition to the modularization of products, also requires technologies for configuration and synchronization as well as new methodologies and organizational adjustments. The modular strategy therefore also inevitably leads to high data quality and a high level of methodological maturity. Both are helpful when it comes to implementing digital transformation and AI topics effectively and efficiently. At the same time, a modular system also requires a minimum level of system support in terms of digitalization. These potential synergies between the modular strategy, digital transformation and AI should be exploited in order to achieve faster and more sustainable results. The following article provides information on the need for action and possible solutions for implementing a mechatronic modular strategy.

Single-source-of-truth instead of clone-and-own

Many companies are convinced that they have already implemented a modular strategy. However, a closer look often reveals a carry-over strategy at product and module level. In new development projects, a decision is made as to which content from a previous project should be carried over in order to reduce costs. In practice, copies are often created during such a takeover, whereby the copied modules are adapted to the requirements of the new project. If the new project is not a successor but a derivative, the original assembly and the adapted variant exist in parallel in the company and in the field. Although this clone-and-own approach produces results quickly, it increases both the complexity costs throughout the company and the risk of unplanned redundant development activities.

The modular strategy, on the other hand, is based on the "single source of truth" principle. Here, a configurable module is developed and versioned. This module is then used by different product families. The user can only select the required variants through configuration. The further development of the modules takes place in parallel and synchronously with the machine projects, so that new requirements from machine projects are also implemented in the module. A systematic evaluation of the optimum degree of standardization is carried out so that new variants are not constantly created during the life cycle of a module. Here, a balance must be struck between oversizing (one-size-fits-all) and high complexity costs (many variants through local optimization).

A modular strategy has three main advantages for the development sector:

  • lower manufacturing costs due to economies of scale,
  • capacity savings by avoiding redundant development activities and
  • shorter time-to-market by adding new versions to a product family or platform.

Integration of software development

Despite the increasing importance of software and electrics/electronics, mechanical engineering is based on physical products that need to be manufactured and assembled efficiently. Managing the supply chain for the often complicated and varied products is challenging - especially with regard to changes - which is why processes for transferring data from design to purchasing and production, often across locations, have been established and refined over many years.

As software is gaining in importance as a product or product component for mechanical engineering, processes and tools have emerged that support the transition from development to commissioning and service for software components in a similar way to physical products. Many of these tools are developed and managed by the specialist department. This has both positive and negative aspects.

Advantages:

The tools are developed by people from the specialist department who know the processes to be mapped in detail. From the department's point of view, no coordination with external bodies is required, which speeds up implementation, at least in the initial phase.

Disadvantages:

  • Complex, redundant developments, e.g. in the area of product configuration
  • Isolated solutions: Each site develops its own tool, which makes standardization across locations more difficult.
  • Permanent commitment of capacity for tool development, maintenance and support
  • Dependence on individuals
  • Decoupling of IT (it never gets to know the internal processes)
  • Solutions not oriented towards long-term IT roadmap
  • Dependencies on IT interfaces that can change at any time
  • Solutions not always technologically state-of-the-art

The sometimes massive amount of shadow IT in the area of software development leads to a parallel world on the process side. This makes it difficult to design, implement and establish an effective cross-discipline and cross-location modular strategy. For the modular strategy, but also for a comprehensive digital transformation, shadow IT must be examined and objectively evaluated in the overall context.

Development - Production interface

Parts lists and routings are among the fundamental data structures in a company. Production cannot take place without this information. When planning systems were introduced in production, product portfolios and company structures were manageable. With increasing cross-location development and global production networks, the framework conditions for the handshake between development and production are changing.

Both areas have different requirements for the bill of materials (BOM). In development, the BOM structure follows the structure of the CAD assembly according to design criteria. In production, on the other hand, the contents of assemblies correspond to the assembly sequence. This may differ from the development view, e.g. if covers for individual assemblies are only installed at the end of the assembly line. If a product is produced at several locations, the assembly process can vary between the plants. One solution is therefore to separate the engineering bill of materials (EBOM) from the manufacturing bill of materials (MBOM). As changes are made to the product and therefore to the EBOM over time for series products, these must be updated in the MBOMs. Without system support, this process is prone to errors, which is why companies use a group BOM as an alternative to avoid data inconsistencies. This universally used BOM is coordinated between development, production and purchasing and is the responsibility of the development department.

In addition to the advantage of consistent data and simple processes and systems, the group BOM concept has serious disadvantages in terms of modularity and digitalization. Assembly-related changes to the BOM must be implemented by the development department as a service for the production department. Production is limited in its flexibility and is dependent on input from Development. This causes unforeseen disruptions in development, and the changes can lead to discrepancies between the CAD structure and the bill of materials. As a result, processes such as the automatic synchronization of parts lists from CAD can only be implemented to a limited extent. BOMs are still created manually, which leads to additional work and increases the risk of errors. The group BOM has a particularly disadvantageous effect on multiple use in the modular system. This is because multiple use requires stable system boundaries. A physical modular system module should include all associated components. This is not always the case with production-driven group BOMs because components can be moved in the BOM structure according to the assembly sequence. In addition, it is difficult to implement location-specific, time-flexible control of changes with the group BOM.

The solution is to separate EBOMs and MBOMs with system-supported synchronization of changes. MBOMs can be created if they are required for production reasons. In this case, they are derived from EBOMs and the components are moved between the MBOMs. For the now separate BOMs, it must be ensured that changes to the EBOM are updated in the dependent MBOMs with system support. This process requires correspondingly powerful tools and organizational framework conditions.

Depending on the IT architecture, the optimal allocation of sub-processes to the PLM or ERP system may differ. The interface between development and production is also conceptually very demanding with regard to variant configuration. The design should be planned, conceived and implemented by an interdisciplinary project team with the support of management.

The introduction of parts list synchronization not only creates the prerequisites for a modular strategy, it also results in numerous synergies with other digital transformation topics, such as the automatic conversion of CAD assemblies for the digital twin.

Terms

The ambiguity of terms quickly leads to misunderstandings and can disrupt collaboration, especially across departmental boundaries. Clear, standardized terms are required, but there is often a lack of clarity, especially in the modular context.

A typical example is function orientation. In electrical design, the term "function" refers to a coherent technical subsystem, regardless of the physical modules to which the components of the function are distributed (e.g. machine bed, e-chain, control cabinet). Mechanical design defines a "functional assembly" as an assembly structured from a development perspective, in contrast to an assembly group structured according to production criteria.

In the area of product configuration, the terms sales feature, technical feature, feature attribute, variant and option are unclear for many players. This lack of clarity is then reflected in the underlying product structures. For example, software projects often use a mixture of physical module, technical feature and sales option to describe the software modules. The development of a cross-location modular software system as part of the mechatronic modular strategy is correspondingly complicated.

One of the major challenges lies in mechatronic modularization. The attempt to define a mechatronic module as a container that contains all aspects of mechanics, electrics and software, including all documents required for planning and documentation, right through to simulation models, is not expedient in mechanical engineering. This is due to the fact that the views and system boundaries of the mechanical, electrical and software disciplines differ significantly. It would therefore be of little use to break down software on the basis of physical module boundaries. Nor does it make sense to divide mechanical assemblies into purely functional groups. It is therefore impossible to define uniform mechatronic module boundaries that do justice to all disciplines. The solution is to apply two structuring principles in parallel: physical and functional modularization. Each discipline in the R&D area must be aligned with one of these structures. A comprehensive configuration system and the mapping of the functional to the physical structure ultimately form a coherent overall system for the mechatronic modular system. Where possible, each discipline uses the tools available in each case, provided they have appropriate configuration options.

Vague terms not only make collaboration between people more difficult, but also pose challenges for digital transformation and the use of AI. This is because systems can only be efficiently networked with one another through clarity and precision. The same applies to the application of AI to data structures in engineering. Only if these are unambiguous can AI-based systems be trained efficiently and deliver meaningful results.

Organization

The classic organization of the development area consists of a hierarchical structure that is divided into specialist disciplines. Projects are organized with the help of a matrix structure. As part of a modular strategy, multiple use according to the single-source-of-truth approach creates dependencies between module and product, which must also be taken into account organizationally through new tasks and responsibilities. To this end, roles can be defined that can be flexibly mapped to existing line organizations. Individual persons can also perform several roles. It is crucial that the task profiles of these roles are defined and their assignment communicated. Even if companies differ greatly in their organizational and operational structures, the following roles are generally useful for a modular strategy in the area of R&D.

Module responsible: Is responsible for the development and versioning of a physical module and leads the module team.

Function responsible: Is responsible for the development and versioning of a technical function and leads the function team.

Product architect: Is responsible for the product architecture. In design theory, product architecture refers to the mapping of the functional structure onto the physical structure. The architecture determines, for example, whether components of a technical function are arranged centrally or decentrally. If the architecture is varied within a product family due to unforeseen requirements, this results in numerous changes at assembly level, which increases complexity and prevents economies of scale. The architecture within a product family should therefore be invariant. The prerequisite for this is forward-looking planning of the modular system. This also includes structured requirements management.

Product family or platform manager: Is responsible for the product family or platform as a whole. Product family/platform is understood here as the sum of all similar end products that are combined in a maximum project.

Product responsible: Is responsible for an individual characteristic from the product family/platform.

Other roles ensure, for example, the implementation and continuous development of discipline-specific methods and tools. Responsibility for the sometimes complicated project files for product families within the disciplines (MCAD, ECAD, PLC, etc.) can also be regulated by roles.

As tool support makes an essential contribution to the implementation and continuity of the modular strategy, it is important to involve all tool and discipline-specific stakeholders in the further development of the methodology in an appropriate manner, whereby close coordination with product development is required.

Guidance

A comprehensive modular strategy will significantly improve the competitiveness of companies and at the same time create the conditions for the effective implementation of digital transformation and the use of AI.

However, a modular strategy requires investment. In addition to tools and expertise, sufficient internal capacity must be made available, which may make it necessary to adjust the roadmap. The decision to consistently introduce a modular strategy must therefore come from the company management and be driven forward by them. The corresponding objectives for this must be broken down into individual targets in order to set priorities and motivate managers. Company management should also promote cross-functional collaboration, particularly between IT, development and production.

In this way, the underlying conditions are set to make companies ready for modularity and thus for efficiency and sustainability.