Oshkosh Defense: Engineering for a Digital Army

Oshkosh Defense has never had the luxury of building pristine systems. The vehicles it supplies to the U.S. Army — the Joint Light Tactical Vehicle, the Family of Medium Tactical Vehicles, the Heavy Expanded Mobility Tactical Truck — operate in dust, mud, extreme heat, and combat conditions. Reliability is not a product differentiator. It is the product. For decades, that meant Oshkosh’s engineering excellence was concentrated exactly where the problem lived: drivetrains, suspension systems, frame architecture, cab protection.

That era is not over. But a parallel era has arrived on top of it.

The Army’s current vehicle programs no longer ask Oshkosh to deliver a capable truck. They ask for a capable truck with an integrated vehicle network, a software-defined power management architecture, provisions for autonomous operation, and compatibility with a suite of government-furnished electronics the OEM does not fully control. The JLTV carries electronic warfare systems. The autonomous logistics vehicle programs require sensor fusion, path planning, and safe-stop behavior. The NGDV postal vehicle — a civilian program, but one that proved the company’s EV and software-integration ambitions — demanded a vehicle architecture designed around a software update cycle, not a model-year refresh.

This is the central engineering challenge at Oshkosh Defense today: not whether to build software capability, but how to build it fast enough, deeply enough, and with enough discipline that it does not erode the mechanical reliability the company’s reputation is built on.

What a Vehicle OEM Actually Means by “Digital Engineering”

The defense industry uses “digital engineering” as a broad term covering model-based systems engineering, digital twins, product lifecycle management, and simulation-driven design. For a vehicle OEM like Oshkosh, the practical meaning is narrower and more specific.

Digital engineering at a ground vehicle manufacturer means, concretely: the ability to manage a vehicle configuration as a connected data model rather than a set of drawings and documents, so that a change to one subsystem can be traced to its effects on mass, power budget, thermal load, and requirements compliance without manually chasing it through a document hierarchy.

The DoD has been pushing this direction explicitly. The 2018 Digital Engineering Strategy from the Office of the Under Secretary of Defense for Acquisition and Sustainment established authoritative digital models as the target state for defense programs. For Oshkosh, compliance with that direction is not optional — it is a contractual and competitive reality. Proposals for major programs now include digital engineering plans. Source selections evaluate them.

The gap between that mandate and current execution is the honest part of the story. Most defense OEMs, including vehicle manufacturers, have functional PLM systems, mature CAD environments, and some model-based systems engineering adoption. What they typically lack is the connective tissue: the ability to link a requirement to a design decision, that design decision to a test result, and that test result back to a specific vehicle configuration — automatically, at scale, across subsystems that were designed by different engineering organizations.

The GFE Integration Problem

Government-furnished equipment is where systems engineering breaks down fastest for vehicle OEMs.

When the Army integrates a communications system, an electronic warfare package, or a counter-IED system onto a JLTV, Oshkosh receives a set of interface control documents and installation kits. The GFE itself — its internal software, its power requirements, its RF emissions profile — is not Oshkosh’s to design or to fully characterize. But the vehicle that hosts it is. And the integrated performance of that vehicle, with that GFE installed, under the thermal and vibration conditions of actual operation, absolutely belongs to Oshkosh to ensure.

This creates a requirements management problem that is structurally different from what commercial vehicle engineers face. Oshkosh must maintain traceability from the vehicle-level performance specification down to subsystem allocations that include interfaces it does not own. When an Army program office modifies a GFE package mid-program — adding a software update that changes power draw, or swapping a radio variant — Oshkosh needs to understand the downstream effects on thermal margin, electrical architecture, and interface compliance before the vehicle ships.

Document-based requirements management cannot handle this at the rate GFE configurations change on active programs. A Word document or a spreadsheet-based RTM does not propagate a power budget change through a vehicle architecture automatically. Engineers do that manually, which introduces latency and error.

The vehicle OEMs who are pulling ahead in this capability — and this is where the competitive differentiation in defense will increasingly live — are the ones building requirements processes that treat the system as a connected graph, where every requirement, interface, and design decision has explicit relationships that can be queried and updated programmatically.

The Organizational Problem Is Harder Than the Technical One

Oshkosh’s mechanical engineering organization is mature. Process, tooling, test methodology, supplier qualification — these are institutionalized. A powertrain engineer joining Oshkosh Defense walks into a functioning system.

The software and systems engineering organization is newer, smaller, and still establishing its processes. It is operating under pressure from two directions simultaneously: DoD program requirements that assume MBSE maturity, and internal schedules driven by mechanical development timelines that were not designed around software integration cycles.

This tension is not unique to Oshkosh. It describes nearly every traditional defense hardware OEM trying to absorb software capability from the inside rather than by acquisition. The mechanical program schedule runs on a model-year logic: major changes happen at defined points, and the vehicle configuration is relatively stable in between. Software development does not work this way. A software architecture that is fixed at the same point as the frame design will be outdated before the vehicle reaches production.

Resolving this requires more than hiring software engineers. It requires changing how requirements are allocated — ensuring that software-addressable requirements are explicitly identified and tracked separately from hardware-fixed requirements, so that software updates can close compliance gaps post-fielding without requiring vehicle modifications. That is a systems engineering process change, not just a staffing change.

The autonomous logistics vehicle programs are forcing this evolution. When a vehicle needs to demonstrate safe autonomous behavior in an operational environment, the V&V process cannot be a paper exercise. Every behavioral requirement has to be traceable to a test case, and the test coverage has to be demonstrable to a program office that is going to ask hard questions about edge cases. That discipline, if it takes hold on the autonomous programs, will pull the broader Oshkosh systems engineering organization toward greater rigor.

Traceability as a Contractual Obligation

It is worth being precise about why requirements traceability matters in this context, because the defense framing is different from commercial product development.

In commercial markets, requirements traceability is a quality practice. You do it because it reduces rework and improves system coherence. If you skip it, the consequence is internal: schedule slip, integration surprises, field failures.

In defense contracting, requirements traceability is a deliverable. The contract specifies that the contractor must demonstrate compliance of the delivered system to each requirement in the specification. The government can — and on major programs, does — audit that traceability. A gap in the RTM is not an internal quality problem; it is a contract performance problem. On a program like JLTV, where the Army is buying tens of thousands of vehicles at controlled configurations, a requirements traceability failure has program-level consequences.

This means the tools Oshkosh uses to manage requirements are not just engineering productivity choices. They are part of the program compliance infrastructure. The tool has to produce artifacts that satisfy government data item requirements. It has to support configuration control at the level of individual requirements versions. It has to handle the interface between Oshkosh’s internal requirements and the government-furnished specifications that sit above them.

Modern requirements management platforms — including tools like Flow Engineering, which approaches requirements as a connected graph with AI-assisted traceability rather than as a document hierarchy — are being evaluated by defense OEMs precisely because the document-based approach is failing at the scale and complexity of current programs. The question for a company like Oshkosh is whether to evolve the tool infrastructure ahead of the next program or wait until a program office forces the issue.

What the Next Five Years Require

The NGDV program was a useful forcing function. Building a vehicle with an EV architecture and an OTA software update capability for a civilian fleet operator required Oshkosh to develop — and demonstrate — a software lifecycle management process that the company did not need for a HEMTT. That capability, if transferred into the defense programs, represents genuine organizational learning.

The autonomous logistics programs will be the next forcing function, and they are more demanding. Demonstrating autonomous system safety to military standards requires a level of requirements discipline — traced from operational concept through hazard analysis through behavioral specification through test — that exceeds what most vehicle OEMs have built so far.

The companies that will win the next generation of Army vehicle programs will not necessarily be the best mechanical engineers. Oshkosh’s mechanical engineering is already good enough to win on that dimension. They will be the companies that can demonstrate, credibly and auditably, that their systems engineering processes are mature enough to manage the full complexity of software-defined, autonomy-enabled, GFE-integrated vehicles.

Oshkosh Defense has the mechanical foundation, the program history, and the customer relationships to be that company. The open question is whether the organizational transition — from truck manufacturer to systems integrator — happens fast enough to stay ahead of both the program requirements and the competitors who are building from software-native foundations up.

That transition is the most interesting engineering management story in ground vehicle defense right now. And it is happening in Oshkosh, Wisconsin, not Silicon Valley.