Computers in Industry 105 (2019) 213–228

Contents lists available at ScienceDirect

Computers in Industry
journal homepage: www.elsevier.com/locate/compind

Collaborative design process and product knowledge methodology for

mechatronic systems
Mehdi Mchareka,* , Moncef Hammadia , Toufik Azibb , Cherif Laroucib , Jean-Yves Choleya
a
Laboratoire Quartz (EA7393), Supméca, 3 rue Fernand Hainaut, 93400 Saint Ouen, France
b
Estaca’Lab, Estaca, 12 Avenue Paul Delouvrier, 78180 Montigny-le-Bretonneux, France

A R T I C L E I N F O A B S T R A C T

Article history: Recent advances in design techniques promote the development of concurrent engineering to reduce the
Received 15 May 2018 time and cost of the design cycle. This is particularly necessary for mechatronic design which involves
Received in revised form 3 October 2018 several disciplines. But companies have to address challenges associated with collaboration and reuse.
Accepted 12 December 2018
The mechatronic design evolves from the system level to the multiple-disciplinary level. This requires
Available online xxx
that system engineers and disciplinary engineers collaborate closely for an integrated and continuous
product development process. However, the heterogeneity of tools used in system level and disciplinary
Keywords:
level with the lack of a common knowledge basis creates a gap between them. Thus, the focus of this
Knowledge management
Collaboration
paper is to develop a knowledge management framework suitable for mechatronic concurrent design
Design process and capable to harmonize the overall design cycle. Our contribution lies in structuring knowledge at the
Systems engineering system and disciplinary levels to ensure the traceability between them. Our methodology called
Mechatronic systems Collaborative Design Process and Product Knowledge (CDPPK) is detailed with the associated meta-
model. A demonstrator is also presented and applied successfully to a collaborative industrial scenario
concerning the Electronic Throttle Body (ETB).
© 2018 Elsevier B.V. All rights reserved.

1. Introduction engineers to manage changes in requirements and access dynamic

Mechatronic systems encompass a variety of disciplines,
including control, electrical and software. It requires a complex
combination of these disciplines to accomplish the entire requisite
functionality [1]. Each one of them independently focuses on a
particular aspect of the system and exploits different Disciplinary
Engineering (DE) tools for technical analysis. Such multiplicity of
tools and methods renders the mechatronic design quite complex.
Systems Engineering (SE) approach was proposed to manage this
issue. It provides a common communication platform between
different stakeholders at the system level, ensuring that each
discipline meets the system requirements [2]. Although these
efforts, a benchmark report about mechatronic design challenges
shows that 44% of the manufacturers have a problem with
understanding and fulfilling requirements [3]. To attain the full
benefit of SE in concurrent engineering, there is a critical need to
create links between system engineers and disciplinary engineers.
Research reports a gap between SE and DE, resulting in costly
failures to meet system requirements [4]. Solutions must support
the collaboration between the two levels, allowing system
* Corresponding auhtor.
E-mail address: mehdi.mcharek@supmeca.fr (M. Mcharek).
decisions made during the design cycle, and disciplinary engineers
to solve their conflicting objectives and to stay consistent with the
system level to reduce iterations. The time lost accumulates when
it comes to reuse previous work because of the lack of a common
reference. This can be reached by creating a common support for
system and disciplinary engineers to share their knowledge in a
dynamic manner. Knowledge is defined as information associated
with a context of use. It generates value to a company through its
use and sharing but this requires that the people receiving
knowledge are able to interpret the shared knowledge [5]. Hence,
we need to communicate the knowledge between SE and DE in a
convenient way for both parties to optimize the design process.
This paper describes a methodology to harmonize the design
cycle of mechatronic systems. It is an attempt to create a link
between SE and DE by means of Knowledge Management (KM) and
conflicts resolution. Our goal is to facilitate the collaboration, in a
more formal way than social communication, and consequently
simplifying the knowledge reuse.
The paper is organized as follows: Section 2 presents the main
issues associated with mechatronic systems. Section 3 presents the
related works. Section 4, gives details about the existing Knowledge
Configuration Model (KCM) and its limits. Section 5, outlines our new
framework Collaborative Design Process and Product Knowledge
(CDPPK) and the associated methodology. In Section 6, we present a

https://doi.org/10.1016/j.compind.2018.12.008
0166-3615/© 2018 Elsevier B.V. All rights reserved.
214 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228
real industrial scenario for the collaborative design of an Electronic
Throttle Body (ETB) controller. In this scenario, we successfully apply
the different steps of our methodology using an implemented proof
of concept. The limits and the outlook of our work are detailed in
Section 7. Finally, we conclude this paper by addressing our future
research.
2. Mechatronic design cycle
The mechatronic design was considered as a sequential process
in which a design solution is generated following a series of
prescribed steps from requirements to validation [6]. However, the
complexity of multidisciplinary design showed the limits of this
approach. Therefore, the V-model was widely adopted by
industrials [7]. Then, it was standardized for mechatronics in
VDI 2206 guideline [8]. This model is composed of two main
phases: the” top-down” step which corresponds to the definition
of the system and its properties according to the requirements,
the” bottom-up” phase which aims to validate and integrate the
different technologies of the product (Fig. 1).
The first phase is mainly managed by system engineers and the
second phase by disciplinary engineers. We can resume this
process in five steps:
Step1: Product Requirements
The customer requirements are identified in this step. A good
understanding of customer requirements is the key to provide the
suitable system [9]. Requirements should be clear and concise
because this step is essential to have a first estimation of
the resources and time allocation.
Step2: Conceptual Design
Based on the requirements, system engineers identify the
different functions of the system. This provides a greater
understanding of the system complexity. For each function, a
functional subsystem is defined [10]. Therefore, we can obtain
different architectures depending on the chosen functional
subsystems. Functional and architectural design can be combined
into conceptual design [11]. This step is important because it has a
direct impact on the main parameters, properties, and cost.
Step3: Detailed Design
The detailed design step is between the two phases. The
previously defined architecture is transformed into technical
solutions by associating physical components to the functional
Fig. 1. Mechatronic V cycle (adapted from VDI Guideline).
subsystems. The overall design problem is partitioned into
disciplinary models. In this step, the system begins to take shape
and the first analyses are made to model the system [12].
Step4: Verification & Integration
Several analyses and simulations are made in this step to test
the system against physical laws. The goal is to recompose the
system and evaluate the integration of the different components
[13]. The properties depending on the nature of the components
(thermodynamic, vibration, dimensions . . . ) and the require-
ments are verified and analyzed.
Step5: System Validation
In this final step, the requirements related to the global system
are validated. This validation can be experimental or virtual using
analysis tools and multidisciplinary design optimization [14].
Within the design cycle, definition and integration phases
should be interconnected. We have initially incomplete require-
ments which gain completion during the integration phase. Also,
conflicts in disciplinary design lead to changes in the architecture
defined by system engineers. There is a critical need to create links
between SE and DE to close the gap between them as reported in
many works [15,16]. This fragmentation is due to several reasons:
 The nature of the results is different between the two phases
(qualitative vs quantitative) [17].
 Different views and perspectives about the system (hierarchical
decomposition vs disciplinary decomposition) [18].
 Incompatible tools used by system engineers (UML, SysML.) and
disciplinary engineers (CAD, CAE, FEM.) [19].
 The lack of standards exchange model for orchestrating the
design cycle across the multiple disciplines [20].
 Semantic mismatch between system level and disciplinary level
(general and abstract vs detailed and concrete) [21].
The gap between system and disciplinary engineers affects
decision making and lead to additional design and development
iterations [22]. The interoperability between the two phases is the key
success factor in concurrent engineering. A product may be innovative
and efficient, but if it does not satisfy the customer requirements, it is a
useless product. Thus, the iterations between system decomposition
and system integration are inevitable. An environment allowing actors
from the two phases to exchange their results and coordinate their
actions is necessary. Such interest is also highlighted by the recent
 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228
creation of Systems Modeling & Simulation Working Group (SMSWG)
between the International Council on Systems Engineering (INCOSE)
and the International Association of the Engineering Modelling
representing SE with Analysis and Simulation Community (NAFEMS)
representing DE [23]. This recent joint relationship highlights the
importance of the integration between SE and DE. The next section
details the related works in this area.
3. Related works
Torry-Smith argues in his survey that the most reported
challenges in mechatronic design are related to how information
linked to the product concept can be shared across engineering
disciplines [24]. In industry, Product Lifecycle Management (PLM)
offers collaborative solutions for product-centric environments. It
applies a set of tools and technologies that provide a shared
platform for collaboration among product stakeholders [25].
However, PLM is not enough to cover the complexity of
mechatronic collaborative design and its heterogeneous tools
[26]. This issue is amplified when a company works with partners
and suppliers with different PLM-systems [27]. To overcome this
situation, engineers resort to informal collaboration channels
(email, meeting, phone . . . ). These means are no longer sufficient
in concurrent engineering for they lead to unnecessary iterations
and lack of traceability [28]. Therefore, in our situation, to connect
effectively SE and DE we need formal means to share the
knowledge of stakeholders in a dynamic way. In this section, we
present solutions related to this context.
3.1. SysML-based solutions
SysML is the leading standardized language in systems
engineering. This graph-based language is used to decompose
the system and allocate the requirements. SysML offers nine
diagrams describing the different aspects of the system [29]. Many
efforts in the SE community aim at integrating SysML with DE
tools. For instance, links have been established between SysML and
different DE tools to generate detailed disciplinary models from
the system model. This was realized with analysis models [30],
simulation models [31] and control models [32]. As a result, the
manual translation from system models to disciplinary models can
be minimized to increase efficiency. However, this solution is
restricted to some DE tools and does neither support the feedback
from disciplinary engineers nor their collaboration.
A methodology was proposed to deal with this issue by linking
online SysML and DE tools in [33]. Three levels are considered in this
approach: requirements level, element level, and attribute level. The
lowest level here is the attribute level and consists on parameters
that are important for the collaboration. These parameters are
modelled in specific SysML diagrams and assure the link with DE
tools parameters. In the same context, SLIM platform was provided to
deal with this integration issue [34]. This platform creates
connectivity patterns between SysML models and DE models. Then
it checks the changes and updates the two models of the connection.
These solutions simplify considerably the work of system
engineers. They can check architectures and realize an easy trade-
off based on SysML diagrams. SysML here captures the product
knowledge, however, the traceability of the collaboration is
missing. This makes the collaboration and reuse phases difficult
in a mechatronic context.
3.2. Ontology-based solutions
Collaborative mechatronic design is vulnerable to model
inconsistency. Managing inconsistencies between SE and DE is a
key enabler to efficient collaborative engineering and reuse.
215
Solutions were proposed in the literature to deal with this problem
using ontology. Ontology-based solutions aim to solve the problem
of semantic mismatch between different modelling languages
[35]. A semantically based visual tracking of engineering tools was
proposed in [36]. This model aims to give a graph overview of the
product development and flexible data insights on collaboration. A
query system is used to facilitate the reuse of this graph and
optimize the design process. This solution can be adapted in our
context because it does not allow to solve dynamically the conflicts
between stakeholders. An interesting solution was proposed to use
ontology to enhance the quality of disciplinary models and to
support stakeholders in the design process [37]. The idea is to
propagate changes from a DE model to another using an
engineering ontology graph. The system level is partially consid-
ered in this work in terms of requirements checking but the
collaboration between system and disciplinary engineers was not
adressed. Similarly, a multiview-point model was proposed in [12],
focusing on dependency between people, model and tool levels.
The dependency is visualized using semantic web solution for inter
and intra viewpoints. This models permits consistency checking
and supports collaborative design. It gives an interesting holistic
view of the system but it does not propose means to exchange
dynamically between engineers.
3.3. Parametric-based solutions
Solutions are proposed in the literature to manage the design
parameters in collaboration and reuse phases. COLIBRI (Constraint
Linking Bridge) is completely dedicated to constraints linking
parameters between heterogeneous expert models. This model
allows the connection between parameters encapsulated in
heterogeneous models through the integration of constraints,
taking into account the structure of the product [38]. The
constraints are classified into mechanical and electrical domains
respectively. Based on this classification, the disciplinary and the
cross-disciplinary constraints of a mechatronic system can be
managed. This solution is interesting to manage inconsistency
between SE and DE but it does not provide product knowledge
structure for reuse. Other solutions focus on creating a central
model to connect the design parameters and manage the changes.
The PROxIMA (PRocess Optimization Inconsistency MAnagement)
framework is a collaborative environment based on design
parameters and design process using Design-Structure Matrix
view [39]. The DSM enables reasoning on inconstancies, their
origin and impact and therefore adopt the design process. However
this solution does not address conflicts between stakeholders. KCM
(Knowledge Configuration Method) is another example parameter-
based solutions using configurations synchronized with DE tools.
KCM focuses on the couple product-simulation, the considered
knowledge consists of parameters and expert rules organized in
order to ensure parameters consistency [40]. This methodology
was tested in an industrial project and other related works have
been made on conflicts managements and tools interoperability
[41].
Consistency-based solutions are very interesting in our context.
They give the possibility to manage knowledge in concurrent
environments and support dynamic exchange. We choose KCM as a
starting point for our methodology, as it will be explained in the
following section.
4. Knowledge configuration model (KCM)
4.1. KCM: academic and industrial aspects
The first objective of KCM is to enable designers to use
parameters consistently in collaborative design. In fact, the lack of
216 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228
communication among different steps of the design cycle causes
consistency problems in parameters. In CE, all participants need to
access all relevant up-to-date product information. This method-
ology is based on the concept of crucial knowledge to keep the
design models consistent with each other [42]. Crucial knowledge
refers to the sufficient and necessary knowledge to the activity of a
company [43]. Here, the knowledge consists of contextualized
parameters and rules that are critical for the collaborative product
development. Therefore, this crucial knowledge is structured
and has its own lifecycle according to the guiding GAMETH
framework [44].
As illustrated in Fig. 2, the main concepts in KCM are [45]:
- Information Core Entity (ICE): An indecomposable generic entity
that can capitalize crucial data extracted from business models
and experts in order to move from the data state to the
information state. It is composed of parameters and generic
constraints.
- Knowledge Configuration (KC): Contains the ICEs that will be used
in the collaboration. Consistency issues are solved in this
configuration. It should be noted that the parameters in this
configuration are of no value at the initial state of the project.
- Usage Configuration (UC): Contains ICE instances (instances of
the ICEs created in KC). It represents the expert interface and it is
synchronized with the expert models. At this state, parameters
acquire value.
Each user of the design process can create his own configuration
(UC) independently of other users. Thus, an ICE can be instantiated
in several configurations at the same time, and each configuration
is synchronized with an expert model. To ensure knowledge
consistency, the configurations are analyzed and possible conflicts
are reported. In fact, the configuration analysis traces the
information of ICE instances and detects inequality between two
Fig. 2. Knowledge Configuration Method (KCM) overview.
instances of ICEs used in parallel in two design activities.
Accordingly, actors end up having all the information to maintain
coherence in their collaboration and converge to a global solution
[46]. KCM inspired works have been achieved in academic and
industrial domains [47]. The issue of synchronizing disciplinary
tools and KCM database has been accomplished by using SOAP web
service protocols [41]. Industrially speaking, the ADN project
tested the first prototype of KCM and provided reliable feedbacks.
Conflicts management and decision making in KCM have been
improved. Additionally, a patent with solutions for units checking
and semantic interoperability of the parameters is proposed [48].
4.2. Limits of KCM
As we can notice, ICE is at the heart of this methodology. This
entity contains all the information and constitutes a cross-
functional baseline. The KCM partially solves our initial problem-
atic. Indeed, it facilitates the exchange between the DE tools in the
integration phase. Yet, it is not the case regarding the exchange
with SE tools. Here are listed the limits of this model:
 The ICEs are indecomposable and may be unsuitable for all the
actors. In the decomposition phase, ICEs are created and filled
according to the system engineer’s view. Whereas, this structure
of ICEs may not reflect the view of disciplinary designers.
 By instantiating the whole ICE, disciplinary engineers may find
some important parameters and other useless parameters. This
can mislead them in their tasks.
 The KCM detects conflicts between users but does not manage
decision making [49].
 The knowledge reuse is difficult because there is no traceability
of the design process. It is important to save the final values of
the project parameters but there is no information about how
the parameters were calculated [50].
 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228
 The collaboration is managed by one person who checks the
consistency between ICEs. This centralized way is efficient for
validation but not suitable for concurrent collaboration.
As a result, system engineers and disciplinary engineers have
problems accessing the information they need and also to
understand previous projects. Our idea is to create a new model
based on KCM, by keeping its positive features (connection to PLM,
configuration management, consistency check) and solving the
previously mentioned limits.
5. New collaborative design model
Mechatronic design deals with multi-disciplinary models. Any
change in one discipline leads to a different design process.
Therefore, the synchronization and the collaboration between the
disciplines are essential. We propose in this research a new
methodology based on Knowledge Configuration Methodology
(KCM). Our approach is to study the existing limits of the KCM and
contribute to a new tailored methodology adapted to our initial
problematic. Our model called Collaborative Design Process and
Product Knowledge (CDPPK) and its methodology are principally
based on academic research and feedbacks from industrials
involved in our project.
5.1. Collaborative design process and product knowledge (CDPPK)
model
One may wonder how we can adapt the already available KCM
approaches in a way that covers the entire design cycle. Our goal is
to manage and communicate knowledge between the decomposi-
tion phase and the integration phase. Our framework aims at
Fig. 3. Collaborative Design Process and Product Knowledge (CDPPK) overview.
217
overcoming collaboration and reuse issues. For collaboration, a
new way of viewing the product is necessary, in order to find
solutions that lie across disciplinary boundaries. For the reuse, the
current KCM focuses on declarative knowledge (know-what). This
knowledge is important to understand the product but should be
completed by process intents (know-how) to facilitate the
project reuse.
Our new approach, illustrated in Fig. 3, is inspired by KCM
structure and our contribution lies firstly on reorganizing param-
eters in order to facilitate collaboration. In fact, all parameters
involved must be reflected in a well formalized conceptual
infrastructure to ensure an effective connection between SE and
DE environments. On one hand, we propose the use of ICEs as a point
of reference for system engineers. On the other, disciplinary
designers are only to instantiate the parameters that they need
from specific ICEs. Accordingly, these disciplinary engineers become
detached from the conceptualization of the ICEs. Moreover, each
parameter is to have an in/out flow in order to orchestrate the
collaboration. We propose the following structure for our approach:
- Information Core Entity (ICE): We keep the concept of ICE in this
methodology to capitalize knowledge. The difference with the
previous methodology is that ICE is considered here as an
organizational structure for the decomposition phase. System
engineers use ICE to decompose the system into functional
subsystems and save the associated parameters and constraints.
Therefore, ICE is used here to transform product data into
product information.
- Design Product Knowledge (DPK): DPK contains all the ICEs used
in the project. After the collaboration, these ICEs will contain the
final product results. Thus, DPK generates product knowledge
from information stored in ICEs.
218 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228
- User Process Configuration (UPC): This new class differs from the
UC defined in KCM. Instead of affecting a block of parameters in
the form of ICE instances, we propose to break ICEs and give the
flexibility to disciplinary engineers in the choice of parameters
that they need. The contribution is to define inputs and outputs
for the instantiated parameters. This considerably facilitates the
collaboration and data exchange between users and helps to
construct a collaboration network. UPC is considered here as a
design process information.
- Collaborative Design Process (CDP): It groups the UPCs present in
the collaboration. In CDP, we can generate a global collaboration
process. It characterizes the originality of this approach by
achieving the traceability of the collaboration evolution for
reuse perspective. This collaboration graph presents the design
process knowledge. The collaboration management is also
carried out in CDP as detailed in the next section
This new model is adapted to the decomposition phase. Each
functional subsystem is represented by an ICE. Then, in the
integration phase, each DE tool is represented by a UPC. We notice
that the knowledge cycle (data-information-knowledge) for the
design process and product is respected. The UML metal-model of
CDPPK framework is shown in Fig. 4. The different classes and
connections are represented between the entities defined previ-
ously. This model is based on Configuration Management (CM)
defined in ISO 10,007:2003 standard and 2015 release [51]. CM
carries the access to the adequate information relative to product
design, realization, verification and use. This information is
organized in a “global configuration” which is updated and
versioned to trace the evolution of the product. In CDPPK, this
organizational concept is the Knowledge Configuration (KC). The
standard defines also “configuration items” that are components of
Fig. 4. CDDPK meta-model.
the global configuration to ensure the final use of information and
allow users to converge to a single product. In our model, these
items are the UPCs.
5.2. Collaborative design process and product knowledge methodology
Actors in the design cycle are submerged in a heterogeneous
tools environment and information flow. They collaborate with
traditional and informal ways (email, meeting . . . ). These ways
are error-prone and impossible to trace for reuse perspectives.
Whereas, if we have effective collaboration we can acquire not only
short-term benefits, during the product development, but also
long-term ones, during the reuse process. KM was proposed to
improve collaboration performance in mechatronic design. Never-
theless, it is not limited to its technological approach for it, also,
includes a sociotechnical approach which considers knowledge as
a resource participating in companies' performance [52]. A very
common problem of a failed collaborative framework is that it does
not meet the users’ real tasks. Therefore, the CDPPK’s methodology
is created with regards to the mechatronic design cycle (Fig. 5).
Each step is adapted to each stakeholder involved in the design
cycle and their needs.
Step1: Project Requirements
The project manager analyses the requirements of the
customer. Accordingly, they create a Knowledge Configuration
and identify the actors needed for each step. Their main objective is
to lead the team towards accomplishing the project.
Step2: Conceptual Design
Based on customer requirements, system engineers define the
functions of the system. They can explore several architectures
according to the defined functions, in this paper, we will focus on
the development of one architecture. Our hypothesis is to
 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228
Fig. 5. CDPPK methodology overview.
decompose the system into functional subsystems. Each one of the
latter is represented by an ICE. The available parameters and
constraints (from requirements and previous works) are added in
this phase to the ICEs.
Step3: Detailed Design
Here, the previously created ICEs are enriched with all the crucial
parameters necessary for the integration phase. To do so, we
recommend a meeting between the different stakeholders. A
knowledge expert can also capitalize the crucial knowledge
necessary for the collaboration. Automatic extraction methods exists
also using ontology-based solutions. This step is a direct intermediate
between the decomposition and the integration phases.
Step4: Verification & Integration
In this step, disciplinary engineers create their own User
Configuration Process (UCP). Each engineer instantiates the param-
eters that they need in their own UPC. Then, they instantiate the
parameters to link with their DE model. Then, the in/out flow is selected
for each parameter. When all the engineers have filled their UPC, the
collaboration starts and the exchange of the parameters follows the
network generated by different parameters flows. Each designer gets to
know which UPCs are currently related to their work. Each UPC has a
collaboration state to manage the exchange (Start/Ready/In Progress/
Publish). We will further explain this point in the following section.
Step5: System Validation
Thanks to the product knowledge in DPK and the
process knowledge in CDP, the project manager has a holistic view
of the design cycle. They need to check the collaboration state and the
recorded conflicts between system engineers and disciplinary
designers in order to assess the situation and make decisions.
This methodology enables each stakeholder to access and use
the right knowledge. At this point, Knowledge becomes of great
value for the company. In managerial terms, our methodology
219
moves from the traditional predefined collaboration process to a
more dynamic and flexible one. It provides a common basis of
exchange adapted to SE and DE views and does not disrupt the
tasks of the stakeholders. The main inconvenience of such
methodology is the need to convene the different stakeholders
that formalizing knowledge might be time-consuming but have
high long-term benefits. In addition, this formalization in
mechatronic context will facilitate considerably the conflicts
resolution between disciplinary and system engineers.
5.3. Conflicts resolution
Web technology communication can ensure the exchange of
information between different actors but when it comes to
complex multi-stakeholder problem resolution, it does not
succeed to provide active supports to resolve conflicts. In
collaborative design, a conflict is an incompatibility between
two (or more) design decisions. According to our methodology,
conflicts are generated when parameters’ values do not respect the
constraints. The constraints associated with the parameters can be
system constraints (defined at the beginning in the ICE) or
interdisciplinary constraints (defined in UPC during the second
phase). Therefore, system constraints help us manage requirement
changes and interdisciplinary constraints help us to manage
conflicts between disciplinary engineers (Fig. 6). We defined
collaboration states for UPC and CDP in order to organize the
conflict resolution process. Each UPC has four collaboration states
in accordance with the four facets of knowledge management cited
by Grundstein: identify, formalize, value and update [53]:
- Start: In this initial state, actor instantiates the needed
parameters
220 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228
Fig. 6. Conflicts resolution in CDPPK.
- Ready: When all the parameters and the flows are assigned, the
actor switches to “Ready” state to indicate their readiness to
collaborate. They can receive in this state input parameters from
collaborators who published their work.
- Publish: When the actor finishes their tasks, they switch to
“Publish” state. All the output parameters will be sent to the other
collaborators. Each publication upgrades the version of the UPC.
- Conflict: When a parameter value does not respect the
constraint (system constraint or interdisciplinary constraint),
the user switch to conflict state and the concerned collaborators
are informed automatically.
In parallel, the CDP has its own cycle:
- In progress: When one or many UPCs are in start state, it means
that they didn’t choose all the parameters they need.
- Process: When all UPCs are in ready status, it means that actors
defined all the parameters and flows. The collaboration graph
can be generated in this state.
- Collaboration: When all actors are publishing their work and/or
solving their conflicts. In the case of an unresolved conflict, the
project manager intervenes to provide a balanced solution based
on compromises in global vision.
- Validation: When all UPCs are in Publish status. In this state, the
final values of the collaboration are saved in DPK inside ICEs and
the final collaboration graph is saved in CDP.
Developing products without a good collaborative environment
can result in unnecessary iterations, higher development costs, and
quality problems. This methodology assists designers finding optimal
solutions and making decisions by structuring knowledge for different
actors. The process knowledge plays an important role in decision
making and collaboration as it will be explained in the next section.
5.4. Collaboration graph
The collaboration management in CDPPK is based on graph
theory [54]. To generate collaborative graph process and manage
the exchange of knowledge we propose to generate a
unidirectional graph constituted of edges and analysis blocks.
Each analysis block represents a UPC and the edges represent the
exchange of parameters between the UPCs. A graph approach to
problem formulation for multidisciplinary design analysis and
optimization is presented in [55]. Two kinds of graphs are
considered:
- Maximal Connectivity Graph (MCG): Represents all the possible
interconnections between DE tools.
- Fundamental Connectivity Graph (FCG): Simplification of the
MCG to represent only the tools and the connections necessary
to solve an engineering problem.
The approach is based first on Fundamental Problem Formula-
tion (FPF). It is a general way to present an engineering or
optimization problem by specifying the objectives to minimize, the
constraints to respect and the design variables [56]. Based on this
formulation, there are two limits to this approach. The first limit is
the difficulty to create the MCG when the models are dynamic. In
fact, when only one analysis block changes this will affect the
whole MCG graph. Second, one cannot have all the information
needed to transform MCG into FCG. In our approach, we create
directly an FCG. We propose to implicate actors in the creation of
the global graph by recovering their work in UPCs that represent
the nodes that constitute the FCG. Given the nature of UPCs, the
FPG can be generated dynamically at any moment.
As illustrated in Fig. 7, analyses are considered as bocks with
inputs and outputs:
- Parameter connecting two analyses blocks is a coupling variable
(out 1 of analysis 1 for example)
- Parameter without flow is a shared variable
- Output parameter without a connection and without a
constraint is an objective variable
- Output parameter without a connection and with a constraint is
a constraint variable
- Input parameter with two entries is a decision node (when two
multi-fidelity analyses output the same parameter as analysis
block 1 and analysis block 2 for example)
 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228 221

Fig. 7. Graph representation approach.

The final collaboration graph is considered as process
knowledge. It helps us to understand the different decisions made
during the design process and to reproduce the experts reasoning.
In addition, this traceability avoids duplication and inconsistency
of data which are processed separately. This knowledge gives also
actors the opportunity to anticipate problems by taking into
consideration previous experiences. A demonstration of the
methodology will be described in the next section.
- Rising time (from 11,5deg to 90deg) lower than 240ms
- Return time (from 90deg to 11,5deg) lower than 140ms
- Static error at maximum aerodynamic torque lower than 0.8deg
The environment of the system is:
- A pressure drop between 20 and 120mbar
- Temperature between -20 and 140  C

6. Industrial case study The project manager analyzes the requirements and affects the
actors of the project.
In order to illustrate the capacity of our methodology, we
6.2. Step2: conceptual design
present a concrete mechatronic collaborative design scenario. The
case study refers to an Electronic Throttle Body (ETB) controller.
In this step, the system functions are outlined with the
The ETB is a mechatronic system that controls the intake air of the
associated functional subsystem. In the Design Product Knowl-
engine. The system consists of a DC motor, a gearbox, a failsafe
edge, system engineers define the next ICEs:
system with two springs related to the gearbox, a valve and a
position sensor (Fig. 8). The failsafe system is used when the
- Motorization function: ICE_DCMotor
control system fails, the springs keep the valve at the Limp Home
- Control function: ICE_Controller
position (in our case 11.5 deg) in order to provide the necessary
- Transmission function: ICE_Gearbox
flow to keep the engine running [57]. In fact, this nonlinear system
- Air regulation function: ICE_Valve
is multi-physical (control, fluid, mechanics . . . ) and interesting to
apply our methodology. A collaborative scenario implying various
An ICE_System is also created to affect general requirements
fields of expertise is presented. We have developed a software
concerning all the system like the temperature or the global mass.
prototype under Python environment in order to demonstrate the
The controller used here is a proportional-integral-derivative
functionalities of CDPPK methodology in each step.
(PID). This type of controllers is widely employed in the industry.
However, in practice, it’s hard to optimize when conflicting
6.1. Step1: project requirements
objectives are to be achieved [58]. As shown in our demonstrator
(Fig. 9), the first parameters coming from requirements and
ETB is a nonlinear mechanism which contains several physical
general knowledge are filled in this step in DPK.
effects, such as friction, the return spring load, and aerodynamic
forces, causing a variable time response, an unsteady behavior and
static errors. The throttle angle has to be precisely maintained to 6.3. Step3: detailed design
provide an enhanced throttle response. Thus, the goal is to develop
a robust and effective controller for Siemens VDO Electronic In this intermediate step, effective communication between
Throttle Body with the following representative requirements: stakeholders is necessary in order to determine all the parameters
222 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228

Fig. 8. Electronic Throttle Body architecture.

Fig. 9. Design Product Design in Python demonstrator.

necessary for the project and to have a common understanding of scenario. Some parameters are filled by system engineers in the
the design problem. A meeting between system engineers and previous step but the technical parameters are filled by disciplin-
disciplinary engineers is proposed to fill all the parameters in the ary engineers. In this step, a refinement of requirements is possible
DPK structure. Table 1 contains all the crucial parameters in this by adding constraints to the newly added parameters.
 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228 223

Table 1
The list of crucial parameters and the values found by users.

Parameter Description Unit Min. Max. UPC_ Identification UPC_ Dynamic UPC_ Fluid UPC_ Test
ICE_System
D ETB diameter mm 60 – –

T Temperature C 20 140 – – – –
Dp Pressure drop mbar 20 120 80 –
ICE_DCMotor
R Motor Resistance Ohm 4 –
K Motor constant N.mm/A 16.9 –
L Motor inductance H 1.5e-3 –
J Motor inertia Kg. m2 1e-6 –
F Friction coefficient N.mm 1.5 –
ICE_Controller
P Proportional gain [] 0.07 –
I Integral gain [] 0.008 –
D Derivative gain [] 0.001 –
Se Static error at maximum aerodynamic torque deg 0 0.8 0.59 0.62
t1 Rising time from 11.5deg to 90deg ms 0 240 218 215
t2 Return time from 90deg to 11.5deg ms 0 140 112 108
ICE_Gearbox
N Gearbox ratio [] 44 –
C1 Main spring stiffness N.m/rad 0.17 –
C2 Return spring stiffness N.m/rad 0.82 –
J Gearbox inertia Kg. m2 0.7e-6 –
ICE_Valve
Ta Maximum aerodynamic torque N.m – 0.15
Wa Angle at Ta deg 0 90 – 30 –
J Valve inertia Kg. m2 2e-6

6.4. Step4: verification & integration
Four disciplinary-specific engineers are involved in this
scenario (Fig. 11):
- UPC_Identification: Traction tests are made to identify the
springs’ stiffness and calibration test are made to identify the
motor and friction parameters.
- UPC_Dynamic: A 0D model in Modelica using Dymola1
environment studies the dynamic response of the system based
on differential equations [59]. This model takes into account the
system non-linearity and operating constraints.
- UPC_Fluid: The role of the Fluid model is to identify the
maximum aerodynamic torque applied and the associated angle
by CFD calculations in Fluent2 software.
- UPC_Test: The test bench is equipped with dSPACE card for a
real-time control of the ETB using Simulink3 environment. A
wind tunnel and pressure measurement instruments are used to
adequately reflect tests under real conditions.
As shown in Fig. 10, each user instantiates his parameters and
indicates the in/out flow. Each user has a collaboration state and
when the analysis is finished, the user can publish his work and
send the values to related collaborators. The collaboration is then
managed as explained in Section 5.3. The collaborative scenario is
composed of four iterative steps (Fig. 12): (1) The identification of
the ETB parameters are made and saved in UPC_Identification. The
later sends their values to UPC_Fluid and UPC_Dynamic (2) The
fluid calculation are performed to determine the maximum
aerodynamic torque and angle. This information is saved in
UPC_Fluid, then sent to UPC_Dynamic and UPC_Test to adapt their
profile and test the maximum torque angle condition (3) Dynamic
calculations are made in Modelica to optimize the PID controller
1
Dassault Systèmes, http://www.3ds.com/fr/products-services/catia/products/
dymola
2
Ansys, https://www.ansys.com/fr-fr/products/fluids/ansys-fluent
3
Mathworks, http://fr.mathworks.com/products/simulink
and respect the requirements in term of rising time, return time
and static error in maximum aerodynamic torque. The optimized
PID parameters are sent to UCP_Test for validation (4) The test
bench is used to verify the requirements in real conditions. The
experimental values are saved in UPC_Test (5) The validation is
made by comparing the results of UPC_Test and UPC_Dynamic as
explained in the next section.
6.5. Step5: system validation
In this last step, the final results are saved in the PDK and the
final collaboration graph is saved in CDP. In order to validate the
design, the project manager has to ensure that the simulation
results and the experimental validation satisfy the control design
requirements (step (5) in Fig.12). The project manager has now
access to the collaboration process and the product design
knowledge (Table 1). In this scenario, the control system is
validated for there is a good agreement between simulation and
experimental results (Columns UPC_Dynamic and UPC_Test in
Table 1). The system response is also represented in Fig. 13 and
follows the profile to illustrate the rising time, the return time and
the aerodynamic effect at 30 when the wind tunnel is activated.
7. Discussion and outlook
In the context of our project, the CDPPK methodology meets the
mechatronic industrial needs, regarding collaboration and reuse.
The CDPPK is capable of harmonizing the design cycle and ensuring
an effective connection between system engineers and disciplinary
engineers. This work is for the companies that have already
adopted a system engineering approach, very often manufacturers
in the automotive and aeronautics fields, and would like to ensure
effective collaboration between system engineers and disciplinary
engineers. They are the target of our approach for the nature of
their highly collaborative design methods and their need to
manage product families for reuse.
In this context, the presented use case is based on the
automotive industrial requirements. Various disciplines are
involved in the design of a robust ETB control system. By applying
224 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228
Fig. 10. Collaborative Design Process in Python demonstrator.
the different steps of our methodology, we managed to exchange
parameters between stakeholders and to connect the knowledge
generated by system engineers and discipline-specific engineers.
Thereupon, the collaborative scenario validates the practicality of
the approach.
Our methodology brings new elements in collaboration and
reuse:
Traditionally, collaborative methods have no evident added
value for solving simple design problems. In such case, simple
direct communication between engineers seems sufficient. How-
ever, when the design involves many parameters and tools, the
collaboration becomes time-consuming and conflicts become even
impossible to resolve. In practice, stakeholders spend in average 20
percent of the workweek looking for internal information or
tracking down other actors who can help with specific tasks [60].
The CDPPK proposes an exchange environment that resolves
mechatronic design related conflicts. This is done through
interdisciplinary constraints between discipline-specific engi-
neers, and through system constraints between discipline-specific
engineers and system engineers. Thus errors, during the design
phase, and iterations, between the decomposition and integration
phases, are bound to be reduced. The cost and effectiveness
benefits cannot be evaluated accurately without testing the
methodology in an industrial environment. Nevertheless, estima-
tions show that the use of collaborative tools in the product
development phase is likely to improve the revenues in the
automotive and aeronautic industries by 0.5-0.7% [61].
Conventionally, engineers had to refer to written reports and
one or two DE tools, with no need for KM support. However, in
multidisciplinary mechatronic design, understanding and reusing
the different SE and DE tools are challenging. As reported recently,
research indicates that wasted time comprises about 60 percent of
the total operational time in most businesses. This is partially due
to working with wrong data and unnecessary reinvention of the
existing knowledge [25]. Therefore, all the manufacturing compa-
nies dealing with product families and repetitive design task
should adopt a knowledge management methodology. In CDPPK,
knowledge generated by the collaborative activity is stored into
product knowledge and process knowledge in a way that it can be
easily reused. On one side, the product knowledge serves as a
source of information for system engineers and disciplinary
engineers. The system engineers use this knowledge to decompose
the product parameters and requirements. This is suitable for their
system view. The disciplinary engineers select the parameters that
they need to collaborate and find the optimal value. On the other
side, the dynamic process knowledge breaks with a traditional
predefined process which is no more suitable for concurrent
engineering. This type of knowledge, generated with the FPG
graph, can be reused in product families design. Stakeholders learn
from the recorded conflicts and iterations to reduce them in the
next design.
The CDPPK Knowledge formalization process might be time-
consuming. It requires a close exchange between the different
actors of the design cycle. We suggested in step 3 of our
methodology a meeting to formalize the parameters needed for
the collaboration. The project manager, the system engineers, and
the disciplinary engineers must have a close exchange to form a
holistic product knowledge. But this can be difficult to organize in
complex and distributed environments. Automated solutions to
extract knowledge exist and can be incorporated in this step. Either
 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228 225

Fig. 11. The different users involved in the collaborative scenario.

way, the benefits of the formalized knowledge are proven in the
long term. The structured knowledge is highly valuable for
companies because it can be easily accessed, mined and used
for decision making.
Lately, knowledge risks have gained increasing attention in the
information security related literature. Indeed, knowledge can
have a competitive value which makes it at risk of inter-
organizational collaboration [62]. One must note that such risks
are already present in traditional solutions (e.g. email social
platforms and face-to-face conversations). The CDPPK proposes, in
this context, to grant each actor special access privileges to reduce
the probability of such threats.
226 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228

Fig. 12. Collaboration graph generated by Python demonstrator.

Fig. 13. The system response to the complete profile reference.

For people, there is an inconvenience when adopting new proposed on an industrial level yet, but feedbacks from industrials
collaborative and reuse tools for they require training and time to in our project give us an insight.
be assimilated. Therefore, to avoid rejection, the concept should be The other people related limit is their acceptance to share their
simple and easy to master. Our CDPPK methodology has not been knowledge. Research indicates that, in a typical organization, only
 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228
4% of organizational knowledge is available in a structured and
reusable format and the rest is either unstructured or resides in
people's minds [63]. Therefore, the successful development of such
tools requires the ability of the dedicated design team to
communicate, collaborate and integrate their knowledge and
know-how [64].
The next step of our work is to upgrade the prototype for web-
service applications to test it in a distributed industrial environ-
ment. This will allow us to have actual feedbacks from engineers.
We also plan to include other kinds of parameters like vectors and
matrix to give more flexibility for actors. Collaboration wise, it is
interesting to have Agent-based solutions supporting the exchange
and assisting actors to avoid conflicts. This technology can be
integrated into our methodology as well as constraint satisfaction
techniques to advise stakeholders during collaboration. Regarding
reuse, the knowledge process can also be used to generate
Multidisciplinary Design Optimization architectures which is a
planned extension to our work. For query purposes, we plan to use
state-of-the-art graph querying tools to facilitate the access to the
knowledge. And finally, a link between CDPPK and planning
services should be considered to evaluate the time allocated for the
collaborative activity.
8. Conclusion and remarks
We carried out this work in the national MIMe project
integrating the prime manufacturers PSA and Valeo. This validates
the industrial interest of our problematic. Many companies today
have realized the strategic importance of a collaborative knowl-
edge management system implementation and its ability to
increase productivity. It is particularly important to adopt the
right strategy in the design cycle since the majority of the cost and
quality of the system are determined during this stage. In this
research, we developed a novel approach to connect SE and DE to
move from isolated design steps into an integrated collaborative
environment. Therefore, we are prone to design better and faster.
This approach will be implemented in a real web-based platform to
validate it in an industrial environment.
Acknowledgments
The present work was developed within the French FUI 19
project (MIMe project). We would like to thank the consortium
partners for the contributions they have made during this project.
References
[1] C. Zheng, M. Bricogne, J. Le Duigou, B. Eynard, Survey on mechatronic
engineering: a focus on design methods and product models, Adv. Eng. Inform.
28 (2014) 241–257.
[2] G. Barbieri, C. Fantuzzi, R. Borsari, A model-based design methodology for the
development of mechatronic systems, Mechatronics 24 (2014) 833–843.
[3] C.K. Jackson, The mechatronics system design benchmark report–
Coordinating engineering disciplines, Boston: The Aberdeen Group (2006).
[4] J. Gausemeier, T. Gaukstern, C. Tschirner, Systems engineering management based
on a discipline-spanning system model, Procedia Comput. Sci. 16 (2013) 303–312.
[5] M. Alavi, D.E. Leidner, Knowledge management and knowledge management
systems: conceptual foundations and research issues, Mis Q. (2001) 107–136.
[6] R. Isermann, Mechatronic design approach, The Mechatronics Handbook, CRC
Press, Boca Raton, 2002, pp. 3 Section I: Overview of mechatronics.
[7] K. Forsberg, H. Mooz, 7.17. System engineering for faster, cheaper, better,
INCOSE International Symposium, (1998) , pp. 917–927.
[8] J. Gausemeier, S. Moehringer, New guideline vdi 2206-a flexible procedure
model for the design of mechatronic systems, DS 31: Proceedings of ICED 03,
the 14th International Conference on Engineering Design (2003).
[9] S. Wiesner, M. Freitag, I. Westphal, K.-D. Thoben, Interactions between service
and product lifecycle management, Procedia Cirp 30 (2015) 36–41.
[10] F. Peluso, Knowledge Reuse and Collaborative Environments in Industrial
Engineering, (2015) .
[11] A. Kellner, P. Hehenberger, L. Weingartner, M. Friedl, Design and use of system
models in mechatronic system design, Systems Engineering (ISSE), 2015 IEEE
International Symposium on, (2015) , pp. 142–149.
227
[12] M. Törngren, A. Qamar, M. Biehl, F. Loiret, J. El-Khoury, Integrating
viewpoints in the development of mechatronic products, Mechatronics 24
(2014) 745–762.
[13] M.D. Petty, Verification and validation, Principles of Modeling and Simulation:
A Multidisciplinary Approach, (2009) , pp. 121–149.
[14] M. Hammadi, J.-Y. Choley, O. Penas, A. Rivière, Mechatronic system
optimization based on surrogate models-application to an electric vehicle,
Simultech, (2012) , pp. 11–16.
[15] Y. Cao, Y. Liu, H. Fan, B. Fan, SysML-based uniform behavior modeling and
automated mapping of design and simulation model for complex
mechatronics, Comput. Des. 45 (2013) 764–776.
[16] H. Kim, D. Fried, P. Menegay, Connecting SysML models with engineering
analyses to support multidisciplinary system development, 12th AIAA
Aviation Technology, Integration, and Operations (ATIO) Conference and 14th
AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, (2012)
, pp. 5632.
[17] T.W. Simpson, J.R. Martins, Multidisciplinary design optimization for complex
engineered systems: report from a national science foundation workshop, J.
Mech. Des. 133 (2011) 101002.
[18] C. Zheng, J. Le Duigou, M. Bricogne, B. Eynard, Multidisciplinary interface
model for design of mechatronic systems, Comput. Ind. 76 (2016) 24–37.
[19] P.D. Borches, G.M. Bonnema, System evolution barriers and how to overcome
them! 8th Conference on Systems Engineering Research (CSER2010), 2010, pp.
455-464.
[20] M.K. da Silva, S. Remy, T. Reyes, On providing design process information to the
environmental expert, Res. Eng. Des. 26 (2015) 327–336.
[21] S. Feldmann, K. Kernschmidt, B. Vogel-Heuser, Combining a SysML-based
modeling approach and semantic technologies for analyzing change
influences in manufacturing plant models, Procedia Cirp 17 (2014) 451–456.
[22] D. Di Ruscio, M. Franzago, H. Muccini, I. Malavolta, Envisioning the future of
collaborative model-driven software engineering, Proceedings of the 39th
International Conference on Software Engineering Companion, (2017) , pp.
219–221.
[23] M. Cencetti, Evolution of Model-based System Engineering Methodologies for
the Design of Space Systems in the Advanced Stages of the Project, Politecnico
di Torino, Torino, 2016 (Ph. D. Thesis). Dassault Systemes.
[24] J.M. Torry-Smith, A. Qamar, S. Achiche, J. Wikander, N.H. Mortensen, C. During,
Challenges in designing mechatronic systems, J. Mech. Des. 135 (2013) 011005.
[25] F. Ameri, D. Dutta, Product lifecycle management: closing the knowledge
loops, Comput. Des. Appl. 2 (2005) 577–590.
[26] V. Fortineau, T. Paviot, S. Lamouri, Improving the interoperability of industrial
information systems with description logic-based models—the state of the art,
Comput. Ind. 64 (2013) 363–375.
[27] V. Srinivasan, An integration framework for product lifecycle management,
Comput. Des. 43 (2011) 464–478.
[28] B. Dave, L. Koskela, Collaborative knowledge management—A construction
case study, Autom. Constr. 18 (2009) 894–902.
[29] J.A. Estefan, Survey of model-based systems engineering (MBSE)
methodologies, Incose MBSE Focus Group 25 (2007) 1–12.
[30] T. Johnson, A. Kerzhner, C.J. Paredis, R. Burkhart, Integrating models and
simulations of continuous dynamics into SysML, J. Comput. Inf. Sci. Eng. 12
(2012) 011002.
[31] G.-D. Kapos, V. Dalakas, A. Tsadimas, M. Nikolaidou, D. Anagnostopoulos,
Model-based system engineering using SysML: deriving executable
simulation models with QVT, Systems Conference (SysCon), 2014 8th Annual
IEEE, (2014) , pp. 531–538.
[32] T. Sakairi, E. Palachi, C. Cohen, Y. Hatsutori, J. Shimizu, H. Miyashita, Designing
a control system using SysML and simulink, SICE Annual Conference (SICE),
2012 Proceedings of, (2012) , pp. 2011–2017.
[33] M. Chami, J.-M. Bruel, Towards an integrated conceptual design evaluation of
mechatronic systems: The SysDICE approach, Procedia Comput. Sci. 51 (2015)
650–659.
[34] M. Bajaj, D. Zwemer, R. Peak, A. Phung, A. Scott, M. Wilson, 4.3. 1 satellites to
supply chains, energy to finance—slim for model-based systems engineering:
part 1: motivation and concept of SLIM, INCOSE International Symposium,
(2011) , pp. 368–394.
[35] Z. Huzar, L. Kuzniarz, G. Reggio, J.L. Sourrouille, Consistency problems in UML-
based software development, International Conference on the Unified
Modeling Language, (2004) , pp. 1–12.
[36] S. Softic, M. Rosenberger, A. Denger, J. Fritz, A. Stocker, Semantically based
visual tracking of engineering tasks in automotive product lifecycle,
Proceedings of the 13th International Conference on Knowledge Management
and Knowledge Technologies, (2013) , pp. 36.
[37] T. Tudorache, Employing Ontologies for an Improved Development Process in
Collaborative Engineering, (2006) .
[38] S. Kleiner, R. Anderl, R. Gräb, A collaborative design system for product data
integration, J. Eng. Des. 14 (2003) 421–428.
[39] I. Dávid, J. Denil, K. Gadeyne, H. Vangheluwe, et al., Engineering process
transformation to manage (in) consistency, Henry Muccini (Ed.), Proceedings
of the 1st International Workshop on Collaborative Modelling in MDE
(COMMitMDE 2016) Co-Located With ACM/IEEE 19th International
Conference on Model Driven Engineering Languages and Systems (MoDELS
2016) (2016) 7–16.
[40] J. Badin, D. Chamoret, S. Gomes, D. Monticolo, Knowledge configuration
management for product design and numerical simulation, DS 68-6:
Proceedings of the 18th International Conference on Engineering Design
228 M. Mcharek et al. / Computers in Industry 105 (2019) 213–228
(ICED 11), Impacting Society Through Engineering Design, Vol. 6: Design
Information and Knowledge (2011).
[41] D. Penciuc, A. Durupt, F. Belkadi, B. Eynard, H. Rowson, Towards a PLM
interoperability for a collaborative design support system, Procedia Cirp 25
(2014) 369–376.
[42] D. Monticolo, J. Badin, S. Gomes, E. Bonjour, D. Chamoret, A meta-model for
knowledge configuration management to support collaborative engineering,
Comput. Ind. 66 (2015) 11–20.
[43] I. Saad, S. Chakhar, A decision support for identifying crucial knowledge
requiring capitalizing operation, Eur. J. Oper. Res. 195 (2009) 889–904.
[44] M. Grundstein, C. Rosenthal-Sabroux, GAMETH1, a decision support approach
to identify and locate potential crucial knowledge, Proceedings 5th European
Conference on Knowledge Management, (2004) , pp. 391–402.
[45] J. Badin, D. Monticolo, D. Chamoret, S. Gomes, Using the knowledge
configuration model to manage knowledge in configuration for upstream
phases of the design process, International Journal on Interactive Design and
Manufacturing (IJIDeM) 5 (2011) 171.
[46] M. Mcharek, T. Azib, M. Hammadi, J.-Y. Choley, C. Larouci, Knowledge sharing
for mechatronic systems design and optimization, IFACPapersOnLine 51
(2018) 1365–1370.
[47] F. Caron, Leveraging tradeoff, bridging the gap among disciplines, INCOSE
International Symposium, (2016) , pp. 2407–2428.
[48] A. Navarro, J. Badin, M. Austruy, A. Sow, Collaborative Generation of
Configuration Technical Data for a Product to be Manufactured, ed: Google
Patents, 2018.
[49] N. Drémont, N. Troussier, R.I. Whitfield, A. Duffy, A meta-model for knowledge
representation integrating maturity for decision making in engineering
design, IFIP International Conference on Product Lifecycle Management,
(2013) , pp. 385–395.
[50] F. Belkadi, N. Dremont, A. Notin, N. Troussier, M. Messadia, A meta-modelling
framework for knowledge consistency in collaborative design, Annu. Rev.
Control 36 (2012) 346–358.
[51] I. ISO, "10007: 2003, Quality Management Systems Guidelines for
Configuration Management, British Standards, 2003.
[52] P.-E. Arduin, M. Grundstein, C. Rosenthal-Sabroux, From knowledge sharing to
collaborative decision making, Int. J. Inf. Decis. Sci. 5 (2013) 295–311.
[53] M. Grundstein, From capitalizing on company knowledge to knowledge
management, Knowl. Manage. Classic Contemp. Works 12 (2000) 261–287.
[54] J.A. Bondy, U.S.R. Murty, Graph Theory With Applications, vol. 290, Citeseer,1976.
[55] D.J. Pate, J. Gray, B.J. German, A graph theoretic approach to problem
formulation for multidisciplinary design analysis and optimization, Struct.
Multidiscip. Optim. 49 (2014) 743–760.
[56] E.J. Cramer, J. Dennis, E. John, P.D. Frank, R.M. Lewis, G.R. Shubin, Problem
formulation for multidisciplinary optimization, SIAM J. Optim. 4 (1994) 754–776.
[57] B. Ashok, S.D. Ashok, C.R. Kumar, Trends and future perspectives of electronic
throttle control system in a spark ignition engine, Annu. Rev. Control (2017).
[58] K.H. Ang, G. Chong, Y. Li, PID control system analysis, design, and technology,
Ieee Trans. Control. Syst. Technol. 13 (2005) 559–576.
[59] M. Mcharek, M. Hammadi, J.-Y. Choley, T. Azib, C. Larouci, Modeling and multi-
objective optimization of an electronic throttle in open-loop, Mechatronics
(MECATRONICS)/17th International Conference on Research and Education in
Mechatronics (REM), 2016 11th France-Japan & 9th Europe-Asia Congress on,
(2016) , pp. 331–335.
[60] R. Åman, H. Handroos, H. Kärkkäinen, J. Jussila, P. Korkealaakso, Novel ICT-
enabled collaborative design processes and tools for developing non-road
mobile machinery, ASME/BATH 2015 Symposium on Fluid Power and Motion
Control, (2015) pp. V001T01A040-V001T01A040.
[61] M. Chui, J. Manyika, J. Bughin, R. Dobbs, C. Roxburgh, H. Sarrazin, et al., The
Social Economy: Unlocking Value and Productivity Through Social
Technologies, McKinsey Global Institute, 2012.
[62] I. Ilvonen, J.J. Jussila, H. Kärkkäinen, Towards a business-driven process model
for knowledge security risk management: making sense of knowledge risks,
Int. J. Knowl. Manage. (IJKM) 11 (2015) 1–18.
[63] D. Rasmus, Collaboration, Contents and Communities, an Update, Giga
Information Group Inc, 2002.
[64] I. Assouroko, G. Ducellier, P. Boutinaud, B. Eynard, Knowledge management
and reuse in collaborative product development–a semantic relationship
management-based approach, Int. J. Prod. Lifecycle Manag. 7 (2014) 54–74.