US SUBMARINE CONCEPT DESIGN TOOL - Warship 2011 - Naval Submarines and UUVs.pdf

A J Mackenna,S A Patten, and R K Van Eseltine, Naval Surface Warfare Center – Carderock Division, USA SUMMARY

When Naval Sea Systems Command (NAVSEA) is faced with the challenge of a new submarine concept design, it has until recently taken the traditional approach of developing a few point designs using a physical and digital library of historical submarine design data and a variety of commercial and in-house design tools. Navy leadership has a need to make informed requirements decisions early on in a submarine acquisition program. To service this need, a tool was required that would allow a design team to analyze more of the submarine design space within the limited time and budget constraints of early stage design. This use case guided the requirements for a new submarine concept design tool that is capable of creating multiple ship concepts with greater speed and accuracy than traditional methods. NAVSEA commissioned Naval Surface Warfare Center Carderock Division to develop Advanced Ship and Submarine Evaluation Tool (ASSET) for Submarines. In addition to cost and schedule efficiency, ASSET-Submarine provides technical ac- countability by having vetted the engineering design processes through US Navy Technical Warrant Holders. This paper recounts the development of ASSET-Submarine.

1. INTRODUCTION

Early stage submarine design encompasses a broad spectrum of design activities. A design activity can last as little as a man-day or as long as several man-years. Early stage study results are used to define cost and effectiveness relationships and to make educated decisions for technical and programmatic matters. If more studies are performed at the early stages of a submarine design, re- sulting in more comprehensive exploration of the design space, this will lead to better design and requirements decisions. In order to reduce the amount of time each study takes, ASSET-Submarine was developed to rapidly create a submarine concept design.

2. OVERVIEW OF EARLY STAGE SUBMARINE DESIGN

Submarine design combines the design expertise of several engineering disciplines. The scope of the studies range from Rough Order of Magnitude (ROM) concept studies to detailed design for production; the former re- quiring as little as a man-day and the latter involving a large team working for years. The focus of this paper will be the lower end to intermediate level of the concept design spectrum, encompassing ROM and feasibility studies.

ROM studies provide estimates of a notional submarine’s rough arrangements drawings, characteristics, and performance attributes, such as displacement, length, draft and speed.

Feasibility studies provide sufficiently detailed information that enables:

x Analyses of system performance x Identification of technical risks x Accurate tradeoff studies x Cost estimates

x Definition of additional ship characteristics for use in operational effectiveness analyses

Submarine concept and feasibility studies may be performed to provide:

x Support of submarine acquisition programs x Whole ship concept studies

x Tradeoff studies

x Support Research and Development (R&D) and Science and Technology (S&T) Community, including technology assessment

x New concept exploratory studies

x Support of Office of Naval Intelligence (ONI) x Reference studies for evaluating contractor per-

formed submarine design

x Assessment of third party submarine concepts Traditional methods of conducting early stage submarine concept designs reference a physical and digital library of historical submarine design data and a variety of commercial and in-house design tools. The majority of designs use legacy data as a starting point; the weight and displacement balance calculations are performed by the concept naval architects by adjusting weight and displacement data from past ships or concept designs.

Computer Aided Design (CAD), including three- dimensional modeling of the hull or two-dimensional arrangements drawings, is used for design and reporting.

The entire process is comprised of separate design disciplines that are manually iterated by the concept naval architect based on the given requirements. Figure 1 shows a flowchart of the submarine design disciplines.

Warship 2011: Naval Submarines and UUVs, 29 – 30 June, 2011, Bath, UK

3. REQUIREMENTS

3.1 RAPID CONCEPT GENERATION Early stage concept design process consists of many design disciplines that are brought together in an iterative approach to synthesize the design. This method is condu- cive to a computer based tool that integrates the design disciplines to assist the designer. Using the traditional method of concept design, small iterative changes incur a large amount of rework and calculation. The time needed to respond to queries for concept design solutions would be reduced significantly with a software solution to concept design. The US Navy has a direct need to generate rapid submarine concept designs to support acquisition decisions.

3.2 DESIGN KNOWLEDGE RETENTION The frequency of early stage submarine concept design is difficult to predict; therefore, it is difficult to maintain an experienced concept naval architect workforce. This in- stability introduces difficulties with knowledge retention and transference of knowledge to new naval architects. A design tool with integrated design rules could help to alleviate these concerns. Documenting the design rules used in the tool is essential to keeping future concept naval architects trained in not only the use of the software, but in the principles behind submarine concept design.

3.3 DESIGN SPACE EXPLORATION The traditional method of doing submarine concept designs consists of performing a point design and performing subsequent iterations on that point design.

The time required to do iterations is shorter than performing a single point design from scratch, but it still can be a labor intensive effort to design only a couple of points in the design space. A design tool with the ability to quickly perform iterations allows the designer to rapidly explore a multivariable design space.

3.4 COST SAVINGS

The use of a design tool for submarine concept design can produce cost savings by significantly reducing the amount of time to perform a study and increasing the quantity and quality of output for a given cost. More of the design space can be explored because the point designs are performed faster and cheaper. Proper ship sizing during the concept stage is critical to a successful acquisition program. The capability to rapidly produce concepts can identify sizing issues and design flaws ear- lier in a submarine design. This has the potential to save programs significant costs, as flaws in the submarine design become more and more costly to fix the longer they go undiscovered.

Warship 2011: Naval Submarines and UUVs, 29 – 30 June, 2011, Bath, UK

An important requirement for a submarine concept design tool is that the implemented design process be validated by the US Navy. Software that hides the design approach within the code does not agree with the strict technical authority culture of the US submarine design force. The US Navy puts a large portion of design work out on contract; therefore, the necessity to validate work delivered on contract requires transparent design processes.

4. DEVELOPMENT HISTORY

Attempts to create an early stage submarine design tool began as early as 1985. At various points in time proprie- tary, university, and government development efforts have been tried.

A recurring issue with past submarine design tool development efforts is that the naval architects that are capable of creating the design algorithms do not have the computer science background necessary to make a good software product. Likewise, computer scientists lack the design knowledge to effectively write a meaningful submarine design tool.

In an effort to reduce cost, focus on the development of capability instead of infrastructure, and the need for the tool to also be a design repository, the decision was made that the Navy would develop its own submarine design tool based on Navy requirements and needs. The Navy team is comprised of both naval architects and computer scientists who work together to produce the software.

5. APPLICATION DEVELOPMENT Development of ASSET-Submarine focused on achiev- ing the following three overarching requirements.

x Validate the analysis modules by replicating recent US attack submarine designs within the tool.

x Support design variation studies on recent attack submarines.

x Develop new attack submarine concepts.

The development of ASSET-Submarine was divided into two phases. The first phase was a theory development phase which produced a set of documents that delineated the mathematical equations and calculation processes required for a submarine design. The theory documents were then combined into an overall design calculation process. The second phase was the software development phase, which implemented the theory.

6. THEORY DEVELOPMENT

Theory documents were developed for each engineering discipline that is included in the computational capabilities of the tool. Subject matter experts were used to develop and review the theory. At the conclusion of the theory development, the theory documents were re- viewed and approved by the NAVSEA submarine design community. An overarching requirements document was developed that detailed how the different design disciplines would be integrated into a single tool that is capable of generating a balanced submarine design.

In the requirements for the first release of ASSET- Submarine, the weight estimation and displacement calculation capability were given the highest priority above all other design capabilities. Submarine concept design is centered on balancing weights and displacements. The balance of the ship vertically and longitudinally is the key to determining basic feasibility of a submarine concept.

6.1 MODEL FIDELITY

Compared to surface ship concept design, the weights and displacements are worked at a much higher level of fidelity. The required modeling fidelity required the implementation of a 5-digit level Ship Work Breakdown Structure (SWBS), which contains 375 separate weight categories. These weights are scaled from the USS VIRGINIA (SSN 774) parent weights, but use a parametric equation to scale the weight based on the weight driver(s) for each category. Being parametric algorithms, the weights of a concept submarine will scale with the changes in dimensions and requirements. These weights can be calculated at almost any point in the submarine design process; even if most of the geometry is left unde- fined; the only requirement is the concept submarine must have an outer hull and pressure hull defined.

Since US submarines have ballast tanks located forward and aft of the pressure hull, displacement items in those areas have a significant effect on the longitudinal balance of the ship. Therefore, the prominent displacement items are individually represented and accounted for in the model. Many displacement items are dependent on ship geometry; for example, torpedo tubes require large re- cesses in the main ballast tank volume, yet; the recess geometry is dependent on the outer hull, pressure hull, and main ballast tank geometry. A tool that assists with the difficult main ballast tank geometry calculations is valuable to a concept naval architect, whose time can be better spent analyzing the resultant concepts.

Warship 2011: Naval Submarines and UUVs, 29 – 30 June, 2011, Bath, UK

Designing a concept submarine before requirements are known is difficult. Designing a concept submarine is cumbersome after a high level of design definition is complete. A flexible methodology is needed so the user is able to quickly develop a new design from scratch. The decision was made to establish a baseline design, or parent ship, as a starting point for the designer; the first baseline developed is the VIRGINIA. When the user starts the tool for the first time, the VIRGINIA is loaded as the default. The user is required to activate these de- faults during the design definition process. Since a detailed baseline lies under the concept model, the designer can quickly sketch out a submarine design and perform detailed calculations on that design.

6.3 DESIGN PROCESS

Given an initial baseline, the requirements for the submarine, such as mission duration, crew size, etc., can be adjusted. Once modified requirements are established, a rough sizing of the outer hull, pressure hull, and main ballast tanks is performed. After the hull is sized, hull appendages, such as sail, rudder, stern planes, and bow planes, bow sonar, and hull mounted sonar can be defined. At this point, sizing and placement of all of the major tanks that reside inside of the pressure hull, such as trim tanks and auxiliary tanks are determined. The hull geometry has the flexibility to be resized at any time during the design process. An equilibrium polygon is calculated to assist the designer with the tank sizing and arrangement process; this ensures the tanks have suffi- cient volume to trim the boat in a variety of submerged conditions.

The solid ballast solution is calculated accounting for stability, trim, and weight-displacement balance. The solid ballast value is permitted to go negative if needed to satisfy the balance criteria; however, the program identifies the design as infeasible with negative solid ballast. Performance analyses (e.g. speed-power calculations) are then performed on the balanced design.

7. SOFTWARE DEVELOPMENT Upon completion of the theory development phase of the project, the theory documents and design process produced were provided to the software development team for implementation.

7.1 USING EXISTING INFRASTRUCTURE Prior to the commencement of development of the submarine portion of ASSET (ASSET-Submarine), the US Navy had designated ASSET and the Leading Edge Ar- chitecture for Prototyping Systems (LEAPS) as its standard early stage concept development platform for surface ships. Future analysis tool development by the US Navy will be done with LEAPS integration. ASSET-

Submarine was built upon this existing platform. Each component of the platform is described in general, and any significant differences are noted in an individual subsection.

7.1 (a) Advanced Ship and Submarine Evaluation Tool (ASSET)

ASSET is the US Navy’s early stage concept development tool for surface ships. The surface ship portion of ASSET is referred to as ASSET-Ship. ASSET-Ship is made up of discipline specific modules (i.e. hull geometry, gross arrangement, hull structural design, resistance, propulsion, power plant sizing, weight estimation, and area/volume sufficiency analysis).

ASSET-Ship performs synthesis utilizing the discipline specific modules in a design spiral approach with multiple iterations until it converges into a feasible ship design. The modules in ASSET-Ship are tightly integrated so that the synthesis process is stable and converges on a solution.

7.1 (b) Leading Edge Architecture for Prototyping Sys- tems (LEAPS)

The LEAPS software enables an engineering analysis team to evaluate a product’s design and verify its capabilities against customer requirements. The LEAPS architecture is an effective tool for supporting concep- tual, preliminary, and late stage ship design and analysis integration. Due to the complexity and diversity of naval ship design and analysis tools, the LEAPS architecture takes a “meta model” approach to product model development. This approach is capable of analyzing ships, aircraft, tanks, and any other complex system of systems.

LEAPS provides the ability to create design repositories through the use of its Persistent Database (PDB) capability.

The US Navy has several analysis programs that inter- face with LEAPS. One of which that is of particular interest is the Ship Hydrostatics Calculation Program (SHCP) which was used as the base of the hydrostatics analysis used in ASSET-Submarine.

7.1 (c) Lessons Learned From ASSET–Ship

Prior to the commencement of development, a design review was performed on ASSET–Ship. ASSET-Ship is designed with an integrated ship design process built into the application. This process is applied to user requirements, and an ASSET-Ship model goes through its iterative process adjusting the design parameters of the ship to arrive at a feasible ship design. ASSET-Ship un- derstands how to change the ship to ensure feasibility, and can make those changes in a way that is computa- tionally stable during the synthesis process. Some of the larger issues with this approach are:

Warship 2011: Naval Submarines and UUVs, 29 – 30 June, 2011, Bath, UK

x Changes to the design algorithms or design processes often yield unintended consequences due to the dynamic nature of the synthesis process.

x Certain design tradeoffs are automatically performed during synthesis.

x End users require significant knowledge of the design algorithms and processes in order to use the tool effectively.

Given the above, the submarine design tool takes an al- ternative approach. Instead of implementing a design spiral approach within the application, ASSET- Submarine enables the user to perform a design spiral.

The user is free to make whatever changes they wish, and then re-analyze the design on demand to see the effect their changes have had on the overall design. ASSET- Ship can be configured to be used in this way as well, but only a minority of the user base take advantage of the additional control.

The effect of this philosophy change is to remove the design tradeoff decisions from the program, and place it in the hands of the naval architect. The naval architect is also given the responsibility of making sure the design is feasible by monitoring the information generated by the analysis.

From a software development perspective, this achieves a program that is easier to implement, maintain, and ex- tend. For the naval architect, the result is a more flexible and intuitive tool since there are fewer constraints placed on the user by the application.

The ASSET-Submarine design spiral can be summarized by Figure 2.

Figure 2: ASSET-Submarine Design Spiral

7.2 CURRENT MODEL

The Current Model (CM) is defined as containing all data related to the state of the design. The CM contains enough information such that all analyses can be run.

This does not mean that all analyses will provide meaningful numbers from an engineering perspective at every stage of the design process, for example, if components protrude from the hull, the analyses will not produce reli- able data. The responsibility is placed on the designer to look at the design as a whole and determine the overall fitness of the design.

The CM is defined in two parts. Both parts are defined within the object meta model provided by the LEAPS framework. The first part defines the actual product, a submarine design, and all of the information required to define that design. The second defines the set of information that is used solely by the application to either perform analysis or to construct the solid geometry that represents the submarine. This second set of data can be thought of as working space or “tool data”. Tool data is not considered to be part of the submarine definition, but is required by the application.

Changes made by the user through the GUI are recorded with the CM.

7.3 GEOMETRY CONSTRUCTION

At the heart of ASSET-Submarine lies a NURBS based solid geometry model created in the LEAPS framework.

The construction of the submarine geometry was first broken down into the individual geometry elements.

Each of these elements was further broken down into dimensions which control the element’s various shape aspects. Upon changing any of these dimensions, the solid model of the element is adjusted. The elements are then aggregated into a complete model. This allows for:

x Incremental development of the design.

x Mass properties of the geometry elements can be reported to the user as an element is being dimensioned.

x Geometric elements can be added or edited in a number of different orders.

7.4 MODEL ANALYSIS

Analysis of the model is performed by a series of inde- pendent modules. Each module is responsible for the computation of a different design discipline. Modules do not communicate with each other, instead all data is writ- ten to, and read from the CM. The analyses are run in a specific sequence by a control module allowing for all information required for an analysis to be available when its module is called. Currently, the application provides analysis for the following design disciplines:

Dalam dokumen Warship 2011 - Naval Submarines and UUVs.pdf (Halaman 166-172)