3D Printing – Ship Modularisation Pilot Project

by Sthéfano Lande Andrade and Thiago Gabriel Monteiro – MSc Students in Ship Design
(sthefano.lande@gmail.com, thiagogabrielm@gmail.com)
Ícaro Aragão Fonseca and Olivia Silveira Chaves – Exchange Students in Ship Design
(icaro.fonseca@ufpe.br, oliviachaves@poli.ufrj.br)
Henrique M. Gaspar – Associate Professor – Ålesund University College – Ulstein Professorship
(hega @ hials.no)

Høgskolen i Ålesund, v1, Feb 2015.

Part of EMIS Project, in cooperation with Ulstein Group, Norway

[toc]

Objectives

Our main objective is to apply modularisation techniques on the virtual prototype of ships.We have been working in different segments of an OSV modular conceptual design, and now we intend to bring it all together into a virtual and physical prototype. This consists in a modular design, 3D designing and visualisation, and data management. The final result will be a logical modular thinking, a library of modules (of a Platform Supply Vessel – PSV), the 3D virtual assembly and the 3D printing of the modules.

Regarding modularity, our intention is to exemplify the flexibility provided by a modular design, which is about being able to build many different vessels using the same set of modules. Therefore, we should be able to build a significant number of vessel variations by replacing, adding or removing modules to an assembly, each one with its own characteristics.

In order to bring the modular concept to life, we used the Siemens NX modelling package to design the modules. In this phase, the modules should take shape and be source for 3D printing and an additional 3D virtual visualisation tool. The tool consists in a Graphical User Interface (GUI) that allows the user to assemble virtually all the arrangements that can be possible made from our initial set of modules.

Finally, we also propose an instrument to support the information handling that is an object-oriented script collecting all relevant data about the ship and its modules.

Platform Supply Vessel

A platform supply vessel (PSV) is a ship designed mainly to transport cargo to/from shore to oilrigs and other supply operations. Those ships usually transport cargo related to the drilling activity such as drilling mud, pulverized cement, water and chemicals, but they may also carry equipment and spare parts for the rig, besides food and supplies for the crew. When returning to shore, PSV’s often transport chemical residuals for recycling or disposal.

The variety of its tasks and circumstances of operation require a big flexibility from PSV’s. Their large open decks are provided with cranes, pumps and other equipment for cargo handling activity. Dynamic positioning system and a full-view command bridge are usually required for precise manoeuvring control during operations. Different PSV’s may exhibit different characteristics depending on the specificities of their activities. For instance, for a bigger rig, a larger cargo hold may be necessary, while the bow shape may vary according to the typical sea state of the offshore field, for example.

This variety of design configurations and required operation flexibility make this kind of ship a potentially good target for our simplified modular approach, as we expect to demonstrate in the next sections.

Modular division

We conceived our prototype as a composition of seven modules that are classified in three types: Changeable, optional and standard. The changeable modules can be replaced for another one with the same function but different characteristics, the optional modules can be freely added or removed, and finally the standard modules have only one configuration and they are not optional. The modules are hypothetical, not connected to a real vessel:

Modules’ description

 

[table id=1 /]

Modular approach

1. Bow: the bow configurations can be chosen between two shapes: Conventional bow and X-bow. Each bow grants specifics hydrodynamic properties to the vessel, and most suitable bow may vary depending on the typical sea state.
2. Accommodation: this module has one single format that is layer-based, which allows the user to choose the accommodation capacity by adding or removing layers/modules from the model.
3. Bridge: this module is the same for all designs. The superstructure was split in accommodation and bridge so that we can change the accommodation capacity by adding layers.
4. Crane: this crane is optional and can be used for cargo handling or other deck operations.
5. Winch: this winch is also optional and can be used for cargo or other operations.
6. Cargo tank: it has only one configuration as the accommodation module, but we can join two or more identical modules to provide additional cargo space if necessary.
7. Propulsion: this model allows the user to choose between conventional shaft and azimuth propeller.

Object structure – Vessel Data Management

The JavaScript object stores some essential information about the model, including costs, main dimensions and other relevant characteristics. A schematic structure is shown below, where the balloons represent the objects and the frames list properties and data types. The Ship object includes some methods that calculate values according to the user choice for each module, e.g. the ship cost is the sum of the costs of all modules, as would be expected.

When it comes to the data representation of the model, we made some adaptations in order to simplify the code. The bridge and the accommodation modules were joined in one single “Superstructure” module, that includes both the required bridge module and the additional accommodation decks, if any.

Module library

The 3D modules were modelled using Siemens NX. For more information about the modelling procedures, please refer to our previous reports here. Below we present each one of the modules used in the assemblies.

 

Module kit

These modules were organised in two kits containing the modules in a way that is possible to assembly two different ships at the same time. Clicking on the figure you can check their 3D versions.

 

 

 

And these are some of the assemblies that can be produced from them:

GUI (Graphical User Interface)

We also developed an online tool where it is possible virtually generate the model. It works generating a 3D visualisation of the assembly composition chosen by the user. First, the user should choose one configuration for each one of the changeable modules, and whether he/she wants to include the optional modules or not. This is made clicking on the button, which turn blue when selected. After that, the assemble button should be pressed and the chosen arrangement will be displayed.

(Click on the image to be redirected to the GUI)

 

3D Printing

A 3D print version was ordered from i.materialise and made of polyamide, standard plastic for this kind of printing.

The final 3D print result is observed as follows:

Conclusions

With this project, we can see that even a small application with a limited number of modules may generate a good number of options with a significant amount of related information (3D models, module’s specifications). It seems probable that for more elaborate models, the quantity of data would start to overload our capacity to process and store it. Some tools we used, such as the JavaScript data structures, may help to deal with those setbacks, but they are still not enough to completely suppress them.

This scenario points to necessity of allying those modular approaches with any kind of functionalities that can reduce: the workload involved in designing each module (e.g. parametric design) or even the necessity of designing the modules themselves (e.g. decision-making in early conceptual design).