Walk the deck plates of the future USS Enterprise (CVN 80) at Newport News Shipbuilding and you will not find many rolled-up drawings. Shipfitters work from ruggedized tablets showing a three-dimensional model they can rotate, zoom, and query. Huntington Ingalls Industries calls it the world’s first paperless aircraft carrier.

That image is easy to file under “nice technology upgrade.” It is something larger. The shift to digital engineering in shipbuilding changes what the authoritative description of a warship actually is. For most of naval engineering history, the ship was defined by documents, and models were tools used to produce those documents. Now the model is the ship’s definition, and documents are views generated from it.

That inversion changes how requirements flow, how shipyards build, how fleets are maintained, and — the reason this post exists — what a naval engineer needs to know to be employable and effective over the next thirty years.

What Digital Engineering Actually Means

The term gets used loosely, so it is worth being precise. Digital engineering is not “we use CAD.” Naval architects have used CAD for decades.

The Department of the Navy’s Digital Systems Engineering Transformation Strategy calls for common, composable, interactive, model-based systems to store and exchange data, models, and information within and across acquisition programs. NAVSEA and NAVWAR compress the idea into a slogan worth remembering: create data once and use it everywhere across the digital thread.

The operative distinction is between a document-centric process and a model-centric one. In a document-centric process, the specification is a text document, the hull form lives in a CAD file, the stability analysis lives in a separate tool, and a human being is responsible for keeping all three consistent. In a model-centric process, those things are connected representations drawn from one authoritative source, and a change in one propagates to the others.

The Problem It Was Built to Solve

To see why the Navy is pushing this hard, look at what it replaces.

Traditional ship design followed the design spiral — roughly twelve phases of design activity, grouped into Concept, Preliminary, Contract, and Detailed Design. You start with mission requirements at the outer edge, then work inward, progressively fixing proportions, powering, hull form, and arrangements, iterating as the design matures. It is a sound methodology. Generations of good ships came out of it.

Its structural weakness was that each discipline worked in its own tools, with its own data formats, producing its own static documents. Structural engineers, hydrodynamicists, combat systems integrators, and electrical engineers were all working on the same ship without working in the same place.

Consider a concrete failure mode. A combat systems engineer increases the cooling requirement for a radar during Preliminary Design. The mechanical engineers who own the chilled water system are working from the earlier figure. Nobody is at fault; the information simply has no automatic path between them. The conflict surfaces during Contract Design, when it is an architectural problem rather than a specification change, and the fix is expensive.

ASNE has repeatedly flagged a related danger: requirements getting lost in the first ten percent of the design phase. In a document-centric environment, there is no reliable mechanism to trace a stakeholder need through to the engineering decisions that are supposed to satisfy it. Set-Based Design helps by deliberately deferring decisions until knowledge gaps close, but without a central model, traceability still degrades across the spiral — and the resulting rework arrives late, when it costs the most.

The goal of digital engineering is to hold ship design data in a single dynamic authoritative source of truth so requirements do not decay across a platform’s multi-decade life.

Pillar 1: Model-Based Systems Engineering and SysML v2

Model-Based Systems Engineering (MBSE) sits at the center of this. INCOSE defines it as the formalized application of modeling to support requirements, design, analysis, verification, and validation, starting at conceptual design and continuing through every later lifecycle phase.

In practice, MBSE replaces text specifications with interconnected system models. When a requirement changes, you can trace its impact across the functional and physical hierarchy immediately — identify affected subsystems, run analyses, and decide, without manually reconciling thousands of drawings and spreadsheets.

The modeling language underneath matters more than it might appear, and it is changing right now.

SysML v1 was built on Unified Modeling Language constructs borrowed from software engineering. It was a major advance over text, but it had inconsistent diagram definitions and poor interoperability across vendor toolsets. Exchanging a model between a prime contractor and a supplier often meant a translation that lost fidelity.

SysML v2 is a substantial redesign, and the DoD and major shipbuilders are moving toward it.

Three consequences are worth understanding if you are early in your career.

First, the cleaner separation between model definitions and usages makes real traceability possible — you can cross-link operational requirements, behaviors, and physical structures directly.

Second, the textual notation means models can be written, diffed, and version-controlled like source code. “Models as code” is not a metaphor; it opens the door to formal analysis and automation.

Third, and most important for an industry as fragmented as shipbuilding, replacing XMI with standard REST and OSLC APIs means models can move among primes, tier-two suppliers, and government oversight without the usual data-translation friction. The naval industrial base is a network of hundreds of organizations. Interoperability is the whole game.

Pillar 2: The Digital Thread and Sustainment

MBSE handles design. Its value compounds when connected to the digital thread — the framework linking MBSE with physical model-based engineering, mission engineering, and model-based logistics.

NAVSEA has targeted this explicitly through Model-Based Product Support (MBPS). The problem it addresses is stark: historically, sustainment data like reliability and maintainability metrics almost never fed back into the original design models. Designers made choices; the fleet lived with the consequences; the lessons rarely returned upstream. MBPS aims at a virtual data lake that connects design decisions to readiness outcomes, built on three enterprise capabilities:

• Navy Product Data Management (NPDM) — enterprise configuration management and access to technical data packages for legacy and future weapon systems.
• Navy Common Readiness Model (NCRM) — analyzing, predicting, and optimizing readiness and operating-and-support costs across a vessel’s life.
• Navy Data Acquisition Requirements Tool (NDART) — common data standards for procuring technical and product data from industry.

Underneath sits Product Lifecycle Management infrastructure connecting design, simulation, manufacturing, and support. The payoff arrives decades later: when a ship enters a naval shipyard for availability work in 2050, the workforce has an accurate as-built digital baseline instead of a drawing package with thirty years of undocumented changes.

If you want a career thesis in one sentence, it is this: the gap between as-designed and as-built is where enormous amounts of Navy money and time disappear, and digital engineering is the effort to close it.

Pillar 3: Digital Twins

A digital twin is a dynamic virtual representation of a specific physical vessel and its mechanical, electrical, and combat systems. The distinction from a CAD model is that a twin continuously ingests real sensor telemetry from the actual ship at sea. A CAD model describes a design. A twin tracks a hull.

NSWC Carderock’s Department 70 has been central to moving twins from concept to deployed capability. The target is the maintenance paradigm. Calendar-based maintenance replaces parts on a schedule regardless of their condition — simultaneously wasteful and unsafe, since it replaces healthy components while missing degrading ones. A digital twin synthesizing failure history, live sensor data, operational stress profiles, and machine learning can assess material risk dynamically and flag a degrading component before it fails underway.

NAVSEA frames the strategic math memorably: increasing a ship’s operational availability by one percent produces an aggregate effect comparable to adding three ships to the fleet, without building anything. In a period when the fleet is in demand and shipbuilding capacity is constrained, availability is leverage.

One design principle here deserves attention, because it reflects how the Navy is approaching AI generally. Twins are built human-in-the-loop. The analytics do not execute maintenance or operational decisions. They present options, failure probabilities, and risk assessments to subject matter experts who decide. That is partly about trust and adoption, and partly about accountability. Expect to see this pattern in whatever you work on.

Pillar 4: Virtual Construction

Virtual construction is where the model meets steel. Turning naval drawings into assembled structure has always produced spatial conflicts, interferences, and rework. Integrated digital shipbuilding attacks this with laser scanning, augmented reality, and module simulation.

Mobile laser scanners and reality-capture software let a yard build continuous 360-degree models of construction progress. Overlaying the design model onto the physical environment through AR on a tablet lets an engineer see, immediately, where as-built diverges from as-designed.

This matters most because of how warships are now built. Modular construction means large hull blocks are fabricated at different yards and brought together for final assembly. A fit problem discovered at the dry dock is a schedule catastrophe. If critical module interfaces carry persistent digital identifiers and suppliers capture automated metrology, misalignments can be caught — and fixed at the supplier yard — before the block ever ships. The shift is from detecting problems to preventing them.

Where This Is Actually Happening

CVN 80: the paperless carrier

The future Enterprise is the third Ford-class carrier and the first U.S. carrier designed and built entirely on digital platforms. Beyond tablet-based work instructions, high-fidelity models support the program’s superlifts — moving large, pre-outfitted hull sections into the dock with confidence that piping, electrical, and structural interfaces will land where they should. Newport News has also used laser-scanning point clouds for confined-space installation work such as catapult troughs, and is applying digital engineering to qualify additive manufacturing for ship components, which demands rigorous digital pedigree and process control to meet warship tolerances.

A detail worth keeping: Newport News has said more than 35,000 pounof steel recovered from the decommissioned USS Enterprise (CVN 65) is being recycled into the new hull. The most digital carrier ever built carries its predecessor’s steel.

FFG 62: adapting a parent design

The Constellation-class program shows digital engineering applied to a hard integration problem. Fincantieri Marinette Marine is adapting the Italian FREMM parent design to accommodate U.S. systems including the Aegis Baseline 10 combat system and AN/SPY-6(V3) radar. Fitting American power, cooling, and combat systems into a European hull form is exactly the kind of multi-domain problem that punishes document-centric methods.

The program also produced a good example of human-in-the-loop design. At the Mariner Skills Training Center Pacific in San Diego, sailors used virtual reality models to walk the Constellation’s bridge before it existed, interacting with console layouts across simulated watchstanding conditions. Their feedback went back into the model and changed the arrangement before steel was cut for the superstructure. Getting operator input while changes are still cheap is one of the clearest wins digital engineering offers.

One caution on this program, since this audience follows it closely: the Navy’s stated metric at the start of fabrication was that detailed design was just over 80 percent complete, a threshold intended to prevent mid-construction redesign. Design maturity and schedule on Constellation have been the subject of considerable subsequent government reporting, so treat the 80 percent figure as a point-in-time program goal rather than a settled outcome.

Columbia class: zero tolerance

The Columbia-class ballistic missile submarine will carry the sea-based leg of the nuclear triad into the 2080s. General Dynamics Electric Boat has pushed a thoroughgoing shift from paper to model-based work, with 3D models replacing 2D drawings for building, inspecting, and validating components in spaces where tolerances run to thousandths of an inch.

The most instructive point concerns timing. For Columbia and the next-generation attack submarine, digital twin capability is being designed in from the start rather than retrofitted. There is a hard engineering reason. The Columbia reactor is designed to last the boat’s entire 40-to-45-year service life without mid-life refueling. Sustaining a propulsion plant that will not be opened for refueling across four decades demands exactly the predictive analytics and lifecycle modeling a mature twin provides.

Where It Is Heading

AI inside the digital thread. Generative design can explore multi-variable trade spaces far faster than manual iteration — identifying promising structural load paths, unconventional component configurations, and material distributions that reduce weight. It is not producing finished, production-ready engineering products. AI is also being applied to numerically controlled programming for low-volume complex parts, a real shipbuilding bottleneck. The governance point matters as much as the capability: before an AI agent alters a product model, releases a toolpath, or modifies a bill of material in an authoritative source, the system has to enforce verified claims — that the agent is acting within its authority, that collision checks are complete, and that human engineering approvals are recorded.

Directed energy makes ship defense a time problem. A missile is fired and forgotten. A laser requires sustained dwell time on target to achieve thermal effect, which turns ship resources into tactical constraints. Generating the electrical power and rejecting the heat for sustained laser duty cycles means modeling entirely new thermal and electrical flows. MBSE lets architects simulate those dynamic loads during concept design, so that firing the laser does not brown out the radar.

Distributed fleets require it. The UK’s Hybrid Navy concept abandons one-for-one capital ship replacement in favor of crewed command ships coordinating fleets of autonomous Common Combat Vessels. That architecture only works if software, sensors, and payloads can refresh on timelines of months rather than the decades of traditional shipbuilding. Common data standards, composable architectures, and standardized APIs are the prerequisite, not a convenience.

The Problem Digital Engineering Creates

Every gain here expands the attack surface. Converging business IT with shipyard operational technology ends the era of the air gap. Engineering control systems are now networked, and that is not reversible.

The threat environment reflects it. Industry threat reporting describes a steep year-over-year rise in maritime cyber incidents — ransomware, malware, and denial-of-service — along two main axes: direct attacks on vessel operational systems, and supply chain attacks aimed at maritime infrastructure from component manufacturers up to prime yards.

The 2017 NotPetya attack remains the clearest warning. Aimed initially at Ukrainian infrastructure, it spread to Maersk, halted operations at ports around the world, and cost the company roughly $300 million. It also raised unsettled legal questions about whether a state-sponsored cyber operation that paralyzes global maritime trade without sinking a hull or killing anyone constitutes an armed attack under international law.

For warships the stakes are different in kind. Advanced persistent threat actors target shipyards and subcontractors to steal classified design models, encrypt CNC production lines, or plant latent vulnerabilities in trusted software update channels. GNSS spoofing can distort a vessel’s position data, with consequences ranging from grounding to a manufactured geopolitical incident.

The policy response centers on the Cybersecurity Maturity Model Certification (CMMC), which sets compliance requirements for protecting controlled unclassified information across the defense industrial base. Compliance costs are genuinely burdensome for small, specialized maritime suppliers, which creates a real tension: a framework meant to protect the industrial base can also thin it. Industry organizations such as NCDMM work to translate the requirements into repeatable workflows for shop-floor operational technology — PLCs, CNC machines, additive equipment. CMMC’s implementation timeline has been subject to change, so check its current status before relying on any particular phase or deadline.

The engineering takeaway is the part to internalize: cybersecurity is not the IT department’s problem. It is a design requirement that belongs in the system architecture from the earliest MBSE phases, alongside reliability and safety.

What This Means for Your Career

Here is the practical core. The Navy has been explicit that this transition is not trivial and requires the workforce to commit to new methods, tools, and modeling languages. Traditional competence — thermodynamics, hydrodynamics, structures, 2D drafting — is now necessary but not sufficient.

Four areas are worth deliberate investment.

1. MBSE and SysML v2, at depth. Not drawing block diagrams, but building semantically meaningful models: creating reusable definition elements, using subsetting, managing variability so a proven design applies across multiple programs. Learn to query and interface with models through REST APIs. That skill is becoming as fundamental as calculating a structural load. Academic programs are adapting, with institutions including Webb and MIT strengthening systems engineering pathways alongside traditional naval architecture, but much of this you can learn on your own with available tooling.

2. Systems thinking, genuinely practiced. A warship has thousands of coupled subsystems. Change the cooling requirement for a laser and you change the electrical generation baseline, which changes fuel consumption and range, which can change sea chest intake sizing and therefore drag. Being able to trace that chain — and to trace allocated requirements back up to validated mission capabilities — is the skill the digital thread exists to support.

3. Data governance. Understand what an authoritative source of truth is and respect the protocols that keep it authoritative. An accurate model that is not cataloged, version-controlled, and accessible across teams and classification boundaries is close to worthless. This is unglamorous and it is where a lot of digital engineering programs actually fail.

4. Cross-disciplinary literacy across IT, OT, and cyber. A mechanical engineer designing a seawater valve control system now needs to understand what it means to connect that PLC to the ship’s digital twin and, through it, to satellite communications. Familiarity with the NIST Cybersecurity Framework, CMMC requirements, and OT network segmentation makes an early-career engineer disproportionately valuable to HII, Electric Boat, Fincantieri, and the government organizations that oversee them.

Certification

To make these competencies legible to employers, consider INCOSE’s Systems Engineering Professional credentials:

• ASEP (Associate) — aimed at junior engineers and recent graduates; requires passing the INCOSE knowledge exam. This is the one to target early.
• CSEP (Certified) — for practicing systems engineers, requiring documented applied experience in addition to the exam.
• ESEP (Expert) — for senior leaders with extensive demonstrated systems engineering leadership.

Experience requirements and exam details change, so verify current criteria with INCOSE. Many tier-one defense contractors and government organizations now require or strongly prefer ASEP or CSEP for systems engineering roles.

The Real Argument

Naval shipbuilding is in the middle of a cultural change disguised as a technology change. The technology is largely available. What is hard is the shift away from familiar document-centric habits, the integration of incompatible tools across a fragmented industrial base, and the cyber exposure that comes with connecting everything.

For an engineer early in a career, that friction is the opportunity. The people who can model a system properly, trace a requirement from mission need to bolt pattern, respect the discipline of an authoritative data source, and think about cyber resilience as a design parameter will not merely work in this industry. They will be the ones trusted to run the programs.

The strength of a future fleet will sit in its steel and in the integrity of the models that define it. Those models will be built by people who are, right now, deciding what to learn next

Main image caption: A U.S. Sailor inspects an oil sample in the oil lab aboard Arleigh Burke-class guided-missile destroyer USS Rafael Peralta (DDG 115), Sept. 23, 2026. Rafael Peralta is deployed to the U.S. 5th Fleet area of operations to support maritime security and stability in the Middle East. (U.S. Navy photo)