Data-Driven Documents (D3) applied to Conceptual Ship Design Knowledge

v0.1, Apr. 2014
Based on the paper published at COMPIT, 2014, Newcastle, UK
by Henrique M. Gaspar¹², Per Olaf Brett², Ali Ebrahim², Andre Keane².
1 – Aalesund University College, Faculty of Maritime Technology and Operations
2 – Ulstein International AS.

Abstract

This work focuses on data-driven documents (D3) examples applied to the conceptual ship design process, especially in how to effectively and quickly filter and present complex input, multilevel and multiclient interactions, associating into design knowledge. The traditional ship breakdown structure, with cost and subsystems elements, is encapsulated via analogous representations, such as tree layout, force layout, pack layout, sunburst layout, and Sankey diagrams. Large dependency matrixes are represented via interactive chord diagrams (dependency wheel and hierarchical edge bundling). A parametric design web application is used as example, to tie in a single structure knowledge representation. An overall discussion is presented, focusing on how this approach improves the expressiveness of data and interactions in an industrial ship design context, allowing the designer to better interact with a conceptual ship design dataset, as well as facilitating the presentation of the expectations of stakeholders involved.

Introduction

1. Knowledge in Conceptual Ship Design

A good functional design description requires gathering conceptual ship design knowledge, that is, an efficient exploration of existing and related information. Even as the freedom to change the primary variables of the design decreases as a design progresses through phases, the engineer's knowledge of the problem and how the design could be adapted to the situation increases, Erikstad (1996), Brett (2012). In other words, as one goes to a more detailed part of the process, the decisions narrow toward a certain set of solutions. Ontologically, to make a decision means giving up other options, thus decreasing the freedom to modify the design parameters in future stages of the process. The idea of conflict between design knowledge and freedom to change is presented in Fig.1a.

The objective of every design method during the conceptual phase is thus to create knowledge as early as possible, without compromising much of the freedom, as observed in the lighter line from Fig.1a. In other words, a designer would like to have as much flexibility as possible to improve vessel parameters while acquiring fast knowledge about her decisions, hopefully decreasing risk and uncertainty, PMBOK (2008).

a

b

---

Fig.1: Trade-off between freedom to change a design and the knowledge acquired during the process (a) and basic design process (b); based on Erikstad (1996)

In addition, designers must seek elucidation of the requirements proposed by Andrews (2003,2011). The author contrasts fixed and straightforward approaches to a pre-established list of requirements, that is, purely systematic requirement engineering, with collaborative elucidation of the requirements from the ship owners, cargo owners, operators, and designers. This multi-stakeholder dialogue in the early stages is an essential technique to verify and mature a reason to construct the ship, methods, and tools, and to select which conceptual solutions should be used. Andrews' (2011) analysis also elucidates the sequential and iterative process of the design as a recurrent theme, captured by Erikstad as four steps: generate, analyse, evaluate, and decide, Fig.2b. This concept exploration model relies on the nature of the search space: rather than a single ship generative model (i.e. design spiral method), a whole set of designs is explored. Recent methodologies, which explore this approach to ship design, are exemplified by the set based design method, Singer et al. (2009), and epoch-era analysis/ responsive systems comparison, Gaspar et al. (2011), Gaspar et al. (2012).

Erikstad (2007) discusses acquisition of syntactic and interpretative knowledge, and suggests five common knowledge element groups in the conceptual ship design domain: previous design cases and existing vessel data, generalized design cases and templates, syntactic knowledge (vocabulary), rules and facts, and solution methods, strategies, and tactics. As part of addressing each element group, designers must consider data, methods, regulations, and economic factors of the environmental measures. In this context, the current literature reinforces the important role of acquiring correct data from the operational profile. Levander (2006) affirms that the starting point for ship design is to define its mission and related functions well. The design should focus on a ship that performs its mission according to the plan.

We corroborated Erikstad's idea that knowledge is the most important actor in the design process. Knowledge, in a wider definition, may be viewed as the relevant information acquired from filtering and interpreting the available data, Aamodt (1991). This data, as noted by Ulstein and Brett (2012), is strongly connected to a critical systems thinking for the ship design process. The authors state that the desires of stakeholders in the design, their general level of accord, and the information they possess and expect to possess influence decision-making in a new shipbuilding development, noting that poor decisions in the early stages create more conflicts and problems later. Brett et al. (2006) suggests a modular procedural structure, and the use of both a communicational and a decision-making support tool among all the actors in the total decision-making process of a transport system at, named Ulstein Accelerated Business Development Process (ABD).

We corroborated Erikstad's idea that knowledge is the most important actor in the design process. Knowledge, in an wider definition, may be viewed as the relevant information acquired from filtering and interpreting the available data (Aamodt, 1993). And undoubtely a large amount of data is created during this early stages, data connected to generating and analysizing the large space of possible options.

With this context in mind, the rest of this work we will discuss how using D3 may assist the designer to extract knowledge from the data already available when describing and evaluating a design by means of a holistic procedure such as ABD. Rather than analysing the extensive (and too large) dimensions that knowledge in ship design can have, the paper will focus on aspects which are usually not represented in interactive/parametric graphical forms. In other words, we present here an exercise to investigate how D3 can create knowledge by visualizing available data which are usually computed (and perhaps forgotten) among a many others numbers, and, as stated by Hamming (1962), the purpose of computing is insight, not numbers.

2. Visual Representation of Knowledge

Most current engineering quantitative analyses are presented via a combination of numbers and graphs (for instance a bar, pie, scatter, and line charts). This is a standard approach, and consensus states that data graphs communicate more than tables, Few (2009). At their best, graphics are instruments for reasoning, by looking at pictures of the data and its relationships.

A classical example is the data sets compiled by Anscombe (1973) in Fig.2, presenting a dataset where statistical analysis did not differentiate among but graphic representation makes their discrepancies clear. This example demonstrates that even the most skilled designer must use visual information to fully grasp knowledge from the data, Tufte (2001).

Therefore, the immense amount of data handled during the design process, Fig.1b, can quickly become unmanageable and incoherent. As new simulations tools and technologies are constantly being developed, there is also a dire need for new types of visualizations capable of capturing the importance of each key aspect, coupled with the ability of providing structured representations. Having such capabilities would directly benefit the designer by giving her the ability to include and incorporate information from the decision makers at the earliest possible stage, making the whole process more efficient, and subsequently increasing stakeholder value.

Anscombe's quartet I II III IV x y x y x y x y 10.0 8.04 10.0 9.14 10.0 7.46 8.0 6.58 8.0 6.95 8.0 8.14 8.0 6.77 8.0 5.76 13.0 7.58 13.0 8.74 13.0 12.74 8.0 7.71 9.0 8.81 9.0 8.77 9.0 7.11 8.0 8.84 11.0 8.33 11.0 9.26 11.0 7.81 8.0 8.47 14.0 9.96 14.0 8.10 14.0 8.84 8.0 7.04 6.0 7.24 6.0 6.13 6.0 6.08 8.0 5.25 4.0 4.26 4.0 3.10 4.0 5.39 19.0 12.50 12.0 10.84 12.0 9.13 12.0 8.15 8.0 5.56 7.0 4.82 7.0 7.26 7.0 6.42 8.0 7.91 5.0 5.68 5.0 4.74 5.0 5.73 8.0 6.89

---

Fig.2: Anscombe's (1973) data sets, with a data representation via table (left) and graphically (right)

Our impression is that the current industrial approach during early stages of ship design relies heavily on information concentrated, condensed, and processed via spreadsheet-like programs/outline specs dictate by the shipowner. Even more complex analyses, such as hydrodynamic and structural, are quickly transformed into a number in a cell, usually evaluated in relation to a list of internal and external criteria. Not surprisingly, this spreadsheet data is transformed into a large set of charts, which will feed the innumerous reports and presentations created during this process, Fig.3.

• Data saved (and not easily accessible) in Excel

---

Fig.3: Core of design data concentrated in spreadsheets, presentations, and reports

Although essential, this process may be hiding other types of relevant information, which can be difficult to access due to the constraint of this MS Excel-Powerpoint-Word format. As criticized by Tufte (2006), many data visualizations are created to persuade rather than inform, with ideas disconnected from the context and squashed into unhelpfully simplistic tables, charts, and bullet points. How can a single stakeholder such as the shipowner, interact with the requirements and the extensive simulation data created for satisfying it, if usually results are presented to them as a picture set, within a folder containing a main .doc report with its many .ppt and .xls sources obscured?

Moreover, spreadsheet users know how complicated it can be to understand, adapt, and use a spreadsheet created by others, which worsens if packed with simulation results. The fact that data is stored and handled in a row versus column format may also constrain how this data is presented and understood. The current selection of charts is, even if extensive, yet unable to represent some funda-men¬tal hierarchical elements found during design. Consequentially, this essential information is usually transformed into a static picture, created via the drawing application available in the software suite (for instance MS Visio or MS PowerPoint).

Our proposition is not that the spreadsheet-presentation-report procedure should be avoided, but rather that it should be extended into a more interactive and multi-stakeholder simulation opportunity environment. We believe that solely focusing on this procedure constrains the perception of relevant design information, and that a more web-based collective environment would contribute to the ship design process by:

• Handling parametric data outside the row versus column format, allowing hierarchic presentation of the structural, temporal, and economic aspects of design.
• Handling data in an open/readable format, keeping integration with proprietary/protected databases/spreadsheets.
• Progress beyond the passive share of performance evaluation, allowing an effective design understanding and interaction with the knowledge behind the data.
• Presenting a new type of graph, visualizing parametrically aspects previously handled as static figures. Past plotting was an issue, but D3 eases the process, and data is still easily available.

Currently there are diverse commercial software programs available that promise more efficient information handling, such as Qlikview, Tableau, and Spotfire, and research on how these tools can be applied to the ship design case must be studied. In this paper, we propose a more code-oriented approach, using the web browser directly as a graphic user interface, via the recent D3.js JavaScript library, which requires no special installation/configuration in any modern computer able to access a web page, and works even with mobile devices such as smartphones and tablets.

3. Data Driven Documents (D3)

3.1 Introduction

D3 is a novel and efficient way to handle, visualize, and interact with a large amount of information. It consists of a JavaScript library developed initially by the Stanford Visualization Group and today mainly developed by Michael Bostock under the BSD license, Bostock (2014). Bostock et al. (2011) states that D3 uses the full capabilities of modern browsers without the constraints of a proprietary framework, combining powerful visualization components and a data-driven approach to objects manipulation. The library uses digital data to create and control dynamic and interactive charts, running in most common web browsers, enabling:

• A representation-transparent approach to visualization for the web.
• Direct inspection and manipulation of text-like data.
• Bind input data to HTML document elements
• Efficiency in quickly rendering and animating charts

While D3 is normally developed and used for web applications, its application can be extended to any kind of dataset that contains a hierarchized type of information, such as in ship design. Utilizing D3 during conceptual design not only allows the user to interact with different visualisations, creating an increased understanding of different variables correlations with each other, but also provides a simple and aesthetically pleasant interface, making it substantially easier to separate important aspects from superficial ones. Ware (2012) states that visual displays provide the highest bandwidth channel from the computer to the human (...) we acquire more information through vision than through all of the other senses combined. This, combined with the sheer amount of information that can be rapidly interpreted through various forms of visualisation, serves as an undeniable potential source of value that has yet to be fully explored.

The examples discussed in the rest of this paper are largely based on the extensive set of examples available online, mainly from D3.js, Bostock (2014), Dimple interface, Kiernander et al. (2014), and DependencyWheel interface, Zaninnoto (2014).

3.2 Basic Features

The fundamentals of D3 are introduced by Bostock et al. (2011) and Bostock (2014). In summary, it works as an interpreter to select, modify, and transform plain data into web visual elements (scalable vector graphs). Moreover, a collection of application programming interfaces (APIs) is available to facilitate the process of creating regular graphs, such as bar, scatter, line, and area charts, Kiernander et al. (2014). Fig.4 presents a simple XY regression (a) and a multiple bar chart (b) created with D3.

a) Simple XY scatter with regression

b) Simple Bar Chart (D3 + dimple)

D3 advantages relate to a high level of customization and user interactivity. Mouse actions, for instance, can be customized for each element of the graph. Fig.4a shows a scatter plot with regression equation, which presents the coordinates when the mouse is over a point, pretty much as in modern spreadsheets’ charts. Fig.4b shows a multiple bar chart, where the mouse over action generates a pop-out box containing design information about the data connected to each bar.

Fig.5 presents a more advanced design-space plot, containing Utility A versus Utility B of four design sets plotted together. One more dimension is added, since the cost is proportional to the size of the circle. In Fig.5a we are able to analyse all design sets, and a click on the mouse filters the data into a single set.

Scatter / Bubble Chart

It is essential to refine and make better the understanding of the design set during the early stages by documenting the design and preparing a comprehensive scope of work containing product specifi-cation, required standards, regulations, mission requirement, and client expectations. Although D3 can be used to produce spreadsheet-like charts, the real gain in knowledge is observed when we go beyond these functionalities, using this library to handle data that heretofore was considered static. More powerful visual techniques in early stages will enhance the possibility of producing a better grasp of design space, product mission, and performance objectives in a collaborative space, rather than just traditional visualization methods.

In Section 4 we introduce visualisation examples that lie beyond this spreadsheet-like approach, focusing on structural, mapping, temporal, and economic aspects of concept ship design.

4. Extracting Ship Design Knowledge - Examples of Visualizations

4.1 Structural Examples

The structural aspect relates to arrangement and interrelationships of the physical parts in the ship. The structure/behavior pair derives from form-function mapping, aggregating information covered extensively in traditional model-based techniques. The structure is decomposed and encapsulated in subsystems and components, Gaspar et al. (2012). Current design methods, such as Levander (2006), decompose the design into ship and task related subsystems, presenting a functional breakdown of the system into semi-independent parts. A more modular approach, for example, is presented by Andrews and Pawling (2009), with building block as a design method, connecting this decomposition into the simulation of modular chunks performance.

For the sake of illustration, let’s consider Erikstad and Levander’s (2012) decomposition for offshore support vessels (OSVs) presented in Fig.6. This type of information is usually visualized statically, with limited interaction and investigation of all the sub-levels that this breakdown can have. Translating this data into an object oriented-data, with each subsystem connected to a parent – as well as any other type of value or property – we obtain the type of object found in Table I. Table I data can be bound to a variety of D3 visualizations, exemplified in Fig.7 (tree layout), Fig.8 (sunburst layout), Fig.9 (pack layout), and Fig.10 (force layout). These visualisations are highly interactive, allowing the user to understanding and explore the many underlined properties of each subsystem, such as value in the form of a “bubble size,” and its connection with other elements. Data can also be connected to an external library, such as 3D software and classes with ship’s modules, blocks, and parts.

 var Data_OSV_Systems = [
{ "name" : "OSV Systems", "parent":"null},
{ "name" : "Cargo Spaces", "parent":"Task Related Systems"},
{ "name" : "Dry cargo decks", "parent":"Cargo Spaces"},
{ "name" : "Liquid and dry cargo bulk", "parent":"Cargo Spaces"},
{ "name" : "Cargo handling equipment", "parent":"Cargo Spaces"},
{ "name" : "Anchor Handling and Towing", "parent":"Task Related Systems"},
{ "name" : "Winches and reels", "parent":"Anchor Handling and Towing},
{ "name" : "Rope and chain storage", "parent":"Anchor Handling and Towing"},
{ "name" : "Handling equipment", "parent":"Anchor Handling and Towing"},
{ "name" : "Offshore Construction", "parent":"Task Related Systems"},
{ "name" : "Lifting equipment", "parent":"Offshore Construction"},
{ "name" : "Construction equipment", "parent":"Offshore Construction"},
{ "name" : "Diving equipment", "parent":"Offshore Construction"},
{ "name" : "Spaces in accommodation", "parent":"Offshore Construction"},
{ "name" : "Ship Structure", "parent":"Ship Systems"},
{ "name" : "Hull", "parent":"Ship Structure"},
{ "name" : "Forecastle", "parent":"Ship Structure"},
{ "name" : "Deckhouse", "parent":"Ship Structure"},
{ "name" : "Ship Outfitting", "parent":"Ship Systems"},
{ "name" : "Offshore operation support", "parent":"Ship Outfitting"},
{ "name" : "Ship equipment", "parent":"Ship Outfitting"},
{ "name" : "Rescue and fire fighting", "parent":"Ship Outfitting"},
{ "name" : "Accommodation", "parent":"Ship Systems"},
{ "name" : "Crew and client spaces", "parent":"Accommodation"},
{ "name" : "Service spaces", "parent":"Accommodation"},
{ "name" : "Technical spaces in accom.", "parent":"Accommodation"},
{ "name" : "Machinery", "parent":"Ship Systems"},
{ "name" : "Machinery main components", "parent":"Machinery"},
{ "name" : "Machinery systems", "parent":"Machinery"},
{ "name" : "Ship systems", "parent":"Machinery"},
{ "name" : "Tanks and Voids", "parent":"Ship Systems"},
{ "name" : "Fuel and lube oil", "parent":"Tanks and Voids"},
{ "name" : "Water and sewage", "parent":"Tanks and Voids"},
{ "name" : "Ballast and void", "parent":"Tanks and Voids"},
{ "name" : "Ship Systems", "parent":"OSV Systems"},
{ "name" : "Task Related Systems", "parent":"OSV Systems"}
];

Classic tree diagram

Sunburst layout

Pack layout

Force layout

4.2 Temporal Examples

Representation of temporal knowledge is determined by the way in which time is specified and measured. Similarly, in conceptual ship design, the temporal aspect pertains to the dimensions and properties of a system over time, including potential contextual shifts and uncertainties. To take these traits into consideration during early stages has been extensively peripheral to systems engineering practice, but is particularly important because of the need for anticipatory analysis, which enables the identification of concept designs that perform well across multiple contexts, and inherently create higher value and utility margins for stakeholders.

In order to fully understand the benefits of mitigating uncertainty inherent in temporal analysis, the input scope must also be presented. As an input variable and a significant contributor of complexity, the contextual aspect consists of external entities, interfaces, and other factors defining the systems behavior. This should be taken into account during early phase design because the vast amount of changing characteristics could serve as substantial hinders of future profitability if not dealt with accordingly. By defining scenarios subject to these types of constraints, a set of alternate futures can be modelled and visualized, ultimately giving the designer a better foundation on which to base governing decisions.

To properly handle these contextual and temporal aspects, a similar structure explained in Section 4.1 can be applied to temporal data. This structure calls for first organizing the design set in terms of its properties, Fig.11a, and later analyzing and envisaging each of the designs analyzed for each of the scenarios, Fig.11b. Besides tree layout, sunburst, pack, and force layouts can be similarly applied to represent similar temporal data.

a) Design Set

b) Scenario Set

4.3 Design Factors Relationship Mapping Examples

Design factors relationship mapping is a structured process for creating the correct understanding of (and feel for) the final product in preliminary design stages. Design mapping methods are particularly useful for: Making informed design decisions, identifying areas of opportunity for developing new products, analyzing a competitive landscape, and analyzing complex, changing, and ambiguous design problems.

Relationship mapping techniques have a significant role in demonstrating vessel required mission and objectives, as well as consequences of different design scenarios on final product performance, with its correlation among different design parameters, decision making techniques, and market based design solutions. A useful mapping visualization will make a better understanding of the product and an earlier agreement among stakeholders, leading to a more reliable design and, consequentially, lower changes in further product lifecycle phases.

Fig.12a presents a typical three-leveled design mapping, connecting value with performance attrib-utes, and performance with design characteristics (adapted from Erikstad (2014)). Such a relationship can also be transformed into an object-like data, allowing the interactive visualization from Fig.12b.

Value - Performance - Design Mapping

Another advantage of this approach is the plot of dependencies between two or more factors. For the sake of exemplification, let’s say that we are able to connect three missions of an OSV (anchor handling, supply, and towing) into each vessel capability. This data is exemplified in Table II. Fig.13 introduces how a chord diagram can effectively contribute to the clarification of such complex data, with a dependency wheel able to efficiently present, Fig.13a, and filter, Fig.13b, the mission-capabilities relationships.

Chord diagram

4.4 Economic Examples

Economic aspects are strongly connected to the physical parts of the system. Considering the data exemplified in Table I, we can assume that each subsystem of the vessel will have a certain material cost, which can be added as a property of that object, for instance “cost: value”.

Therefore, we are also able to create the same range of examples provided in Section 4.1. Fig.14 presents an interactive version of the sunburst, which represents in one chart the total material cost of a vessel, Fig.14, while neatly identifying the cost of each subsystem with a mouse-over action.

Sequence Sunburst

If we consider another economic property linked to each subsystem, such as the man-hours used in that subsystem during the vessel construction, we may create a relationship between the material and man-hours cost. This diagram is statically represented by Levander (2006) in Fig.15a, which can be dynamically transformed (and updated) via a Sankey diagram using D3, observed in Fig.15b.

5. Simple Parametric Model in HTML and JavaScript

The objective of the parametric design procedure is to establish a consistent parametric description of the vessel in the early stages of design, starting from the basic design principle that a certain description of a vessel should be able to perform efficiently a given mission. The scope of the project is to present an entire but simplified iteration of the parametric design process applied to OSVs, starting from the mission parameters until the final design characteristics and attributes. This project is supported by Ulstein Group (... click to access the example)

6. Discussion and Concluding Remarks

In this paper we have demonstrated some of the early phase design visualizations and interactions by use of the D3.js library. The focus has largely been structural components, economic aspects, and especially hierarchical breakdowns. Even so, we have barely breached the limitations of today’s current static practice. Data-drive documentation is by no means limited to the representation of a vessel’s physical traits, but can also be used to visualize meteorological conditions such as ice density, wave height, temperature, and other vital pieces of information such as the boundaries of certain regulations when conceptualizing high level requirements into lower level capabilities.

The approach’s advantages can be summarized as the ability to efficiently store and present non-trivial data, such as hierarchical information, in an easy to share setting. Its high level of customization, although requiring JavaScript coding, allows intensive multi-platform interactivity, as well as association with proprietary simulations tools and design databases.

Moreover, the visualization of exorbitant amounts of information, whether obtained via experience or simulation database, is not just relevant in order to increase our limited ability to gain value through cognitively processing raw data, but also to uncover the value decreasing aspects. The identification of a parametric outlier could potentially increase the final product’s performance just as much as any recognised positive contributor, and may even be even harder to identify amongst the plethora of non-prominent attributes.

It is our belief that using data-driven documentation on a web based dynamic environment, during early ship design stages, will enhance the possibility of improving the design understanding, operational profiles, and performance objectives. This extension of the spreadsheet-like approach aligns with a more holistic design approach, such as in ABD, allowing an interactive empiric and simulation data exploration multi-stakeholder environment.

There is however a known challenge associated with state of the art technological developments regarding the end user’s process of adaptation – a critical step towards qualification and acceptance. In general, demanding processes such as ship design will stick to proven solutions because the risk associated with trials of new solutions is simply too high. Getting key users to adopt these alternative methods is of the utmost importance in order to gain vital feedback so that the proposed solutions continually can be improved upon, and subsequently enable designers to save both time and money by eliminating faults and illuminating possibilities much earlier than previous practices.

References and Disclaimer

The models presented here are based on the examples made available online by Bostock (2014), Kiernander et al. (2014) and Zaninnoto (2014), and their uses and rights are stated by each specific library/API license.

References

AAMODT, A. (1991), A knowledge-intensive, integrated approach to problem solving and sustained learning, PhD Thesis, NTNU

ANDREWS, D.J. (2003), Marine design: requirement elucidation rather than requirement engineer-ing, 8th Int. Maritime Design Conf., Athens

ANDREWS, D.J. (2011), Marine requirements elucidation and the nature of preliminary ship design. Trans. RINA 153 pp.23-39

ANDREWS, D.J.; PAWLING, R., (2009), The impact of simulation on preliminary ship design, 10th Int. Marine Design Conf., Trondheim

ANSCOMBE, F.J. (1973). Graphs in statistical analysis, American Statistician 27/1, pp.17–21

BOSTOCK, M.; OGIEVETSKY, V.; HEER, J. (2011), D3: Data-Driven Documents, IEEE Trans. Visualization and Computer Graphics

BOSTOCK, M. (2014); D3: Data-Driven Documents, http://d3js.org/

BRETT, P.O. (2012), Industry insights – Accelerated business development - The Challenge, BI - Norwegian School of Management

ERIKSTAD S. O. (2014), Design mapping: Value attributes, performance attributes and design characteristics, UNPUBLISHED.

BRETT, P.O.; BOULOUGOURIS, E.; HORGEN, R.; KONOVESSIS, D.; OESTVIK, I.; MERMI-RIS, G.; PAPANIKOLAOU, A.; VASSALOS, D.A. (2006), Methodology for the logistics-based ship design, 9th Int. Marine Design Conf., Ann Arbor

ERIKSTAD, S.O. (1996), A decision support model for preliminary ship design, PhD Thesis, NTNU

ERIKSTAD, S.O. (2007), Efficient exploitation of existing corporate knowledge in conceptual ship design, Ship Technology Research 54

ERIKSTAD, S.O.; LEVANDER, K. (2012), System based design of offshore support vessels, 11th Int. Maritime Design Conf., Glasgow

FEW, S. (2009), Now you see it: Simple visualization techniques for quantitative analysis, Analytics Press

GASPAR, H.M.; ROSS, A.M.; ERIKSTAD, S.O. (2011), Handling temporal complexity in the design of non-transport ships using epoch-era analysis, Trans. RINA 154, Part A3, Int. J. Mar. Eng.

GASPAR, H.M.; ROSS, A.M.; RHODES, D.H.; ERIKSTAD, S.O. (2012), Addressing complexity aspects in conceptual ship design - A systems engineering approach, Trans. SNAME 120

HAMMING, R. (1962), Numerical methods for scientists and engineers, McGraw-Hill

KIERNANDER, J. et al. (2014), Dimple - An object-oriented API for business analytics powered by d3, http://dimplejs.org/

LEVANDER, K. (2006), System based ship design, NTNU

PARSONS, M.G. (2004), Parametric design, Ship Design and Construction Vol. 1, SNAME

PMBOK (2008), A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute

SINGER, D.J.; DOERRY, N.; BUCKLEY, M.E. (2009), What is set-based design? Naval Eng. J. 121/4, pp.31-43

TUFTE, E.R. (2001), The visual display of quantitative information, Graphics Press

TUFTE, E.R. (2006), Beautiful evidence, Graphics Press

ULSTEIN, T.; BRETT, P.O. (2012), Critical systems thinking in ship design approaches. 11th Int. Maritime Design Conf., Glasgow

WARE, C. (2012) Visual thinking for design, Morgan Kaufmann Series in Interactive Technologies

ZANINOTTO, F. (2014), DependencyWheel: An interactive visualization of package dependencies, http://redotheweb.com/DependencyWheel/