Managing Design Changes in Shipbuilding: Proposing a Real-Time Simulation Dashboard

1 Managing Design Changes in Shipbuilding: Proposing a Real-Time Simulation Dashboard Jisang Ha1,*, Janica A. Bronson1, and Henrique M. Gaspar1 1 Norwegian University of Science and Technology, Ålesund, Norway Abstract. A design simulation model with a unified data format is demonstrated in this work, focusing on: i) how design changes affect other objects and attributes; ii) what interfaces are required for this; and iii) the advantages of the implemented model through a real-time ship 3D model. Tracking design changes and revisions throughout the ship design and production process is known to be a challenge, especially when it involves multiple stakeholders working on 2D, 3D, and real-world objects. It is paramount to understand the impact that fragmentation has on drawings and model versions across different software and files. As a solution to this issue, data interoperability and a unified data format have emerged from different actors, and attempts are currently being conducted to accomplish this through neutral formats such as Open Class 3D Exchange Format (OCX) and STEP ISO 10303. In this study, we utilized the NTNU experimental vessel “Gunnerus” as the target vessel. We collected design data of Gunnerus before and after the design changes and implemented the design simulation as an open web-based model to observe the design change process in real time. As a result, we were able to implement a model to verify the ship design that changes according to the design version of each design object, especially the compartments. Furthermore, we provided both version-based and timebased views of the target ship’s design to assist designers and producers. In addition, we proposed an initial structure for representing changes over versions of each design object. Keywords: Ship Design, Data Interoperability, Real-Time Design Simulation, Unified Data Format, Version Control 1. Introduction Throughout the ship design and production process, design changes are often initiated at each stage for various reasons. However, if a design is changed and the changes affect versions across different software and files, it is challenging to understand the impact, and the versions of the design drawings can be fragmented at each stage. This could be a reason for unintended gaps between drawings and designs, especially between conceptual design, detailed design, and production. As a solution to this issue, data interoperability and a unified data format have emerged from different actors, and attempts are currently being conducted to accomplish this through neutral formats such as Open Class 3D Exchange Format (OCX) and STEP ISO 10303. There are various previous studies and attempts to utilize it. A notable example is the collaboration between Damen, DNV, and NAPA, who used the OCX standard to streamline the classification review process for a new ship design. This initiative enabled the direct exchange and approval of 3D models, replacing traditional 2D drawings and allowing designers and classification societies to work in parallel, ultimately accelerating the design cycle and reducing risk in the early stages of ship design [1][2]. One of the other attempts, SFI (Ship Functional Information) system is a wellestablished classification and coding system developed to standardize ship information for specification indexing, cost accounting, and project management across shipyards, shipowners, and suppliers. It is a function-oriented system, grouping components and systems logically to facilitate engineering, estimating, planning, purchasing, and production processes in shipbuilding [3]. In this study, we consider a method that can be applied to the entire ship design, rather than just the hull, machinery, and outfitting, with limited coverage of lifecycle management metrics critical for shipowners, because existing methods are difficult to follow the ship design history or focus only on the hull, machinery, and outfitting. Bronson et al. (2024) [4] reviewed data models in ship design and construction and investigated their potential for application. The success of BIM can be applied to the shipbuilding industry, and we want to facilitate the organization, management, and contextualization of data used in shipbuilding by fusing data from CAE/CAD/CAM/PDM systems through a single source of truth for ship data [5]. * Correspondence to: [email protected] 16th International Symposium on Practical Design of Ships and Other Floating Structures PRADS 2025 Ann Arbor, MI, USA, October 19th – 23rd 2025 2 In this study, we implemented a design simulation model with a unified data format and demonstrated how design changes affect other objects and attributes, what interfaces are required for this, and the advantages of the implemented model through a real-time ship 3D model as shown in Figure 1. Figure 1. This figure presents an example of a real-time simulation dashboard for managing design changes in shipbuilding. A design simulation model with a unified data format is demonstrated in this work, focusing on: i) how design changes affect other objects and attributes; ii) what interfaces are required for this; and iii) the advantages of the implemented model through a real-time ship 3D model. In this study, we utilized the NTNU experimental vessel “Gunnerus” as the target vessel. We collected Gunnerus’ design data before and after the design changes and implemented the design simulation as an open web-based model to observe the design change process in real-time. As a result, we implemented a model to verify the ship design that changes according to the design version of each design object, especially the compartments. Furthermore, we provided both version-based and time-based views of the target ship’s design to assist designers and producers. In addition, we proposed an initial structure for representing changes over versions of each design object. 2. Managing Design Changes in Shipbuilding 2.1 Data file structure or version control simulation 3 While building the data model and the model that expresses design changes, we need to find the relation or hierarchy between the data. Commonly, data management methods, such as SFI, use grouping rules to manage data relationships. However, these methods show the relation between objects or designs in an indirect way. We wrote the names directly to show related data and considered whether to link or node each design change version based on whether they are related to each other or not, or whether they are completely independent designs. The input requirements for the simulation in this study are as follows: To perform design change simulation for compartments, we need the name (or ID) of each compartment, attributes to perform calculations, and model information for volume-related calculations and visualization. In addition, the timestamp of each revision is required for the design changes simulation to be timeline-based instead of version-based. We also need information about how each design changes the version relates to each other and which drawings or models are related to each other. We want to represent this in a tree-like representation based on version-based and timeline-based approaches. The data objects we utilize for this will be introduced in the next section. 2.2 JSON data model for the simulation We utilized a JSON object in our simulation described in the section 2.1. JSON (JavaScript Object Notation) is one of the most common formats for exchanging data on the web. The JSON data model for this study has the following components and structure as shown in Figure 2. Figure 2. An example figure presents a structure of the JSON file. For our Version Managing Design Changes Simulation, we created an example JSON file as shown in Figure 2. In the JSON file, we organized each component required for ship design into arrangements, structures, ship specification, and timestamp. In this paper, we only used the Arrangements and timestamp parts of these components. An Arrangement consists of the following parts: compartments, interface, and elements. Each element has a “name”, attributes, and a model. The attributes contain numerical values that describe the element, and the model stores geometry information, including a 3d model file. Ship specifications are used for the calculation of alphanumeric changes. Timestamp contains information about the time the JSON file was created or modified for revision. In addition, when designing or simulating compartments, additional information about the equipment and structural components in each compartment is required for compartment calculation. If it is also used for detailed design, such as equipment and pipe arrangements, additional specifications, such as nozzle location and direction, 4 equipment location, and pressure required by the equipment, are required. Considering the possibility of further expansion, this JSON file contains information that can be used to perform equipment and pipe arrangements. 2.3 Simulation for managing design changes This case aims to illustrate the advantages of the proposed form of revision design change simulation when representing time-based lines and version-based lines together. This time-based simulation is influenced by Building Information Modeling (BIM), which can be used in connection with Gantt charts to observe the construction process of a building along with a timeline. We would like to show a simulation that utilizes this in terms of ship design. Figure 3. Bently Syncrho4D BIM Solution showing simulation with Gantt Chart (Source: https://blog.bentley.com/software/what-is-synchro-4d/) This delivery of version and time-based simulation together can significantly assist designers in two areas; i) Reduce the number of attempts that a designer needs to converge, ii) Make it easier to re-use data. In Figure 1, the black rectangles are simplified representations of the objects on the experimental ship Gunnerus. The orange rectangles are items that have drawings, and the GA versions at the top are related to other drawings. The green bar shows the timeline. It can be sorted by time-based or version-based, depending on the user's preference. The ship model at the bottom is a simulation of the physical ship, with the boxes inside representing the compartments. These compartments change in real-time based on the selected drawing. 2.4 Alphanumeric changes While the current JSON model includes arrangement and hull geometry data, along with timestamped simulation values, a complete digital representation of a vessel must also incorporate alphanumeric information. This includes electrical system properties, propulsion parameters, and other performance-critical specifications. Traditionally, such data is structured according to classification schemes like SWBS (Ship Work Breakdown Structure) [6] and SFI [7], which helps codify how ship data is systematically organized. The example SWBS designation below illustrates how electrical system data onboard the vessel is distributed across multiple codes. 5 This snippet highlights the diversity and scope of systems and documentation considered for electrical data, particularly during the detailed engineering and design phase [8]. Electrical data, particularly in the form of Electrical Load Analysis (ELAs) and Single-Line Diagrams (SLDs), presents a unique challenge when visualized in 3D formats. This type of data is often represented schematically. However, in the early stages of design, this information can be efficiently distilled into a simplified load analysis that is linked to geometry, based on standard scaling laws [9]. These laws help us understand the parametric impact of changes in geometry. For instance, an increase in hull length may necessitate corresponding adjustments to propulsion capacity, cable lengths, and electrical loads. These interdependencies can be represented through parametric relationships that connect alphanumeric values to geometric variables. For example, a straightforward increase in overall volume typically results in a proportional increase in propulsion power, and consequently, in electrical load. With a known speed, an increase in Length at Waterline (LWL) will, by definition, raise the Froude Number (Fn) according to the equation, where velocity is the ship speed [10]. Figure 4. Equation of Fn This increase in Fn will then lead to a corresponding rise in power, which can be approximated due to the events of the Fn in the ship’s resistance [11]. For the purposes of simplification and to demonstrate change propagation, we use the Admiralty formula, which relates displacement, speed, and power, and can be used in early estimations [14]. A constant Admiralty coefficient is assumed noting that the new ship hull is similar to the original but will only have different displacement, shaft power and/or speed. Such simplified scaling laws are common not only in propulsion and electrical systems but also across various other critical alphanumeric data needed to assess basic ship performance. These power estimates could be further refined with detailed resistance data and additional performance parameters. Figure 5. Equation of EHP Figure 6. Equation for Admiralty Coefficient 6 Figure 7. Hierarchy of performance parameters and load data. In the context of change management, the system recalculates these alphanumeric values dynamically after each design update. By defining transformation functions based on parametric equations, we ensure that any change in the design automatically propagates throughout the data model. This modular approach minimizes the risk of human error during manual updates, ensuring consistency. 3. Applications 3.1 A simple design change simulation case To illustrate the proposed simple design change simulation, we present a simple example consisting of two blocks (compartments). Figure 8 shows an example of the simulation. Figure 8. The simple design change case with 2 blocks The simulation consists of two blocks, CargoHold and ControlRoom. Information about the two compartments is contained in two GA versions. The graph consisting of lines shows how each data structure is connected. Each GA version and compartment is connected to the previous data. The horizontal axis is aligned according to the 7 timeline on which each revision was written. This may or may not be connected to the previous GA version. The designer can select a GA revision version to view the design of each compartment for that version or drag the timeline to observe design changes at the desired timeline. Based on the GA version, the alphanumeric changes for the corresponding ship were also calculated, which is explained in the next section. 3.2 A design changes simulation case with Gunnerus 3.2.1 Data mode of Gunnerusl In the Gunnerus case study, a single official revision of GA was recorded. However, there were changes in at least four blocks within GA. In our simulation, we segregated the data for each block, enabling us to select and review only the revision of the desired block. An example is shown in following Figure 9. Figure 9. The design changes based on the revision of blocks with Gunnerus However, internal timestamps reveal that three distinct design modifications occurred. The design progress, based on timestamp data, is visualized in Figure 10. 8 Figure 10. The design changes based on the timeline with Gunnerus To effectively track design revisions, it is essential to maintain a structure linking each design to its parent version or to associate it with a data structure that reflects its dependencies. In this case, we leveraged metadata extracted from the GAs to establish these connections. Based on this, we reviewed the design proposal by applying not only visual design changes but also the simple alphanumeric changes introduced in Section 2.4. 3.2.2 Alphanumeric changes Based on the hierarchy presented in Section 2.4, the simplified structure for key propulsion and electrical variables, and other alphanumeric parameters, based on Gunnerus' specification sheet is shown in Figure 11. While the parameters used are specific to the case vessel, the framework can be generalized to other vessel types by extending the underlying schema and transformation logic. For simplicity, propulsion data is presented in blue. 9 Figure 11. Alphanumeric data on propulsion based on Gunnerus Specifications. Figure 12. Changes to the propulsion parameters based on geometry. To display this change triggered in a multi-domain recalculation (from geometry to propulsion), we took an example of the lengthening case applied to Gunnerus during its development, where the Length Overall (LOA) increased from 31.25m to 36.25m, representing a 1.16 factor change in the Length at Water Line (LWL). This modification in geometry necessitated corresponding changes in alphanumeric properties. Using our unified model and transformation functions, the 1.16 length increase automatically translates to appropriate power requirement adjustments, calculated through Froude scaling principles and admiralty coefficient. This integration eliminates the need for manual calculations across multiple documents, reducing redundancies and ensuring that all design changes propagate from a single source of truth with proper version control. Figure 13 presents the various files used to corroborate the propulsion data. This capability offers clear workflow advantages over conventional practices when tackling change [12]. In current industry workflows, alphanumeric specifications are often scattered across multiple files, spreadsheets, PDFs, and database exports. These are maintained manually or tracked using general-purpose version control systems like Subversion or Git [13]. While these tools enable change tracking at the file level, they lack semantic awareness of the data structures and interdependencies specific to ship design. As a result, engineers must rely on tacit knowledge and custom scripts to understand the implications of changes. By integrating alphanumeric version control directly into the same model that governs 3D geometry and simulation, we enable fine-grained, context-