Advanced Engineering Informatics 28 (2014) 241–257

Contents lists available at ScienceDirect

Advanced Engineering Informatics

journal homepage: www.elsevier.com/locate/aei

Survey on mechatronic engineering: A focus on design methods

and product models
Chen Zheng, Matthieu Bricogne, Julien Le Duigou, Benoît Eynard ⇑
Université de Technologie de Compiègne, Department of Mechanical Systems Engineering, CNRS UMR7337 Roberval, CS 60319, 60203 Compiègne Cedex, France

a r t i c l e i n f o a b s t r a c t

Article history: According to the principles of concurrent engineering and integrated design, engineers intend to develop
Received 8 October 2013 a mechatronic system with a high level integration (functional and physical integrations) based on a
Received in revised form 3 May 2014 well-organised design method. As a result, two main categories of issues have been pointed out: the pro-
Accepted 31 May 2014
cess-based problems and the design data-related problems. Several approaches to overcome these issues
Available online 19 June 2014
have been put forward. To solve process-based problems, a dynamic perspective is generally used to pres-
ent how collaboration can be improved during the mechatronic design. For design data-related problems,
Keywords:
solutions generally come from product models and how to structure and store the data thanks to the
Mechatronic engineering
Systems engineering
functionality of data and documents management of Product Lifecycle Management systems. To be able
Design methods to assess design methods and product models, some criteria are proposed in the paper and used to eval-
Product models uate their added value on integrated design of mechatronic system. After this assessment, main outcomes
Product Lifecycle Management which focus on the combination of design method and product model for improving the design of mech-
Integrated design atronic system are finally discussed.
Ó 2014 Elsevier Ltd. All rights reserved.

1. Introduction mechanical parts to integrated electronic–mechanical systems

with sensors, actuators, and digital micro-electronics. These inte-
The term ‘‘Mechatronics’’ originated at the Yaskawa Corpora- grated systems, composed of hardware and software modules,
tion from the combination of mechanics and electronics, to are generally called mechatronic systems [3,4].
describe the integration process of four disciplines: mechanics, Mechanical system has started to integrate electrical and con-
electronics, computing and automatic control [1]. Because of the trol functions to become a real mechatronic system, and several
technology development, mechatronics becomes the synergistic evolution steps have been generally observed. Fig. 1 [5] presents
integration of physical systems with information technology (IT) this evolution, the different involved engineering disciplines and
and complex decision-making in the design, manufacture and the overlaps between them. First, Actuators (A), represented on
operation of industrial products and processes [2]. In this section, the right angle of the triangle, are added. They are in charge of
mechatronic system specificities will be introduced. Due to these managing actuation forces and speed. It can be regarded as the first
specificities, issues linked to mechatronic systems design will be combination of electronics and mechanics disciplines. To supply
presented. power to these actuators, external power is needed and generally
provided by electrical engineering disciplines. Second, the Embed-
1.1. Mechatronics and integrated design ded control (E), comes ‘‘with the goal of an automatic or more
reproducible process’’ [5]. On the top angle of the triangle, embed-
Products are becoming increasingly complex and integrating ded control can be considered as the overlap between the elec-
technologies from several fields, such as mechanical engineering, tronic and software disciplines. Third, the Sensors (S), on the left
electronic/electrical engineering and software engineering. angle, allow the system to get detailed information about the sta-
Mechanical systems developed since the 1980s have thus evolved tus of the system and to fulfil correctly to the various environmen-
from electro-mechanical systems with discrete electrical and tal conditions. It is considered as the overlap between the
mechanics and IT disciplines. Finally, the Communication (C) is
⇑ Corresponding author. Tel.: +33 3 44 23 45 78; fax: +33 3 44 23 52 29. now considered as the central piece of the system, especially for
E-mail addresses: chen.zheng@utc.fr (C. Zheng), matthieu.bricogne@utc.fr distributed systems. It allows integrating the sub-system into the
(M. Bricogne), julien.le-duigou@utc.fr (J. Le Duigou), benoit.eynard@utc.fr (B. Eynard). whole product/system.

http://dx.doi.org/10.1016/j.aei.2014.05.003
1474-0346/Ó 2014 Elsevier Ltd. All rights reserved.
242 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257

components’’. The mechanical component will be designed in

order to place the electrical and/or the electronic components in
juxtaposition with each other. Distances between components
have been reduced. The third kind of integration is called
‘‘included’’: electronic components are spread out into the whole
system, but this kind of integration does not achieve a ‘‘real’’ inte-
gration. Finally, the ultimate integration level is the ‘‘merged’’ com-
ponents: electronics is integrated as close as possible to the
mechanical and electrical components. Parts are gathered in a con-
sistent and functional manner and mechanical parts can also be
used as signal transmitter. The contributions of this integration
Fig. 1. Mechanical systems integrating electronics in interaction with information are various:
and power [5].
 Physical integration: spatial and weight optimisations.
 Functional integration: detection, communication, control/
This kind of evolution allows fulfilling much more functions information processing allow the system to provide new func-
compared to a pure mechanical system or pure electronic system. tionalities and to be reliable.
‘‘But all this could still be just called an automated system; mech-
atronics means more than this’’ [5]. Mechatronic systems are the In this section, the design of mechatronic system, the issues
resulting product of a global concurrent engineering or integrated related to multi-disciplinary integration and their possible effects
design approaches [6,7]. To achieve such integrated design, Abra- on the final integration of mechatronic system have been dis-
movici and Bellalouna describe the problems to overcome as ‘‘Pro- cussed. The following section describes the focus of the paper
cess-based problems’’ and ‘‘Design data-related problems’’ [8]. and the way the survey will be organised.
According to Abramovici and Bellalouna, ‘‘Process-based prob-
lems’’ are linked to the coordination and the synchronisation of 1.2. Focus of the paper and survey organisation
the ‘‘different disciplines, specific development processes, activi-
ties, tasks and results across all fields is not sufficiently supported’’, To achieve the optimal integration for the final mechatronic
but also to the fact that complex ‘‘coherences and interactions system, several problems have to be overcome. As described in
between the disciplines are considered in a late development the previous section, these problems could be divided into two
phase’’. Furthermore, ‘‘comprehensive integration, configuration, main categories, the ‘‘Process-based problems’’ and the ‘‘Design
change and release management across all disciplines is little or data-related problems’’. To overcome these problems, several
barely supported’’ [9]. efforts have been presented in different communities. The paper
The second kind of difficulties encountered during design of aims at presenting some of these approaches. In Section 2 the iden-
mechatronic systems, called ‘‘Design data-related problems’’ [9], tified collaboration challenges are presented and discussed in
is related to the edition and management tools heterogeneity. detail. For a better understanding of the added value of every
For example, mechanical designers use Computer Aided x (CAx) methods or models, several specific collaboration criteria based
applications to support the product development process. The data on these collaboration challenges are also exposed in this section.
generated are generally stored in Mechanical Product Data man- Section 3 gives a review on existing design methods used in mech-
agement (M-PDM) systems while electrical and electronic design- atronic engineering. They are all considered as a potential solution
ers use Electrical/Electronic Engineering Solutions (EESs) to create to the ‘‘Process-based problem’’, focusing on the dynamic of the
data which are stored in Electrical PDM (E-PDM). Software design- collaboration. Section 4 presents various product models enabling
ers use development solutions to create source code that is man- mechatronic design and disciplines integration, dedicated to
aged thanks to Software Configuration Management (SCM) or ‘‘Design data-related problems’’. Section 5 introduces the assess-
Concurrent Versions System (CVS) systems. This heterogeneity in ment of studied design methods and product model according to
terms of product data, data models and data formats leads to sev- the specific criteria derived from the collaboration challenges in
eral problems that can be summarised as no adequate multi-disci- Section 2. Section 6 proposes a synthesis and discussion on the
plinary integration of product data [10]. main outcomes obtained. Last, the concluding section summarises
All these multi-disciplinary integration issues could have some the proposed survey and key ideas of the paper.
negative impacts on the final integration of the mechatronic sys-
tem. Fig. 2 presents several levels of integration for a mechatronic 2. Collaboration challenges in design of mechatronic system
system. The first kind of integration is called ‘‘separated compo-
nents’’. In this case, components are designed separately and are As depicted previously, an ‘‘integrated design’’ for mechatronic
just incorporated in the same system thanks to cable. The second system embodies in two aspects: a design process with high-level
level of integration corresponds to the concept of ‘‘joined multi-disciplinary collaboration and a mechatronic system with

Fig. 2. The different integration levels in mechatronic systems [11].

 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257 243

high-level functional and physical integration. The former raises micro-level collaboration. Traditionally, the micro-level collabora-
‘‘Process-based problems’’ while the latter brings up ‘‘Design tion is often performed thanks to informal exchanges supported by
data-related problems’’. However, neither academia nor industry e-mail, phone or regular meeting.
has yet provided explicit solutions to solve such two kinds of prob-
lems due to some collaboration challenges in design of mechatron- 2.2. Design data-related problems
ic system. These collaboration challenges related to such problems
will be discussed in more detail. A large number of product data will be created and managed
throughout the whole product lifecycle, especially during the pro-
2.1. Process-based problems cess. The main objective of product model is to support Product
Data Management (PDM) functions of Product Lifecycle Manage-
One strong particularity of design process of mechatronic sys- ment (PLM). Product model includes all the information that can
tem is that it requires a multi-disciplinary and holistic develop- be accessed, stored, served and reused by stakeholders and it can
ment process. Although efforts that address design process-based help the mechatronic system to achieve a high-level functional
problems have been done, some challenges are still remaining, and physical integration. However, diversity of data from different
such as: disciplines also brings about some challenges to the design of
mechatronic system such as:
 Traditional sequential design process can still be considered as a
standard in industry.  Organisation of design process by making use of product
 There is a lack of effective methods to support multi-disciplin- models.
ary design during the whole design process.  Overlooking the importance of the interfaces’ information
 There is a lack of effective tools to support the sharing and between the subsystems of mechatronic system.
exchange of design data among engineers.  Lack of an effective support for the data exchange among
designers.
By analysing these challenges, three criteria to evaluate current  Representation of one temporal dynamic of product during the
design methods can be proposed. They correspond to the major whole design process.
encountered industrial problems during the multi-disciplinary  Representation of the design changes for a product family.
design process. These criteria correspond to the challenges pro-
posed previously and affect many of the problems during the By examining these challenges, five criteria to evaluate current
multi-disciplinary design process: product models can be identified. These criteria will be grouped in
the same order as the challenges proposed previously:
 Concurrent engineering.
 Macro level collaboration.  Organisational interface.
 Micro-level collaboration.  Macro level interface.
 Micro-level interface.
These criteria are more precisely described in the next section.  Vertical change.
 Horizontal change.
2.1.1. Concurrent engineering
Mechatronic design activities often depend on separated design These criteria are more precisely described in the next section.
tools and data, so traditional method, like sequential design pro-
cess, remains a standard in industries. However, this design pro- 2.2.1. Organisational interface
cess has proven to be unsuitable for modern mechatronic design Although the process model has been taken into account by sev-
because it increases the design cost and development leading-time. eral product models, how to use product model to direct the design
Concurrent engineering is a work methodology based on the paral- process of mechatronic system has still been a critical issue. Organ-
lelisation of design tasks [6]. It is of great importance as the design isational interface is used to guide the design tasks and support the
cost and development lead-time can be drastically reduced collaboration throughout the whole design process. The organisa-
through the design tasks carried out at the same time [12]. How- tional interface affects the design process of mechatronic system
ever, how to organise the concurrent tasks in order to achieve in two aspects. On one hand, the organisational interface helps to
the coordination of resources and project team members is still a transform the users’ requirements into the principal solutions in
critical issue, especially to get a fully integrated design [7]. the preliminary design phase to assist designers in making deci-
sion. On the other hand, it notifies the designers that their disci-
2.1.2. Macro level collaboration pline-specific solutions have to be taken into account by other
As mentioned by [4], mechatronic systems are often built from disciplines for their own solutions to manage conflicts between
discipline homogeneous subsystems (mechanics, electrics/elec- them. In summary, organisational interface can help engineers
tronics and software). The typical approach for the design of mech- have a well-organised concurrent engineering for mechatronic sys-
atronic system is carried on in a concurrent manner with a special tem design, focusing on possible inconsistencies or poor
focus on the subsystems and the interfaces among them [13]. The integration.
macro level collaboration emphasises such discipline homoge-
neous collaboration. It not only focuses on the assembly of the sub- 2.2.2. Macro level interface
systems from different specific design disciplines, but pays special During the process of mechatronic system design, a great num-
attention to the discipline interfaces among them as well. ber of subsystems are defined by specific disciplines and are under
development by different engineers. With the purpose of two sub-
2.1.3. Micro-level collaboration system to be interconnected, there must be compatible interfaces
The design process of mechatronic system should also focus on in mechanical, electronic/electrical and software disciplines [14],
the collaboration of the different engineers or designers, such as which are called in this paper macro level interfaces. Such inter-
communication among designers, data sharing and exchange. faces describe the associations between subsystems, both to indi-
Such collaboration among the individuals is called in this paper cate their inter-dependence and to provide high-level guidance
244 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257

for how subsystems should be joined in the final product [15]. The be dramatically increased thanks to the predecessors’ successful
macro level interfaces can help engineers to achieve the basics for design. Last, extensive versions can be easily derived from the pre-
integration of the subsystems. By comparing the description of decessors [17].
macro level interface with that of macro level collaboration Fig. 3 presents vertical and horizontal change. The vertical
described previously, macro level interface envisions to be an arrow represents the vertical change while the horizontal arrow
effective support for macro level collaboration during the design represents horizontal change.
process of mechatronic design.
2.3. Criteria of design methods and product models
2.2.3. Micro-level interface
The engineers need another kind of interface which allows Generally speaking, design knowledge can be classified into two
them to exchange and share information or data from other disci- categories: design process knowledge and product knowledge [16].
plines during the process of mechatronic design. It intends to help The collaboration challenges related to the process-based prob-
designers to collaborate or coordinate by sharing information lems (process knowledge) and design data-related problems (prod-
through formal or informal interaction [16]. Micro-level interface uct knowledge) have been discussed in this section. As depicted in
provides an effective mean to solve this issue. Because micro-level the previous subsections, organisational interface, macro level
interface has been built in many information and distributed com- interface and micro-level interface are considered as effective sup-
puter systems to support the process of mechatronic design, it fos- ports for concurrent engineering, macro level collaboration and
ters a better micro-level collaboration. micro-level collaboration separately. Fig. 4 shows the relationship
between the criteria of concurrent engineering and organisational
2.2.4. Vertical change interface, macro level collaboration and macro level interface and
Vertical change focuses on how to manage the product’s tempo- micro-level collaboration and micro-level interface.
ral dynamics of the product definition during the product develop- Another two criteria of product models, vertical change and
ment process. Mechatronic design is a dynamic process and a static horizontal change were subsequently proposed. The criteria and
product model is no longer suitable for mechatronic design. Such their descriptions are summarised in Table 1. Current design meth-
dynamic process mainly embodies two aspects: on one hand, prod- ods and product models will be presented and assessed by the cri-
uct data are specified as versioned to take into account the tempo- teria in the following sections in more detail.
ral dynamics of the product definition; on the other hand, the
product definition may be modified from time to time due to 3. Design methods for mechatronic engineering
customers’ requirements and market changes. Because the mecha-
tronic system is a combination of mechanical, electronic/electrical Design of mechatronic system requires a multi-disciplinary col-
and software technology, a modification in any discipline will lead laboration. To deal with such multi-disciplinary design issue, since
to a completely different design process. The product model of the late 1950s and the early 1960s, system engineering has been
mechatronic system should evolve dynamically according to the proposed as an interdisciplinary approach and means to enable
progress of design process. the realisation of successful system [18]. In the 1980s, some sys-
tem design methods, such as waterfall model [19], spiral model
2.2.5. Horizontal change [20] and V-model [21] were widely used for systems engineering.
Horizontal change focuses on how to manage product families’ A design method can help the engineers from different disciplines
data. The development of new product based on the successful to enable their collaboration for the increasingly complex tasks of
design of its predecessors brings several benefits for the company systems engineering [22]. However, a design method specially
and customers. First, the development approach of product family adapted for design of mechatronic system was not put forward
reduces lead-times and costs due to the development background at that time. After the 1980s, the use of microcomputer technology
of the predecessors. Second, the reliability of the new product can and software determines functions were integrated in mechatronic

Fig. 3. Product change: horizontal vs. vertical evolutions.

 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257 245

Fig. 4. Relationship between the criteria of product models and those of design methods.

Table 1
Summary of criteria and their descriptions.

Contribution Criterion Description

type
Design Concurrent A work methodology based on the parallelisation of design tasks
methods engineering
Macro level Discipline homogeneous collaboration which focuses on the assembly of the subsystems from different specific design disciplines
collaboration and the interfaces among them
Micro-level Collaboration of the different engineers, such as communication among designers, data sharing and exchange and design
collaboration knowledge management
Product Organisational Interface which assists designers in making decision and managing conflicts between them in order to help them have a well-
models interface organised concurrent engineering for design of mechatronic system
Macro level Interface which describes the associations between subsystems and can help engineers to achieve the basics for integration of the
interface subsystems
Micro-level Interface which allows engineers to exchange and share information or data from other disciplines and helps designers
interface collaborate or coordinate through formal or informal interaction
Vertical change Management of the product’s temporal dynamics of the product definition during one product’s development process
Horizontal change Management of product families’ data

system [3]. The continuously growing complexity of mechatronic is not suitable for modern industrial company any longer. Firstly,
system requires a more integrated design than ever. Therefore a this whole duration of the design process is very long since the
number of mechatronic design methods have emerged to meet design in each discipline has to be carried out one after another.
the need of collaboration during the design process of mechatronic Consequently, this approach usually does not lead to optimal over-
system. Derived from approaches such as the traditional sequential all behaviour. Secondly, the software plays a key role for the sys-
design [23], the concurrent engineering [24] or the much recent tem’s performance, so it must be considered during the whole
lean product development [25], many design methods for mecha- design process. As the software design is often executed as the last
tronic engineering have been proposed, but these design methods task in the sequential design process, this process cannot reflect
still remain poor to support the technology integration and multi- the importance of software in modern mechatronic design. In order
disciplinary perspectives in mechatronic design. A non-exhaustive to solve the problems brought by sequential design process, sev-
list of design methods is presented hereafter. eral design approaches which allow concurrent engineering have
been put forward. V-model, for instance, will be presented in the
3.1. Sequential design process next section.
Table 2 shows an evaluation of the sequential design process
The traditional approach for the design of mechatronic system according to the three criteria above proposed. Obviously, the
is called sequential design process. In this design process, the main sequential design process cannot support concurrent engineering.
concerns of the mechanical view are reliability and technical per- Fig. 5 shows that there are explicit links between subsystems (sen-
formance of the system. The control view of the system is then sor and actuator, detailed modular, control system and etc.) during
designed and added to provide additional performance or reliabil- the design process. So the macro level collaboration can be per-
ity and also to correct undetected errors in the design. As the formed in such design method. But it does not provide an effective
design steps occur sequentially, this approach is called sequential support for the collaboration among different engineers. So the
design model [4]. The principle of the sequential design process micro-level collaboration has not been developed in this design
is that each new design task must be started when the previous method.
one has been finished ([4] – Fig. 5). For example, the mechanical Thus, the sequential process leads to negative effects on further
design has to be ‘‘frozen’’ before proceeding to the design of control developments of the mechatronic systems. In order to solve the
software [26]. problems brought by sequential design process, several design
Obviously, the sequential design process can help the executive approaches which allow concurrent design have been put forward.
manager to have a global view about the whole design. However, it V-model, for instance, will be presented in the next section.
246 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257

Modelling/Simulation Prototyping Deployment/Lifecycle

Hardware-in-the-loop Deployment of embedded

Recognition of the need
simulation software

Conceptual design and Design

optimisation Life cycle optimisation
functional specification

First principle modular

mathematical modelling

Sensor and actuator selection

Detailed modular
mathematical modelling

Control system
design

Design
optimisation

Fig. 5. Sequential design process [4].

Table 2 with a user-validated system (upper right). In order to arrive to the

Evaluation of sequential design process. final product, each stage of the product definition should be tested
Design method Sequential design process [21].
Concurrent The design steps occur sequentially No During the High-level Design and Detailed Design phases on the
engineering axis of ‘‘Decomposition and Definition’’ (Fig. 6), subsystems of the
Macro level There are explicit links between subsystems Yes system are identified and decomposed further into component.
collaboration Requirements are allocated to the system components and inter-
Micro-level It does not support the collaboration of different No
faces are specified in detail. Therefore the design tasks for different
collaboration engineers
subsystems can be executed in parallel. The main purpose of the
axis of integration and recomposition is to validate each corre-
sponding stage in the part of decomposition and definition in
3.2. V-model Fig. 6 [21].
The V-model defines an integrated design process, and a con-
The V-model presents a general flow for the product develop- current engineering has been achieved in this model. As shown
ment process. It starts with identification of user’s requirements. in Fig. 6, during the phase of implementation, the V-model simply
Once the requirements have been taken into account, they are then divides the mechatronic system into software and hardware, ignor-
placed under project control (upper-left) and the V-model will end ing the fact that the mechatronic system is the combination of

Fig. 6. V-model [27].

 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257 247

Table 3
Evaluation of V-model.

Design method V-model

Concurrent engineering The design tasks for different subsystems can be executed in parallel during the Detailed Design phases Yes
Macro level collaboration During the phase of Implementation, the V-model simply divides the mechatronic system into software and hardware Partial
Micro-level collaboration It does not support the collaboration of different engineers No

concept defined during the phase of system design. If the system

has to be improved, the design process will be repeated.
The modelling and model analysis lasts from the system design
phase to the system integration phase. During process of modelling
and model analysis, modelling technique and CAx applications will
be used. In order to meet the some special requirements of com-
plex mechatronic system, several variants of VDI 2206 have been
proposed. A product development process which focuses on the
degree of mechatronic product maturity is developed based on
the principle of VDI 2206. In this variant, the mechatronic product
is generally not produced within one macro cycle of V-model, but
within many macro cycles as a continuous macro cycle. At the end
of each macro cycle, a product with an increasing maturity, such as
Fig. 7. VDI2206 [30].
laboratory specimen, functional specimen and pilot-run product
will be produced [31]. A mechatronic systems controlled by a
mechanics, electronics and software. For that reason the macro PLC (Programmable Logic Controller) can be developed by another
level collaboration is partially performed in V-model. The collabo- variant of VDI 2206. In this variant, because the information tech-
ration of different engineers has not been mentioned in this design nology (developing the software for the PLC) and mechanical engi-
method. An evaluation of the V-model is shown in Table 3. The V- neering (using CAD to design the geometry) has been identified as
model provides a design process which is more integrated than the major engineering domains for such mechatronic system, the
sequential design process. domain ‘‘electrical engineering’’ is neglected [30].
The VDI 2206 provides a practice-oriented guideline for design
3.2.1. VDI 2206 of mechatronic system. Compared with the V-model, it unifies the
The VDI guideline 2206 is a functional modelling methodology domain-specific design more systematically (Mechanical engineer-
based on the V-model. The functional modelling methodology ing, electrical engineering and information technology), but the
means that different methods are used to define a model of any interfaces among the subsystems of different design domains do
system by capturing and processing the information about its pur- not arouse enough attention in this organisational method. More-
pose and the functions of its components to fulfil the purpose [28]. over, an explicit links between the different engineers does not
The VDI guideline 2206 is developed and standardised by a VDI exist in VDI 2206. An assessment of the VDI 2206 is shown in
committee, a German engineers association. It represents a prac- Table 4.
tice-oriented guideline for the systematic development of mecha-
tronic system. Different from the VDI/VDE 2422 used for the
3.2.2. RFLP method
design of mechanical and electrical components separately, the
The RFLP approach is a specific V-model derived method partic-
VDI 2206 provides the first neutral guideline for the design of
ularly adapted to design of mechatronic system. It is implemented
mechatronic system [29].
in the CATIA System v61 software and can therefore be considered
The VDI guideline 2206 provides a useful frame for designing
as a commercial approach. In this method, the descending branch
any kind of mechatronic system. It consists essentially of three
of V-model is divided into 4 views: Requirement engineering view,
elements [30]:
Functional view, Logical view and Physical view [32].
In the requirement engineering view, users’ requirements are
 The V-model on the macro-level.
clarified. These requirements can be described according to the
 A general problem-solving cycle on the micro-level.
APTE2 method or the SysML3 language.
 Predefined process modules for handling recurrent working
In the functional view, the main functions of mechatronic sys-
steps in the development of mechatronic systems.
tem are presented. The language SysML or CATIA System Engineer-
ing can be used as the modelling tools in order to build the
The VDI guideline 2206 divides mechatronic system design into
functional view.
four major phases, called ‘‘system design’’, ‘‘domain-specific
In the logical view, the logical architecture of mechatronic sys-
design’’, ‘‘system integration’’ and ‘‘assurance of properties’’
tem will be defined. Multi-disciplinary tools to model and carry out
(Fig. 7).
numerical analysis, such as Modelica4, Matlab/Simulink5 and
The goal during the system design phase is to define a cross-dis-
bondgraphs6 can be used for the logical modelling of mechatronic
cipline solution concept for the system. In this phase the overall
system.
function of the system will be divided into sub-functions.
The domain-specific design phase can be regarded as several
1
parallel smaller design tasks. The results from the discipline-spe- http://www.3ds.com/products-services/catia.
2
http://cabinet-apte.fr/.
cific design are integrated to the complete mechatronic system in 3
http://www.omgsysml.org/.
the phase of system integration. 4
https://www.modelica.org/.
The purpose of the assurance of properties phase is to make 5
www.mathworks.com.
sure that the results of the system integration fulfil the solution 6
http://www.bondgraph.org/.
248 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257

Table 4
Evaluation of VDI 2206.

Design method VDI 2206

Concurrent The discipline-specific design phase can be regarded as several parallel smaller design tasks Yes
engineering
Macro level VDI 2206 unifies the domain-specific design more systematically, but the interfaces among the subsystems of different design domains Partial
collaboration do not arouse enough attention
Micro-level It does not support the collaboration of different engineers No
collaboration

Table 5
Evaluation of RFLP method.

Design method RFLP method

Concurrent The RFLP method fully supports concurrent engineering Yes
engineering
Macro level Multi-domain modelling methods are used to fully support the macro level collaboration in the logic view Yes
collaboration
Micro-level In the physical view, the geometric definition of product, the schematic definition and the source code will be created, but the exchange Partial
collaboration of information between software design and other disciplines remains a challenge and should be further developed

Nowadays, the RFLP method has been integrated into CATIA/

ENOVIA v6. This CAx/PDM system provides functionalities for stor-
ing, sharing and exchanging certain types of data and information
among the engineers of different disciplines, such as the data of M-
CAD and E-CAD [34]. But how to integrate the software source code
remains a challenge.
Two organisational methods of V-model, VDI 2206 and RFLP
methods have been presented in the sub-sections above. A last
design method, called the hierarchical design method, is presented
in the following section. This method can greatly reduce unneces-
Fig. 8. Mechatronic system and model pillars [37]. sary iteration loops during the design process, especially for the
complex mechatronic system.

3.2.3. Hierarchical design method

The hierarchical design method takes the integration of
mechanical, electrical and electronic control and software aspects
from the very beginning of the earliest design phase [35].
Mechatronic system can be broken down into discipline-spe-
cific subsystems and each discipline-specific subsystem is charac-
terised by a model pillar. Only the first (highest) level has an
interface to the other pillars via the mechatronic coupling level
(Fig. 8).
The functional requirement (FR) of each model pillar is defined
by several design parameters (DPs). In the hierarchical design
model, one FR at level i can affect several FRs at level i + 1 via the
DPs at level i. The design parameters at one level can be classified
into two categories, the internal design parameters and the exter-
Fig. 9. Hierarchy of parameter [36].
nal design parameters. One subset comprises ni+1 external param-
eters representing requirement parameters for the next level. The
other internal parameters are exclusively local at the active level
In the physical view, the components, the geometric definition for dimensioning the component at this level. The process of defin-
of product (Mechanical Computer Aided Design, M-CAD), the sche- ing hierarchical levels must be repeated until elementary FRs (e.g.
matic definition (Electronic/Electrical Computer Aided Design, E- proven solutions, standard components) with their associated, well
CAD) and the source code (software) will be created. The 3D CAD known DPs are achieved (Fig. 9 – [36]).
applications and the analysis software, such as Simulia7 can be The hierarchical design method is proposed to address complex
used. In this view, the difficulty of multi-disciplinary simulation is design tasks, in which the discipline-specific design tasks do not
related to issues of interoperability between design and analysis need to be integrated as a whole on the mechatronic level. By ana-
applications, which will lead to difficulties to ensure multidisciplin- lysing the interconnections of the functional parameters, it enables
ary optimisation [33]. an easy qualification on how a product should be designed to
Table 5 shows an assessment of RFLP method. reduce unnecessary iteration loops.
The hierarchical design method supports the concurrent engi-
neering. A complex mechatronic system can be broken down into
7
www.3ds.com/simulia. domain-specific model pillars according to requirement parame-
 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257 249

Table 6
Evaluation of hierarchical design method.

Design method Hierarchical design method

Concurrent engineering A complex mechatronic system can be decomposed into domain-specific model pillars which can be developed simultaneously Yes
Macro level The interfaces between pillars models of different disciplines have been developed in the highest level of hierarchical design model Yes
collaboration
Micro-level The data derived from the software engineers has not been well integrated during the design process Partial
collaboration

ters and design parameters addressing multiple disciplines. These lifecycle of a product or/and a certain industrial domain. The STEP
domain-specific model pillars can be developed simultaneously. APs can be roughly grouped into the three main areas: design,
This design method also fulfils the macro-level collaboration manufacturing and life cycle support.
because the interfaces between model pillars of different disci- Nowadays, the STEP APs are widely used in mechanical design
plines have been specified in the highest level of hierarchical domain, such as AP 203, AP 209 and AP 214. Some APs related to
design model. However, the hierarchical design model does not electronic/electrical design are also proposed. However, an AP
fully support micro-level collaboration. Although it pays much which can systematically support the whole design process of
attention to the information sharing and exchanging between elec- mechatronic system has not been fully developed. The STEP APs
trical and mechanical design, the data derived from the software which can be used for design of mechatronic system will be intro-
engineers has not been well integrated during the design process. duced in more detail.
Table 6 shows an assessment of hierarchical design method STEP AP233 [47] describes the key product data and information
according to the criteria above proposed. for systems engineering that must be exchanged between dissimi-
All the design methods discussed above help and guide the lar applications for requirements engineering and for systems mod-
engineers in the development of mechatronic system. They are elling and simulation [48]. Industries that can benefit from using
mainly focused on the ‘‘process-based problems’’ solving. How- AP233 are automotive, aerospace, shipbuilding, consumer goods
ever, not all these methods can support the multi-disciplinary col- electronics, and others with complex products and processes. AP
laboration. Product models will be the concerns of the survey 239 provides an integration and exchange capability for product life
introduced in the following section. Product models are used to cycle support data [49]. Besides AP 233 and AP 239, other APs
solve the ‘‘design data related problems’’. Moreover, design process related to the different expert knowledge of mechatronic system
and organisational models have been linked with some product have been proposed. AP 210 [50] describes the requirements for
model. Hence, they are also considered as effective supports for the design of electrical printed circuit assemblies (PCA). AP 214
the ‘‘process-based problems’’. [51] specifies the exchange of information between various applica-
tions which support the automotive mechanical design process, but
it only focuses on the vehicle development process.
4. Product models for mechatronic engineering STEP standard partially represents the organisational interface,
because AP 239 not only integrates the information for defining a
The main objective of product model is to support PDM func- complex product and its support solution, but it also represents
tions of PLM throughout the whole product lifecycle. Product the planning, the scheduling of the tasks and the management of
model includes all the information that can be accessed, stored, the subsequent work. However, it remains very generic to support
served and reused by stakeholders throughout the entire product design of mechatronic system and some characteristics and param-
lifecycle [37–39]. eters of mechatronic system have not been integrated in this data
Nowadays, several product models and their extensions have model. STEP standard partially fulfils macro level interface in some
been proposed. They are not dedicated and implemented specifi- specific disciplines. For example, AP 214 specifies the interfaces
cally for mechatronics. However, they can fairly and efficiently between various CAx applications which support the automotive
support the design of mechatronic system. Current product models mechanical design process. STEP AP 210 describes the information
will be presented in the following sections. needed for the design of electrical printed circuit assemblies. As to
the micro-level interface, STEP is a powerful standard which sup-
4.1. STEP (STandard for the Exchange of Product) ports the exchange of geometric data between CAD applications.
It focuses on the electronic/electrical discipline and mechanical
STandard for the Exchange of Product model data (STEP) is actu- discipline but not in an integrated perspective of both disciplines.
ally a series of standards, known as ISO 10303 developed by It does not provide an effective interface to fully support the data
experts worldwide [40,41]. Its scope is much broader than that exchange in software discipline. Considering the vertical and hori-
of other existing CAD data exchange formats, such as Initial Graph- zontal changes, STEP allows the designer to exchange the data and
ics Exchange Specification (IGES) which was developed primarily information at any time during the product development process,
for the exchange of pure geometric data between CAD applications and it also provides a possibility for representing the existing or
[42]. STEP is intended to handle a much wider range of product- potential future products, which allows the evolution of product
related data covering the entire life-cycle of a product [43]. families [52]. An assessment for STEP standard is shown in Table 7.
As the area of STEP application is extremely broad, it is issued in In this section, the STEP data model and its Application Proto-
numerous sections, identified as Parts. The Parts known as APs cols have been discussed. In the next section, the Core Product
(Application Protocol) define the scope, context and information Model (CPM) will be presented.
requirements of applications [44,45]. STEP has developed more
than forty standard APs for product data representation. They 4.2. CPM (Core Product Model)
reflect the consolidated expertise of major industries for more than
twenty years, covering the principal product data management CPM, an abstract model with generic semantics, initially devel-
areas for the main industries [46]. In other words, the APs are oped at NIST (National Institute of Standards and Technology), can
specific data models based on STEP standard covering the entire support the full range of PLM information [53].
250 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257

Table 7
Evaluation of STEP standard.

Product model STEP

Organisational STEP AP239 represents the planning and scheduling of complex design tasks, but it is still very generic regarding the specificities in Partial
interface design of mechatronic system
Macro level STEP standard only fulfils macro level interface in some specific disciplines (AP 214 specifies the automotive mechanical design process; Partial
interface AP 210 focuses on PCA design. . .)
Micro-level It focuses on the electronic/electrical discipline and mechanical discipline but not in an integrated perspective of both disciplines. It does Partial
interface not provide an effective interface to fully support the data exchange in software discipline
Vertical change STEP allows the designer to exchange the data and information at any time during the product development process Yes
Horizontal change AP 239 provides a representation of existing or potential future products, which allows managing the data of product families Partial

CPM is based on two principles. First, the key object in the CPM virtual components. The interfaces between HW/SW, HW/HW
is the artefact. Artefact represents a distinct entity in a product, and SW/SW are proposed in this model (Fig. 11). The interface fea-
whether that entity is a component, part, subassembly or assem- ture and the co-design of HW/SW in embedded system largely
bly. Second, the artefact aggregates three objects representing expand the CPM model. To a certain extend the embedded system
the artefact’s principal aspects: function, form and behaviour. can be fairly assimilated to mechatronic system and ESM partially
CPM consists of two sets of classes, called object and relationship performed the collaboration between electronic and software dis-
classes [54,55]. The two sets of classes are equivalent to the Unified ciplines. However, the embedded system is not a real mechatronic
Modelling Language (UML) terms of class and association class, system and sometimes it is only a part of mechatronic system.
respectively [56]. A UML class diagram of the CPM data model is The Product Family Evolution Model (PFEM) which extends the
shown in Fig. 10. CPM to the representation of the evolution of product families is
As to the multi-disciplinary design (design of mechatronic sys- developed by [17]. This model represents the independent evolu-
tem), the CPM model does not provide the interfaces between tion of products and components through families, series and ver-
different disciplines. In order to meet the requirements of multi- sions. The information model representing product families is an
disciplinary design, some extensions have been proposed. extension of the CPM and consists of three sub-models: Product
Zha et al. proposed the Extension of CPM Embedded System Family, Family Evolution, and Evolution Rationale (Fig. 12).
Model (ESM) which is feature-based approach to the co-design of The Mechatronic Device Model (MDM) proposed by [58] is an
hardware (HW) and software (SW) in embedded systems [57]. extension model of CPM. It supports the preliminary design of mul-
The extended model provides a framework for co-design of fea- tiple interaction-state mechatronic devices, where the interactions
ture-based HW/SW components allowing the designer to develop between the use-environment and the device may have different
a virtual prototype of embedded system through assembly of qualitative structures. This model supports the preliminary design

Fig. 10. UML class diagram of the Core Product Model [53].
 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257 251

Fig. 11. Interface feature of Embedded System Model [57].

4.3. MOKA

Mechatronic design can be considered as a knowledge intensive

engineering process. Large amounts of different kinds of knowl-
edge derived from numerous disciplines are needed during the
design process of mechatronic system. The KBE application is pro-
posed to manage the vast amount of data and its flow through
complex systems during one product development [59]. It can be
seen as an effective tool for capturing knowledge and reusing it
during the design process of mechatronic system.
MOKA is a European research project with the aim to develop a
Fig. 12. Main diagram of Product Family Evolution Model [17]. methodology and tools to support the deployment of KBE applica-
tion [60]. MOKA product model is represented thanks to UML. The
Structure, Function, Behaviour, Technology and Representation are
phase in which the desired behaviour and the specification of the considered as five basic views for building the product model. The
internal structure of the mechatronic device will be analysed. As MOKA product model is shown in Fig. 14.
multi-disciplinary collaboration tasks are mainly performed in Different from the two product models introduced in the previ-
the ‘‘detailed design’’ phase, in which the principle solutions will ous subsections, constraints which represent design restrictions
be detailed for every components of the system, the MDM does are described within the MOKA product model. The constraint con-
not fulfil collaboration issue (Fig. 13). cerns the combinations of subsystems in a complex system. It
In this section, CPM and its extensions have been discussed. implies the interface between two subsystems [61].
CPM proposes an abstract and generic product model for product Besides MOKA product model, MOKA also proposes the design
development. Some extensions of CPM have been proposed to process methodology. It defines how to resolve product choices
solve certain kinds of problems during the mechatronic design subject to product constraints and the order in which design steps
(ESM, PFEM and MDM). However, neither CPM nor its extensions have to be executed and design decisions have to be made [61].
can fully support the mechatronic design. MOKA describes design activities and rules with enough detail to
CPM does not allow the representation of the organisational enable them to be automated by UML Activity Diagrams.
interface, but the macro level interface and micro-level interface Table 9 shows the assessment of MOKA. MOKA provides an
have been integrated in CPM. The extension of CPM Embedded Sys- organisational interface to describe the design tasks by the Activity
tem Model not only defines the interface between hardware and Diagrams of MOKA, but it does not propose the models where
software in embedded systems to meet the requirement of designers can take into account the status of their own work and
multi-disciplinary collaboration, but an IT platform based on the their expertise which lead to some change for other disciplines.
extension is implemented to fulfil the collaboration between MOKA can also represent the constraints. Constraints can be repre-
designers. The extension of CPM Product Family Evolution Model sented in the MOKA product model. They imply the interfaces
provides the description of the change of product family, but the between subsystems. But the constraints existing in mechatronic
temporal definition has not been explicitly proposed during the system have not been specialised. MOKA describes the steps that
product development process. An assessment for CPM is shown implement a model instance from a product model, which partially
in Table 8. depicts the vertical change of a product. As to the horizontal
In order to enlarge perspectives on mechatronic expertise, a change, MOKA stores the experience, geometry and data related
product model based on the Knowledge Based Engineering (KBE) to a product family in a database.
methodology issued from the MOKA (Methodology and tools MOKA has been discussed in this section. It not only provides a
Oriented to Knowledge-based engineering Applications) research product model, but also describes the design process by UML
project will be presented and discussed in the following section. Activity Diagrams. Like MOKA, Product–Process–Organisation
252 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257

Fig. 13. An abstraction of information flow in design [58].

Table 8
Evaluation of CPM.

Product model CPM

Organisational interface CPM does not represent the organisational interface No
Macro level interface The Extension of CPM Embedded System Model defines the interface between hardware and software in embedded Partial
systems
Micro-level interface An IT platform based on CPM Embedded System Model has been established. It allows the designers to develop a virtual Partial
embedded system prototype through the collaboration between designers
Vertical change CPM supports all the information throughout the full range of product lifecycle, but temporal dynamics of the product Partial
definition has not been explicitly proposed during the product development process
Horizontal change The extension of CPM Product Family Evolution Model provides the representation of the change of product families Yes

model (PPO) model also focuses on the organisational process. The An interface class is described in the product model by the way
following section will present the PPO model. a component (mechanical, electrical, etc.) may be linked to
another. Although the interface class is derived into Common
4.4. PPO (Product–Process–Organisation) model Interfaces (CI), Alternative Interfaces (AI) and View Interfaces
(VI), it needs to be further specified for mechatronic system and
Design process of mechatronic system requires collaboration the collaboration among different disciplines has to be fully imple-
among different disciplines and designers. The collaboration dur- mented in the product model.
ing design process can be considered as a problem that has to be In the PPO model, product model is extended according to the
solved. Therefore, the process and the organisational models have process and organisation models. In the process model (Fig. 16),
been linked with the product model. a particular activity is defined to describe collaborative actions
In order to fulfil these aims, the IPPOP (Integration of Product, (Collaborative Activity) in which the team members may collabo-
Process and Organisation for improvement of engineering Perfor- rate in order to solve a conflict during the design process.
mance) project has developed the PPO model which describes Moreover, the PPO model offered a traceability of the evolution
information of product, process and organisation. It enhances of the design process in the whole design organisation. This trace-
interoperability of heterogeneous expert tools during the product ability is based on the versioned technical data to take into account
development process [62]. The product model developed in the the temporal dynamic of the product definition. It is characterised
IPPOP project is shown in Fig. 15. It consists of 4 main concepts: by its maturity degree (‘‘Maturity’’) and a ‘‘Status’’ as shown in
Component, Interface, Function and Behaviour. Fig. 16.
 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257 253

Fig. 14. MOKA product model.

Table 9
Evaluation of MOKA.

Product model MOKA

Organisational interface MOKA provides an interface to describe the design tasks and rules by Activity Diagrams of MOKA, but it does not offer the Partial
design environment where engineers can take into account the status of their own design and their expertise which lead to
some change for other disciplines
Macro level interface Constraint has been represented in the MOKA product model which implies the interface between two subsystems Partial
Micro-level interface MOKA does not provide an interface for data exchange between engineers No
Vertical change MOKA describes the steps that implement a model instance from a product model, which partially depicts the vertical Partial
change of a product
Horizontal change MOKA is one of approaches for Knowledge Based Engineering by which the experience, geometry and data that relate to a Yes
product family can be stored in database

Fig. 15. Product model class diagram [63].

In the PPO model, the organisational interface has been well during the product development process to support the horizon-
specified. A decision framework has also been developed in the tal change of a mechatronic system. An evaluation of PPO is
organisational model. It defines different horizons for the deci- shown in Table 10.
sion-making and manages the design process according to the The PPO model is considered as an effective support for the
engineers’ needs. The PPO model also establishes an interface development process of a complex system because the data of
by which subsystems can be linked to each other, but this inter- product, process and organisation during the design process have
face should be further specialised for mechatronic system model- been taken into account by the PPO model, but it should be further
ling. A prototype of software supporting the PPO model has been specialised for mechatronic system design. As shown with recent
developed. It can be underlined that it fulfils the micro-level PPO model developments, PPO is generally considered as an exten-
interface so that the designers can find the information necessary sible data model [65]. Hence, a special extension for design of
to achieve their own tasks. As to the vertical change, technical mechatronic system can be developed based on PPO model.
data is considered as versioned to take into account the temporal Numerous product models have been presented and discussed
dynamics of the product definition. However, the information in the above sections. The following section will summarise the
related to a product family has not been explicitly proposed assessment of different design approaches, including the design
254 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257

Milestone * Constraint
Goal
-planned date
-real date
1..*
next maturity
* * Trigger
1
Maturity Transition
*
-value -AND / OR
1..* 1..** 1 decompose
* *
* * Activity
1..* * *
Product Data (versioned) output
*
-subject input
-producing activity ID * 1 * Capability
-content Capacity
* * *
-version number Resource
*
next version
*
* 1
Status
*
-status(created, validated, released)
-date Human Hardware / Software Methodological / Informational
-name of the modifier

next status
*

Fig. 16. Process model developed during the IPPOP project [64].

Table 10
Evaluation of PPO.

Product model PPO

Organisational A decision framework has been developed in the organisational model, which defines different horizons for the decision-making and Yes
interface manages the design process according to the engineers’ needs
Macro level An interface class is proposed by which a subsystem (mechanical, electrical and etc.) may be linked to another, but this model is very Partial
interface generic and should be further specialised for mechatronic system modelling
Micro-level A prototype of software supporting the PPO model has been developed during the IPPOP project. An engineer can find all information Yes
interface necessary to achieve his task by using a specific Graphical User Interface (GUI)
Vertical change Technical data is considered as versioned to take into account the temporal dynamics of the product definition Yes
Horizontal change The information related to a product family has not been explicitly proposed during the product design process Partial

methods and the product models for design of mechatronic coordination of project team members in order to be successful.
system. Hence, the collaboration among different expertise and disciplines
during the design process of mechatronic system plays a key role
to ensure that the results of their efforts are successful, especially
5. Assessment of studied design concerns
to obtain an integrated system.
Concurrent engineering approach (1) of product development
From the survey above, the two concerns for design of mecha-
process is of great importance, because the development lead-
tronic system are highlighted as ‘‘design method’’ and ‘‘product
times can be drastically reduced through the design tasks carried
model’’, which are respectively dedicated to solve the ‘‘Process-
out in parallel. However, organising the concurrency of tasks in
based problems’’ and the ‘‘Design data-related problems’’.
order to achieve the resources management and coordination of
Although there have been efforts that address such two kinds of
project team members is still a critical issue, especially to get a
concerns. Some challenges still exist during the design process of
fully integrated design.
mechatronic system. Therefore, both design method and product
Two kinds of collaboration levels are considered. The first one,
model should be further improved to meet the requirement of
called in this paper macro level collaboration (2), emphasises the
integrated design.
discipline homogeneous collaboration. The second one focuses on
In this section, the design concerns presented above will be
the collaboration of individuals, in other words, the interaction
assessed and discussed according to specific criteria. The assess-
between projects team members, which is called in this paper
ment will start with the design methods.
micro-level collaboration (3).
In this subsection dealing with design methods, three criteria of
5.1. Assessment of studied design methods collaboration have been chosen for the evaluation: (1) Integrated
design and concurrent engineering; (2) Macro level collaboration;
Design of mechatronic system requires a high degree of integra- (3) Micro-level collaboration. The assessment is summarised in
tion, and the complex mechatronic system is often broken down Table 11.
into simpler subsystems or components. Meanwhile, the complex Table 11 shows the assessment of the design methods accord-
design project calls for the resources management and ing to the above proposed criteria. Except the sequential design
 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257 255

Table 11
Assessment of the design methods regarding needs of multi-disciplinary collaboration.

Design method Concurrent engineering Macro level collaboration Micro-level collaboration

Sequential design model No Yes No
V-model Yes Partial No
VDI 2206 Yes Partial No
RFLP Yes Yes Partial
Hierarchical design model Yes Yes Partial

process, the other design methods allow the concurrent engineer- design tasks more efficiently, the organisational interface has been
ing and integrated design. There exist explicit links between the included in STEP, MOKA and PPO. The product models, such as
expert components in the sequential design process, RFLP method STEP, CPM and PPO, have partially developed the interfaces (macro
and hierarchical design method. So these three methods can fully level interface and micro-level interface) to meet the requirements
support the macro level collaboration. However, only the RFLP of collaboration between various experts and disciplines. All the
method and hierarchical design method partially support the product models discussed in this paper take partially product
micro-level collaboration during the design process. change into account.
Based on the assessment outcomes shown in Table 11, the cur- Several criteria have been chosen to assess a selection of design
rent design methods partially support the design of mechatronic methods and product models in this section. Table 11 has shown
system, but none of them can help project team members to that current design methods for mechatronic system cannot fully
achieve the integrated design. On one hand, although most of these achieve the integrated design. Some product models provide the
design methods allow an effective concurrent engineering, the organisational interface, the macro level interface and the micro-
detailed design phase has not been clarified. On the other hand, level interface to support the concurrent engineering, the macro
more attention should be paid on the interfaces to help the engi- level collaboration and the micro-level collaboration respectively.
neers to accomplish both the macro level collaboration and the A synthesis on assessment of design method and product model
micro-level collaboration. will be presented in the following section.
Product model includes all the information that can be
accessed, stored, served and reused by stakeholders throughout
the entire product lifecycle. As some product models have inte- 6. Synthesis of design methods and product models
grated a part of the organisational model or process model, they
are also considered as an effective tool to support the design Several design methods and product models have been sur-
method. The assessment outcomes of different product models will veyed and assessed according to a proposed list of specific criteria.
be detailed in the following section. A synthesis will be given according to the survey and assessment
outcomes in this section.
5.2. Assessment of product models
6.1. Product model as an effective support for design method
In this section, the product models will be assessed according to
specific criteria-interface and product change. In Section 5.1, different design methods have been assessed
Considering multi-disciplinary design, three criteria linked with according to three specific criteria: concurrent engineering, macro
the concept of interface are proposed in this paper. (1) Organisa- level collaboration and micro-level collaboration. None of the
tional interfaces can guide all the design tasks and support the col- design methods have fully met these criteria. However, Section 5.2
laboration during the design process. (2) macro level interface, shows that certain interfaces which allow concurrent engineering,
which is a special link between components defined by the differ- integrated design and multi-disciplinary collaboration have been
ent disciplines involved in the design of mechatronic system, and implemented in some product models. Even process and organisa-
(3) micro-level interface, which allows the experts to use the infor- tion models have been integrated into some product models.
mation or data from other disciplines. Concurrent engineering greatly reduces the design lead-times
Considering the product change, two criteria have been pro- of mechatronic design. The assessment outcomes in Section 5.1
posed to deal with the different kinds of changes: (4) vertical show that most of design methods meet the concurrent engineer-
change and (5) horizontal change. ing principles. However, the mechatronic system becomes increas-
In this subsection, five criteria dealing with interface and prod- ingly complex. The design process should be broken down into
uct change have been chosen for assessing the product models: (1) detailed tasks which require multi-disciplinary collaboration.
organisational interface; (2) macro level interface; (3) micro-level How to organise these design tasks in a concurrent way is still a
interface; (4) vertical change; (5) horizontal change. The assess- critical issue. In order to solve this issue, some product models
ment of the product models based on these criteria will be dis- have taken organisational interfaces into account. Section 5.2
cussed in the section below. shows that the organisational interfaces have been partially met
Table 12 shows the assessment of the studied product models in STEP and MOKA model. In the IPPOP project, process model
according to the proposed criteria. With the purpose of organising and organisation model have been fully implemented (PPO model).

Table 12
Evaluation of the different data models.

Product model Organisational interface Macro level interface Micro-level interface Vertical change Horizontal change
STEP Partial Partial Partial Yes Partial
CPM No Partial Partial Partial Yes
MOKA Partial Partial No Partial Yes
PPO Yes Partial Yes Yes Partial
256 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257

Macro level collaboration pays special attention to the link principles of integrated design, engineers intend to develop a
between subsystems in order to achieve a strong integration of mechatronic system with a high level integration (integrated
them. It can bring the system perspective as a synergetic integra- mechatronic system) through a well-organised design method
tion. With the purpose of two subsystems to be interconnected, (integrated design method). As a result, two main categories of
the macro level interface can greatly enable the macro level collab- issue have been pointed out: the ‘‘Process-based problems’’ and
oration. Section 5.2 has shown that STEP, CPM and PPO models the ‘‘Design data-related problems’’. Several approaches to
have partially fulfilled the macro level interface. overcome these problems have been put forward. To solve ‘‘Pro-
The micro-level collaboration takes place among the design cess-based problems’’, a dynamic perspective is generally used to
team members and is always performed thanks to a dedicated IT present how collaboration can be improved during the mechatron-
platform. Some product models, such as STEP, CPM and PPO mod- ic design. For ‘‘Design data-related problems’’, solutions generally
els, allow implementing such IT platform for exchange of disciplin- come from product models and how to structure the data and doc-
ary data derived from design and simulation tasks. uments management of PLM throughout the whole product
Considering that none of the design methods can completely lifecycle.
meet the criteria of collaboration, certain product models can be The design tasks in mechatronic engineering are becoming
adopted during the design process to help the engineers achieve more and more collaborative and integrated. Nowadays simply
an integrated design. For instance, the assessment outcomes in manage the progress of design process is not enough. The organi-
Section 5.1 have shown that the RFLP method cannot fully support sation of design project support by the design method should be
micro-level collaboration, but the micro-level interface have been taken into account. The conclusion drawn from this paper is that
completely defined in PPO model. Moreover, a mapping can be product model is an effective support for design process of mech-
implemented between the function level of RFLP and the function atronic system. Even design process and organisation models have
class of PPO model, which makes the integration of RFLP method been linked with some product models (e.g. PPO model). Making
and PPO model becomes possible at macro level. In summary, use of the product model can help to achieve a better collaboration
product model is an effective support for design method, but a in the design process, but how to integrate the product model into
lot of work still to be done in the future. Future research will be the current design process effectively and efficiently remain a crit-
presented in the following section. ical issue.

6.2. Future work Acknowledgment

Future work should be divided into three parts. First of all, spe- This work was carried out in the framework of the LabCom
cial attention should be paid to the organisational interface in the DIMEXP, which was funded by the French government, through
design method. The second issue is to focus on improving the prod- the ‘‘Economic impact of research and competitiveness’’ program
uct model for the design of mechatronic system with a high level managed by the French National Agency of Research (Reference
integration (physical and functional integration). Last, mappings ANR-13-LAB1-0006-01).
should be constructed between design method and product mod-
els in order to achieve a global concurrent engineering and inte- References
grated design approach.
[1] J.E. Carryer, R.M. Ohline, T.W. Kenny, Introduction to Mechatronic Design,
First, organisational interface helps engineers to organise the
Prentice Hall, 2011.
design tasks properly and to achieve an effective concurrent design [2] M. Tomizuka, Mechatronics: from the 20th to 21st century, Control Eng. Pract.
approach. Two kinds of organisational interfaces should be further 10 (2002) 877–886.
[3] R. Isermann, Mechatronic Design Approach, in: R.H. Bishop (Ed.), The
studied in the future. The first one exists between the require-
Mechatronics Handbook, CRC Press, 2002. LLC.
ments and the principal solution. The second kind of organisational [4] D. Shetty, R.A. Kolk, Mechatronics system design, in: Mechatronics System
interface improves the exchange among different design team Design: SI, 2010: pp. 1–40.
members to notify the others on how their design solution affects [5] H.-P. Schöner, Automotive mechatronics, Control Eng. Pract. 12 (2004) 1343–
1351.
the other one. [6] G. Sohlenius, Concurrent engineering, CIRP Ann. – Manuf. Technol. 41 (1992)
Second, as for the product model, on one hand, the three kinds 645–655.
of interfaces above proposed should be further improved to meet [7] S. Tichkiewitch, De la CFAO à la conception intégrée, Revue Internationale de
C.F.A.O. et D’infographie. 9 (1994) 609–621.
the collaboration requirements. On the other hand, much work [8] M. Abramovici, F. Bellalouna, Service oriented architecture for the integration
should be done to improve the product change management in of domain-specific PLM systems within the mechatronic product development,
the product model in order to reduce the lead-times and the devel- in: Proceedings of the 7th International Symposium on Tools and Methods of
Competitive Engineering (TMCE 2008), Izmir, Turkey, 2008, pp. 941–953.
opment cost. [9] M. Abramovici, F. Bellalouna, Integration and complexity management within
Last, as the product model can be a valuable support for mech- the mechatronics product development, in: Advances in Life Cycle Engineering
atronic design, it should be focus on how to integrate the product for Sustainable Manufacturing Businesses, 2007, pp. 113–118.
[10] M. Bricogne, L. Petit, A.M. Meyine, N. Troussier, B. Eynard, D. Schweitzer,
model into the current design process. Although some mappings
mechatronics issues for specification of PLM functionalities and features, in:
can be implemented between design method and product model MECATRONICS2010, Yokohama, Japan, 2010.
(e.g. Function Level of RFLP and Function Class of PPO model), [11] O. Penas, R. Plateaux, J.-Y. Choley, A. Rivière, The different complexity levels in
mechatronic design process, in: 3rd International Conference on Software,
the current product models cannot be completely adapted to the
Knowledge, Information Management and Applications SKIMA, Fès, Morocco,
design method. In the future work, in order to achieve a global con- 2009.
current engineering and integrated design approach, design [12] L. Wang, W. Shen, H. Xie, J. Neelamkavil, A. Pardasani, Collaborative conceptual
method and product model should be further merged so that more design state of the art and future trends, Comput. Aided Des. 34 (2002) 981–
996.
mappings can be built between them. [13] J. Wikander, M. Törngren, M. Hanson, Emphasizing team building in a
problem- and project-based curriculum to meet the challenges of the
interdisciplinary nature of this field, Robot. Automat. Mag. 8 (2001) 20–26.
7. Conclusion [14] K. Thramboulidis, Model-integrated mechatronics—toward a new paradigm in
the development of manufacturing systems, IEEE Trans. Industr. Inf. 1 (2005)
54–61.
Integrated design for mechatronic system plays an increasingly [15] B. Bettig, J.K. Gershenson, The representation of module interfaces, Int. J.
key role for more and more smart products. According to the Product Dev. 10 (2010) 291–317.
 C. Zheng et al. / Advanced Engineering Informatics 28 (2014) 241–257 257

[16] X.F. Zha, H. Du, Knowledge-intensive collaborative design modeling and [43] M.J. Pratt, Introduction to ISO 10303 – the STEP standard for product data
support, Comput. Ind. 57 (2006) 39–55. exchange, J. Comput. Inform. Sci. Eng. 1 (2001) 102–103.
[17] F. Wang, S.J. Fenves, R. Sudarsan, R. Sriram, P. Group, M. Systems, et al., [44] P. Gu, K. Chan, Product modelling using STEP, Comput. Aided Des. 27 (1995)
Towards modeling the evolution of product families, in: ASME Computers and 163–179.
Information In Engineering Conference, Chicago, USA, 2003. [45] G.L. Smith, Utilization of STEP AP 210 at the boeing company, Comput. Aided
[18] B.S. Blanchard, System Engineering Management, John Wiley & Sons, 2012. Des. 34 (2002) 1055–1062.
[19] B.W. Boehm, Software Engineering Economics, Prentice Hall, 1981. [46] R. Jardim-Goncalves, N. Figay, A. Steiger-Garção, Enabling interoperability of
[20] B.W. Boehm, A spiral model of software development and enhancement, STEP application protocols at meta-data and knowledge level, Int. J. Technol.
Computer 21 (1988) 61–72. Manage. 36 (2006) 402–421.
[21] K. Forsberg, H. Mooz, System engineering for faster, cheaper, better, in: [47] ISO10303-233, Industrial Automation Systems and Integration – Product Data
Proceedings of the 9th Annual International Symposium of the INCOSE1998, Representation and Exchange – Part 233: Application Protocol: Systems
Vancouver, Canada, 1998: pp. 1–8. Engineering, ISO, 2012.
[22] G.A. Hazelrigg, Systems Engineering: An Approach to Information-Based [48] J. Lefèvre, S. Charles, M. Bosch-Mauchand, B. Eynard, E. Padiolleau,
Design, Prentice Hall, Upper Saddle River, 1996. Multidisciplinary modelling and simulation for mechatronic design, J. Des.
[23] G. Pahl, W. Beitz, J. Feldhusen, K.H. Grote, Engineering Design: A Systematic Res. 12 (2014) 127–144.
Approach, Springer, 2007. [49] T. Paviot, V. Cheutet, S. Lamouri, A PLCS framework for PDM/ERP
[24] Q. Li, W.J. Zhang, L. Chen, Design for control – a concurrent engineering interoperability, Int. J. Prod. Lifecycle Manage. 5 (2011) 295–313.
approach for mechatronic systems design, IEEE/ASME Trans. Mechatron. 6 [50] ISO10303-210, Industrial Automation Systems and Integration – Product Data
(2001) 161–169. Representation and Exchange – Part 210: Application Protocol: Electronic
[25] N. Gautam, N. Singh, Lean product development: maximizing the customer Assembly, Interconnect, and Packaging Design, ISO, 2011.
perceived value through design change (redesign), Int. J. Prod. Econ. 114 [51] ISO10303-214, Industrial Automation Systems and Integration – Product Data
(2008) 313–332. Representation and Exchange – Part 214: Application Protocol: Core Data for
[26] A.A. Alvarez Cabrera, M.J. Foeken, O.A. Tekin, K. Woestenenk, M.S. Erden, B. De Automotive Mechanical Design Processes, ISO, 2010.
Schutter, et al., Towards automation of control software: a review of [52] ISO10303-239, Industrial Automation Systems and Integration – Product Data
challenges in mechatronic design, Mechatronics 20 (2010) 876–886. Representation and Exchange – Part 239: Application Protocol: Product Life
[27] Department of Transportation, Systems Engineering for Intelligent Cycle Support, ISO, 2005.
Transportation Systems, Washington, DC, USA, 2007. [53] S.J. Fenves, S. Foufou, C. Bock, R.D. Sriram, CPM: a core model for product data,
[28] C. Koch, A. Spröwitz, T. Ströhla, Project course ‘‘Design of Mechatronic J. Comput. Inf. Sci. Eng. (2006) 1–14.
Systems’’, in: IEEE International Conference on Mechatronics (ICM 2006), [54] S.J. Fenves, A Core Product Model for Representing Design Information,
Budapest, Hungary, 2006, pp. 2–5. Gaithersburg, USA, 2002.
[29] A.B. Fotso, R. Wasgint, R. Achim, State of the art for mechatronic design [55] S.J. Fenves, S. Foufou, C. Bock, R. Sudarsan, N. Bouillon, R.D. Sriram, CPM2: A
concepts, in: 8th IEEE/ASME International Conference on Mechatronic and Revised Core Product Model for Representing Design Information,
Embedded Systems and Applications, Suzhou, China, 2012, pp. 232–240. Gaithersburg, USA, 2004.
[30] J. Bathelt, A. Jonsson, C. Bacs, S. Dierssen, M. Meier, Applying the new VDI [56] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language User Guide,
Design Guideline 2206 on mechatronic systems controlled by a PLC, in: Addison-Wesley, 1998.
International Conference on Engineering Design (ICED 05), Melbourne, [57] X.F. Zha, S.J. Fenves, R.D. Sriram, A feature-based approach to embedded
Australia, 2005, pp. 1–14. system hardware and software co-design, in: ASME Design Engineering
[31] V.S. Vasi, M.P. Lazarevic, Standard industrial guideline for mechatronic product Technical Conference, Long Beach, USA, 2005, pp. 1–12.
design, FME Trans. 36 (2008) 103–108. [58] C. Xu, S.k. Cupta, Z. Yao, M. Gruninger, Towards computer-aided conceptual
[32] S. Kleiner, C. Kramer, Model based design with systems engineering based on design of mechatronic devices with multiple interaction-states, in:
RFLP using V6, in: Proceedings of the 23rd CIRP Design Conference, Bochum, Proceedings of the ASME Design Engineering Technical Conferences, Long
Germany, 2013, pp. 93–102. Beach, CA, USA, 2005.
[33] J. Lefèvre, S. Charles, M. Bosch-Mauchand, B. Eynard, É. Padiolleau, Towards [59] C.B. Chapman, M. Pinfold, The application of a knowledge based engineering
multidisciplinary modeling and simulation: Interoperability issues and approach to the rapid design and analysis of an automotive structure, Adv.
challenges for mechatronic engineering, in: Proceedings of the 9th Eng. Softw. 32 (2001) 903–912.
International Symposium on Tools and Methods of Competitive Engineering [60] K. Oldham, S. Kneebone, M. Callot, A. Murton, R. Brimble, MOKA – a
(TMCE’2012), Karlsruhe, Germany, 2012. methodology and tools oriented to knowledge-based engineering
[34] G. Beier, A. Figge, R. Müller, U. Rothenburg, R. Stark, Supporting product applications, in: Proceedings of the Conference on Integration in
development through cross-discipline dependency-modeling – novel Manufacturing, Goteborg, Sweden, 1998, pp. 198–207.
approaches for traceability-usage, Lect. Notes Inform. Theor. 1 (2013) 21–28. [61] MML Working Group, MOKA user guide (MOKA modelling language core
[35] P. Hehenberger, M. Follmer, R. Geirhofer, K. Zeman, Model-based system definition), Technical Report, 2000.
design of annealing simulators, Mechatronics 23 (2013) 247–256. [62] F. Noël, L. Roucoules, The PPO design model with respect to digital enterprise
[36] P. Hehenberger, F. Poltschak, K. Zeman, W. Amrhein, Hierarchical design technologies among product life cycle, Int. J. Comput. Integr. Manuf. 21 (2008)
models in the mechatronic product development process of synchronous 139–145.
machines, Mechatronics 20 (2010) 864–875. [63] F. Noël, L. Roucoules, D. Teissandier, Specification of product modelling
[37] S. Rachuri, S.J. Fenves, R.D. Sriram, F. Wang, A product information modeling concepts dedicated to information sharing in a collaborative design contexte,
framework for product lifecycle management, Comput. Aided Des. 37 (2005) in: 5th International Conference on Integrated Design and Manufacturing in
1399–1411. Mechanical Engineering (IDMME’04), Bath, UK, 2004, pp. 135–146.
[38] X. Tang, H. Yun, Data model for quality in product lifecycle, Comput. Ind. 59 [64] P. Nowak, B. Rose, L. Saint-Marc, M. Callot, B. Eynard, L. Gzara-Yesilbas, et al.,
(2008) 167–179. Towards a design process model enabling the integration of product, process
[39] B. Eynard, T. Gallet, P. Nowak, L. Roucoules, UML based specifications of PDM and organisation, in: 5th International Conference on Integrated Design and
product structure and workflow, Comput. Ind. 55 (2004) 301–316. Manufacturing in Mechanical Engineering (IDMME’04), Bath, UK, 2004: pp.
[40] SCRA STEP Application. Step Application Handbook ISO 10303 Version 3, Hand 91–103.
Book; 2006. [65] J. Le Duigou, A. Bernard, N. Perry, Framework for product lifecycle
[41] ISO10303-1. Overview and Fundamental Principles, ISO; 1994. management integration in small and medium enterprises networks,
[42] S.J. Kemmerer, STEP: The grand experience, US Department of Commerce, Comput.-Aided Des. Appl. 8 (2011) 531–544.
Technology Administration, National Institute of Standards and Technology,
Gaithersburg, USA, 1999.