W H I T E P A P E R

z u k e n . c o m

T h e M o d u l a r P r o d u c t A p p r o a c hA guide to multidisciplinary success

Z u k e n – T h e P a r t n e r f o r S u c c e s s

2

Z u k e n – T h e P a r t n e r f o r S u c c e s s

Machinery and industrial equipment are typically costly and therefore tightly calculated investment goods. As margins shrink because of competitive pressure, manufacturers need to keep an even closer eye on cost and profitability.

In this context it is not only macroeconomic factors – such as exchange rate fluctuation – that constitute risks and uncertainties, but the growing complexity of products also adds an element of volatility because along with technical complexity, the risks in quotation costing, engineering and production also increase.

A modular product approach, along with a product development process that is organized to support the requirements of modularity, are generally accepted methods of meeting the challenge brought by the growing complexity of products and processes. To deliver on the promise of modular product development, companies need to create a number of preconditions in terms of organization, processes and infrastructure.

When technical complexity blurs the boundaries between engineering disciplinesIn the context of product development, modules are commonly understood to be functionally and physically discrete units that can be combined and configured into an end product through uniquely defined interfaces.

One example of configuring a product from separate modules is a classic SLR camera: it consists of discrete, functionally distinct

modules – such as an enclosure, flash, objectives and storage media – that can be combined in many different ways. This is because the single modules are independent of each other and precisely defined interfaces are in place. In addition, the single modules typically represent purely mechanical or optical units.

A digital compact camera, on the other hand, combines all the functional elements (capturing light, taking pictures, lighting etc.) into a single product in which the characteristic functionality is no longer implemented as a discrete mechanical component, but as a combination of electronics and software. Products of this kind, which are frequently referred to as electromechanical or mechatronic products, are characterized by an interaction of different elements which makes them difficult organize into distinctive modules.

Wherever a product can be described in its entirety within one single engineering discipline (i.e. as a mechanical, electronic or software product), modularization is reasonably straightforward. If, however, a functional entity contains elements from different disciplines, its physical uniqueness is no longer retained.

Because of this, it is impossible to consider the mechanical components of a piece of capital equipment – such as the conveyor belt of a packaging machine – as a separate module; just as switchboards and panel cabinets, or their operating software, do not represent single functional entities.

Despite this, in today’s product development organizations we find mechanical, electrical and electronic components being developed in separate departments.

Complex modules call for an interdisciplinary engineering organization – but which discipline should take the lead?While this modular engineering methodology suggests horizontal integration, in which different functional units are developed by interdisciplinary teams, in practice most businesses are organized vertically.

Abstract

A modular product approach is an established way of improving the calculating and realizing the value of investment goods. Yet modular product initiatives often fail to live up to expectations because of poor coordination between engineering disciplines.

To deliver on the promise of a modular product architecture strategy, companies need to create a number of prerequisites in organization, process and infrastructure.

This white paper takes a look at the resulting tasks form an electronic, electrical and fluid engineering perspective and presents a pragmatic solution approach.

It is impossible to conceive the mechanical components of a piece of capital equipment as a separate module, just as switchboards and their related operating software do not represent functional entities of their own. (image: Müller Martini)

z u k e n . c o m 3

If this division into different engineering disciplines and departments is to be retained, it becomes necessary to ensure a continuous coordination of the single departments. Typically this coordination is ensured by appointing a leading and integrating discipline – usually mechanical engineering, for historic reasons – which is assigned the responsibility of coordinating the information exchange. In most cases, this will be done in a manual handover.

Beyond a certain degree of product complexity this approach becomes increasingly difficult to manage, as product functionality is made up of mechanical, electrical and software elements.

In today’s engineering reality, the functional view of a product is separated off into the various disciplines very early on in the development process. As part of this separation process, functional entities are mapped or assigned to physical entities that will be detailed out in the various disciplines.

While this may be a feasible approach for an integral or non-modular product architecture model, it sets up a huge coordination overhead for companies looking to harness the benefits of modular methodology.

To keep up with the promise of modular product concepts, this dilemma needs to be resolved by introducing a function-oriented type of organization. Otherwise there is a risk that the benefits of modularization will be neutralized by the organizational overhead that inevitably comes with it.

It is therefore worthwhile considering creating interdisciplinary teams of engineers who work together to develop functional units comprising mechanical, electrical, electronic and software components.

One emerging approach is to assign the coordinating function to the IT department, as it has responsibility for all authoring systems used in the different departments. In addition, it can be assumed that IT has a certain degree of impartiality that is needed to monitor potential conflicts of interest between the different engineering disciplines and departments.

But as sensible as it sounds, this approach has many limitations: tool ownership alone is not enough to ensure transparent access to information for all stakeholders in an interdisciplinary team. And this is a key point – every member of a product development

Th

e M

od

ula

r P

ro

du

ct

Ap

pr

oa

ch

In a digital compact camera the modules the physically distinct modules of an SLR camera are combined across shared elements.

team needs to be able to access current data of all types for a horizontal, function-oriented product development approach to succeed.

Functional characterization avoids ambiguityAs we saw earlier, every product can be broken down into its constituent functions. Using our previous example of a packaging machine, these are delivering, filling, sealing and transporting a package. Expanding out the delivery function, we have: transporting the empty containers to the filling station and then on to the closing station after filling.

This function cannot be fully-defined by the mechanical parts of the conveyor belt alone as it also involves a multitude of sensors, controls and related processor logic. It is therefore the combination of these elements that represents the function. In the same way, a module needs to contain all data describing the different elements that in combination define its function.

This means we are not so much describing a conveyor belt as a function or a functional sequence – in this case ‘carrying an empty container to a filling station and forwarding it to a packing station’. This way of looking at the machine from a functional perspective also has another positive aspect: It provides exactly the level of detail that is needed for an efficient approach to modularization.

However, at this stage of the functional description we have not yet defined the allocation of the functions to individual physical items. This will be done in the next stage, when we translate the functional structure into physical items and components.

4

Z u k e n – T h e P a r t n e r f o r S u c c e s s

This is the point where mechanical, electrical and software engineering part ways in today’s industrial practice to follow through the detailed design processes in their respective disciplines. It is only in the prototype phase, or in the case of customized machinery, the production stage, that they will be reunited.

It is important to note that as the functions are split into different physical items, the relationship to the functional structure will be broken. This means it is no longer possible to understand and review a product as a system of discrete, functionally-closed items consisting of mechanical, electrical and software components.

So we can conclude: If we want to be able to configure products from functional entities, the connection between the engineering data of the single disciplines and their functional description must not be lost – even if these data are created in different authoring environments.

Functional structure and PLM

In order to maintain this connection it is necessary to manage the functional description of a product along with the related product structure, modules and configuration logic within a single digital environment. It is commonly assumed that this is achieved in the leading PLM systems.

However, to ensure functional unambiguousness of all elements, it can easily be overlooked that an electromechanical module not only needs to be represented in every physical detail, but also in its functional description.

For all purely mechanical elements (such as an M10 screw) this is not a problem, because the function of a screw, even if it is used in several instances on the same machine, will always be to connect or fasten. If we look at an electrical element, such as cable, which is also used in several instances in the same machine, it could be have the function “energy supply” in one instance and “heating” in another. According to the industry norm IEC81346, this type of functional information is documented through the functional identification, and needs to documented accordingly. So if we want to provide a comprehensive description of a module, a PLM system must be able to cover the functional description down to the level of electrical components.

Asking this level of detail from today’s PLM systems would mean extending their scope, as their data models were developed to meet the requirements of mechanical engineering – which does not require this level of granularity. To provide a granular view of electrical components, deep modifications of the data structure of the PLM system would be needed, entailing a major programming and maintenance effort.

A viable alternative – not only from a pragmatic point of view – is a federated data management model. In such a model, the fast-moving engineering data is managed within a discipline-specific environment and referenced to a PLM-level as part of a modular entity.

For the requirements of electrical engineering this approach has a dual advantage: Component information is held where it is created – in the electrical engineering and data management environment – and the PLM layer does not have to be extended to enable a degree of granularity that is unnecessary in mechanical engineering.

Electronic, electrical and fluid engineering as equal partners in an end-to-end product development process Through 40 years of partnership with global leaders in the electronics, machinery, automotive and aerospace industries, Zuken is well-versed in the challenges of coordinating electronic and electrical engineering with mechanical and software engineering.

Instead of organizing development by discipline, it is worthwhile thinking about creating interdisciplinary teams of engineers who work together to develop functional units comprising mechanical, electrical, electronic and software components.

In modern capital equipment, product functionality is defined by a planned interaction of mechanical, electrical and software elements.

Electronic, electrical and fluid engineering as equal partners in an end-to-end product development process

z u k e n . c o m 5

Interdisciplinary product development teams require access to all types of information describing a product.

“We need to harmonize engineering processes across our different lines of business to enable a seamless flow of information between departments, engineering disciplines and geographical locations.”Markus Husner, Müller Martini Electronic AG

We were among the first to develop and deploy solutions for global electronic library and data management that removed the risk of second-sourcing and substituting components in the fast-paced semiconductor industry.

These library and data management technologies provided a solid basis for integration and coordination with other disciplines and processes in both engineering and sourcing, and manufacturing execution.

From developing and providing interfaces that enable our customers to exchange engineering information with their PLM and ERP environments, we learned that handing over an approved design does not represent the end of a product development process. Every design is subject of a lifecycle of its own, during which it will be updated, modified or re-used as a part of a new project.

Th

e M

od

ula

r P

ro

du

ct

Ap

pr

oa

ch

Functional view: All electrical components need to be characterized by a functional description.

This type of second life, and the functional aspect of electrical elements and components that we have introduced in this paper, led us to the conclusion that the handover of an approved design to PLM or ERP – although a necessary first step towards an end-to-end product development process – is not sufficient to ensure a functional view of an electro-mechanical product structure. This learning led to the development of a federated approach that allows management of engineering data within a specific discipline, which can be referenced in a higher PLM layer. More information about technologies that achieve this can be found at zuken.com.

It should be noted that the related technologies represent only elements of a comprehensive solution that provide the specific capabilities required by individual customers and industry segments.

The definition of an individual solution is always subject to a comprehensive analysis and – if required – re-engineering of established processes, identification of critical paths and related priorities, and then a planned and measurable implementation using a certified project management process.

Copyright © Zuken 160505