Integration of Tools for Application Case Studies

Abstract

This chapter elaborates the bottom-up approach taken within the European R&D project HOLISHIP to flexibly integrate and utilize software tools and systems of tools for the design, analysis and optimization of maritime assets. The focus of the project HOLISHIP and its bottom-up integration platform(s) was the design of maritime assets at the early design phases in heterogeneous environments. As it is often the situation, tools and systems come from different developers, companies and research institutes. So far they have been mostly used as stand-alone applications with the design team being responsible for proper tool execution, data exchange and management. Within HOLISHIP the tools and systems were coupled to CAESES^®, i.e., a cross-platform Process Integration and Design Optimization (PIDO) environment that also provides comprehensive Computer Aided Design (CAD) functionality for the parametric modelling of shapes. Any tool or system that can be run in batch-mode can be coupled to CAESES and can be set up in order to exchange data with other tools, supporting the assembly of sophisticated synthesis models. Further developments as were needed for the application cases (AC) of the HOLISHIP project will be presented, complementing the discussion given in Harries and Abt (A holistic approach to ship design, Vol. 1: optimisation of ship design and operation for life cycle. SPRINGER Publishers, 2019).

2.1 Introduction

The bottom-up approach taken within the European R&D project HOLISHIP to flexibly integrate and utilize systems for the design, analysis and optimization of maritime assets, primarily of ships, is discussed and shown by means of selected application cases. Details of these application cases are given in dedicated chapters of this book while the idea of how to integrate tools and systems and, furthermore, how to collaborate between systems, even though they stem from different (and sometimes competing) sources, are discussed here and in (Harries and Abt 2019). The two chapters, i.e., this one and (Harries and Abt 2019), should be understood as complementing material with a slight overlap to still allow for independent reading.

Implementing the HOLISHIP approach by use of the CAESES^® design platform (Harries and Abt 2019) some general requirements for the set-up of an efficient ship design process and CAE procedure need to be considered:

• Explicitly state objectives, constraints and free variables and have an agreement on them between the various stakeholders,

• Generate large sets of variants by parametric models from which cause-and-effect relationships can be better understood,

• Identify most influential variables and detect governing constraints,

• Ease the burden of repeated (and error-prone) data transfer,

• Ensure that the right data are exchanged between tools (to be handled by the tool experts for quality control) and that the tools are run consistently for all variants (quality enhancement),

• Prepare decision making by formulating quantifiable objectives and decide on favourable and best designs for multiple objectives in a rational way.

For the platform(s) of HOLISHIP, a key characteristic is flexibility, i.e., the flexibility of incorporating additional tools as needed, of extending and/or changing tools as designs (and demands) are progressing and, furthermore, of managing evolving and growing sets of data.¹

2.2 Approach to Application Case Studies

The main application cases (AC) that utilized CAESES^® as HOLISHIP design platform were.

• 1. Offshore supply vessel (OSV) [responsible partner: Kongsberg]

• 2. Multi-purpose Ocean Vessel (MPOV) [responsible partner: The Naval Group]

• 3. Structural design of a superstructure with composite materials [responsible partner: Meyer Werft]

• 4. Retrofitting of Merchant Ships, including Machinery Outfitting [responsible partners: NTUA and DNV GL]

• 5. Offshore platform [responsible partner: Elomatic]

• 6. RoPAX ferry [responsible partner: Tritec]

• 7. Double-ended ferry [responsible partner: Elomatic]

These application cases are elaborated in respective chapters of the present book.

The synthesis models for four of the above ACs are given in Figs. 2.1, 2.2, 2.3 and 2.4. Table 2.1 presents an overview of tools involved. The diversity of the synthesis models is obvious and corresponds to the situation encountered “on the ground” in which (i) different design environments with diverse tool sets, (ii) different design phases, and (iii) different levels of detail have to be accommodated. Not only can it be seen that many tools had to be connected but that not one synthesis model would fit all purposes. Details of several of these AC are given in Harries et al. (2019) and in Papanikolaou et al. (2019).

Fig. 2.1

Synthesis model for the design and optimization of a RoPAX ferry (see also Fig. 2.5)

Fig. 2.2

Synthesis model for the design and optimization of a double-ended ferry (Elomatic)

Fig. 2.3

Synthesis model for the design and optimization of a MPOV (The Naval Group)

Fig. 2.4

Synthesis model for the design and optimization of an OSV (Kongsberg)

Table 2.1 Tools utilized within HOLISHIP platform(s) and coupled to CAESES^® (excerpt)

In addition, the ACs provided feedback for the adjustment of CAESES (bottom-up approach), introducing several challenges that would go even beyond standard design tasks: (i) Quite many different partners and many tools from various developers had to be brought together, and (ii) the process was spread out over several years. The latter implied that, naturally, communication was less stringent than in purely commercial design projects and that the partnership encountered changes typical of long-term projects (e.g. people leaving the project due to career changes, periods of parental leave and sabbaticals, new people being onboarded, adjustments and progress in tools). In this sense the HOLISHIP platform(s) were not only tested successfully for technical diversity but also for robustness and the usage within distributed and evolving teams.

Figure 2.5 gives an abstract view of the process that involves several simulations to be executed. Important tools utilized within the HOLISHIP platform(s) and coupled to CAESES^® for the ACs are summarized in Table 2.1.

Fig. 2.5

Process of design and optimization as realized within CAESES^® for a synthesis model bringing together various simulations

2.3 Recent Improvements of CAESES

In the course of the HOLISHIP project, CAESES^® itself was extended and improved. A few selected improvements shall be elaborated here.

2.3.1 Parallelization

For several years there has been a notable shift in processor technology. Today most computers, from workstations to notebooks, offer multi-core chips which strengthen computers to be effective in performing several tasks concurrently. This was different up until a few years ago when processors primarily saw a steady increase in clock speeds. CAESES was originally developed for single-core usage, its origin dating back to 2004 when most CPUs, even for engineering workstations, still offered only sequential task execution.

However, typical hierarchies of (even simple) parametric models feature objects that are independent from each other, and, hence, can be updated in parallel. In order to support this, CAESES had to be adapted and rearranged, leading to the parallelization of the code basis.

The most important advantage for the user can be seen from Fig. 2.6: The parallelized version of CAESES, here CAESES 5, yields a substantial speed-up when building or updating parametric models. Within the context of automated exploitation and exploration in which many CPU hours are spent for high-level computations, say RANS simulations, this speed-up from several dozens of seconds to a few seconds during an update may not be needed. However, when actually building and also when preparing a parametric model for simulation-driven design, the typical work flow requires numerous interactive steps with updates, changes and quality tests. Then, a fast update of geometry is of very high importance.

Fig. 2.6

Speed-up via parallelization for two different parametric models, depending on numbers of cores (single-core sequential update given in blue, using CAESES 4.4; parallel updates given in green, using CAESES 5.0)

2.3.2 Complementing Algorithms

CAESES already offers a range of standard algorithms for exploration and exploitation, see (Harries and Abt 2019). In addition, the DAKOTA environment by Sandia National Laboratories (dakota.sandia.gov) can be utilized as a plug-in. This connection was further streamlined, making a large number of high-end optimisation algorithms available (see also Sect. 2.3.3). In addition, a new and dedicated search strategy was implemented for early design (as suggested by HSB). The method iteratively linearizes objectives and (inequality as well as equality) constrains as first proposed in (Gudenschwager 1988).

Particularly in early design phases many free variables, bounds, constraints and dependencies are present while the freedom of change and the potential for the right (and threat for an unfortunate) choice of main dimensions is still the highest. In order to support this phase, many relationships need to be formulated, setting up a non-linear and quite extensive set of equations and inequalities. This set is solved by means of a new design engine within CAESES which was called Simplexer. It is an extended implementation of the Simplex algorithm (linear programming).²

Figure 2.7 illustrates the Simplexer and the optima found for two-dimensional test cases with one objective (here F as function of x₁ and x₂) and several constraints (here g_j as functions of x₁ and x₂), a two-dimensional test being easier to visualize. The constraints actually are inequality constraints for various tests but are formulated as equalities (i.e., for the situation in which the inequality constraints are active). Depending on which constraints are considered and on the starting point for the search, different optima are identified by the Simplexer. The linearization of both constraints and objectives is done internally within CAESES so that the engineer can focus on formulating the design task.

Fig. 2.7

Illustration of the Simplexer for a search in two dimensions, including constraints

2.3.3 Extended Feature for Surrogate Modeling

2.3.3.1 Response Surface Methodology

When exploring a design space spanned by multiple design variables, often the complex interactions and correlations of the design variables with an objective are rather non-intuitive and hard to grasp. From statistics, Response Surface Methodology (RSM) is known as a technique that explores exactly this relationship between a set of design variables and (at least) one evaluation. See also (Harries and Abt 2019).

In simulation-driven design (SDD), often formal optimization algorithms are used to navigate through the design space and efficiently converge towards local or even global optima. But still, a more thorough understanding of how different geometric characteristics affect a solution and how this might be different for another region of the design space offers valuable insight. Such knowledge, which traditionally had to be acquired over many years of research in the field, will allow the designer to make well-educated guesses, as to how and where to modify the shape or even the underlying parametric model, in order to achieve a certain design goal. Furthermore, this capability of surrogate modeling—i.e., to predict, with a certain (known) accuracy, how a complex system will answer to a previously not yet considered set of input arguments—can be used to enhance the performance of a multitude of formal optimization methods originally developed without this technique in mind (Sánchez Castro and von Zadow 2019).

As mentioned above the open source library DAKOTA (Adams et al. 2020)is embedded within CAESES, which offers a variety of methods and tools that can be put to use in this context. The terms Response Surface (RS), Response Surface Model (RSM) and surrogate are used somewhat interchangeably. All of them follow the same basic idea, which is, to make use of an existing result pool to approximate the response of a system to a change in one or several of the free variables. Such a surrogate, if visualized in 3D space takes the shape of a surface (see Figs. 2.8 and 2.10). On two axes, a certain range of input values for two of the design variables is shown, while the remaining design variables are kept constant at any freely chosen combination of values. On the third axis the prediction of the model for any evaluation within this space can be mapped. Often all three axes will be normalized with a color-coding indicating the absolute measures of the response.

Fig. 2.8

Different surrogates based on a Sobol (top row) and LHS sampling (bottom row) for 5, 10, 15 and 20 samples; the predicted and the correct optima are indicated via red and green points, respectively

2.3.3.2 Sampling

As a prerequisite for any surrogate, a result pool is needed. This data set is often referred to as training data—especially in the context of Artificial Neural Networks (ANN). It should consist of a sufficient number of designs that are conveniently spread throughout the design space. For most simulation-driven design applications, having more designs within the pool will lead to a model of higher accuracy. However, the chosen method of sampling does not only significantly affect the accuracy of a prediction itself but where in the design space the highest accuracy, i.e., the best match to the actual function value, can be found.

From the perspective of an engineer who is already searching for a final, locally optimal design, this region of high accuracy should preferably lie in the vicinity of this design point. However, in an earlier phase of the design process it might still be the objective to just detect potentially interesting regions or simply to acquire a greater understanding of correlations and cause-and-effect relationships. Without being able to look at different surrogates one might not even be able to tell if the problem under consideration is single- or multi-modal, or how well the objective behaves with respect to a certain change in input variables, after all. In such cases, where a prediction of similar accuracy across a design space is targeted, a Design-of-Experiments (DoE) method such as Latin Hypercube Sampling (LHS) or a Sobol sequence is often the most suitable.

2.3.3.3 Illustrating Example

The Rosenbrock function

$$f\left( {x,y} \right) = \left( {a \, {-} \, x} \right)^{2} + \, b\left( {y \, {-} \, x^{2} } \right)^{2}$$

(2.1)

with a = 1 and b = 1 is a popular test function and shall be used to illustrate a single-objective optimization problem with x and y being the design variables and f(x,y) being the objective. When restricting the range of the input variables x ∈ [–2, 2] and y ∈ [–1, 3] and normalizing the function to its maximum value within this range, i.e., f(–2, –1) = 34, it can be written in normalized form with u ∈ [0, 1] and v ∈ [0, 1]

$$g\left(u,v\right)=\frac{1}{34}\left[{\left(3-4u\right)}^{2}+{\left(\left(4v-1\right)-{\left(4u-2\right)}^{2}\right)}^{2}\right]$$

(2.2)

Figure 2.8 shows multiple surrogates with the analytically determined global minimum at g(0.75, 0.5) = 0, indicated by a green point. The global minimum associated with each surrogate is marked by a red point. For both sampling methods a good approximation can be observed for 15 and more samples. The actual positions u_min and v_min for the predicted global optima are given in Fig. 2.9. Comparing the obtained optima for 15 and 20 LHS samples, one can observe that more samples do not necessarily result in a more accurate approximation.

Considering the low gradient of the chosen benchmark function in the optimal region, both data sets yield rather satisfactory approximations. (For comparison, to determine the positions u_min and v_min as well as the functional value of the optimum found by running a T-Search algorithm starting from u = 0 and v = 0 would require more than 120 designs until a similarly good solution is obtained. In addition, the knowledge derived from a data set stemming from an exploitation will be clustered near the optimal design point and, hence, will not allow for a reasonable approximation in the remaining design space).

Fig. 2.9

Predicted optima and their positions based on Sobol and LHS sampling for different sample sizes. (Note, that LHS, as opposed to Sobol sampling does not offer the added benefit of repeatability and hence, the outcome for another run might differ slightly)

2.3.3.4 Model Generation

Within CAESES and the present implementation, the generation of a surrogate always refers to a model that will predict just one evaluation based on a set of at least two design variables. Therefore, all the necessary input needed to trigger a model generation via Surfpack, which is part of the DAKOTA software toolkit, is available in CAESES in the form of a results table containing the sampling designs. All it takes is a custom export that writes out these data in the appropriate file format. Next, a template file is written to specify the type of model that shall be generated along with the previously prepared data set. It is then merely a matter of triggering an external executable that performs the necessary calculations in batch-mode and returns a model file.

As can be seen from Fig. 2.10, all of these steps were conveniently wrapped into a CAESES feature (here in CAESES 4.4), enabling the design engineer to apply the technique with just a few clicks. The only input arguments that need to be given by the user are the type of model one wishes to generate, the design variables and evaluation of interest (“Response Index”) as well as the table containing the corresponding training data. Out of the different model types that are offered within Surfpack, the current implementation offers Kriging, ANN and second as well as third order polynomials.

2.3.3.5 Evaluation and Visualization

Similar to the generation of various models, the evaluation of an existing model file can be conveniently wrapped within a CAESES feature. To improve usability both feature definitions were packaged as sub-features and, hence, their in- and outputs are automatically linked; this means that a previously generated model file will be directly available for evaluation within the project (see input argument “Surrogate” in Fig. 2.10).

Fig. 2.10

Input arguments of the CAESES feature for generation, evaluation, visualization and cross-validation of the surrogate

For the evaluation of one or multiple designs a data file is written, too. Furthermore, a template file pointing to the data as well as to the model which shall be used for prediction needs to be created. Again, from within the same feature, DAKOTA’s Surfpack is called in batch-mode. The obtained response is subsequently written into an additional file.

For only one evaluation at a time, all it takes for CAESES is to wait for this file to appear and read in the predicted response. For multiple simultaneous evaluations, an array of responses can be read in from a single Surfpack computation. By evaluating two series of design variables with all their permutations of interest, keeping the remaining design variables constant, this procedure allows to conveniently visualize the surrogate in three-dimensions via the use of an interpolation surface. This is illustrated for the Rosenbrock function in Fig. 2.11.

Fig. 2.11

Comparison of original Rosenbrock function and an associated surrogate

2.3.3.6 Cross Validation

To judge the quality of a surrogate, a k-fold cross-validation (Fushiki 2011) has been implemented. The available result pool containing n designs is hereby split into k subsets, each of which contain n-k designs. For each subset, a model of the desired type is generated and evaluated at the remaining k design points. The coefficient of prognosis (CoP) is then calculated as

$$CoP = 1 - \frac{{\sum\nolimits_{i = 1}^{n} {\left( {g - g_{RSM} } \right)^{2} } }}{{\sum\nolimits_{i = 1}^{n} {\left( {g - \frac{{\sum\nolimits_{i = 1}^{n} g }}{n}} \right)^{2} } }}$$

(2.3)

For the surrogate shown in Fig. 2.11, the maximum coefficient of prognosis of a threefold cross validation equals CoP_max = 0.9506. For a Kriging model it follows, that the actual CoP when using the entire result pool of 15 will be even higher. However, it should be noted that a higher CoP does not necessarily mean that any point within the design space will be predicted with a higher accuracy. Also the CoP is not necessarily higher for larger sample sizes as could be seen from Fig. 2.9.

Fig. 2.12

Set-up of a partially-parametric modeling approach using RBF

Fig. 2.13

Application of a partially-parametric modeling approach using RBF

2.3.4 Further Partially-Parametric Modeling

In order to enable less experienced engineers to more easily and quickly introduce high-quality changes in geometry, in particular to hull forms, the broad range of partially-parametric modeling approaches already available within CAESES was further extended. A new Radial Basis Function (RBF) approach was developed which allows the selection of regions to be modified interactively and to evoke changes to a baseline by means of source and target geometry. Figures 2.12 and 2.13 illustrate the set-up and the modification for a representative hull form given as a tessellated geometry (here by importing an stl-file to CAESES). Details of the RBF approach, following (Botsch and Kobbelt 2005), are elaborated in Table 2.2.

Table 2.2 Radial Basis Function approach

2.4 Additional Means of Integration

2.4.1 Integration via COM

The standard connection between CAESES and any external simulation tool via template files was discussed in (Harries and Abt 2019). This type of connection is very flexible and independent of the operating system and, hence, is available for both Windows^® or Linux™. Quite frequently, however, statistical data, auxiliary computations, estimates and quick checks (e.g. on the basis of previous design work or literature surveys) are compiled and run within Microsoft Excel. To support data exchange with Excel there is an integration mechanism within CAESES built on the COM-interface under Windows^®, allowing to utilize Excel as an additional simulation tool.

In principle, any cell within an Excel-file can be addressed either to write data to or to extract data from (bidirectional data exchange). This allows a design team to formulate analyses, built parametric models (e.g. for costs and weight) and formulate company-specific relationships between data (e.g. from heuristics) within a spreadsheet—as is often done already—and still include this “knowledge” in a complex synthesis model. Maintenance of the data within the spreadsheet can then be done outside the synthesis model (and does not require an update of the integration unless the cells for data exchange, as identified via their row and column numbers, are modified).

Figure 2.14 shows an excerpt of a feature within CAESES with which to connect to Excel in the context of the application case of the design of an offshore platform. Within this AC, an Excel spreadsheet was developed that determines project costs (as an objective), the estimated duration for platform installation and an overall feasibility (as a constraint).

Fig. 2.14

Excerpt of CAESES feature for the connection to Excel (AC Offshore Platform)

A more elaborate explanation about integration via COM can be found in (Abt et al. 2009). Further adaptations, maintenance and improvements were realized within the scope of the HOLISHIP project.

2.4.2 CAESES and ANSYS Workbench

For the same AC of an offshore platform, an additional type of connection was needed, namely a smooth connection between CAESES and the ANSYS Workbench, with ANSYS Finite Element Analysis (FEA) being one of the market leaders in structural design. Building on the existing collaboration between ANSYS and FRIENDSHIP SYSTEMS, two interfaces could be established to support data exchange between CAESES and the ANSYS Workbench: (i) The ANSYS Workbench is run from CAESES as the controlling entity (i.e., the PIDO) and (ii) CAESES becomes available within the ANSYS workbench. While the former regards the ANSYS Workbench as yet another tool run in batch-mode, the latter offers CAESES parametrics and geometry generation for the Workbench as a plug-in (or component), further increasing the scope of multi-lateral integration.³

Figures 2.15 and 2.16 illustrate the integration within the ANSYS Workbench. Here, CAESES itself is executed in batch-mode (on the basis of an FSC file, i.e., a CAESES script file, see Fig. 2.15a). Within the AC Offshore Platform this approach was utilized to compute with ANSYS FEA the maximum deformation under gravitational loads, under ice loads and under wave loads for a set of platform geometries (caisson) and seabed configurations (soil), see Fig. 2.15b.

Fig. 2.15

Integration of CAESES^® within the ANSYS Workbench (AC Offshore Platform)

Fig. 2.16

Integration of CAESES within the ANSYS Workbench (AC Offshore Platform)

2.4.3 Integration via XML

Within CAESES, tools can also be integrated on the basis of data exchange via XML files. This type of integration is typically used (and favoured) by tool developers that can freely decide on the format of their input and output files and that opt for XML syntax to combine human readability with easy maintenance.⁴

The XML integration in CAESES is based on a custom document type definition (DTD) provided by FRIENDSHIP SYSTEMS. This DTD defines all usable datatypes for both input and output, enabling the tool developer to complement (or, alternatively, even to replace) the existing input and output files by file formats following standard XML syntax. As soon as this has been done—which represents the major work load encountered—the tool provider sets up a so-called CAESES Definition which contains all possible input data. This can be readily done by using the GUI of CAESES itself.

Figure 2.17 shows parts of the so-called XFFL file for MARIN’s flow code RAPID for illustration, RAPID being a nonlinear potential flow code for wave resistance computation. Figure 2.18 illustrates the definition for RAPID in the object tree of CAESES along with one of the entries, here the Froude number, in the object editor. Entries can be added or deleted and all necessary attributes like name, type, default value, number of occurrences etc. can be set interactively. Furthermore, CAESES Definitions can be structured in groups and sub-groups.

Fig. 2.17

Excerpt of XFFL file for MARIN’s RAPID code

Fig. 2.18

Definition within CAESES^®

A CAESES Definition is saved in an XML file by the tool developer and then directly supplied to the users. This means that tailored versions of a tool, new features and changes can be distributed throughout a tool’s user community without any need of involvement of FRIENDSHIP SYSTEMS. See also (Abt et al. 2009) for details. As with the COM interface, further adaptations, maintenance and improvements were realized within the scope of the HOLISHIP project.

2.4.4 Cross-Platform Integration of Tools

Tool integration as needed to build synthesis models does not only face the challenge of having to bring together separate tools from different providers with non-homogeneous inputs and outputs, disparate data storage, non-harmonized nomenclature etc. but also that not all tools can be made available on a single computer or even within the same operating system. One way to circumvent this problem is to utilize surrogates as discussed in Sect. 2.3.3. An additional means of bridging the gap between computers and/or operating systems is to use CAESES’ resource management capabilities.

As shown in Fig. 2.19 different apps—i.e., applications, meaning simulation tools and/or other integration platforms—can be accessed by a CAESES instance via the so-called SshResourceManager that can trigger and communicate with computers, may they run under Windows^® or under Linux™, which are administered within one (local) network or within a virtual private network (VPN). This then enables, for instance, a design engineer to run CAESES on his or her personal computer, say under Windows^®, and make use of a simulation tool that was installed and for which a license was provided on a more powerful Linux™ workstation (or on an HPC). It also supports the utilization of various computers for resource-intensive simulations overnight and over weekends when these computers would usually not be needed for interactive work. Furthermore, it can be put to use to run a tool remotely that is only installed on a colleague’s computer and to which concurrent access cannot be provided easily.

Fig. 2.19

CAESES resource manager for usage of tools across platforms and on different computers

2.5 Selected Connections and Collaboration

The main strategy behind the development of CAESES^® and of HOLISHIP in general was not to attempt to introduce yet another monolithic system. Rather, the approach was to flexibly connect tools as they are needed for solving challenging design tasks. CAESES allows communication with stand-alone simulation tools either in a one-to-one relationship or in a one-to-m synthesis model (see again Figs. 2.1, 2.2, 2.3 and 2.4) with m being the number of tools connected. In addition, CAESES as the chosen integration platform can collaborate with Computer Aided Engineering systems that represent platforms themselves.

Several CAE systems were utilized within the scope of HOLISHIP’s application cases, e.g. the ANSYS Workbench (see above) from ANSYS, CADMATIC from Elomatic, NAPA Ship Design and NAPA Steel from NAPA OY and the Remote Component Environment (RCE) from DLR. The primary motivation for this was and continues to be that the engineering environments found in industry are rather diverse and that, depending on experience, available soft- and hardware, partners involved, the design task to undertake etc. a number of tools, be it for the reason of utilizing best-of-class or just the tools at hand, need to be brought together. If a CAE system then already has connections to other tools the key advantage of collaboration between platforms is obvious, i.e., an integration need not be replicated but integrating systems and/or frameworks can cascade and exchange data from one system to the other.⁵

Some of the connections and collaborations shall be highlighted here with reference for further reading.

2.5.1 CAESES and CADMATIC

Figures 2.20 and 2.21 are taken from the application case of the design of a double-ended ferry. As discussed in detail in Harries et al. (2019) CAESES and CADMATIC exchange data that relate to the hull form and the inner structure. CADMATIC utilizes the current hull geometry to map a parametric model for decks, bulkheads etc. to generate an estimate of steel weight. When changing the hull form the inner structure is automatically adapted so that a considerable range of design variants can be taken into account.

Fig. 2.20

Coupling of CAESES and CADMATIC (AC Double-Ended Ferry)

Fig. 2.21

Two variants of a parametric model for steel weight analysis within CADMATIC as triggered via CAESES (AC Double-Ended Ferry)

The full elaboration of the design task, the optimization, including hydrodynamics and considerations for batteries, a hybrid and a conventional drive system, along with results are given by the task leader, Elomatic, in (Jokinen et al. 2020, and Chap. 12 of this book).

2.5.2 CAESES and NAPA Steel

Figure 2.22 is taken from the application case of the design of a RoPAX ferry (AC RoPAX). It shows the imported data of the steel structure set up for the RoPAX ferry (design Alpha). Here, CAESES allows filtering of data for viewing and examination.

Fig. 2.22

Import from NAPA Steel (AC RoPAX)

Fig. 2.23

Import of blocks in CAESES (AC MPOV)

2.5.3 CAESES and Shipbuilder

Figure 2.23 is taken from the application case of the design of a Multi-purpose Ocean Vessel (MPOV) (AC MPOV by the Naval Group, see Chap. 6 of this book). It displays the data imported from a general arrangement (GA) of blocks, representing rooms, compartments and important functional areas and volumes as defined within Shipbuilder by Sirehna. Details are described in (Le Néna et al. 2020). The data imported from the GA helps to adjust the hull shape or, alternatively, to check if the blocks fit the geometry and to identify which blocks may need adjustments (e.g. cut-aways, tapering, resizing, relocation etc.).

2.6 Outlook

2.6.1 Version Control

It needs to be noted that CAESES even though versatile and flexible as a parametric modelling system (CAD) and as a process integration and design optimization environment (PIDO), respectively, has the inherent limitation of not being a product life-cycle management system (PLM). A PLM system would offer roles, access rights, version control, check-out and check-in of data, unified and long-term data storage etc. This is not the purpose of CAESES and, when developments started in 2004, was not part of its roadmap. Consequently, in order to elevate integration, coworking, concurrent engineering, collaboration between team members and also across company boundaries to another level, an additional PLM layer would be required. This was beyond the purpose of the HOLISHIP activities. Nonetheless, it would be worthwhile to pursue this topic, even though it has to be addressed with considerable effort within a yet to be defined new R&D project.

2.6.2 Marketplace

Complementing the holistic approach to ship design and the development of integration platform(s) within HOLISHIP, further ideas were proposed and studied, namely how to enable access to tools of various origin at a wider range, not only for partners of HOLISHIP but for the broader maritime community.

A first prototype of a web-based marketplace was realized on the basis of MAGENTO, a platform for B2B (and possibly also B2C) commerce. Figure 2.24 gives an impression. In principle, such a marketplace can offer tools, services, consultancy for design and simulation, quality assurance and can bring together teams beyond traditional company and academic boundaries. Two examples tasks are described in Table 2.3.

Fig. 2.24

Screen shots from a first mock-up of a potential HOLISHIP marketplace (note that this is an outlook and all prices shown are purely fictitious and are given just for illustration)

Table 2.3 Exemplary description of tasks and solution approaches for a possible marketplace on the basis of HOLISHIP (outlook)

2.7 Conclusions

The purpose of integration and collaboration is to create synthesis models that comprise the most important drivers, i.e., the key aspects, when working on a specific design task. Since key aspects and the way they are determined differ depending on the design stage, the actual design task and the available resources an ad-hoc assembly of tools and systems as well as of dedicated parametric models and surrogates are proposed. The approach showed its validity and versatility when brought to life and put to use for challenging applications, namely the design of twin-screw passenger ferries of different size (RoPAX), the development of an Offshore Supply Vessel (OSV) for safe crane operations under dynamic positioning, the concept and contract design of a Multi-Purpose Ocean Vessel (MPOV) for safety and security as well as search-and-rescue in European waters, the design of a double-ended ferry (DE-ferry) with electric (alternatively hybrid and conventional) propulsion, the design and installation of a gravity-based offshore platform for shallow waters and, moreover, the retrofitting of a bulk-carrier and a container ship already in operation. As can be readily appreciated neither the design challenges nor the synthesis models for these application cases are the same nor are the parties involved or the interests they pursue.

Setting up suitable synthesis models takes time as well as the expertise and cooperation of several partners. Presently, this may still call for too much effort and may yet take too much time for daily practise when working on standard designs. Nevertheless, once synthesis models are available they can be employed to run sophisticated optimisation campaigns in order to generate valuable and new insight. This then leads to cutting-edge and even to rather ingenious designs which yields a competitive advantage in a commercially challenging economy. In particular if non-standard solutions are required the potential gain merits the effort. Furthermore, with each new integration and with more experience gained, the speed of setting-up synthesis models and the benefit of utilizing them for simulation-driven design increases.