Addressing Complexity Aspects in Conceptual Ship Design:

A Systems Engineering Approach

Henrique M. Gaspar,* Donna H. Rhodes, Adam M. Ross, and Stein Ove Erikstad*
*Department of Marine Technology, Norwegian University of Science and Technology, Trondheim, Norway

Systems Engineering Advancement Research Initiative, Massachusetts Institute of Technology, Cambridge, MA

This article approaches the complexity aspects of conceptual ship design from a
systems engineering point of view. We introduce the issue by defining the term com-
plexity in systems engineering, placing the conceptual ship design task as a complex
system problem and creating analogies between generic complex systems and a
ship. Five main aspects of complexity are presented, linking challenges of the con-
ceptual phase to each of the aspects. The structural aspect is related to the arrange-
ment and interrelationship of the physical objects in the ship. The behavioral aspect
derives from the form-function mapping. The external circumstances to which the
ship is subjected are approached through the contextual aspect. Uncertainties in the
scenarios and changes over time are related to the temporal aspect. The perceptual
aspect relates to how stakeholders perceive the value that they receive from a chosen
design. A theoretical study to address these five aspects is presented, applying the
responsive systems comparison method in the conceptual design of an anchor han-
dling a tug supply vessel. The last section discusses why decomposing the com-
plexities of the ship design task in five aspects is a benefit.

Keywords: conceptual ship design; complex systems engineering; responsive

systems comparison method

1. Complexity in systems engineering and
conceptual ship design
1.1. Defining complexity in systems engineering
THE FIELD known as complexity theory has been rapidly evolving
in the last few years, spreading complexity thinking in social, bio-
logic, and technical sciences from corporation management (Tasaka
1999) to the evolution of biologic organisms (Braha et al. 2006).
In the case of engineering, three seminal works can be used
as the basis for a complexity definition. First, Herbert Simon
(Simon 1962) proposes that how complex or simple a structure
is depends critically on the way in which we describe it. Simon
proposes a hierarchical approach to complexity, decomposing the
system until it can be understood. It is, however, always difficult
to describe a structure; by selecting words, we are also defining
Manuscript received by JSPD Committee April 20, 2012; accepted
July 9, 2012.
the abstract boundaries in the meaning of the term and, by exclu-
sion, all the infinite characteristics that the term does not contain.
A simple example is a ship. Is it a structure that floats? Does it
have its own propulsion? Are barges, canoes, and ships vessels?
Are vessel and ship synonymous?
Second, to clarify the previous definition, it is necessary to
embrace a few arguments from the algorithm information theory
and Kolmogorovs definition of complexity (Kolmogorov 1983):
If any object is simply constructed, then for its description a
small quantity of information is sufficient; but if it is compli-
cated, then its description must contain much information.
According to certain arguments, it is convenient to call the
quantity thus introduced the complexity.
In simple terms, Kolmogorov introduces that the more infor-
mation an object has, the more complex it is. Our object is thus
the system. The arguments that Kolmogorov refers to can be
understood as the other objects that interact with the system,
because the specification task of an object is easier when another
object to which this object has a relation is already specified.

52
 Figure 1 represents the link between complexity and information
with two essential principles. First, when a system requires more
information to be defined, it can be considered more complex.
Second, this information can be observed under many aspects, and
a good system definition will take into account only the relevant
ones. In the remainder of this section, we propose that the structural
and behavioral aspects have dominated when defining and evaluat-
ing a complex system. These two aspects are essential in engineer-
ing, but, when used alone, they exclude important information.

1.2. Complex systems

Fig. 1 Complexity and information
A third work is by Suh, who also developed the idea of infor-
mation connected to the design complexity, proposing that the
violation of the information axiom, to minimize the information
content of the design will maximize the probability of success,
will result in complexity in the system (Suh 1990, 2005). In
other words, more information brings complexity, applying
common sense that is easier to design and evaluate a system
that requires less information to be defined than a system that
requires more information.
In summary, the complexity that we talk about in the remainder
of this article is related to the systems engineering (SE) point of
view, summarized by the work of Magee and de Weck (2004).
Complexity is thus defined as the amount of relevant information
necessary to define a system, including components, intercon-
nections, performance, and scenarios among other perspectives
that may be required.
This definition assumes that every system carries an amount of
information, and only the relevant information will be taken into
account when defining it. It is clear that information related to the
structural strength or welding properties are more pertinent than
taste or color when designing for the maritime sector. The same
assumption, however, cannot be assumed as true if we are dealing
with food engineering or dentistry.
The SE approach already incorporates the word complex in the
definition of a system: a system is a complex unity formed by
many often diverse parts subject to a common plan or serving
a common purpose (Oliver et al. 1997). Complex thus means a
system that requires much information in several perspectives
to be defined.
Magee and de Weck (2004) developed this definition to distin-
guish complex engineered systems from other complex systems
such as natural systems. They define all complex engineered sys-
tems as real, open, artificial, dynamic, hybrid (system states are
both continuous and discrete), and have mixed control (both
autonomous and human-in-the-loop elements or subsystems).
The definition of complexity related to the amount of informa-
tion also goes in line with the SE approach to define complexity.
Hubka and Eder (1988) propose a four-level degree to measure
complexity, presented in Table 1. Although the classification is
limited by the prementioned focus on the structural/behavioral
point of view, it serves as a rough measure to affirm the common
sense idea that a ship is more complex than a propeller.
Most advanced engineered systems can be considered even
more complex than the level IV presented in Table 1, because a
large ship, aircraft, or building lies in the limit between a system
and a system of systems. SE is, therefore, a discipline that goes
in line with this attempt to understand problems such as highly
complex designs. Most authors who focus on SE usually do not
define the term complexity, letting the common sense of the
reader define it. For this reason, and to grasp the benefits of
applying SE in conceptual complex systems design, we briefly
introduced previously in this section a general definition of com-
plexity based on information and its perspectives. This definition
is applied on the ship design case in Section 1.3. Section 2 intro-
duces the five aspects of complex systems to extend the traditional
structural/behavioral aspects and their link with early stages of
ship design. In Section 3 we apply the concept of value robustness

Table 1 Technical Systems Classified by Degree of Complexity (Hubka and Eder 1988)

Degree of Complexity Technical System Characteristics Examples

I (simplest) Part, component Elementary system produced without assembly operations Bolt, bearing sleeve, spring, washer
II Group, mechanism, Simple system that can fulfill some higher functions Gear box, hydraulic drive, spindle head,
subassembly brake unit, shaft coupling
III Machine, apparatus, device System that consists of subassemblies and parts that Lathe, motor vehicle, electric motor
perform a closed function
IV Plant, equipment, complex Complicated system that fulfills a number of functions Hardening plant, machining transfer
machine unit and that consists of machines, groups and parts that line, factory equipment
constitute a functional and spatial unity

Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach 53

in the ship case. The Responsive Systems Comparison method
(RSC), developed by the Massachusetts Institute of Technology
(MIT), is selected as an SE method able to achieve this value
robustness while addressing the five aspects. Section 4 presents
a theoretical example of the technique, applying the RSC method
to the design of an anchor handling tug supply vessel (AHTS).
A discussion of the approach is presented in Section 5.
1.3. A ship as a complex system
The idea of a ship as a complex structure is so established
in the field that even in classic works such as Evans (1959) and
Benford (1967), it is possible to find a reference to the word.1
At that time, the main research question was to determine the
correct value of the technical performance of a design. The cor-
responding tradeoff between technical and economic objectives
is still the core of the design task and can be captured in the
Evans-Buxton-Andrews spiral. The extension of this traditional
view toward a SE approach can be exemplified in the early
1990s by Mistree et al. (1990) with their proposal to embrace
stronger systems thinking, concurrent engineering, and life-cycle
perspectives during the conceptual phase. More recently, Gualeni
and Dazzy (2009) and Hagen and Grimstad (2010) call for
extended boundaries on the systematic design, focusing on current
challenges such as new technologies and environmental concern.
Andrews also discusses SE thinking as a rational way to
approach ship design with many uses in both UK and US defense
acquisitions. The approach is, however, criticized by constrain-
ing the fundamentally creative elements of design Andrews and
Pawling (2009). This is one of the main arguments when justify-
ing his comprehensive methodology for ship design (Andrews
1998) and a creative approach to ship architecture (Andrews 2003)
as extension of the pure SE thinking. Andrews proposes, for
instance, the building block approach as a method to handle the
structural aspect (of a complex system as a ship), producing a
more informed and information rich preliminary design.
Singer et al. (2009) ratifies the current increase in complexity
during the preliminary design and proposes the set-based design
as a means to handle the increased information content during
conceptual design. The method goes beyond the traditional point-
based design (McKenney et al. 2012), concurrently identifying
multiple design alternatives within the feasible design space as
opposed to iterating from only one single instance like in the
design spiral.
The continuous advancement of computational capacity and
methods has developed as well a more reliable simulation-based
ship design (Sharma et al. 2012). It allows applications in struc-
tures, fluid dynamic, discrete events (such as oil spilling, cargo
handling and ship evacuation (Bertram & Thiart 2005), and
economic efficiency. These advancements create even more
information to be handled during the conceptual phase. Some
optimization techniques dig into this information to handle
uncertainty in the input data such as fuzzy logic modeling (Gray
1
Our emphasis: Evans (1959): ships and aircraft are examples of such
extremely complex problems. Not only are they structures, but vehicles as
well. Furthermore, they are vehicles whose efficiency or, in fact, whose very
ability to perform at all, is strongly dependent on weight economy; Benford
(1967): the selection of ship size has in the past been rather arbitrary simply
because the complexities of the problem precluded any sort of rational approach.
54 Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
et al. 2010) and identification of an optimal design for future
contracts such as the ship design and deployment problem
(Erikstad & Fagerholt 2011).
Caprace and Rigo (2011) developed a metric to assess com-
plexity in the conceptual phase of a shipbuilding project. The
approach can be considered an introduction to the complexity
thinking in the conceptual phase, suggesting a value to compare
ships on the basis of complexity. The formulation proposed is
based on the type and arrangement of the ship. The metric is
strongly focused on the structural aspect of design, thus leaving
out other complexity aspects, also important in the early stages.
To define what type of complexities exists in the early stages
requires an extension in the boundaries of the design, as pro-
posed by Hagen and Grimstad (2010). This extension calls not
only for more refined methods and calculations, but to bring
into the early stages other aspects besides the purely technical
evaluation of a constrained context. It means a wider design
methodology, able to include new technologies, environmental
concerns, operational profiles, and fleet interaction during the
early stages. In other words, a realization that the traditional
structuralbehavioral aspects no longer cover all the information
necessary to defines a design as a good one during the early
stages. Nowadays a ship is more complex because much more
information is required for a design to be perceived as a good
one. This new amount of information increases the complexity of
new designs, and it is necessary to develop methods able to bring
other types of insights into the preliminary stage such as robust-
ness toward uncertain scenarios and environmental performance.
This call for new perspectives leads us to raise the following
open research questions:
How should the traditional structural/behavioral focus be
extended to incorporate the new requirements on the concep-
tual phase of ship design?
How can SE provide support for handling this increase
in complexity?
What set of techniques can be applied in conceptual ship
design to address the main aspects of complexity?
Section 2 presents a SE taxonomy that will give a partial
answer to these questions, characterizing systems complexity by
five aspects that extend the traditional model-based SE with
new constructs and methods.
2. Five aspects of complex systems
2.1. Five aspects to organize complex systems information
Rhodes and Ross (2010a, 2010b) propose five essential aspects
for the engineering of complex systems. The benefit of this
decomposition is to keep the current model-based SE approach,
which embraces the behavioral and structural complexity aspects,
adding three other aspects: contextual, temporal, and perceptual.
The latter three extend the design problem boundaries while at
the same time leading to a systems environment that is con-
tinuing to grow in terms of information. Table 2 provides a brief
SE definition of the five aspects.
This classification works as well as a taxonomic framework, that
is, a useful way to organize information to share knowledge with
others (Rhodes & Ross 2010b). This effort to organize systems
 Table 2 Complexity Aspects Definition (Rhodes & Ross 2010a)

Traditional Structural: related to the form of system components and
their interrelationships
Behavioral: related to performance, operations, and reactions
to stimuli
New aspects Contextual: related to circumstances in which the systems exists
Temporal: related to dimensions and properties of systems over time
Perceptual: related to stakeholder preferences, perceptions,
and cognitive biases
State of the practice: systems architecting and design, and emerging
model-based systems engineering approaches
New constructs and methods: seek to advance state of the art,
for example: set-based design, ship design and deployment problem,
epoch modeling, epoch-era analysis, multistakeholder negotiations,
visualization of large data sets

information reflects in a characterization of the complexity in engi-
neering. As follows, we apply this characterization to the concep-
tual ship design problem.
The following aspects are explained through the product point
of view, in which the process is just a means to achieve the desired
physical object. Although one could also address complexities
in the design task (process), as briefly commented by McDonald
(2010), the focus of this article is on the product (ship).
2.2. Five aspects in conceptual ship design
In the following subsections the five aspects of classification
are applied to the conceptual ship design problem. An introduc-
tion to the complex system application is discussed by Gaspar
et al. (2012), but the authors focus mainly on the relation between
uncertainties and the temporal aspect. In this section we extend
this application to the five aspects as a whole.
2.2.1. Structural. The structural aspect is related to the form
in the basic form-function mapping of the design. It includes
the physical objects of the ship, as observed by Levander in
his system-based ship design methodology (Levander 2006;
Erikstad & Levander 2012).
Primarily, this aspect relates to the ship as a large, self-
contained system with several highly integrated subsystems such
as propulsion, hull, outfit, and so on. Each of the subsystems
contains many components, which also consists of a physical
structure, and interacts with other components, similar to the
classification presented in Table 1. All these subsystems must
be provided by the vessel itself within a limited volume, in which
changes on one part may influence other parts through highly
interactive relationships. This large structure, the ship, also inter-
acts with other structural components from the maritime transpor-
tation system, a system of systems, in which it is included.
An overview of the structural aspect is presented in Fig. 2 with
the ship as the main system and the surrounding interconnections.
2.2.2. Behavioral. The behavioral aspect derives the function
from the form, and it is handled by the technical analysis per-
formed during the design phase such as resistance, propulsion,
seakeeping, maneuverability, and stability. It can also be observed
as the interaction between the system and a stimulus, either inter-
nal stimuli from a subsystem (such as the propulsion engine) or
external stimuli from the environment (such as the waves).
Figure 3 illustrates the behavioral aspects.
During conceptual design, the type of analyses required to esti-
mate the ship behavior relies to a large degree on empirical formu-
lation and advanced engineering tools such as regression analysis
models, finite element methods, and computational fluid dynamics.
The traditional performance is thus estimated by the correct
mapping between form and function to ensure in the conceptual
phase that a ship X will perform a task Y. Over the past decades,
model-based approaches have been developed to handle the
structural/behavioral aspect and are now at a relatively mature
practice level (Rhodes & Ross 2010a).
In addition to traditional technical/economical tradeoffs, con-
ceptual ship design nowadays requires estimation of the behavior
across a broad number of areas, including risk, safety, and envi-
ronmental performance. It results in a more complex and multi-
objective evaluation function.
2.2.3. Contextual. The contextual aspect consists of external enti-
ties, interfaces, and factors outside of the control of ship designers,

Fig. 2 Structural aspect for the ship as a system, with subsystems and system of systems.

Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach 55

 Fig. 3 Systems behavior under stimuli
which may affect the behavior of the system and should be taken
into account while designing it. Traditional contextual aspects are
usually considered fixed and predetermined during the require-
ments of the elucidation phase. It usually includes a specific scenario
with a predefined set of market variables, regulations, and rules.
Andrews and Pawling (2009) defend an extension of these
fixed requirements, extending the context to include those ele-
ments that traditionally would be considered in another phase of
the project and/or during the design of another system/subsystem
related to the ship. For instance, estimation of operational profiles
is used in the design of machinery configuration (Gaspar et al.
2010) and should be taken into account in the estimation of
possible scenarios for the design of complex mission vessels
such as offshore support vessels. Fleet estimation data such
as optimal velocity, total capacity, and a possible contract
scenario also can be fed into the conceptual phase for envi-
ronmental assessment (Winnes & Ulfvarson 2006) and risk
(Berle & Asbjrnslett, 2011). Hagen and Grimstad (2010) also
comment about the addition of contextual information in terms
of new technologies and environmental rules/milestones in the
early phases.
Figure 4 illustrates contextual elements that should be taken
into account when designing the system.
2.2.4. Temporal. The dynamic properties of the context lead to
changes of the external entities that may affect the system over
time. The temporal aspect characterizes those shifts of the context
during the system lifespan. Uncertainties in how contexts may
unfold are also incorporated as part of this aspect, for instance
the uncertainty related to the operational profile of the ship or
as a result of the estimation of future contract scenarios.
Fig. 4 Contextual aspects of the system
56 Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
Fig. 5 Temporal aspects as a shifting uncertainty in the context
These different possible contexts can be interpreted as what if
situations. If the set of parameters leads to context A, the desired
system behavior/structure is obtained in design A; if uncertain
context shift creates a different context B, then another ship may
perform better, leading to design B. This idea of the temporal
aspect is captured in Fig. 5.
The context parameters are normally related to some general
categories of key exogenous uncertainties such as: demand (opening
of a new market/route); technology development (a new type of
fuel or engine, changes in the hull or ballast system); policy and
regulations (a new emission control area [ECA] or an SOX /NOX
tax); and market shifts (alterations in fuel and freight price, high
or low global economic growth).
2.2.5. Perceptual. The perceptual aspect is related to how the
system is interpreted through the perspective of system stake-
holders. In general terms this aspect intends to answer the question
of How is decision X perceived by stakeholder Y? For instance,
how the decision of installing a technology to reduce air emission
(e.g., selective catalytic reduction [SCR]) is considered by:
Society ! reduce emission in atmosphere
Shipyard ! more components during construction
Shipowner ! higher construction cost
Ship User ! higher maintenance cost
Design Office ! more elaborated mathematical model to
estimate air emission during design
The perceptual aspect also deals with the perceived good-
ness of design concepts when a stakeholders preferences shift
over time. The what if situation is extended, adding other
points of view into the design, to achieve value robustness of
the system.
A key point to realize per this aspect is that the same system
could be perceived to change in value solely as a function of
changes in the stakeholders preferences. That means, the system,
its context, behavior, and everything else could remain the same,
but the system could still fail if people change their perception
and expectations (i.e., preferences) on what they want from the
system. This is distinct from requirements, which are just aggre-
gated, derived snapshots of needs early in the life cycle.
To answer whether design A is more efficient than design B
will require a formal construction of the system key perfor-
mance indicators (KPIs), customized to each stakeholders pref-
erences, without changing the core system. As an example,
consider the recent concern with energy efficiency. A solution
 Fig. 6 Perceptual aspects in ship design

to install less power and/or slow speed creates a conflict between

environmental gain and loss of availability. Figure 6 illustrates
the perceptual aspect.
The perceptual aspect must also take into account the pre-
sentation of the KPI data. It is rather impossible to present only
one design as the best one without taking into account stake-
holders needs and selected contexts. Even when a systematic
approach is used such as quality function deployment (QFD) or
analytic hierarchy process (AHP), a weight must be given to each
of the KPIs. However, different designers, contexts, and require-
ments may need different weights, thus making it difficult to
provide a baseline weighting value that will satisfy the evaluation
of every possible design to every single stakeholder.
The evaluation of all data from the multidimensional design
space is thus inconceivable as a result of the strict time and
Fig. 7 Five aspects in complex system ship design
resources on the preliminary ship design process (Erikstad 1996).
For this reason, most of the attributes of this aspect cannot
be directly measured, that is, its abstraction sometimes lacks a
standard set of metrics, relying on a gut feeling, instead of solely The following sections present a SE approach to address these
on a quantified basis. It can be considered that this aspect is the one five key complexities.
that contributes more to the residual information of a complex
design. That is, it deals with some information that cannot be quan-
tified, although it is necessary to define the goodness of the system. 3. Systems engineering approach to complexity
in conceptual ship design
2.2.6. Overview of the five aspects in ship design. Figure 7
compiles an overview of the five aspects within the traditional 3.1. Designing for value robustness
ship design boundary and with an extension of it into a complex
Value robustness is defined as the ability of a system to con-
system approach (based on Gaspar et al. 2012).
tinue to deliver stakeholder value in the face of shifts in con-
Based on the current conceptual ship design problem, we pro-
text and needs (Ross and Rhodes 2008). Value robustness is a
pose five key complexities faced in this phase, one for each
key objective during the conceptual design phase of a complex
aspect. As follows:
system, because the range of system expectations may vary from
Structural: interaction between components, i.e., strongly stakeholder to stakeholder and the recognition that the system
coupled design, with useful modularization, to efficiently deter- resides in a dynamic context. These expectations are translated
mine function from form in stakeholder-defined and perceived decision metrics, that is,
Behavioral: a functional breakdown, leading to the correct the system performance attributes. These performance attributes
mapping between form and function, that is, assuring that a are used as indicators to evaluate the system. The goal of a
design can be evaluated given a scenario and mission. system designer is thus to maximize the value delivered by a
Contextual: extension of the context entities, taking design at an efficient level of resource expenditure across time
into account not only technical and economic factors, but (Ross et al. 2009).
also adding new elements such as environmental concerns Observing this concept in light of the five main complexity
and risk. aspects, value robustness is strongly related to the perceptual
Temporal: take into account context shifts and uncer- aspect, because that is the part of the information that will
tainties during the lifespan of the ship, evaluating sequences determine how the stakeholders perceive value from a design.
of changes in the context entities through time. However, as commented Section 2.2, this is the aspect with high
Perceptual: documentation of what if situations to residual information, that is, with some information that cannot
capture different stakeholders preferences and expectations. always be quantified.

Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach 57

 To diminish the residual and to handle these five aspects of
information, we propose the use of the RSC method, a seven-
process method that can provide insight into the measurable part
of the perceptual aspect as well as taking into account informa-
tion related to the other four aspects.

3.2. Responsive Systems Comparison Method

RSC offers a suite of techniques that can be adapted to a wide
range of complex systems. This MIT-developed method (Ross &
Rhodes 2008; Ross et al. 2009) consists of a synthesis of recently
developed SE constructs and methods, allowing for the incorpora-
tion of traditional model-based systems engineering techniques
with more recent approaches such as Epoch-Era Analysis. The
goal of RSC is to generate knowledge about tradeoffs, com-
promises, and risks to a system development project and identify
system concepts that are actively and/or passively value robust
(Rhodes & Ross, 2010a).
The reasons to select RSC among many others SE methods
to address the complexity aspects are stated as follows:
The method offers a suite of techniques that can be
adapted to a wide range of complex systems, including not
only a particular type of ship or scenario.
It is not a standalone technique; on the contrary, it has
the advantage of being able to merge with many traditional and
novel design methods.
It is in line with the SE definition of complexity, handling
it by decomposing and encapsulating the information neces-
sary to define the system.
It contains a strong emphasis on the structural and
behavioral aspects by mapping of function and form through
design variables and performance attributes. However, it
also has the benefits of including methods to handle the addi-
tional three aspects, discretizing the context into variables,
time into epochs and eras, and perception into utilities through
the life cycle.
Figure 8 shows a flowchart of the method, with its seven main
processes, briefly explained as follows. More details about this Fig. 8 Responsive Systems Comparison method flowchart (based on
method are presented in Ross et al. (2008, 2009). Ross et al. 2009)
The following subsections provide a brief description of
each of the seven processes, linking the method with the five
complexity aspects. This process strongly impacts the definition of what is a value
robust design, that is, what is the problem, why it is important,
3.2.1. Value-driving context definition: identify overall problem/ who cares about it, and which types of value are required for a
needs statement. The first process in RSC captures the overall solution to be considered satisfactory over its lifespan.
problem statement. It consists of selecting what is the overall
value proposition for a design, key constraints, and which context 3.2.2. Value-driving design formulation: elicit stakeholders
and stakeholders should be taken into account. needs statements (performance attributes) and formulate system
This is the process that filters the information, establishing the solution concepts (design variables). The value-driving design
main expected results for a design to be considered value robust formulation is the process in which the needs and require-
under stakeholder perceptions. This information is linked to the ments are expressed as objectives. It includes the mission of the
perceptual aspect and must be gathered into an efficient state- system, its structure, and the main performance attributes to
ment of the problem to define and evaluate the designed system. achieve these goals.
These high-level requirements will feed the next two processes: The process contains two main parts: first the quantification of
they create the boundaries for the attributes and variables of the the performance attributes with a range of minimum/maximum
design of process 2 and they establish the key contextual factors value based on stakeholders preferences. The attribute perfor-
that may affect the problem, including instances from the past, mance reflects the behavioral aspect, whereas the acceptance
present, and expectations and uncertainties for the future, which ranges on the attributes, along with utility function, are related
will be the basis for decomposing the context entities in process 3. to the perception of what is and is not perceived as acceptable.

58 Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach

The second part is generation and proposition of the concepts
and associated design variables. Those variables are the decom-
position of the structural aspect, which will drive the stakeholder-
expressed attributes.
It converges the elicitation of the basic information design
problem, the mapping between the structure (form) and behavior
(ability of perform a function), which are based on expert knowl-
edge. The QFD that is typically used here to organize and justify
inclusion of particular design variables will be partially validated
by the modeling and simulation (or other data) in process 4.
3.2.3. Epoch characterization: parameterize the range of
contextual shifts/uncertainties (epochs) under consideration.
This process characterizes the potential contexts in which the system
will be inserted. It takes into account contextual information and
transforms these into parameters to describe not only a fixed con-
text (snapshot of the present situation, for instance), but also alter-
native potential contexts resulting from shifts and uncertainties.
The contextual aspect of complexity is decomposed into con-
text parameters called epoch variables. Each epoch variable has a
unit, range, and discretization level, similar to the design vari-
ables. The epoch variables represent thus a possible change in a
key exogenous uncertainty, working as an instrument in the map-
ping between the context and vessel performance.
The interval of time with a fixed set of contextual factors, that
is, a vector of epoch variables, is called an epoch. A potential
epoch space is defined at the end of this process with the enumer-
ation of many possible epochs to create a set of contexts. Each
epoch encapsulates a fixed context, that is, a snapshot of a certain
period of time when the epoch variables will not shift.
3.2.4. Design tradespace evaluation: gain an understanding,
via modeling and simulation, of how key system concepts
and trades (design variables) fulfill overall value space (perfor-
mance attributes) in response to contextual elements (epochs).
The design tradespace evaluation is the process in which many
design alternatives in each of the selected epochs are evaluated in
terms of (performance) attributes, utilities, and costs of each
design. The approach typically includes the production of a plot
of a general utility versus cost in a scatter graph of all of the
designs per epoch.
This process is the one in which techniques from traditional
design processes are performed. Many computer tools are avail-
able in the market to calculate the main attributes given a range of
design variables based on regression analysis, analytical and dis-
crete models, and so on. Optimization methods can also be applied.
The main function of this process is the decomposition of the
behavioral aspect, giving understand of the design space. An eval-
uation of the design space will converge (encapsulate/filter) into
a set of selected designs (for instance, through a Pareto set).
After this evaluation, the product is a large amount of data.
The analysis of this data is conducted in the following processes
(5, 6, and 7).
3.2.5. Multiepoch analysis: identify value robust system designs
across changing contexts and needs. Multiepoch analysis starts
the process of organizing the data obtained in process 4. This
produces a large number of system designs, organized by common
metrics, the utilities, and costs defined in process 2. The selection
Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
of the designs that will be part of the next process can be done in
many ways.
The temporal aspect is decomposed into epochs, and it is possible
to evaluate the design space behavior within each of these epochs.
The evaluation of the design across these epochs contributes to a
filtering or classification of the most robust designs, taking into
account probabilistic distribution of expectations, specific stake-
holder preferences, or extensive epoch space search. An example
is using Pareto Trace metrics identifying the designs that perform
well across a large number of epochs.
Ross et al. (2009) present some techniques such as tradespace
yield, distribution of attributes, Pareto Set for a single epoch, and
Pareto Trace across epochs. The objective is to identify possible
passive value robust designs, that is, clever designs that are
perceived to maintain high value over many different epochs.
Active robustness is also possible to be evaluated through change-
ability analysis, that is, when design characteristics are able to
change through epochs (Ross et al. 2008). Fitzgerald and Ross
(2012a, 2012b) extend the analysis proposing a set of metrics
to mitigate contextual uncertainties with valuable changeability.
3.2.6. Era construction: develop era timelines from the set of
enumerated epochs. An era is defined as a time-sequenced set of
epochs, which follows a determined logic through time, that is, a
time-ordered set of contexts. Various potential eras will be gener-
ated in the era construction process, which results in a group of
eras arranged in a way that represents potential lifetimes (era) of
the system. The epoch sequencing must obey consistency rules in
the epoch variables such as continuity constraints and appropriate
monotonicity in the progression of the epoch variables (such as
technology levels).
This process promotes the understanding of the impact of time-
dependency within selected lifespan scenarios for potential designs,
including time sequences of such point scenarios as: high expected
demand, followed by a crisis time, followed by changes in regula-
tions or the emergence of new technologies.
3.2.7. Life cycle path analysis: develop near- and long-term
system value delivery strategies in response to time-dependent
contextual elements (described through era timelines). The last
process deals with strategies to sustain the value of designs
across potential eras. Life cycle path analysis allows for an under-
standing of the cost of modifications that designs have to perform
better when a shift in one of the epochs in an era occurs. In other
words, this process helps to answer two questions: Which modifica-
tions do the designs need to perform better within a given era?
What are the costs and benefit of these changes?
To answer these questions, it is necessary first to define which
design variables can be changed during the operational life cycle
given a cost. An example design change is adding new technology
or installing some new equipment. We can also compare making
changes to an existing design with the cost of a new design.
The product of this process must be analyzed based on the stake-
holders value-driven context definition established on process 1.
It means a convergence of the structural, behavioral, contextual,
and temporal aspects to satisfy the perceptual aspect, because it is
the perception of the decision-makers who will decide if the final
set of designs is value-robust enough. Fitzgerald and Ross (2012b)
extend the analysis to apply valuable changeability in this phase,
proposing techniques toward identifying strategies that enable
59
a more robust value design when design characteristics are able to
be changed, given a certain cost, through epochs.
The next section illustrates the RSC method with a ship
design example.
4. Example of the Responsive Systems Comparison
method: anchor handling tug supply vessel design
Our theoretical example consists of the conceptual design of a
ship from a complex SE point of view. RSC is used as the main
method to handle the information. It is important to keep in mind
that this is not a definitive or closed method, and the ideas behind
this article can be extended to handle more complicated situations.
For instance, no changeability analysis is done, that is, we are
not considering changes in design over time. Our main objective
is to present a design procedure able to handle the five aspects,
gaining understanding of the complexity inherent to the system,
and finally producing better designs.
This example applies the method to the design of an AHTS. For
such vessels, the operational profile is more complex and diverse
than for most other ships. The combined range of transportation
work (supply), nontransportation/functional work (anchor handling/
tug), and geographical operating conditions (such as North Sea,
Brazilian Coast, Arctic, African Coast, Gulf of Mexico) forms a
large number of potential missions (Gaspar 2010). The problem
statement, approach, and proposed solution are presented accord-
ing to the seven processes of the RSC method.
4.1. Anchor handling tug supply vessel value-driving
context definition
The problem is to design an AHTS for the support of hydro-
carbon exploration and production in the areas on the Brazilian
continental shelf. The vessel should be able to operate during a
25-year lifespan. Figure 9 illustrates this phase.
The purpose of the design is narrowed down to supply, anchor
handling, and tug missions. Each contract is considered a mission
with requirements specified for each task activity such as: supply
capacity and field operations requirements. Other context entities
also are taken into account such as the possible implementation
of ECA regulations in the future (SOX: SECA, and NOX: NECA)
and availability.
The main design question remains whether the shipowner should
install or not install more capabilities than the minimum required
for the first contract. Five main capabilities are thus taken into
Fig. 9 Anchor handling tug supply vessel overall problem and needs statement
60 Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
account: transport, nontransport, environmental, energy efficiency,
and cost. A decomposition of those capabilities into utilities is
done in the next process.
4.2. Anchor handling tug supply vessel value-driven
design formulation
The transition between stakeholders needs and objectives occurs
in this phase. It organizes the set of performance attributes that
are necessary to fulfill the mission statement of need.
In our case, the performance attributes are divided into four
main utilities plus cost:
Transport capabilities requirements: related to the mini-
mal contract transportation work capabilities, that is, supply.
The vessel should have enough volume in the tanks (m3) and
deck area (m2) for the cargo.
Nontransport capabilities requirements: related to the
minimal contract nontransportation work capabilities, that is,
functional work. The vessel should have enough capability
installed on board to match contract requirements and deploy
them. Those capabilities are related to:
Bollard pull: used as main attribute to evaluate tug and
anchor handling missions
Availability: related to the ability of a vessel to per-
form its task under a certain environmental condition. It is
measured in time window percentage, meaning that a vessel
with a 98% value will keep working under more severe
conditions than a vessel with a 95% value.
Environmental: related to the ability of a vessel to operate
in a SECA or NECA.
Energy efficiency: measured by the fuel consumption of
the vessel. Additional technologies can be considered during
the design phase to make the vessel more energy-efficient.
Cost: related to the investment cost (CAPEX) and opera-
tional cost (OPEX).
CAPEX is assumed to be a function of vessel size and
capability.
OPEX is related to a fixed cost equal to all vessels plus
a fuel cost related to the consumption of the vessel under a
certain contract.
The mapping between the design variables and performance
attributes includes knowledge intrinsic to the design process. In
this example, for illustrative purposes, our assumptions will be
 Table 3 Stakeholder-desired Performance Attributes Table 5 Epoch Variables

Attribute Name Units Utility (0 to 1) Epoch Variables Units Range (minimummaximum) Levels

Transport Volume Cargo m3 5.000 ! 12.000 Volume Cargo m3 1000 to 10000 6

Area Cargo m2 500 ! 1200 Area Cargo m3 500 to 1000 3
Non-transport Bollard Pull ton 150 ! 250 Bollard Pull ton 150 to 250 11
(towing and anchor handling: SECA yes/no 0 to 1 2
proportional to Bollard Pull) NECA yes/no 0 to 1 2
Availability % 95 ! 98 Availability %time window 95 to 98 4
Env. SECA yes/no 0!1 Potential Epoch space 3.168
NECA yes/no 0!1
E.Eff. Energy Efficiency % 0 ! 20
Fuel Consumption kton/year 5 ! 20 with different requirements. Therefore, context parameters are
Eco. CAPEX MUSD 50 ! 100 based on potential contract requirements with a minimum require-
ment for transport and nontransport capabilities. Three other
Table 4 Design Variables constraints are added: necessity (or not) of SECA, NECA, and
minimal availability value. Only vessels with capabilities  contract
Variables Units Range (minimummaximum) Levels requirements are able to deploy the contract. The revenue of each
epoch is related to its capabilities requirements and yearly-based.
Length m 90 to 110 11 Table 5 lists the epoch variables.
L/B 4 to 5 6
B/D 2 to 2.5 6
SECA yes no 0 to 1 2 4.4. Anchor handling tug supply vessel design
NECA yes no 0 to 1 2 tradespace evaluation
Extra Power %MCR 0 to 20 3
Energy Efficiency %Fuel 0 to 20 3 The tradespace evaluation deals with the behavioral aspect, assur-
Availability %time window 95 to 98 4 ing that a design is evaluated given a mission. It means evaluating
Design Space 57.024 the whole tradespace (the span of enumerated design variables, that
is, the design space) for each of the epochs (fixed set of epoch
variables, that is, the epoch space). This evaluation is made through
based on a regression analysis of similar designs.2 The performance modeling and simulation, and as output, we obtain the attributes,
attributes are organized in Table 3 in terms of units, and utility utilities, and cost of each design for each epoch. The current design
range, from minimum acceptable (0) to maximum desirable (1).
The structural aspect is decomposed to the selection of a few
primary design variables related to the main dimensions and capa-
bilities of the ship. The list of the design variables is presented in
Table 4 with units and ranges resulting from this process. For this
study, each range is discretized in a certain number of equally
spaced levels to enumerate the design space. These design vari-
ables were chosen so as to drive the attributes and cost.

4.3. Anchor handling tug supply vessel epoch characterization

Epoch characterization deals with the contextual aspect, taking
into account the external factors of the contracts that influence
the ship. Each epoch represents a different context, that is, a contract

2
Assumptions:
Supply: cargo tanks volume proportional (/) 0.4 * the cubic number
(CN) [m3]; cargo deck area (/) 0.4*total deck area [m2]
Towing and anchor handling: / bollard pull [ton]
ECA: comply with ECA regulations [y/n]
Availability: / perform a task under a certain time window [% time
window] energy efficiency: (/) fuel consumption given a operation profile
[ton/year]
Energy efficiency: (/) fuel consumption given a operation profile [ton/year]
L/B and B/D ratio: / regression analysis data [adimensional]
Bollard pull: / installed power (182[CN]0.4368).
Extra installed power: / percentage of 182pCN[0.4368 [%]
CAPEX: / size of the ship (10e3 USD/GT) plus extra capabilities
(installed power, ECA, energy efficiency, availability) [M USD]
OPEX: / fuel consumption cost within a given contract [M USD]
Contract revenue / to the contract requirements. A more demanding
contract will pay more. Fig. 10 Tradespace evaluation process

Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach 61

space contains 57.024 possible designs, and it is evaluated for
all 3.168 epochs. Figure 10 illustrates this process.
As a result, the process presents data for the attributes of each
of the designs in each of the epochs.
Most of the data of this process is used to compare designs.
Figure 11 combines two plots to illustrate some of the results.
First, in Fig. 11(a), it is presented the total utility for all designs
versus CAPEX. This total utility is calculated with equal weight
for all performance attribute utilities through all epochs (cargo
volume, cargo area, bollard pull, energy efficiency, SECA,
NECA, and availability utilities). Five designs along the Pareto
frontier are highlighted. Second, it is possible to understand the
influence of the design variables on the performance attributes,
bringing more insight to the structural/behavioral aspects. An
example is the plot of the CAPEX versus the ship length, as in
Fig. 11(b).
4.5. Anchor handling tug supply vessel multiepoch analysis
This process deals with the extensive amount of data obtained
from the tradespace evaluation. Each epoch is a different context,
a snapshot of a possible time period. The objective is to obtain
insight from these contextual and temporal data through an analy-
Fig. 11 Example of tradespace data: total utility (a) and performance
attributes versus design variables (b)
62 Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
Fig. 12 Attributes analysis for one epoch
sis of the good design solutions among the epochs. Our design
set was based on static utility; however, it could be obtained from
the performance of any single or set of epochs.
Figure 12 presents the epoch space with all 3168 epochs. An
epoch set is selected to compare epoch variables (i.e., contract
requirements). The life cycle cost was selected rather than the
CAPEX, because now we are taking into OPEX (fuel consump-
tion) and epoch revenue.
Analyzing across many epochs allows one to identify the pas-
sive value robust designs, that is, designs that retain high value
over many different epochs. As an example, Fig. 13 plots the total
utility for Epoch 1032, considered as if the whole life cycle
(25 years) consisted of no contextual changes. The plot also
presents the decomposition of the total utility within the four
selected utilities.
It is also possible to analyze the performance though one spe-
cific set of epochs with common characteristics, for instance, only
epochs with ECA requirements or epochs with high nontransport
capability requirements. From the analysis of many Pareto Frontiers
of each, set it is possible to obtain a multiepoch Pareto Set, exem-
plified by Fig. 14.
4.6. Anchor handling tug supply vessel era construction
An era encapsulates a piece of information from the temporal
aspect and represents a full potential lifespan of the system. It is
defined as a time-ordered sequence of epochs (contexts). The era
space is created by combining elements of the epoch space to
construct long-term scenarios.
The possible era space is typically very large and with a high
computational cost for it to be calculated in its entirety. The
era construction process selected for this example is based on
Gaspar et al. (2012) and consists of applying the storytelling, or
narrative approach, as observed in Table 6. By selecting
expectations and preferences, one can identify the corresponding
 Fig. 13 Utilities plot for Epoch 1032

Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach 63

 epoch and model those manually constructed eras. The sum of
these possible lifetime scenarios (eras) defines the era space.
An automatization of the process can be easily done based on
probabilistic distribution of future contracts and/or stakeholders
preferences, a more risky or conservative approach, for instance.

4.7. Anchor handling tug supply vessel life cycle path analysis
The last process of the RSC method deals with the perceptual
aspect, focusing on what kind of result is needed to achieve value-
robustness. It includes the comparison of solutions, tradeoffs,
and time-based strategies to select a set of designs that will be
carried forward to be refined after the conceptual phase.
In this example we plot the profit per each of the epochs (the
Fig. 14 Pareto set with efficient design across epochs
revenue of a contract minus the OPEX) and the life cycle profit for
two eras (sum of the revenue of all epochs, minus the CAPEX)
Table 6 Storytelling Process for Construct Era Space
presented in Fig. 15. Net present value is used to calculate the
profit with a symbolic discount rate of 3%, combining the revenue
Expectations Epoch Start End
of each contract, ship CAPEX, and OPEX.
Era 1 An extension of the model may contain the calculation for a
Minimal contracts for the first 10 years 0 2013 2023 given return of investment (ROI) period, which varies from 5 to
SECA requirements is added 8 2023 2028 12 years in shipping. This means the revenue of future contracts
5 years later NECA requirement is added 12 2028 2038 deployed after this period should have much less importance
Era 2 in the selection of the design than the ones deployed on the
Minimal contracts for the first 5 years 0 2013 2018 first years. One way to address ROI in the current model is to
Increase of Bollard Pull (190 tons) 64 2018 2028
construct eras with the duration of only the ROI period, that is,
5 years later, increase of availability (97%) 66 2028 2033
modifying the era length from 25 years to the desired period, for
Increase of Bollard Pull (240 tons) 146 2033 2038
instance 10 years.

Fig. 15 Life cycle profit for two eras

64 Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach

 5. Discussion and concluding remarks
In this article we have characterized the conceptual ship design
task as a complex system problem. We introduced and applied the
five aspects of complex systems to the early stages of conceptual
ship design, and later, we used the RSC method to address the
information of these five aspects to develop value robust designs.
The design of an AHTS was used as an illustrative example of
application of the method.
The principal value of our work lies not in the result of the
AHTS example, but rather in the ideas behind it. Instead of only
dealing with information of the traditional structuralbehavior
approach, the five aspects extend the ship design task. By adding
the conceptual, temporal, and perceptual aspects into the early
stages, the designer is able to address the additional information
that nowadays is necessary to identify a good design, that is,
a value-robust one.
To handle these five aspects, we introduced the use of the RSC
method into the ship design problem. The RSC method represents
a divide-and-conquer approach to the five aspects, namely:
Structural: decomposition of the structural aspects through
a discretization of the design variables, with a given range
maximumminimum, creating a design space. The evaluation
and refinement of the design space though the processes leads
to a flexible group of choices, not based on a single design
point such as the traditional spiral method.
Behavioral: performance attributes will guide the design
set choice, which is evaluated through a series of different pos-
sible contexts. The tradespace evaluation process is also less
iterative than the traditional spiral, having a characteristic more
related to the concurrent engineering process, because all the
design space is evaluated for all the epochs in the same phase.
This allows the evaluation of the performance attributes in
parallel, making the task of comparing designs faster.
Contextual: context factors are decomposed during the
epoch characterization process. Therefore, a large number
of different scenarios are evaluated in the following process,
capturing expectations and uncertainties.
Temporal: a discrete context allows for manipulation of
future scenario constructions through era construction. Life
cycle analysis is a powerful way to evaluate the behavior of a
given design set under many alternative future scenarios.
Perceptual: the method has the advantage of taking into
account multiple stakeholder perceptions. For instance, defining
on the first process what is considered to be valuable, pro-
posing a utility range in the attributes able to grade designs
according to a certain performance attribute value. The attri-
butes are also normalized later under a common utility metric,
facilitating the solutions comparison and tradeoffs. It allows a
customized selection of the design set toward specific decision-
makers preferences.
In summary, the complex systems approach requires the decom-
position and encapsulation of the design problem to manipulate
and understand the complexities. Because it is not always possible
to reduce complexity, that is, to reduce the required information
to define a good system, the objective of the design process
transforms into controlling the current information and reduc-
ing the part of the information that cannot be easily handled.
This residual part, the gut feeling, may never be totally con-
Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
trolled, but the extension of the aspects, at least, brings more light
into uncertainties.
The RSC method goes in line with the current call for new
methods to handle complexity in the early stages of design. For
instance, the tradespace evaluation process shares some of the
characteristics from the set-based design to deal with the structural
and behavioral aspects such as the establishment of feasibility
before commitment, keeping good solutions to evolve in parallel
instead of sticking to a single point. Both methods use low computa-
tional cost tests to prove infeasibility or identify Pareto dominance
(Singer et al. 2009). Our AHTS example is a rather simple imple-
mentation of the method, because the structural/behavioral aspects
are handled mainly by regression analysis. An extension of the
method would be the use of discrete methods, for instance QFD to
extend the energy efficiency (Sharma et al. 2012) or the use of mod-
ularization as building elements (Andrews 2003; Erikstad 2009) with
a design space composed by the possible interaction of the modules.
The fuller appreciation of the RSC method is better gained
through the handling of the contextual, temporal, and perceptual
aspects. The multiepoch and era analysis allows for the modeling
of uncertainties, handling the contextual aspect and evaluating
many contexts at the same phase of the design process. The tem-
poral aspect is also observed in these processes, including changes
in the context over time and creating tradeoffs among the designs
under different scenarios. The life cycle path analysis process
also proposes strategies to adapt designs to better perform across
unfolding era uncertainties.
The perceptual aspect is exploited by the use of what if situ-
ations through era construction and life cycle analysis. It means
that not only one single design is evaluated, but also a design set,
comparing each of the solutions for each of the envisioned scenarios.
Hence, our conclusion is that the complex systems theory pro-
vides an efficient way to handle the complexity aspects in the
conceptual phase of ship design. The discretization of the sys-
tem into five aspects, and the use of an overall method to address
all aspects such as RSC is an advancement on the current ship
design task, allowing the use and integration of novel and well-
established techniques.
Acknowledgments
We gratefully acknowledge funding for this research provided
through SHIP-4C KMB project (NTNU, Norway) and the MIT
System Engineering Advancement Research Initiative (SEAri).
We also thank Arnulf Hagen (DNV \ NTNU) for his contribution
during the research.
References
ANDREWS, D. 1998 A comprehensive methodology for the design of ships
(and other complex systems). Proceedings, R. Soc. Lond. A. Vol 454.
ANDREWS, D. 2003 A creative approach to ship architecture, International
Journal of Maritime Engineering, 145, 3, 229252.
ANDREWS, R., AND PAWLING, R. 2009 The Impact of Simulation on Prelimi-
nary Ship Design. IMDC, Trondheim, Norway.
BENFORD, H. 1967 On the Rational Selection of Ship Size. Society of Naval
Architects and Marine Engineers, Jersey City, NJ.
BERLE, ., AND ASBJRNSLETT, B. E. 2011 Failure modes in the maritime
transportation systema functional approach to throughput vulnerability.
Maritime Policy and Management. Routledge, Taylor & Francis Group,
London, UK.
65
BERTRAM, V., AND THIART, G. D. 2005 Simulation-Based Ship Design.
OceansEurope, June 2023, Brest, France.
BRAHA, D., MINAI, A. A., AND BAR-YAM, Y. 2006 Complex Engineered
Systems. Springer-NECSI, Cambridge, UK.
CAPRACE, J. D., AND RIGO, P. 2011 Ship complexity assessment at the
concept design stage, Journal of Marine Science and Technology, 16, 1,
6875.
ERIKSTAD, S. O. 1996 A decision support model for preliminary ship
design. PhD thesis, Norwegian University of Science and Technology,
Trondheim, Norway.
ERIKSTAD, S. O. 2009 Modularisation in Shipbuilding and Modular Pro-
duction. Innovation in Global Maritime Production, Norwegian University
of Science and Technology, Trondheim, Norway.
ERIKSTAD, S. O., AND FAGERHOLT, K. 2011 A ship design and deployment
model for non-transport vessels, Ship Technology Research, 58, 3, 132141.
ERIKSTAD, S. O., AND LEVANDER, K. 2012 System Based Design of Offshore
Support Vessels. International Marine Design Conference, June 1114,
Glasgow, UK.
EVANS, J. H. 1959 Basic design concepts, American Society of Naval Engi-
neers Journal, 71, 4, 671678.
FITZGERALD, M. E., AND ROSS, A. M. 2012a Mitigating contextual uncer-
tainties with valuable changeability analysis in the multi-epoch domain, Pro-
ceedings, 6th Annual IEEE Systems Conference, Vancouver, Canada, March.
FITZGERALD, M. E., AND ROSS, A. M. 2012b Sustaining lifecycle value:
valuable changeability analysis with era simulation, Proceedings, 6th Annual
IEEE Systems Conference, March, Vancouver, Canada.
GASPAR, H. M., NEUMANN-LARSEN, E., GRIMSTAD, A., AND ERIKSTAD,
S. O. 2010 Efficient design of advanced machinery systems for complex
operational profiles, Proceedings, 9th International Conference on Computer
and IT Applications in the Maritime IndustriesCOMPIT, April 1214,
Gubbio, Italy.
GASPAR, H. M., ROSS, A. M., AND ERIKSTAD, S. O. 2012 Handling temporal
complexity in the design of non-transport ships using epoch-era analysis,
Intl J. Maritime Eng., Trans RINA, 154, A3, 109120.
GRAY, A. W., DANIELS, A. S., AND SINGER, D. J. 2010 Impacts of fuzzy
logic modeling for constraints optimization, American Society of Naval
Engineers, 122, 2, 121132.
GUALENI, P., AND DAZZY, N. 2009 Naval architecture and systems engineer-
ing: a deal for naval ship design evolution, IJME Rina A, 151. doi:10.3940/
rina.ijme.2009.a1.128
HAGEN, A., AND GRIMSTAD, A. 2010 The extension of system boundaries
in ship design, Proceedings, Intl J. Maritime Eng., Transactions of RINA.
Vol. 152.
HUBKA, V., AND EDER, W. E. 1988 Theory of Technical Systems: A Total
Concept Theory for Engineering Design. Springer-Verlag, New York, NY.
KOLMOGOROV, A. N. 1983 Combinatorial foundations of information theory
and the calculus of probabilities, Russian Mathematical Surveys, 38, 4,
2736.
66 Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
LEVANDER, K. 2006 System Based Ship Design. Norwegian University of
Science and Technology, Trondheim, Norway.
MAGEE, C. L. AND DE WECK, O. L. 2004 Complex system classification,
Proceedings, 14th Annual International Symposium of the International
Council on Systems Engineering, June 2024, Toulouse, France.
MCDONALD, T. P. 2010 A library based approach for exploring style in
preliminary ship design. PhD thesis, University College London, UK.
MCKENNEY, T., BUCKLEY, M., AND SINGER, D. J. 2012 Differentiating set-
based design from other design methods and the cultural challenges of
implementation, Proceedings, 11th International Maritime Design Confer-
ence, Glasgow, UK.
MISTREE, F., SMITH, W. F., BRAS, B. A., ALLEN, J. K., AND MUSTER,
D. 1990 Decision-based design: a contemporary paradigm for ship design,
Proceedings, SNAME Annual Meeting, November 3, San Francisco, CA.
OLIVER, D. W., KELLIHER, T. P., AND KEEGAN, J. G. 1997 Engineering Com-
plex Systems with Models and Objects. McGraw-Hill, New York, NY.
RHODES, D. H., AND ROSS, A. M. 2010a Five aspects of engineering com-
plex systems: emerging constructs and methods, Proceedings, 4th Annual
IEEE Systems Conference, April, San Diego, CA.
RHODES, D. H., AND ROSS, A. M. 2010b Shaping socio-technical system
innovation strategies using a five aspects taxonomy, Proceedings, EuSEC
May, Stockholm, Sweden.
ROSS, A. M., MCMANUS, H. L., RHODES, D. H., HASTINGS, D. E., AND LONG,
A. M. 2009 Responsive Systems comparison method: dynamic insights
into designing a satellite radar system, Proceedings, AIAA Space 2009,
September, Pasadena, CA.
ROSS, A. M., AND RHODES, D. H. 2008 Architecting systems for value
robustness: research motivations and progress, Proceedings, 2nd Annual
IEEE Systems Conference, April, Montreal, Canada.
ROSS, A. M., RHODES, D. H., AND HASTINGS, D. 2008 Defining changeabil-
ity: reconciling flexibility, adaptability, scalability, modifiability, and robust-
ness for maintaining system lifecycle value, Systems Engineering, 11, 3,
246262.
SHARMA, R., KIM, T., STORCH, R. L., HOPMAN, H. J. J., AND ERIKSTAD,
S. O. 2012 Challenges in computer applications for ship and floating
structure design and analysis, Computer Aided Design, 44, 3, 166185.
SIMON, H. 1962 The architecture of complexity, Proceedings of the Amer-
ican Philosophical Society, 106, 6, 467482.
SINGER, D. J., DOERREY, N., AND BUCKLEY, M. E. 2009 What is set-based
design, Naval Engineers Journal, 121, 4, 3143.
SUH, N. P. 1990 The Principles of Design. MIT Press, Cambridge, MA.
SUH, N. P. 2005 ComplexityTheory and Applications. Oxford University
Press, Oxford, UK.
TASAKA, H. 1999 Twenty-first-century management and the complexity
paradigm, Emergence, 1, 4, 115123.
WINNES, H., AND ULFVARSON, A. 2006 Environmental improvements in ship
design by the use of scoring functions. Journal of Engineering for the
Maritime Environment, 220, 1, 2939.
 Discussion
Arnulf Hagen, Visitor
This illuminating and well-written paper represents an important
contribution to the development of ship design theory. It has
traditionally focused on developing well-suited responses to
grossly static performance requirements, in effect directing the
ship designer towards optimized solutions for one or a few
situations. There are several reasons for this, including the need
to reduce the degrees of freedom to make the design process less
costly and more manageable, in effect making it easier to
converge towards a documentable sound design solution. It has
been a pragmatic way to manage the complexity of the design
process.
In the shipping community, the fallibility of this is well known.
A ship in operation is not subject to situations remaining static
over time, but a wide variety of physical, regulatory and
commercial circumstances. For instance, in periods of
overcapacity ships may steam down far below the design speed,
moving into speed ranges where both hull and engines perform
poorly.
The challenge is in general that an optimized ship can have a
superior design if evaluated in situations resembling what it was
designed for, but may (and, arguably, in most cases will) show
performance degradation in other situations.
In addition, though highly related to the above, traditional ship
design has focused on functional performance. Whether a ship
meets the requirements is, in a typical shipbuilding contract,
measured on rather rudimentary, measurable criteria such as
attainable speed, cargo capacity, fuel consumption and a few
other parameters. As change occurs faster, the uncertainty about
the future increases. This, combined with the tendency of
businesses, banks and society to become more risk averse,
strengthens the case for robust design. This also implies that
more stakeholders have interests in the design; their perceptions
matter gradually more.
The authors extend the design process, appreciating these
developments, and pave a path towards handling the inherent
complexity. Simplified design frameworks may reduce the
complexity, but this does not change the fact that the complexity
is a real feat in the real world. The epoch-era and the responsive
systems comparison is a novel approach, enriching the field of
design theory.
They have concretely argued well for why the mapping structure
to function, leaving all else either static or outside the realm of
design, is insufficient in our time. They have made an important
contribution with a theoretical framework with which it is
possible to enrich the representation of the design context, with
which it is possible to capture that these contexts change in
time, and with which it is possible to consider the (changing)
perceptions of the stakeholders during design. The paper
formulates a strong theoretical position.
Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
I view the proposition as intentionally idealized. In practice, I
would claim there are severe practical limits to how to capture
all five aspects, or dimensions, during design. Transactional
costs are real and important, leaving the ship designer (in this
context intended as a placeholder for all those involved in the
design process) with limited resources to collect information on
the relevant contexts, the relevant temporal situations, and the
relevant stakeholders. Reducing uncertainty is, in my opinion,
essential to avoid that the resulting design becomes speculative,
too vulnerable to assumptions.
On this issue, I would have liked to see a discussion on what are
acceptable residuals when talking about information. Do the
authors agree that this is an issue, and do they have a view on
whether it is possible to quantify, or otherwise guide on the
matter of how to handle information shortage?
Of course, aiming towards a low residual will typically imply
expenditure of cost and time. Accepting a high residual will
typically imply that the resulting design solution becomes more
speculative, or also making it very difficult for the decision
makers (or the stakeholders) to actually know which of the
design alternatives are best too much uncertainty will increase
the number of plausibly good designs, making selection
difficult.
The authors mention the Pareto front in the paper, leaving it up
to the decision makers to make tradeoffs, but with increasing
number of dimensions and parameters, even Pareto optimization
becomes difficult. Do the authors have a suggestion for how to
guide the decision maker in this process, so as not to overwhelm
her with choices?
The perceptual dimension deserves particular discussion. In
general, multi-attribute decision-making is difficult, as there
must be some way to quantify the utility function. One way is to
force the decision maker to, explicitly or implicitly, prioritize
between different values of different parameters, and use this to
derive enough information to perform tradeoffs. This is already
difficult in a static, traditional setting with one decision maker.
How much extra is a ship owner willing to pay for a ship with
increased environmental performance? When involving
changing contexts (e.g. in a high-risk environment, risk appetite
tends to be reduced, in effect constituting a non-linear effect),
and changes in time (e.g. in poor markets, preferences may be
different than in high markets) it seems very difficult to capture
the true preference structure of the stakeholders. Do the
authors agree that this is an issue, and are there in that case
robust ways to capture (and weight among) preferences from the
relevant stakeholders?
In closing, I would like to congratulate the authors on a
significant work that will inspire new work, paving the way for
a gradual movement away from the rather simplistic and nave
optimization-approach in traditional ship design, and towards
design processes that may result in more robust ship designs.
67
Hans Hopman, Visitor
First I would like to congratulate the authors for their very
interesting paper. This paper defines a new approach for
addressing the need for requirements elucidation in ship
design as promoted by professor David Andrews of UCL. The
five aspects categorizes very well the different types of
requirements to be varied during the concept design phase to
identify design drivers and for doing a sensitivity analysis in a
structured way. It also makes designers more aware of the fact
that requirements are not a fixed target but are usually derived
from a simplified model of a poorly defined problem. In
addition, this problem is usually defined in a predicted future
environment.
However, I would like to make a remark on complexity as
defined in this paper and how this is linked to the five aspects
relevant for engineering. Complexity could indeed be related to
the amount of relevant information necessary to define a system.
Uncertainties, like in behavior prediction and in requirements,
are not necessarily a reason for defining the systems to be
designed as more complex. These uncertainties mainly refer to a
risk-assessment that in itself can be complex (as a process) but
that will not necessarily result in making a system a complex
system.
The overview in 2.2.6 defines the five aspects in ship design. I
am missing human factors as another aspect in complexity.
Perhaps the structural complexity should also mention the
human systems to be designed in case of man-machine
systems like complex ships usually are.
An aspect not made very clear in this paper is how you decide
on what the final solution should be. This method generated
even more solutions. Only when all these solutions can be
linked to one parameter like costs it is possible reduce the
design space to one preferred solution. However, this is often
not the case. This design process will result in a good insight
into the effects that requirements can have on solutions and
different types of performances. These performances are often
combined into one figure by using different weight factors for
each performance aspect to be able to decide which solution is
the best or most promising one. However, to decide on what
value each weight factor should have is still a matter of personal
choice. How do you want to support this aspect of your design
process?
Professor Kazuo Nishimoto, Visitor
Thank you very much for giving me the opportunity to make
comments and questions. I read and analyzed this very
interesting paper.
The paper shows the application of RSC methodology to
conceptual design of the non-conventional ship.
The authors considered several performance attributes for ships
during this analysis, which is divided in some main utilities.
Among these non-transport utilities is included availability,
which is a key point for the design.
68 Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
However, in the case of this kind of ship like AHTS, there are
several events in the adopted attributes that could have
probability aspects that the authors did not take into account in
their methodology. The ocean environmental conditions are
crucial for the design of AHTS and are strongly related to wave,
current and wind spectrums, which are probabilistic events.
Therefore, I would like to ask how these aspects could be
incorporated in your method.
George Rebovich, Jr., Visitor
This paper takes a comprehensive view of and approach to
systems engineering of complex systems. Others have
discussed some or all of the five aspects of complex systems
that the authors do but none, to my knowledge, have conceived
such a structured and well-thought-out approach.
I particularly applaud the epoch, era and lifecycle analysis
concepts and techniques of the MIT-developed Responsive
System Comparison (RSC) method. The problems they address
are much on the minds and lips of systems engineers and
program managers in government acquisition communities that
develop and field large-scale IT intensive complex systems.
The discussion on value robustness and its strong relationship to
the perceptual aspect, especially during the conceptual design
phase, was particularly interesting. My work suggests that for
an acquisition program (and its systems engineering) to succeed,
the strong relationship between value robustness and the
perceptual aspect must extend beyond the point where a single
design is selected and, in fact, must be a continuous process
throughout the entire system development lifecycle.
While stakeholders usually agree on the overarching goal of a
program and may even agree on a common utility metric for
design selection, they each have different interpretations of
success that align with their organizations institutional roles
and responsibilities (achievement of KPPs, interoperability with
other agency systems, O&M, policy compliance, etc.). Each
stakeholder has different forms of influence and resources (e.g.,
operational-user legitimacy, funding, or milestone decision
authority) that they continuously bring to bear throughout the
development lifecycle to move the system closer to its definition
of success, up to and including system test. But at the same
time, it is the rare case in which a development program has the
resources and schedule to satisfy all stakeholders perceptions.
Successful programs understand that they must balance and
satisfice stakeholder needs and expectations. They also
understand that it is a continuous process that depends not only
on engineering and management abilities, but also important
social skills (e.g., negotiation abilities, power of persuasion or
influence).
The big challenge and opportunity for the authors of this paper
is to get their ideas instantiated in the world of practicing
systems engineers, particularly in government acquisition
programs where they are most applicable. The conceptual ship
design example in this paper is a good start. A reasonable next
step could be to map this papers ideas more directly to a
specific government agencys formal policies, regulations and
processes for acquisition of complex systems to show how the
concepts enable and support that agencys critical milestone
decisions. That could spark sufficient interest to get a
government program to partner with you in piloting the papers
ideas, which could create a path to institutional adoption.
Ties van Bruinessen, Visitor
First of all, a compliment for a very well written paper; the
paper clarifies and applies a piece of very complex theory to the
ship design and design analysis. What is especially
commendable is the application of different perceptions over a
time-frame. As we know in complex theory, a ship is not only
part of the business-case of the client, but also part of an
environmental, social and efficiency related systems. The
approach makes it possible for the client to decide whether a
design is correct, robust and socially acceptable over a longer
time-frame, a far broader approach than commonly used.
Two comments should be made. The approach presented here
concentrates on the analysis of the design: even though a wide
range of design variables are considered, the concept of the
AHTS does not change, even though in conceptual ship design
both business, structural and behavioural concepts change
substantially. Secondly, the temporal aspect is currently
primarily applied to the transport and non-transport utilities, as
they relate to profit, even though different scenarios could result
in a different set of requirements (for example, the Green
Future). However, both are comments, because the approach
provides considerable flexibility to incorporate these aspects.
There is one aspect I would like to put up for discussion is
related to the fundamentals of the systems engineering and the
complexity aspects. Based on your research I was wondering
how this approach would apply to a lower system context; for
example, the design of a DP system or a diesel-engine. Would
the same five aspects apply, and how would they relate to the
five aspects on a ship level?
In such a broader approach, the contextual aspects of the engine
would be the structural and behavioural aspects of the DP
system, which context is formed by the ship design. The broader
application could both simplify (less terms) and complicate
(temporal and behavioural aspects influence a broader
perspective) the approach. The current paper discusses the ship-
design as a single entity even though a vessel also consists of
(to-be-designed) systems. Based on the basics of system
engineering, these aspects have considerable impact, even
though they are not considered in this paper.
Michael A. Yukish, Visitor
I appreciate this opportunity to comment on the paper, as the
concept phase of design has been a topic near and dear to my
heart for almost twenty years. The authors work moves the art
forward by bringing to light the contextual, temporal, and
perceptual aspects in concept design. Each of the aspects
certainly modifies and complicates the problem in unique ways.
My discussion consists of a request for clarification and some
general observations.
Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
Complexity Definition
In reading the paper, it wasnt entirely clear to me what entitys
complexity was being defined. The authors write:
Complexity is thus defined as the amount of relevant
information necessary to define a system, including
components, interconnections, performance, and scenarios
among other perspectives that may be requiredwhen a system
requires more information to be defined, it can be considered
more complexAlthough one could also address complexities
in the design task (process) the focus of this article is on the
product (ship).
Pulling the thread on the definition led to some confusion on my
part. There appear to be at least three key entity complexities at
play, they are the complexity of the:
Artifact itself that is being designed
The design
The design problem.
A thought experiment illustrates my confusion. Looking at a
ship designed and fielded in the 1940s, for example, the artifact
itself has a certain complexity, along with its design. The same
artifact today, without modification, would be subjected to
many more analyses and performance evaluations which would
result in a more information about it, and so a more complex
design as per the authors claim. Yet the artifact would not be
more complex, since the ship is just what it is. So the
complexity of the design of the system should not be the same
as the complexity of the system.
Considering another thought experiment, the 1940s ship was
likely designed to requirements that could have been met by any
number of solutions. Working backwards from the ship, a new
heavily constrained design problem could be created that
essentially forces a design team to recreate the ship. While the
resulting artifact for both the original design problem and the
new one would be the same, the new team would have had the
far more complex problem due solving the additional
constraints. So although the artifact and designs would have the
same complexity, the problems would not. Could the authors
clarify?
Contextual Aspect Comments
At first glance, it appears the Contextual aspect is an extension
of the Behavioral aspect, with a context/scenario consisting of a
group of lumped behaviors, so one step up the hierarchy of
behavior. However, a critical element that appears to be
introduced is operating policy, i.e., how the system is operated
to meet the requirements introduced in the Contextual aspect,
the underlying premise being that how a system is operated is as
important as what the system is. This introduces an optimization
problem within a problem, where for a particular design the
designer must now search over the policy space to find the
optimal policy for a given context, in order to present the design
in its best light. This introduces significant complexity to
problem.
Temporal Aspect Comments
An interesting relationship that is not explicitly called out by the
authors but that is pertinent to this section is the relationship
69
between design complexity and time to market. It is generally
understood that other things being equal, more complex means a
longer time to design, test, and deploy. Another relationship that
generally holds is that the accuracy of a forecast decreases the
further out the time horizon considered. So predictions of
scenarios to be used by the example vessel should be more
accurate for near term and less so for the 20-year point in its
life.
Accepting these relationships, including temporal effects, may
then put either upward or possibly downward pressure on
system complexity. The upward pressure in complexity could
stem from the desire to incorporate changeability as described
by the authors. Where the downward pressure could come about
is by attempting to get a product fielded while the requirements
it was designed for still hold, i.e., shortened time to market. In
the Department of Defense acquisition, there are more than a
few systems for which the need for it significantly changed or
even disappeared prior to its ever being fielded.
Authors Response
We are glad that Professor H. Hopman and Dr. M. A. Yukish
each raised a thoughtful critique on the concept of complexity
that we use. When we decided to include it in the paper, we
knew that any kind of definition could raise different
interpretations. As stated by Mitchell [2], this is not only a
systems engineering issue but is applicable to the whole
complex theory field.
Professor H. Hopman and Dr. M. A. Yukish provide critiques
that are primarily related to the classic product/process
distinction. While in the structural aspect it is easier to
distinguish between the product (ship) and the process
(construction), for other aspects this is not so easily delineated.
Probably the most overlapping aspect is the perceptual, where
the distinction between the product (ship) and the process that it
is placed in (operation, commodities, part of a fleet) varies
significantly for each of the stakeholders. In this sense,
Professor Hopmans criticism is valid, and a risk-assessment of
the contextual parameters, for instance, would bring more
complexity to the process, but not necessarily to the system.
This is exemplified by Dr. M. A. Yukishs case, of a 1940s ship
analyzed under modern techniques: the ship would be the same,
while the information about it would be greater (i.e. more
complex). We agree with this distinction, the design process is
thus more complex, and not necessarily the product. However,
we must add an obvious statement to show how fuzzy the
distinction between the product and process is in the conceptual
phases: if we use the current information level, the actual
(complex) design process would certainly lead to a very
different ship. In other words, it would be unlikely one would
consider the simpler 1940s solution a good one.
As for the complexity of the problem, it seems more a question
of boundaries of the problem rather than the five-aspects
taxonomy. Given the basic assumption that the design should
describe a ship able to perform its mission, the challenge seems
to be related to the types of constraints the designer is
considering during the process. In this sense, for the conceptual
70 Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
Perceptual Aspect Comments
I applaud the authors in bringing in aspects of stakeholders
preferences to the conceptual design problem, particularly the
notion that stakeholder preferences need not be fixed in time.
There has been a sense in the engineering design literature that
because design decisions such as addressed in this paper are
engineering problems, they are cleaner and can be
satisfactorily modeled with a prior preference function. But one
can argue the opposite, that because they are engineering
problems and therefore ultimately in the service of people with
all their frailties of decision making, the perceptual aspect
should be considered in full. There is a rich body of literature
from the domains of psychology, judgment & decision-making
research, marketing, and behavioral economics that is rarely
cited in the engineering design literature but that has direct
application to this work.
ship design, we corroborate with Andrews requirement
elucidation rather than requirement engineering proposition. The
strategy is to tackle the wicked problem of determining what is
wanted of a ship and what can be afforded [3] via a three stage
basis: concept exploration, concept studies and concept design.
We support Professor Hopmans suggestion for a deeper study
in the relation of human factors and its relation with the
taxonomy. It was not considered in the scope of our work, and
we agree that attention should be given to how much of the
human system is part of (and affects) each of the aspects.
The decision making problem is another point commented on by
Professor Hopman, which is not strictly related to our approach,
but probably to all proposed design methodologies. Indeed
nowadays we have, given a large design space, a suite of
approaches and metrics to intelligently select a set of good
designs that should be further investigated, such as Pareto Trace
[4], Filtered Outdegree [5] and Fuzzy Logic [6]. These methods
bring some rationale for making an informed decision.
We should keep in mind as well that the best design is not
necessarily the most profitable or with best KPIs, but the one
presenting higher value robustness, strongly connected to the
perceptual aspect. It is not wrong to assume that this aspect is
the most uncertain of all, dealing with (the human perception of)
the lack of knowledge from all other aspects. It may not be
wrong to assume that the degree of value robustness that a
system must have is strongly connected to the amount of
uncertainty that this system needs to (will) face during its
lifetime.
In this sense, we thank Professor Hagen for his discussion. It
touches the core of the question, reminding us how much
residual information exists in a real design process. As stated,
accepting the low residual (or lower uncertainty) means to spend
(or reallocate) the time and money to other points of the design
process in order to obtain value robustness, and therefore select
a worthy design. We do agree with Professor Hagen that there is
an issue in how to properly capture value robustness during the
early phases. In this sense, our suggestion to guide the decision
maker goes in line with Dr. Yukishs comments on the
perceptual aspect, about the rich body of literature from other
domains (e.g. behavioral economics, psychology, marketing)
that can be directly applied to the ship design case. As for his
other comments in the contextual and temporal aspect, the
arguments are correct as stated.
Professor Nishimotos question connects the vessel availability
with the analysis of probabilistic events. His assertion that this is
a key design point is correct, since availability (or operability) is
a current concern when designing highly-specialized offshore
supply vessels. A ship able to operate in a 99% time-window
will cost significantly more (both to design and to contract) than
a ship with just one or two percentage points lower. This
quantification is not a straightforward process, taking into
account advanced hydrodynamic simulation, for instance, when
evaluating the seakeeping of the vessel for each of the
environmental conditions. The incorporation of such analysis in
the method is strongly related to which simulation model is
available, and to how the designer will choose to discretize the
environmental conditions. In this sense, we can briefly suggest
two approaches. First, if the simulation receives as input the
environmental conditions, the epoch space could consist of each
of the possible combinations among the range of wave, wind
and current values. The tradespace evaluation would combine
the design space with each of the epochs, and designs could be
ranked by the robustness in performance as better in most
of/main environmental conditions. A second approach is to
discretize the context by the range of possible routes that the
vessel will operate, with each route linked to the environmental
conditions of a specific area. The simulation would calculate the
operability for each of the routes, and designs could be ranked
by their performance in the sum/set of routes. We believe that,
in both cases, the incorporation is connected to a high-level
problem, demanding more research in how to properly
incorporate discrete and computationally demanding simulations
in conceptual design methods.
Mr. Rebovich raises an interesting challenge for the extension
of the research, applying the ideas of the paper towards
government acquisition programs. The suggestion of mapping
Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach
the ideas in our paper to the government acquisition policies,
regulations and acquisition processes is thought-provoking. The
authors will look into this approach, and how it might yield
particular insights for the acquisition community. There are
certainly possibilities for formulating an interesting research
project along this line of inquiry.
Mr. Rebovich points out the importance of a strong relationship
between value robustness and the perceptual aspect, arguing that
it must be a continuous process throughout the development
lifecycle. We fully agree with assertion, and the compelling
reasons that Mr. Rebovich cites for doing so. The authors are
involved in ongoing research that targets this very issue.
We appreciate Mr. Rebovichs encouragement in instantiating
the ideas into practice, and hope that we will be able to
contribute further research outcomes and case examples to
achieve broad impact across the multiple communities involved
in the engineering of complex systems. Using the real-world
environment is essential to successful research outcomes that
can be transferred to practice. Our ability to make contributions
very much depends upon collaboration with government and
industry.
Mr. van Bruinessen is right in affirming that the approach
provides flexibility, which includes the application of the
methodology not only for ship, but also subsystems design, as
the DP system suggested for discussion. We are currently
finishing a research project that has similarities with the
question, regarding the application of the RSC method for
assessing air emission for the lifecycle via machinery
configuration [1]. Similar to the process presented in the current
paper, the application for the subsystem includes all the seven
steps. In this case, each design corresponds to a unique
machinery configuration and, rather than contracts, epochs are
created for each different operational profile of the ship, that is,
different load to the engines. The value driving design
formulation, for instance, requires the operational profiles of the
ship and machinery parameters as input. Many of the ship level
aspects, such as hull design, regulations, and cost, appear as
constraints, while the important attributes are the ones
connected to the machinery (e.g. fuel consumption). This is
illustrated in Figure AR-1 and an example of possible design
variables is presented in Table AR-1.
71
 Figure AR-1: Value driving design formulation flowchart for the machinery configuration evaluation subsystems level [1]

Table AR-1: Machinery Configuration Design Variables Example [1]

We chose to introduce the method presenting the ship as a single
unit, however it does not limit use of the five aspects in
considering the ship as made up of subsystems, with each
subsystem having its own design variables, and the ship as a
combination of modules. We believe that the methodology has
potential to be combined with other design methodologies, such
as the building block approach, both upstream and downstream
in the process.
Concluding, we are grateful to all of the discussants for their
thoughts, comments, and insights. We are pleased that the five-
aspects taxonomy was considered a useful approach to address
complexity during the early phases of ship design. We hope that
this work can serve as stimulus to more research towards the
questions raised by the discussants that we were not able to fully
answer, specifically related to the human system incorporated in
the methodology, the overlap of product/process during the
conceptual design phase and the impacts of non-rational
information during the early stages of design.
[2] MITCHELL, M. Complexity: A guided tour. Oxford
University Press (2009).
[3] ANDREWS, D. Marine Requirement Elucidation and the
Nature of Preliminary Ship Design, Trans. RINA, Vol 153,
Part A1, 2011
[4] ROSS, A.M., Rhodes, D.H., and Hastings, D.E., Using
Pareto Trace to Determine System Passive Value
Robustness, 3rd Annual IEEE Systems Conference,
Vancouver, Canada, March 2009
[5] VISCITO, L., Chattopadhyay, D., and Ross, A.M.,
Combining Pareto Trace with Filtered Outdegree for
Identifying Valuably Flexible Systems, 7th Conference on
Systems Engineering Research, Loughborough University,
UK, April 2009
[6] GRAY, A. W., Daniels, A. S and Singer, D. J. Impacts of
Fuzzy Logic Modeling for Constraints Optimization, Naval
Engineers Journal, 2010

ADDITIONAL REFERENCES
[1] GASPAR, H. M., Balland, O., Aspen, D. M., Ross, A. M. and
Erikstad, S. O., Assessing air emission for uncertain
lifecycle scenarios via responsive systems comparison
method (unpublished) in Gaspar, H. M - Handling Aspects
of Complexity in Conceptual Ship Design, NTNU, PhD
Thesis, 2013.

72 Addressing Complexity Aspects in Conceptual Ship Design: A Systems Engineering Approach