Utilizing the Generic Design Analysis (GDA) Process Model Within an Extended Set of Design Analysis Contexts

Abstract

In most industrial product development projects, computer-based design analysis, or simply design analysis, is frequently utilized. Several design analysis process models exist in the literature for the planning, execution and follow-up of such design analysis tasks. Most of these process models deal explicitly with design analysis tasks within two specific contexts: the context of design evaluation, and the context of design optimization. There are, however, several more contexts within which design analysis tasks are executed. Originating from industrial practice, four contexts were found to represent a significant part of all design analysis tasks in industry. These are:
1. Explorative analysis, aiming at the determination of important design parameters associated with an existing or predefined design solution (of which design optimization is a part).
2. Evaluation, aiming at giving quantitative information on specific design parameters in support of further design decisions.
3. Physical testing, aiming at validating design analysis models through physical testing, that is, determining the degree to which models are accurate representations of the real world from the perspective of the intended uses of the models.
4. Method development, that is the development, verification and validation of specific guidelines, procedures or templates for the design analyst and/or the engineering designer to follow when performing a design analysis task.
A design analysis process model needs to be able to deal with at least these four. In this work, a process model named the generic design analysis (GDA) process model, is applied to these four contexts. The principles for the adaptation of the GDA process model to different contexts are described. The use of the GDA process model in these contexts is exemplified with industrial cases: explorative analysis of design parameters of a bumper beam system, the final physical acceptance tests of a device transportation system (collision test, drop test, vibration test), and the method development of a template for analyzing a valve in a combustion engine. The “Evaluation” context is not exemplified as it is the most common one in industry.
The GDA process model has been successfully used for the four contexts. Using the adaptation principles and industrial cases, the adaptation of the GDA process model to additional contexts is also possible.

Full text

1 Copyright © 2017 by ASME
Proceedings of the ASME 2017 International Mechanical Engineering Congress & Exposition
IMECE2017
November 3-9, 2017, Tampa, Florida, USA
IMECE2017-71205
UTILIZING THE GENERIC DESIGN ANALYSIS (GDA) PROCESS MODEL WITHIN
AN EXTENDED SET OF DESIGN ANALYSIS CONTEXTS
Martin Eriksson*
Validus Engineering AB
P.O. Box 806
SE-245 18 Staffanstorp
Sweden
martin.eriksson@valeng.com
Håkan Petersson
School of Business, Engineering and Science
Halmstad University
P.O. Box 823, SE-301 18 Halmstad
Sweden
hakan.petersson@hh.se
Damien Motte, Robert Bjärnemo
Division of Machine Design
Department of Design Sciences LTH
Lund University
P.O. Box 118, SE-221 00 Lund
Sweden
damien.motte@mkon.lth.se,
robert.bjarnemo@mkon.lth.se
ABSTRACT *
In most industrial product development projects,
computer-based design analysis, or simply design analysis, is
frequently utilized. Several design analysis process models
exist in the literature for the planning, execution and follow-up
of such design analysis tasks. Most of these process models
deal explicitly with design analysis tasks within two specific
contexts: the context of design evaluation, and the context of
design optimization. There are, however, several more
contexts within which design analysis tasks are executed.
Originating from industrial practice, four contexts were found
to represent a significant part of all design analysis tasks in
industry. These are:
1. Explorative analysis, aiming at the determination of
important design parameters associated with an existing
or predefined design solution (of which design
optimization is a part).
2. Evaluation, aiming at giving quantitative information on
specific design parameters in support of further design
decisions.
3. Physical testing, aiming at validating design analysis
models through physical testing, that is, determining the
degree to which models are accurate representations of
the real world from the perspective of the intended uses of
the models.
* Address all correspondence to this author.
4. Method development, that is the development,
verification and validation of specific guidelines,
procedures or templates for the design analyst and/or the
engineering designer to follow when performing a design
analysis task.
A design analysis process model needs to be able to deal
with at least these four. In this work, a process model named
the generic design analysis (GDA) process model, is applied to
these four contexts. The principles for the adaptation of the
GDA process model to different contexts are described. The
use of the GDA process model in these contexts is exemplified
with industrial cases: explorative analysis of design
parameters of a bumper beam system, the final physical
acceptance tests of a device transportation system (collision
test, drop test, vibration test), and the method development of
a template for analyzing a valve in a combustion engine. The
“Evaluation” context is not exemplified as it is the most
common one in industry.
The GDA process model has been successfully used for
the four contexts. Using the adaptation principles and
industrial cases, the adaptation of the GDA process model to
additional contexts is also possible.
INTRODUCTION
Nowadays, many industrial development projects utilize
computer-based design analysis. Computer-based design
analysis (or design analysis for short) is here confined to

2 Copyright © 2017 by ASME
quantitative analyses, utilizing advanced, computer-intensive
computational methods and tools focusing on analyses of the
physical phenomena which originate from the design and
development of new or improved products or from the
redesign of existing ones. Several works in the literature
present process models to plan, execute and follow up design
analysis tasks, and support the practitioner’s work, e.g. [1-6].
NAFEMS (originally the National Agency for Finite Element
Methods and Standards) has proposed several models during
the last few decades that are intended for practical
implementation in industrial practice [7-9].
Most of these process models deal explicitly with design
analysis tasks within two specific contexts. All of them deal
with tasks performed within the context of design evaluation,
that is using design analysis to give quantitative information
on specific design parameters, which are utilized in the
decisions on the further design of the product-to-be. And some
of them deal with design analysis tasks within the context of
design optimization, e.g. [10].
During interviews in an industry survey [11] involving
the heads of the design analysis and/or engineering design
departments of 15 technology-intensive Swedish companies,
ranging from SMEs to large companies, in which design
analysis was of major interest, it was found that a significant
number of design analysis tasks took place within a larger
number of contexts. Four of those contexts were found to
represent a significant part of all design analysis tasks
originating in industrial practice. The identified contexts are:
1. Explorative analysis (of which design optimization is
a part)
2. Evaluat ion
3. Physical testing
4. Method development
A rough estimate made by the authors, based on the
findings obtained during the interviews, on their own
experience as well as on design analyses referred to in the
literature [11;12], indicates that these represent 65 – 75 % of
all design analysis tasks. These different contexts have
common but also specific design analysis activities and it is
important that design analysis process models should be able
to encompass these contexts.
In this work, such a process model, denoted the generic
design analysis (GDA) process model [13], has been applied
to those four contexts.
This paper is organized as follows. In a first section, the
GDA process model is introduced. Then a second section
explains how the GDA process model can be adapted to these
different contexts. A third section elaborates on the four
contexts. Finally, three examples from industrial projects show
how the GDA process model may be used to handle the
different contexts (the “Evaluation” context is not exemplified
as it is the most common context).
THE GENERIC DESIGN ANALYSIS (GDA) PROCESS
MODEL
The GDA pr o cess model has been developed from several
sources: an extensive literature survey [12], a survey in
industry [11], and the 20 years of field experience of the main
author as design analysis consultant. Some supplementary
information has been extracted from another international
survey [14] (the first survey concerned international
companies but with their engineering design and design
analysis functions mainly based in Sweden). The GDA process
model reported here has been extracted from [13, pp. 37-39].
The GDA process model consists of three phases: analysis
task clarification, analysis task execution and analysis task
complet ion, as well as the activities and sub activities
constituting each of the phases, see Figure 1.
The analysis task clarification phase consists of three
activities. In the identification of the task (activity 1a,
hereafter abbreviated to /1a/), the objective is to ascertain the
task relevance and the actual need for launching the design
analysis task. Once the relevance of the task has been agreed
upon and the decision has been taken to continue, the
preparation of the task content brief takes place /1b/. Once the
task content brief is established, the analysis activity should be
carefully planned and a formal document should be prepared
and mutually agreed on (between the ordering engineering
designer and the performer of the actual design analysis, the
design analyst, or analyst for short), that forms the basis for
the analysis execution /1c/. This should consist of a detailed
plan of the contents described in the design analysis task
content brief.
During the pre-processing /2a/ activity, the agreed task is
processed further resulting in a representative engineering
model (su ch as a geo metrical model or a functional model) as
well as the actual computational model for solut ion. In the
next activity, solution processing /2b/, the analysis task is
solved (executed) to generate the adequate amount of results
needed for producing the required results. Results are
extracted and assessed within the post-processing /2c/ with the
purpose of providing adequate understanding of the general
model behavior as well as accuracy and convergence in results
obtained.
The third phase of the process is the analysis task
completion, in which the first activity is the results
interpretation /3a/, which relates to the interpretation and
evaluation by the analyst of all relevant data and information
that can be drawn from the analysis task execution. The
outputs from the analyses are documented and communicated
back into the overall engineering design/development project.
This is done in the documentation and communication activity
/3b/. In the final activity, integration of the results into the
project /3c/, the design analysis task findings are being
implemented into the engineering design task, from which it
originates.
For each of the activities the core sets of sub activities are
also presented in Figure 1.

3 Copyright © 2017 by ASME
Note that awareness that this core sub activities are not
always enough to cover all aspects in every foreseeable design
analysis task, thus resulting in adding additional sub activities
when needed; denoted …-n. in Figure 1.
Figure 1. The GDA process model with defined phases and core activities [13, p. 39].
ADAPTING THE GDA PROCESS MODEL
Like all generic process models, the GDA process model
needs to be adapted to each design analysis task. Several of the
activities required to fulfill a given task are obvious because
they are present in virtually every design analysis task (e.g.
\2a-2c\). But in order to plan and establish relevant design
analysis activities, it is necessary to base these decisions on
experiences from prior projects together with applicable
engineering knowledge.
It might be possible to develop specific process models
for each context. This approach, however, has so me
disadvantages. Among others, it requires knowledge of four
models instead of one, and, as mentioned above, there are in
practice more than four contexts of design analysis tasks,
which would require even more specific design analysis
process models. Instead, we choose to focus on
exemplifications of each context for which the GDA has been
adapted. By studying these exemplifications, the person in
charge of planning should be able to establish the structure of
future design analysis tasks more easily. Moreover, if it is
necessary to plan for a design analysis task in a context that is
not exemplified here, the knowledge of how to adapt the GDA
process model and the examples should also ease the planning
task.1 This is in a sense very similar to case-based learning
used in management for example [15;16]: cases help
understanding and using fundamental knowledge in disciplines
where applications of this knowledge will differ greatly for
each project. Furthermore, the GDA process model is flexible
and can easily be used for iterative design analysis scenarios
1 This means that the exemplifications below serve two purposes. They
show that the GDA process model can deal with the four contexts, and they
can help the practitioners structure their own design analysis task in any given
context or combination of contexts.
1a. Identification of the
task
1b. Preparation of the
task content brief
1c. Planning and
agreement of the task
1.Definition of the overall
purpose of the task
2.Clarification of the task
3.Establishment of the task
content brief
n.
1.Discussion around task
relevance and need for a
pre-study
2.Pre-study
3.Decision to perform
analysis task
4.Establishment of initial task
mission statement
n.
1.Detailed planning of the
task
2.Discussion and
negotiation of the task
3.Agreement or rejection of
the task
n.
2a. Pre-processing 2b. Solution
processing 2c. Post-processing
1.Establishment of solution
approach and settings
2.Solution scrutinizing
3.Supervision of task solving
process
n.
1.Compilation of task content
2.Establishment of
engineering model
3.Establishment of
computational model
n.
1.Extraction of solution
results
2.Compilation of result
information
3.Assessment of extracted
results
n.
3a. Results interpretation
and evaluation
3b. Documentation
and communication
3c. Integration of the
results into the project
1.Task documentation
2.Documentation of suggested
design alterations
3.Communication of task
findings and
recommendations
n.
1.Results interpretation
2.Evaluation and conclusion
of findings
3.Decision on the need for
additional analysis
n.
1.Implementation of task
results and findings
2.Participation in decisions
on implementation of
design alterations
3.Contribution to further
analysis tasks
n.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

4 Copyright © 2017 by ASME
as discussed in the second exemplification and for
multidisciplinary applications.
Finally, to ensure a successful achievement of the design
analysis task, it is also necessary to adapt the GDA process
model to integrate the design analysis task into the overall
engineering design and product development project. The
issue of integration between the design analysis process and
the engineering design process is of major significance for
providing an increase in efficiency and effectiveness in
engineering design and development of products. To that end,
it is necessary to map out the interactions between the
engineering designers and the analysts. This is made possible
by analyzing the information workflow between the
engineering design process and the design analysis process.
An approach facilitating this mapping is described in [17]. For
each exemplification, the mapping of the interactions between
both functions will also be illustrated.
THE FOUR CONTEXTS
Design analysis mo st often aims at giving quantitative
information on specific design parameters as a support for
subsequent design decisions, i.e. a core activity within the
“evaluation context”. However, as mentioned in the
introduction, design analysis is also used in other contexts
with different points of departure.
During the interviews in the industry [11], it was found
that topology and parameter optimization was used as part of
synthesis activities for concept and product definitions (that is,
in an “explorative” context) by about half of the interviewed
companies. Also physical phenomenon and feasibility studies
as well as statistical and probabilistic evaluations can be
considered as analyses in an explorative context.
All companies participating in the interviews use design
analysis on a regular basis to evaluate product proposals of
details, components and sub-systems and some of them also
for complete systems (the evaluation context).
The companies also asserted that the validation of design
analysis results were usually carried out utilizing physical
testing (“physical testing” context) which in turn might call for
additional design analysis activities. A closely related context
to physical testing is the investigation of root causes of events
occurring during use processes based on identified damages,
failures or other specific related causes. Some companies even
rely on design analysis as validation when other means of
validation are not possible.
In order to be able to do so, verified and validated design
analysis methods (i.e. established procedures, guidelines and
templates) are usually developed (so called “method
development”). The development of methods to facilitate the
effort to introduce engineering designers to design analysis is
also connected with the method development context.
The specificities of each context are described below.
Explorative analysis
It might be argued that in a broad perspective most design
analysis tasks are of an explorative nature, since this implies
that the design analysis activities aim at the determination of
important design parameters associated with an existing or
predefined design solution, thus providing the necessary
results and insights to be utilized by the analyst and/or
engineering designer to fulfil a specific purpose initially
established for the actual design analysis task.
One of the single most important activities within the
engineering design process is the creation of technical
solutions - ranging from simple details to complex product
systems and new working principles on which the product-to-
be might be developed as described in [18;19]. In the
engineering design literature, these activities are usually
referred to as design synthesis or just synthesis for short.
Traditionally, these activities are handled either by an
engineering designer or by a design/development team,
utilizing intuitive as well as discursive methods [18].
Resulting from the introduction of design analysis methods
and tools, especially finite element-based, it has become
possible for the engineering designer to utilize design analysis
of the proposed design solution candidates to analyze different
solution paths more thoroughly than ever before and thus be
able to more or less fully explore the design solution space at
hand. These analyses are traditionally performed by an
analyst, who is either an in-house or an external consultant. In
some cases the engineering designer might take over the role
as analyst on his/her own, when predominantly confined to
linear analyses [20]. However, it is not uncommon that
analysts make suggestions for modifications or redesigns and
in some cases also propose completely new design solutions.
Finally, it is important to note that the synthesis tasks to be
performed throughout an engineering design project are
numerous, and not all of them lend themselves to design
analysis in the given context due to impracticability and other
difficulties associated with the actual synthesis tasks.
The explorative approach to synthesis has significantly
contributed to deeper insights into the potentials provided by
different design solution candidates and thus to more
technically advanced solutions [14]. Adding statist ical and
stochastic as well as optimization methods and tools to this
approach makes it also possible, at least theoretically, to fully
explore the entire design space by determining the ultimate
potential for each and every one of the design solution
candidates; thus not only producing the optimal solution
candidates but also providing the essential facts needed for an
analysis of the robustness of the design solutions. In much o f
the current analysis software it is not only possible to more or
less automate the entire approach, but also to generate the
actual solution candidate by utilizing different statistical
design exploration methods such as composite difference
algor ithms, space filling methods, design of experiments
(DOE) methods, response surface methods (RSM) and goal
driven multi-objective optimization methods such as shape
optimization, and topology optimization [21;22]. A somewhat
different, but closely related, approach to design synthesis as
presented here is generative design, in which evolutionary
algorithms are utilized in design synthesis – see [23].

5 Copyright © 2017 by ASME
Evaluation analysis
During the engineering design process, hundreds or
sometimes even thousands of tasks are carried out in order to
attain the final result in the form of a new or improved
component, sub system or product. In a significant number of
these tasks, decisions are made as to accept, modify or reject
the design solution under investigation. The nature of these
decisions might range from limited decisions on a single
attribute to complex mult i-criteria decisions in which the
decision maker is facing a decision problem involving several,
often contradictory, aspects of the solution candidate that have
to be taken into account [24].
In industrial practice design criteria emanate from product
specifications. A specification (singular) is a formalized
account of the expected feature(s) a given solution candidate
has to possess in order to fulfil the identified need from which
the specification originates. In the “simpler” cases the
engineering designer usually makes the decision on his/her
own, while in the more complex cases decisions are made by
teams, usually by cross-functional teams. The common
denominator in all decisions is the access to knowledge of the
“value” or “usefulness” of the solution candidate under
examination. This knowledge is provided as a result of an
evaluation of the solution candidate with reference to the
expected performance expressed in terms of a design criterion.
In engineering design practice, a number of approaches are
utilized for such evaluations, ranging from subjective
estimates based on the engineering designer’s experience of
similar designs, through testing of prototypes, to the use of
design analysis and formal decision matrices.
When utilizing design analysis in design evaluation, the
result obtained is usually confined to quantitative information
on one or more specific design parameters used for an
immediate decision or to be used in a subsequent multi-criteria
decision activity.
The initial problem o f any design evaluation is the
difficulty of “translating” the often very complex and vague
product specifications into fully operative evaluation criteria.
For design analysis tasks, the process of translating is mainly
carried out in the form of discussions between the engineering
designer and the analyst. Exceptions from the described
procedure occur when predefined design analysis criteria are
supplied by an external source, e.g. by the engineering
designer or the client, or by industrial standards.
Finally, in the words of Vincke [24, p. xv] regarding the
important difference between optimization and multi-criteria
decision-aid: “The first fact which should be noted when
dealing with this type [multi-criteria, authors’ comment] of
problem is that there does not exist, in general, any decision
(so lution, action) which is the best simultaneously from all
points of view. Therefore, the word ‘optimization’ doesn’t
make any sense in such a context; in contrast to the classical
techniques of operations research, mult i-criteria methods do
not yield ‘objectively best’ solutions (such so lutions do not
exist).”
Physical testing
Since all design analysis results are derived from analysis
models, the validation of these models through physical
testing constitutes a key activity in most design analysis tasks.
Validation in the given context is here defined as: “The
process of determining the degree to which a model is an
accurate representation of the real world from the perspective
of the intended uses of the model.” [25, p. 3]
In the planning for a physical testing project, the
application of measurement systems such as strain gauges and
load cells might call for additional design analysis activities to
establish posit ion, directions and levels together with other
measurement parameters related to the actual testing activity.
Even during the most carefully planned physical test
campaign, unexpected events may occur. In order to
investigate the root cause of such events, design analysis is a
powerful tool. Design analysis is also a powerful mean to
perform post-test sensitivity and discrepancy studies in order
to elaborate on deviations found when comparing data from
physical tests and design analysis results.
Method development
Technology or method development, in the analysis
terminology, is the development and validat ion of specific
guidelines, procedures or templates2 to follow when
performing a design analysis task [12, p. 1188;20, p. 4].
The main purpose of the method development is to give
support that has been verified and validated in order to ensure
that the quality of a design analysis task or activity process or
outcome. Verification means: “The process of determining that
a model implementation accurately represents the developer’s
conceptual description of the model and the solution to the
model. ” [25, p. 3] (Validation has been defined in the
preceding section).
Responsibility for the development of these methods
usually lies with the design analysis department in close
cooperation with a dedicated method development team. In
some cases, representatives of external stakeholders also
participate in these activities. The development of these
methods should also include experiences gained and lessons
learned from previous design analysis projects, including
verification and validation before a method is approved for use
in industrial practice. An example of such method
development is presented in [26], in which a tool for
establishing a quantitative measure of the risk of later
encountering high-cycle fatigue (HCF), i.e. life-limiting
vibrations of both rotating and stationary parts, was the goal.
Available user interfaces and templates in commercial codes
are often the results of performed method development tasks.
Beyond the strict quality assurance, other reasons can be
invoked for method development in design analysis. One such
2 Pre-developed code that supports or guides the engineering designer in
performing design analysis tasks, e.g. from predefined settings available in
traditional tools, to developed in-house scripts, and advanced usage of
knowledge ware.

6 Copyright © 2017 by ASME
reason is when the experience and skills o f an analyst are not
sufficient to assure minimal risks and complete control of all
of the activities constituting a design analysis task. This
category usually occurs when the demand for full control of
the entire analysis process is a must, often required by some
external body such as a classification society, or in the
development of military equipment; this may also occur in a
company when extraordinary demands on product quality and
safety exist.
Method development can also be initiated when a
previously unknown design analysis task is to be solved, or
when a new or improved design analysis technique is
developed for existing design analysis tasks, and the objective
might be to improve the performance of the design analysis
process. For these tasks a technology development activity is
performed by a team of analysts sometimes also including
engineering designers and the managers for these functions,
project leaders and, if applicable, representatives from external
bodies. Since the result of such a technology development
project is presented in the form of step-by-step activities, the
term method is also valid here and used to denote the results of
these activities.
More recently, method development has been used to
allo w engineering designers to undertake parts of, or the
entire, design analysis activity traditionally performed by
analysts. The initially expected outcome of this approach for
companies has been decreased costs and lead times without
jeopardizing the quality of the results obtained during the
design analysis project [14]. Later experience has shown that
the involvement of engineering designers in design analysis
has given them deeper knowledge of the product technology,
and improved their knowledge within design analysis, which
in turn resulted in increased collaboration with the analysts
[14]. Since the majority of engineering designers lack the
experience and skills of an analyst, the design analysis tasks to
be undertaken must be adapted to fit these constraints. The
most frequent method development approach to accommodate
this adaptation is to initially identify frequent design analysis
tasks for which tailor-made guidelines or procedures can be
developed and expressed in terms of step-by-step activities to
be followed by the engineering designer. Templates developed
through knowledge-based engineering (KBE) systems can also
be utilized in parallel with the traditional design analysis tools,
in order to provide the necessary support throughout the entire
design analysis process. The nature of the design analysis
tasks to be undertaken by engineering designers might range
from very simple to complex. It is, in other words, fully
possible to allow an engineering designer to undertake design
analysis tasks of a complex nature e.g. involving elements of
multi-physics analysis, without increasing the risks associated
with the actual analysis task [14] when following a properly
establish guideline procedure or template.
Responsibility for the development of these methods
usually lies with a team of engineers, a method development
team, responsible for the engineering design and design
analysis activities within the company. These responsibilities
also include the necessity of active participation of analysts in
the training of the engineering designers as well as supervision
of their analysis efforts, at least initially. The development,
verification and validation of the KBE tools are also the
responsibility of the method development team.
EXEMPLIF ICATION OF THE CONTEXTS
As was mentioned in the introduction, the evaluation task
is not exemplified as it is the most commonly described design
analysis task. An example of an evaluation-oriented analysis
task using the GDA process model (and the mapping of the
interactions between engineering designers and analysts) is
available in [17].
In each of the following exemplifications, the design
analysis activities used for the fulfillment of the design
analysis task are described, following the GDA process model.
The main interactions between engineering designers and
analysts (allowing for a better integration of the design
analysis task into the engineering design and product
development process) are numbered within parentheses. The
adapted GDA process model used for each project is presented
at the end of each section (Figure 4, Figure 9 and Figure 13,
respectively).
Exemplification of a synthesis-oriented explorative
analysis task – the design of a bumper
In designing a bumper beam system, as part of the overall
crash management system, an important task is to assure
accurate predictions of the consequence of various crash
scenarios given different objectives. For low speed impacts, up
to around 15 km/h, the focus is on evaluating repair cost of the
damaged bumper system and for intermediate speeds between
15 and 40 km/h the main focus is pedestrian safety. For crash
scenarios at higher speeds, above 40 km/h, the focus shifts to
driver and passenger protection. A number of regulations,
standards and protocols in Europe, e.g. the United Nations
Economic Commission for Europe Regulation No. 42 (ECE
R42), the Directive 96/79/EC and Regulation No. 78/2009 of
the European Parliament and of the Council, the diverse test
protocols of the European New Car Assessment Programme
(Euro NCAP) and of the Allianz Center for Technology (AZT
Automotive GmbH), are available that outline various
scenarios with which the system should comply.
In this example a center pole impact of the mono rear
bumper beam is introduced; see embodiment in Figure 2. The
purpose of the analysis scenario is to study the intrusion
during a low speed impact in order to reduce the insurance
cost, which is directly related to the predicted level of damage
occurring during the impact scenario. Higher intrusion
indicates increased risk of damaging costly parts in the rear
end of the car resulting in higher insurance costs.
The initial information from engineering design to the
design analysis activities (1) is a short description of the
problem at hand, and since the request came at such an early
stage of the design work, the design space is quite open for
alternative design solutions. During the following discussions

7 Copyright © 2017 by ASME
/1a.1/ it was found that a synthesis-oriented explorative design
analysis task would be the preferred approach. The decision
/1a.2/ to perform the design analysis based on the discussion
were summarized and documented in a preliminary mission
statement /1a.3/, which was communicated back to the
engineering designer (2).
During the next activity, to further clarify the task /1b.1/,
discussions within the project team regarding general
conditions of the analysis scenario (3) took place. The analysis
scenario consists of a 15 km/h central impact against a rigid
pole with a radius of 90 mm as displayed in Figure 2. The type
of result to be extracted was agreed upon as well as the various
input data of the pole and how the interface between the
bumper system and the remainder of the car should be
established /1b.2/, see Figure 2.
Figure 2. Top: constraints setup. Bottom: model parameters
(courtesy Validus Engineering AB).
Furthermore, decisions were also taken regarding the
constraints and the output quantities, such as the objective of
mass and the constraints as shown in Figure 2 (top).
The objective of the design analysis task was set to
minimize the weight while complying with constraints on
intrusion and force into the car crash rail /1b.3/. Also the
project time constituted a constraint that demanded a specific
analysis method to be used in order to keep execution time and
related costs as low as possible. The information known at this
point in time was put into the task content brief for final
acceptance of the task /1b.4/.
However, due to the time span between the preparation of
the task content brief and when it was actually decided to
initiate the execution of the analysis project, there had been
some development on other production related engineering
design activities (4) constraining the design freedom on
thickness parameters, as shown in Figure 2 (bottom), to some
interval values for 7 defined sections whereas other parts were
fixed /1c.1/. This was reflected in an updated version of the
task content brief (5) before the final planning and agreement
on the task was finalized (6).
The geometrical model available was transferred from the
engineering designer to the analyst (7) and the computational
finite element analysis (FEA) model was established /2a.2/
with shell elements that were found adequate for an evaluation
of the response. The car and the pole were both represented as
rigid parts, implying that they are only allowed to translate in
the x-direction, meaning that energy during the impact should
be absorbed by the bumper and transmitted into the car plates.
The model setup was communicated to the project team (8) to
make sure that no new information was available before the
solution processing was initiated. The solution process set out
for this task was to use a d-optimal-based design space
investigation with 13 points based on full factorial DOE wit h 5
levels to establish the base configuration for a linear
metamodel-based RSM optimization. Maximum number of
iterations was set to 8 and tolerance on acceptable results was
set to less than 1% change in both mass and thickness
compared to previous iteration optimum /2b.1/. Thus the total
number of analyses scrutinized was 8 × 13 + 1 = 105 /2b.2/
and the extracted results /2c.1/ show that two feasible designs,
1 and 3, exist for the intrusion constraint, see Figure 3 (left).
Iterations 7 and 8 are close to feasible /2c.2/.
The results were post-processed and the accuracy
predictions in the metamodel were investigated by performing
an additional analysis of iteration 3 that showed that the
predicted value corresponded to the calculated value /2c.3/.
The results were then further assessed /3a.1/, and the
conclusion was that it could be shown that the parameter
configurations of iterations 7 or 8 resulted in lower masses
than the feasible iterations did /3a.2/. These findings were
communicated back (8) to the project team with the purpose of
challenging the constraint level set on intrusion. However, this
was not found practicable and therefore the current set of
results was documented. The main results were thus collected
in a documentation describing the task performed /3b.1/, and
the following main findings were reached:
• The design analysis resulted in a feasible design at
iteration 3 with a mass of 3.79 kg. This is established
through 3 successive generations of linear RSMs and 40
FEAs.
• Additional reduction in mass (about 1.6%) to 3.73 kg was
found in the “nearly” feasible designs in iterations 7 and 8
with 110.2 mm and 110.1 mm intrusion respectively (110
was the criterion), see Figure 3 (right).
These findings were then communicated /3b.2/ and
presented to the project stakeholder (9) with the message that
Pole intrusion
max= 110 mm
Car weight
= 2500 kg
Pole weight =
1000 kg
Rigid car plates move as one
rigid body
Vo = 15 km/h
R=90 mm
Frail
max=75 kN
Bumper cross section

8 Copyright © 2017 by ASME
there is a possible gain in mass reduction if some adjustment
could be allowed on the intrusion constraint against the rigid
pole as displayed in Figure 2. The outline of the workflow
during the bumper design analysis task is shown in Figure 4.
Figure 3. Left: Intrusion as a function of iteration. Right: Mass as a function of iteration (courtesy Validus Engineering AB).
Figure 4. The design analysis activities during the bumper design analysis task (ED: engineering design).
1b. Preparation of the
task content brief
1c. Planning and
agreement of the task
1.Clarification of the task
2.Agreement of results to be
extracted and interface
3.Definition of the overall
purpose of the task
4.Establishment of the
task content brief
1.Discussion around task
relevance and need for
a pre-study
2.Decision to perform
analysis task
3.Establishment of initial
task mission statement
1.Detailed planning of the
task
2.Discussion and
negotiation of the task
3.Agreement or rejection
of the task
2b. Solution processing 2c. Post-processing
1.Establishment of solution
approach and settings
2.Solution scrutinizing
1.Establishment of
engineering model
2.Establishment of
computational model
1.Extraction of solution
results
2.Compilation of result
information
3.Assessment of extracted
results
1.Task documentation
2.Communication of task
findings and
recommendations
1.Results interpretation
2.Evaluation and conclusion
of findings
3.Decision on the need for
additional analysis
1.Participation in decisions
on implementation of
design alterations
3a. Results interpretation
and evaluation
3b. Documentation
and communication
3c. Integration of the
results into the project
2a. Pre-processing
1a. Identification of the task
(9)
ED process
…
……
(1) (2) (3) (4)
(5)
(7)
(10)
…
(6)
GDA process
(8)

9 Copyright © 2017 by ASME
Exemplification of a physical testing – acceptance
testing of a device transportation system
This example presents one of the final physical
acceptance tests of a device transportation system (DTS)
[11;27] developed for a semiconductor device, hereafter
referred to as the “shipped device”, see Figure 5. The shipped
device is sensitive to high acceleration levels and is to be
shipped by different means of transportation, which places
demands on the DTS (see Figure 5 for a schematic overview
of the DTS that insulates the shipped device from vibrations
and shocks during shipment). The main demand on the
performance of the DTS is that the acceleration level on the
shipped device at any point and at any time should not exceed
specified levels. This includes both horizontal and vertical
shock loads as well as vibration. The vertical shock demand is
selected for exemplification in the current publication.
Figure 5. Overall description of the shipped device as well as
the DTS (courtesy Validus Engineering AB).
A total of three different types of tests were performed:
1. Collision test
2. Drop test
3. Vibration test
In this example the drop test scenario has been selected
for the illustration of the workflow during a physical test.
During the identificat ion of the design analysis activity /1a.1/,
the appropriate combination of design analysis approaches to
be used in the validation comparison of the obtained desig n
analysis results to the physical test data was discussed (1). The
limitations and potentials of the selected approaches were
assessed in order to estimate the effect uncertainties would
inflict on the analysis results in relation to the design analysis
activity ahead, based on the present state of knowledge of the
actual project and also within the company emanating from
the preceding design activity /1a.2/. In the current case,
approaches based on multi body simulations (MBS) and FE A
were compared and a decision was made to include
assessments from both types of approaches in the design
analysis task (2).
The purpose of the design analysis task was defined as to
support the testing of the drop test scenario /1b.1/. The drop
test was divided into three phases: free fall, impact and
retardation and the specifications established that the drop test
should be performed from a drop height of 100 mm to avoid
damage to the floor and local damage of the DTS /1b.2/. The
test scenario and placement of measuring devices of the strain
gauges, accelerometers as well as displacement and velocity
transducers on the structure is shown in Figure 6 (left). The
initial proposal on the number and placement of measuring
devices is based on a study of available design analysis results
and documentation from the design work /1b.3/. The task
content brief was established with the above established
information /1b.4/. Within the detailed planning of the design
analysis task it was concluded that properties of a special
made pallet, see Figure 7 ( left), supporting the DTS during the
testing would influence the outcome of testing /1c.1/.
Therefore, it was put forward to the engineering designer to
also include a pre-test analysis assessment of the pallet to the
current design analysis task (3). The task content and approach
was agreed upon and the execution of the design analysis task
was initiated /1c.3/.
The design of the pallet was provided by the engineering
designer (4). The representations of the shipped device and
DTS were also extracted from the development project (5). A
single complete computational model of the pre-test details
was established /2a.2/ and the solution was processed as a pre-
test analysis /2b.1/ in order to assess whether it was able to
sustain the loads during the various test scenarios. The
extracted state of stresses /2c.1/ from the static loading is
displayed in Figure 7 (right); this was communicated back to
the project as intermediate results for review (6). Note that
only the outer frame and pallet are displayed here for clarity.
The interpretation and conclusion of the various cases studied
was that the pallet design proposed was capable of
withstanding all load cases /3a.1/. These findings were
communicated back to the project for further design and
manufacturing of the pallet and preparing it for physical
testing (7), as well as for initiating actual design analyses of
the validation scenario using both ADAMS software (MBS
approach) and LS-DYNA software (FEA approach) (8).
Computation models were established /2a.3/ and initial
analyses were performed for the drop test scenario similar to
the physical testing /2b.2/
Based on the post-processing of the analysis results fro m
the LS-DYNA analysis /2c.2/, further information regarding
the originally proposed measuring points was reviewed and
some small changes were proposed /3a.2/. It was decided to
incorporate them in an updated computational model (9) that
resulted in the actual test setup as shown in Figure 6 (right)
with the DTS mounted on the pallet prepared for a drop into a
1-meter-thick concrete floor from 100 mm /2a.4/. In the
further right hand side of Figure 6 the resulting accelerometer
positions are shown.
The execution of the actual physical test scenario gave the
results presented as red curves in Figure 8. Dimensionless
quantities are used in the graphs, and ±1 represents the
criterion on the shipped device. The measurement point is at
the top of the shipped device. These results were
communicated to the analyst (10) and used in the comparison
between the test data and the extracted analysis results from
Inner
Frame
Outer
Frame
Shock
function
component
Combined carrying and
shock function
component
Vibration
function
component
Shipped
device

10 Copyright © 2017 by ASME
the ADAMS analysis /2c.3/ as shown in the upper picture in
Figure 8, which shows quite good agreement in the free fall
and retardation part of the event /3a.4/. However, the peak at
impact is not captured accurately enough to judge validity. The
comparison /3a.4/ between the test data and the LS-DYNA
analyses /2c.4/ results shows a good correlation for the peak
values.
Figure 6. Drop test description and placement of measurement system (accelerometers, strain gauges and displacement).
Left: Engineering model. Right: Physical test setup (courtesy Validus Engineering AB).
Figure 7. Left: pallet design. Right: stress state from static loading scenario (courtesy Validus Engineering AB).
Figure 8. Top: ADAMS model and results comparison with test data.
Bottom: LS-DYNA results comparison with test data (courtesy Validus Engineering AB).
100 mm
Vo ~ 7.2
km/h
X-direction
Y-direction
Z-direction
Strain gauge
Displacement
Accelerometers
Accelerometers

11 Copyright © 2017 by ASME
Figure 9. The design analysis activities during the physical testing of the DTS (ED: engineering design).
The green dashed rounded rectangles enclose the pre-test analysis steps. The red dashed rounded rectangles enclose the analysis of
the initial test scenario. The red dashed rounded rectangles enclose the analysis of the updated test scenario. These three analyses
have been performed sequentially as described in the text above.
1b. Preparation of the
task content brief
1c. Planning and
agreement of the task
1.Definition of the overall
purpose of the task
2.Clarification of the task
3.Assessment of measuring
devices
4.Establishment of the
task content brief
1.Discussion around task
relevance and need for
a pre-study
2.assessment of viable
approaches
3.Decision to perform
analysis task
1.Detailed planning of the
task
2.Discussion and
negotiation of the task
3.Agreement or rejection
of the task
2b. Solution processing 2c. Post-processing
1.Pre-test solution
scrutinizing
2.Initial analysis of the drop
test scenario
3.Updated analysis of drop
test scenario –ADAMS
4.Updated analysis of drop
test scenario –LS DYNA
1.Establishment of
engineering models
2.Establishment of pre-test
computational model
3.Initial computational model
for test scenario
4.Updated computational
models for test scenario
1.Extraction of pre-test
solution results
2.Results extraction of
initial drop test scenario
3.Results for updated drop
test scenario -ADAMS
4.Results for updated drop
test scenario –LS DYNA
1.Communication of
findings of pre-test
2.Documentation of test
scenario comparison
3.Communication of
documentation
1.Results interpretation and
conclusion of pre-test
2.Evaluation of initial drop-
test analyses
3.Decision on the need
for additional analysis
4.Comparison of physical
drop test data and
analysis results
5.Conclusion on
comparisons
1.Participation in decisions
on implementation of
design alterations
3a. Results interpretation
and evaluation
3b. Documentation
and communication
3c. Integration of the
results into the project
2a. Pre-processing
1a. Identification of the task
GDA process
(5)
ED process
…
……
(1)
(3)
(4)
(6)
(8)
(10)
…
(7)
(2)
(9)
(11)

12 Copyright © 2017 by ASME
The conclusion drawn from the validation comparison
/3a.5/ is that neither analysis approach is capable of capturing
the whole event nor alone able to provide the necessary facts
needed for the acceptance of the criterion. Instead, both the
ADAMS and LS-DYNA analyses are capturing different
aspects of the event to describe adequately the complete drop
test scenario. The ADAMS analysis /2b.3/ is used to predict
the overall informat ion from the event and LS-DYNA analysis
/2b.4/ is used to predict the acceleration levels at and after
impact with the floor. This conclusion is documented /3b.2/
and communicated /3b.3/ to the project team by email as well
as participation in a final product acceptance meeting where
the analysts as well as the engineering designers involved in
the testing were present to elaborate on the inferences from the
validation comparisons (11). The outline of the workflow
during the physical testing of the DTS is shown in Figure 9.
Exemplification of method development –
development of a template for analyzing a valve and
seating for a combustion engine
In the automotive industry, new and more extensive
environmental demands on emissions from combustion
engines force manufacturers to optimize performance of their
engines. One component in such an engine that is especially
affected by these efforts is the exhaust valve and its seating,
see an example Figure 10. The tradit ional procedure in the
design of an exhaust valve seating arrangement is that the
engineering designer generates a design solution that is handed
over to the design analysis department for evaluation.
Figure 10. Exhaust valves and seatings of a diesel engine.
It was decided that the engineering designer in charge of
the design and development of the exhaust valve and its
seating should carry out the generation and evaluation of the
concepts on his/her own. One reason for this approach was
that additional projects of the same nature were expected in
the future. As the engineering designer usually lacks deep
insight into design analysis, it was expected that performing
design analysis on his/her own would introduce major
problems that would demand extensive support [20]. To be
able to handle these problems and thus allow the engineering
designer to generate and evaluate an extensive number of
different exhaust valve seating concepts, it was decided that a
template based design analysis (TBDA) should be introduced.
TBDA is defined in [14] as a pre-developed code that supports
or guides the person performing design analyses tasks, e.g.
from predefined settings available in traditional computer
aided engineering (CAE) tools to scripts developed in-house
and advanced usage of knowledge-based systems (KBS).
In the example presented here, a template is developed for
the design analysis of the exhaust valve seating design,
utilizing method development. Developing such a template
generates high development costs, but as such a template can
be used for a number of different sizes of combustion engines,
the cost for the development could be accepted.
During the project planning, discussions around task
relevance and the need for a pre-study (1) was agreed upon. A
pre-study /1a.2/ was performed. After evaluating the results
from the pre-study and the establishment of a preliminary
mission statement (2), it was decided that a method
development (3) for this type of design task (conceptual
exhaust valve seating designs) should be performed. Since the
method development should result in a template to be used by
an engineering designer who does not have in-depth
knowledge of design analysis, there were many different types
of issues to be resolved.
One important issue was the quality aspect of the
template and how to ensure that the users can only do what
they were allowed to do. It was decided during the definition
of the overall purpose of the task (4) that the implementation
of KBS into the developed template should provide the
necessary quality assurance (QA), /1b.2/. A routine for
ensuring the QA of the developed template was formulated,
/1b.3/. It was also essential to make the implementation of the
template user friendly by developing a custom made user
interface /1b.4/.
During the detailed planning of the task (5), the final
settings for the model were agreed upon. An agreement on
how the user should utilize the template involving sub
activities was now completed and an agreement or rejection to
develop the template was decided /1c.2/.
The user interface, see Figure 11, and the possibility to
read and write from a spreadsheet were utilized in the
establishment of the geometrical and computational models as
well as the KBS elements (rules, checks and constraints) (6).
were integrated and connected to the geometrical and
computational models /2a.2/.
Valve
Seating
Combustion area

13 Copyright © 2017 by ASME
Figure 11. User interface.
The computatio nal mo del /2a.3/ was prepared. Tolerances
of the mesh, boundary conditions and contact properties, and
the materials were implemented into the computational model
– some of the outputs as presented to the user are illustrated in
Figure 12. The necessary settings for the analysis execution
was defined /2b.1/.
The computational model – mesh
The computational model – boundary conditions
Figure 12. Some outputs from the template.
The co mputational model was now ready for solution and
the solution scrutinizing /2b.2/ was performed. Note that
during this activity the method development involved a
number of analyses in order to cover established design space.
During the extraction o f solut ion results /2c.1/, “sensors”
(extreme values in form of parameters) and predefined plots
were implemented. The sensors are also utilized for assuring
the quality, by comparing the result with the agreed settings
for the specific task /2c.2/. If any values are outside the valid
range, warnings appear, informing the user that the given
solution is not valid /2c.3/. With this type of method
development, consistency of both the geometrical and the
computational model is important. During the same phase, an
extra verification was performed with external analysis
software /2c.4/. Under results and interpretation and
evaluation, the template was evaluated and conclusion of
findings were discussed in the method development group (7).
Validation of the developed template was made by instructions
from the previously developed routine (/1b.3/) /3a.2/.
After the validat ion was completed, task documentation
(8) was made, containing the full process of the method
development as well as the background information on its
purpose. As the developed template was intended to be used
by different users, a user guide (9) was written to support the
engineering designer when performing analysis utilizing the
template. The last sub activity in the method development is
finalizing the method development (10) and implementing the
template (11) for use in the engineering design process. The
outline of the workflow of the method development of a
template for the design analysis of the exhaust valve and
seating is provided in Figure 13.
CONCLUSION
Being able to execute efficiently and effectively design
analysis tasks in different contexts is important. The
exemplifications above show that the GDA process model can
be successfully adapted to accommodate these goals. As the
GDA process model shares several activities with other design
analysis process models, these latter models might also
manage efficiently contexts other than explorative and
evaluation-oriented ones. It would be beneficial in any case to
check systematically design analysis process models for
different contexts and devise specific guidelines for the m
when necessary.
Learning to adapt a process model or a methodology by
use of cases is not yet much developed within the engineering
design discipline. Such an approach might be interesting to
enhance learning and understanding of engineering design
process models.
The GDA process model has been used in more than 50
industrial projects within the different contexts mentioned.
However, the guidelines presented here to adapt the GDA have
not been tested with analysts not involved in this research.
This should be the next step, as ease of use and
implementability are keys for the diffusion of methods and
methodologies [28;29].

14 Copyright © 2017 by ASME
Figure 13. The design analysis activities during the method development of a template
for the design analysis of exhaust valves and seatings (ED: engineering design).
REFERENCES
[1] Adams, V. and Askenazi, A., 1998, Building Better
Products with Finite Element Analysis, OnWord
Press, Santa Fe, NM.
[2] Gokhale, N. S., Deshpande, S. S., Bedekar, S. V. and
Thite, A. N., 2008, Practical Finite Element Analysis,
Finite to Infinite, Pune, India.
[3] Moaveni, S., 2014, Finite Element Analysis: Theory
and Application with ANSYS, 4th Edition, Prentice
Hall, Upper Saddle River, NJ.
[4] Rao, S. S., 2005, The finite element method in
engineering, 4th Edit ion, Elsevier, Amsterda m.
[5] Sunnersjö, S., 1992, FEM in Practice - an
Introduction to Use of the Finite Element Method (In
Swedish. Original title: FEM i praktiken - en
introduktion till finita elementmetodens praktiska
tillämpning), Sveriges verkstadsindustrier,
Stockholm.
[6] Zahavi, E., 1992, The Finite Element Method in
Machine Design, Prentice Hall, Englewood Cliffs,
NJ.
1.Extraction of solution
results
2.Compilation of result
information
3.Assessment of extracted
results
4.Verification of
established method
1.Discussion around task
relevance and need for
a pre-study
2.Pre-study
3.Establishment of initial
task mission statement
4.Decision to perform
method development
1.Establishment of
engineering model
2.Preparation of KBS
elements
3.Establishment of
computational model.
1.Evaluation and conclusion
of findings
2.Validation of developed
method
3a. Results interpretation
and evaluation
2a. Pre-processing
1a. Identification of the task
GDA process
(8)
(5)
…
………
(3)
(2)
(1)
(4)
(6)
(7) (9)
1.Task documentation of
established method
and background
2.Documentation of users
guide
1.Finalizing the method
development
2.Implementation of
developed method.
3b. Documentation
and communication
3c. Integration of the
results into the project
2b. Solution processing 2c. Post-processing
1.Establishment of solution
approach and settings
2.Solution scrutinizing
1b. Preparation of the
task content brief
1c. Planning and
agreement of the task
1.Definition of the overall
purpose of the task
2.Clarification of Quality
assurance
3.Definition of user interface
1.Detailed planning of the
task
2.Agreement or rejection
of the task
(10)
(11)
…
ED process

15 Copyright © 2017 by ASME
[7] Baguley, D. and Hose, D. R., 1994, How to Plan a
Finite Element Analysis, NAFEMS, Glasgow.
[8] Adams, V., 2006, How to Manage Finite Element
Analysis in the Design Process, NAFEMS, Glasgow.
[9] Adams, V., 2008, A Designer's Guide to Simulation
with Finite Element Analysis, NAFEMS, Glasgow.
[10] Spicer, 2002, Why Do - Design Optimisation?,
NAFEMS, Glasgow.
[11] Eriksson, M., Petersson, H., Bjärnemo, R. and Motte,
D., 2014, "Interaction between computer-based
design analysis activities and the engineering design
process - An industrial survey", 13th International
Design Conference - DESIGN'14, DS 77, Vol. 2,
Dubrovnik, May 19-22, 2014, pp. 1283-1296.
[12] Motte, D., Eriksson, M., Petersson, H. and Bjärnemo,
R., 2014, "Integration of the computer-based design
analysis activity in the engineering design process –
A literature survey", 10th International Symposium
on Tools and Methods of Competitive Engineering -
TMCE'14, Vol. 2, Budapest, May 19-23, 2014, pp.
1181-1194.
[13] Eriksson, M., 2015, Fundamentals of a Methodology
for Predictive Design Analysis, PhD Thesis, Division
of Machine Design, Department of Design Sciences
LTH, Lund University, Lund.
[14] Petersson, H., Motte, D. and Bjärnemo, R., 2015,
"Using templates to support the engineering designer
performing computer-based design analysis",
International Mechanical Engineering Congress &
Exposition - IMECE’15, Vol. 11, Houston, TX,
November 13-19, 2015, p. V011T14A002.
[15] Ellet, W., 2007, The Case Study Handbook, Harvard
Business School Press, Boston, MA.
[16] Mauffette-Leenders, L. A., Erskine, J. A. and
Leenders, M. R., 2007, Learning with cases, 4th
Edition, Richard Ivey School of Business, The
University of Western Ontario, London, ON.
[17] Eriksson, M., Bjärnemo, R., Motte, D. and Petersson,
H., 2017, "Integrating engineering design and design
analysis activities at an operational level", 11th
International Workshop on Integrated Design
Engineering- IDE Workshop'17, Magdeburg,
Ger many, April 5-7, 2017, pp.69-80.
[18] Pahl, G., Beitz, W., Feldhusen, J. and Grote, K.-H.,
2007, Engineering Design – A Systematic Approach,
3rd Edition, Springer, London.
[19] Ulrich, K. T. and Eppinger, S. D., 2012, Product
Design and Development, 5th Edition, McGraw-Hill,
London.
[20] Petersson, H., Motte, D., Bjärnemo, R. and Eriksson,
M., 2015, "The engineering designer in the role of a
design analyst – An industrial survey", NAFEMS
World Congress 2015, San Diego, CA, June 21-24,
2015.
[21] Eriksson, M., 2003, "Establisment of a foundation for
Predictive Design Analysis within the engineering
design process", NAFEMS World Congress 2003,
Orlando, FL, May 27-31, 2003.
[22] Eriksson, M., 2014, "The Methodology of Predictive
Design Analysis", International Mechanical
Engineering Congress & Exposition - IMECE'14, 11,
Montreal, Quebec, Canada, November 14-20, 2014,
p. V011T14A023.
[23] Nordin, A., 2015, Reconciling Form and Function
through Generative Design, PhD Thesis, Division of
Machine Design, Department of Design Sciences
LTH, Lund University, Lund.
[24] Vincke, P., 1992, Multicriteria Decision Aid, Wiley,
Chichester, United Kingdom.
[25] AIAA, 1998, Guide for the Verification and
Validation of Computational Fluid Dynamics
Simulations, AIAA-G-077-1998, American Institute
of Aeronautics and Astronautics (AIAA), Reston, VA.
[26] Mårtensson, H., Forsman, J. and Eriksson, M., 2009,
"Simplified forced response HCF assessment of
turbomachinery blades", Proceedings of ASME Turbo
Expo 2009: Power for Land, Sea and Air - GT'09,
Vol. 6, Orlando, FL, June 8-12, 2009, pp. 477-486.
[27] Eriksson, M. and Burman, Å., 2005, "Improving the
design process by integrating design analysis", 15th
International Conference on Engineering Design -
ICED'05, DS 35, Melbourne, August 15-18, 2005.
[28] Motte, D. and Eriksson, M., 2016, "Assessment
framework for a methodology under development –
Application to the PDA methodology", 11th
International Symposium on Tools and Methods of
Competitive Engineering - TMCE'16, Aix-en-
Provence, France, May 9-13, 2016, pp. 373-388.
[29] Chakrabarti, A. and Lindemann, U. (Eds.), 2016,
Impact of Design Research on Industrial Practice -
Tools, Technology, and Training, Springer
International Publishing, Cham, Switzerland.