Designing SSN(X) Will Require Modern Digital Modeling

As the Navy has struggled to deliver major ship programs on time and within budgets, the Virginia-class submarine program stands out for its success at those things. From its innovative manufacturing methods, relative affordability, and iterative improvements through consecutive block builds, the sustained success of the 774 hull form is impressive.

A review of the program’s history, however, reveals that its design success was not a foregone conclusion, but rather a steep compromise from the Seawolf-class submarine program that was ultimately canceled after just three hulls because of cost overruns and shrinking defense budgets. As the Navy embarks on the design of the Next Generation Fast Attack submarine (SSN[X]), the many lessons not only from several program failures, but also from the Virginias’ success, should instill a sense of urgency and focus on why things can go wrong rather than the complacency that can result from winning the last battle.¹ New—or new to the Navy—digital design and modeling tools can help the service apply those lessons.

Mission-Focused Design

The Pentagon is challenging the armed services to strive for mission-focused designs, in which “the synchronization, management, and coordination of concepts, activities, technologies, requirements, programs, and budget plans guide key decisions focused on the end-to-end mission.”² This ideal stands in stark contrast with recent platform-centric designs across the Department of Defense (DoD), which have delivered systems that failed to integrate into the department’s broader warfare concepts.

The capabilities of future Navy systems will be measured not by the individual attributes of a single hull type, but rather by the combination of the hull’s combat capabilities, capacity, and ability to interact with off-hull systems. The Navy has the tools and workforce to embrace this paradigm shift, but Navy acquisition leaders must take positive action to achieve this end state. This is particularly important for SSN(X), as the Navy will need to fight its urges to focus in-hull.

The SSN(X) program must pay close attention to its larger battle network, and its team will need to regularly verify that its design meets mission-focused requirements. To do so affordably, the Navy must improve its development of digital models and simulations of planned systems and validate concepts of employment within live, virtual, and constructive (LVC) test environments.³ Requirements development for the SSN(X) began in 2021, offering a perfect opportunity to integrate digital models and simulations to optimize concepts of operation (ConOps) and integrate mission-focused design.

Learning Hard Lessons

In the late 1980s, the Seawolf-class submarine began a paradigm shift in U.S. submarine design, similar to the shift occurring today with SSN(X). Larger, faster, deeper diving, and with twice the torpedo capacity of previous submarine classes, the Seawolf (SSN-21) required a significant amount of new design and engineering work. This complexity led to the problems that ultimately caused its cancelation after only three submarines. Multiple supporting weapon system programs were also canceled.⁴

In the early 2000s, the littoral combat ship (LCS) was supposed to result in a similar shift in surface ship design and construction. Its aspirational goal was to build a system of systems around interchangeable mission modules. LCS would be capable of rapidly changing missions simply by swapping mission modules.⁵ Because of financial and technical challenges, development of the advanced technology needed to make several mission modules a reality fell behind schedule, and some were canceled.⁶ As a result, the LCS program delivered hulls that were largely unable to fulfill their intended purposes. For both the Seawolf and LCS, the Navy sought to procure not only new platforms, but also new technology to operate on those platforms.

The Navy finds itself in a similar position today, intending to integrate technologically advanced unmanned systems into SSN(X) and intending a new ConOps for the boats. Because of comparatively low costs, unmanned system acquisition challenges are less famous—but more numerous—than the well-documented challenges of major defense acquisition programs such as the Seawolf and LCS, among others.

The Navy has already encountered challenges integrating manned and unmanned underwater systems. It plans to cancel the Snakehead Large Displacement Unmanned Underwater Vehicle (LDUUV) in 2023 because of “misalignment of Snakehead LDUUV design and procurement efforts with submarine hosting interfaces resulting in limited availability of host platforms to conduct Snakehead operations.” This decision came after the Navy sank $200 million over 14 years in developing Snakehead.⁷ Designing and fielding autonomous systems is challenging, but the failure to integrate Snakehead with well-documented interfaces available on the Virginia-class host platform suggests a failure to sufficiently examine the ConOps during the early design stages.

The Navy chose early termination for the Seawolf, Snakehead, and various LCS mission modules rather than struggle forever with unachievable designs. While cancelation was arguably better than allowing a struggling program to continue, the Navy should avoid these mistakes with SSN(X) in the first place by leveraging digital engineering from early concept development through the entire life cycle.

Digital Engineering

For programmatic, organizational, and technical reasons, the Navy’s legacy approach to platform design is embodied in its use of physical prototypes. The Navy builds physical prototypes to test platform-centric operational ConOps, and integration with other systems appears to be of secondary importance. Physical prototyping is certainly required for effective material design, but, in isolation, it fails to deliver critical information—such as that needed to fulfill the distributed maritime operations concept, for example, which requires the integration of sensors and shooters across time and space. Physical prototyping is time intensive and financially costly and generally identifies integration issues too late in a program’s development cycle, if at all. Meanwhile, the Pentagon’s increasing focus on distributed sensors and “kill webs” requires prototyping how a platform will integrate within a network of many platforms in realistic combat scenarios, which is substantially more complex.

Legacy document-based systems engineering generates largely static design artifacts, such as drawings, specification documents, and test plans. Any given Defense Acquisition System may require more than 70 separate design documents to meet regulatory, statutory, or component requirements. These document libraries become rows of bookshelves that require tedious page changes each time any design decision is made, creating serious challenges for integrated product teams.

Digital Models

In contrast, digital engineering uses models and authoritative data to coordinate and integrate all disciplines and phases of work for the life cycle of a platform or system.⁸ Having a central digital model ensures that any design team accessing the model always accesses what integrators call the “single source of truth.” Digital models can simulate real-world physics and conditions or can be functional models designed to explore possible system configurations.

This model-based approach allows engineers and acquisition professionals to evaluate designs in digital space with a high degree of fidelity before building costly physical prototypes. Using these models throughout a program’s lifetime creates what former Assistant Sectary of the Air Force Will Roper called a “digital thread” of models and data. As the complexity of defense systems grows, interactions between subsystems become harder to understand without detailed digital models or expensive physical prototypes.

A key contribution to the success of the Virginia-class submarine program was its full rendering in digital computer-aided design (CAD) software. CAD programs used to design Virginia excelled in creating geometric models that were useful for piping arrangement, maintenance task analysis, and design aspects involved in the arrangement of physical objects. However, CAD is only one tool in the digital transformation toolkit, and CAD typically only comes into use after system requirements have been codified and the system’s rough form begins to take shape. Digital models can be used at any level of abstraction, from the concept design phase to studying trade-offs among potential system configurations to calculating precise aircraft maximum takeoff weight.⁹

But a shipbuilder developing a proprietary CAD model of a submarine hull as required under the shipbuilding contract does not automatically generate a “digital return on investment” for associated programs of record. Consider that essentially every sensor, weapon, communication device, and special program has its own acquisition pipeline, and its documentation is managed at classification levels independent of the submarine hull design. And many of these programs are built by vendors that are in competition with each other and that take active measures to limit their proprietary digital models from being made available to competitors. Taken alone, the CAD model is very useful, but it is not capable of allowing designers to consider trade-offs in the same way as an integrated digital model.

The Virginia design process did include a limited number of trade studies. In contrast, the Air Force’s Sentinel missile examined 6 billion different design configurations with digital modeling.¹⁰ These models allowed the Air Force to rapidly move the program from the design to the construction phase while maintaining a focus on affordability. Once a team builds a detailed digital model, scaling from several test configurations to billions is simply a matter of available computing resources.

A key benefit of examining many resource configurations for an integrated digital design is the ability to identify realistic performance capacities. The Congressional Research Service and the Government Accountability Office frequently assess whether the Navy meets its own internally set measures of performance such as reliability, availability, and maintainability (RAM).

Systems thinking, however, is not always applied to Navy estimates of measures of performance. Instead, programs often apply parametric or analogy-estimation techniques based on similar past programs. These techniques often fall short when applied to novel problems—such as a UUV deploying from a new submarine design. For example, if the Navy were to use the RAM characteristics of existing unmanned aerial systems as a basis for UUV RAM measures, the domain and ConOps between aerial and underwater systems might invalidate the analysis. Competent digital design can avoid these conflicts through rigorous analysis of realistic performance capacities.

Another key advantage of digital models is the ability to seamlessly make changes across a system. Traditional program management practices require that the government develop detailed technical requirements after evaluating potential ConOps. Those requirements are passed to industry, where the detailed design work takes place. Much of this work is done in CAD.¹¹ Significant technological challenges encountered during the design process can lead to cost overruns and delays because designers and the government must resolve the issue. Digital models allow for more-detailed design work earlier in the requirements development phase. They also permit verification of ConOps models to be rerun once detailed models are completed.

Properly done, digital models last for the lifetime of the system, not just a single phase of acquisition. As the system matures, the models keep pace and allow for continued verification of designs and requirements—a critical feature. As platform use-cases change or real-world data is gathered, that information is fed back into the model. And each mature model contributes to the digital ecosystem for the benefit of future programs.

Integrate Wargaming with Technical Design

The Navy historically has relied on wargaming to develop future ConOps and engineering design to evaluate future system requirements, but these activities too often occur in silos. For example, the Acoustic Research Detachment at Lake Pend Oreille, Idaho, provides an ideal environment for acoustic testing of physical prototypes. However, the attendant costs, long development timelines, and geographic limitations of physical test infrastructure mean only a few prototypes are affordable. In addition, test infrastructure is not colocated with wargaming centers such as the Naval War College in Newport, Rhode Island, or the Undersea Warfare Development Center in New London, Connecticut, limiting designers’ ability to rapidly integrate wargaming lessons into system design.

The Navy does conduct integration testing of prototypes with fleet units such as Fifth Fleet’s unmanned task force (CTF-59), which is experimenting with a wide range of new systems, and surface and submarine development squadrons. These experiments provide useful feedback, but they occur too late in the development cycle to substantially affect system requirements. By the time an experimental fleet unit acquires a prototype, the Navy is already in the process of purchasing several copies, with contracts for more under discussion.

Wargaming provides a lower cost, easily repeatable process for testing ConOps and future system needs. While wargames excel at parts of this, they often lack the detailed physical models necessary for developing system requirement documents. Thus, the wargame’s value remains locked in the document-based deliverable the team produces.¹²

Digital engineering offers affordable ways to end this siloed approach. Digital models can merge the intensive efforts associated with prototyping and the flexibility of wargames in hybrid LVC environments, which include a mix of the natural world (live), a simulated environment (virtual), and an operator interface through which role players may employ a mix of real and synthetic players (constructive). Integrating digital models into LVC environments allows for both detailed models of the physical world and repeated evaluation of these systems by wargamers and engineers alike, at lower costs than physical prototypes. Testing in this environment means changes in technical requirements can be evaluated against a system’s ability to meet ConOp requirements. Requirements created from digital systems can be handed to contractors for construction with increased confidence that the delivered system will meet fleet needs.

Rudder Correction

At sea, it is easier to avoid a collision by making small course corrections early rather than large corrections in extremis. Similarly, adjustments to a system’s ConOps are easier and cheaper to make early in the requirements and design process rather than later, once the system or platform is in production. The Navy is in the early stages of design and acquisition for several weapon systems that will be the cornerstones of the future Navy. SSN(X), the Next Generation Destroyer (DDG[X]), and Next Generation Air Dominance (NGAD) fighter aircraft programs all will require well-defined ConOps before the Navy purchases systems it expects to be in service until the end of the century.

The Navy learned hard lessons about submarine design and acquisition from the Seawolf program that bore fruit in the highly successful Virginia program. In the years since, the Navy has continued to learn important lessons about ConOps development for new platform acquisition. Recent mistakes can be avoided through digital engineering methods to prototype and examine new platform designs and how they integrate with existing and planned systems. Failure to get operational and technical requirements right before detailed design could result in another struggling acquisition program that cannot meet its capability, capacity, or interoperability goals.