Bradley replacement, OMFV, will live or die by software

WASHINGTON — Pentagon procurement has plenty of problems, but two of the biggest are acquiring modern software and replacing marquee platforms like the Reagan-era M2 Bradley Infantry Fighting Vehicle. So it’s at once bold and a bit unnerving that the Army is trying to tackle both those problems with its third attempt to replace the Bradley, the Optionally Manned Fighting Vehicle, a program whose success depends not on armor or guns, but on software.

“There had been many prior programs to provide a new infantry fighting vehicle,” admitted Maj. Gen. Glenn Dean, the Army’s Program Executive Officer for Ground Combat Systems (PEO-GCS), in an exclusive interview with Breaking Defense. “What is really different about this time [is] digital engineering and modular open systems architecture; that [is] what we are doing fundamentally differently than any of our previous programs.”

“OMFV… is really our leading candidate for our current initiatives” in both those areas, he said.

Digital engineering refers to designing the vehicle entirely on computers, which allows higher precision and easier changes than traditional paper blueprints. The OMFV program has already funded five corporate teams to develop “preliminary digital designs,” of which up to three will win the right to build a physical prototype.

Modular architecture means building all components to strictly specified, widely shared standards — for everything from cable ports to data transfer protocols — which allows easier “plug-and-play” upgrades than traditional bespoke parts. All OMFV vendors must follow a set of standards called the GCS Common Infrastructure Architecture (GCIA). What’s more, because OMFV will operate with a slimmed-down two-man crew or, on some missions, entirely unmanned (hence “Optionally Manned”), it requires unprecedented automation. All these things are all about software.

In fact, Army officials told Breaking Defense that software is so central to OMFV that Army leaders are considering a separate series of contracts specifically for software development, in parallel to the contracts already planned for the physical vehicle. OMFV contractors are already required to deliver new code every six weeks, but the proposed dual track would allow even more intensive focus on software, in hopes of moving even faster.

“The software pathway will be key,” said Col. Jeff Jurand, who, as Dean’s program manager for Maneuver Combat Systems, oversees OMFV. And if the Army can decouple the pace of software upgrades from the much slower cycle for new hardware, Jurand told Breaking Defense, “we can pour it in on a cadence that we’ve never been able to do.”

But the service is still deciding whether to include all software development as part of the current five-phase OMFV program or spin some off as a separate set of contracts.

RELATED: For OMFV competition, American Rheinmatall wants to harness Anduril’s software

OMFV Could Follow Robotic Vehicle Program’s Footsteps

Another Army program, the Robotic Combat Vehicle (RCV), is pioneering the two-track approach with separate contracts focused on hardware and software — though it’s still too early to say how successful it’ll be. RCV contracted with QinetiQ and Textron to build experimental remote-controlled mini-tanks, including the embedded software to run the vehicles. But it’s also contracted, through the Defense Innovation Unit, with Applied Intuition for software development tools and with Kodiak, which makes self-driving trucks, for navigation algorithms.

RELATED: Can the Army’s robotics programs build AI the Silicon Valley way?

“It’s new ground for the department,” said Lt. Col. Chris Orlowski, Dean’s product manager for Robotic Combat Vehicles. “I’m not aware of any other programs that have structured a hardware and software program in parallel like this.”

“This is something that’s going to be a challenge for us” in the RCV program, Orlowski said. “We cannot completely decouple the hardware and the software.”

For instance, he said, specific physical components such as sensors may require very specific software to run, depending on their design. But higher-level functions, such as navigation, don’t really care what kind of vehicle they’re running on. Splitting off these functions into a separate contract, Orlowski believes, will let the Army pick the “best of breed” companies for software development, a highly specialized skillset, rather than just award everything in one bundle to the best builder of hardware.

EXCLUSIVE: Pentagon not prepared for software updates at the speed of war, report finds

Ultimately, Orlowski added, the RCV program might split things up further, awarding contracts for specific software functions. “We’re not ready to make a decision [yet] on how to compete software at the module level,” he said. “We’re monitoring different vendor approaches.”

To have companies compete for individual modules, however, you need your software to be made up of modules in the first place. Modularity, in turn, requires a common set of standards for how those different pieces of software plug-and-play together — a Modular Open Systems Architecture like the Army’s GCIA. Even when a specific make and model of sensor, say a LIDAR, requires unique software to run, Orlowski said, “the interface to those sensors is then standardized through the GCIA interface, [so] the LIDAR [data] is shared.”

G.I. Standard

In World War II, the Allies designed tanks like the M4 Sherman for easy transport using standard-sized harbor cranes, railroad cars, and bridges. In the 21^st century, the standards armored vehicles have to meet are increasingly digital. That’s why the Army’s PEO-GCS has developed what it calls theGCS Common Infrastructure Architecture, GCIA. GCIA, in turn, builds on existing standards, said PEO-GCS Dean, particularly the military aviation community’s FACE (Future Airborne Capability Environment), albeit customized for ground vehicles.

GCIA is a living, evolving thing, not a static template, and it’s being developed in concert with industry. Currently, said Dean, “we’re on GCIA version 2.0,” which is currently circulating for comment.

All OMFV proposals must be designed from the ground up to meet GCIA standards, while RCV is working towards compliance. Dean also hopes to gradually upgrade existing armored vehicles like the 8×8 Stryker to use GCIA-compatible components, allowing them to share at least some parts and programs across the fleet, such as collision sensors or navigation algorithms.

But it’s impractical to rip out all the existing components that do not meet the standard. The reason: There’s been a radical revolution in how hardware and software work together.

During the Cold War, when processing power was minuscule by modern standards, a given piece of hardware, such as a gunsight, might require only a few lines of code, painstakingly tailored to run on the specific circuitry that could be crammed in that component. You couldn’t upgrade the hardware without rewriting the code (and vice versa). Any exchange of data between different components — say the gunsight and a targeting computer — was laboriously custom-built and hardwired. Update one component, and you had to carefully retest the whole vehicle to make sure there were no unforeseen effects.

By contrast, in 2023, processing power, memory, network connectivity, etc. (collectively called “compute”) are all abundant and compact. Each piece of hardware can host its own miniaturized computer running complicated programs, those devices can share lots of data at high speed over a network (wired or wireless), and modern programs rarely care what specific make and model of computer they’re running on thanks to programing techniques known as containerization and virtual machines. So you can replace one component of software or hardware without having to modify and re-test everything it’s connected to — as long as everything is built to a common standard that lets it share data.

Traditionally, said OMFV program manager Jurand, programs had to bundle a bunch of upgrades together into a single package for efficiencies of scale and test them all at once, a process known as “block upgrades” that typically took multiple years. But with every OMFV component required to be GCIA-compliant, he said, you can push out individual upgrades — a new sensor, a better navigation algorithm, and so on — much more quickly. His objective is to upgrade OMFV at least once a year “at a minimum,” he said, likening it to automakers rolling out their new models every fall.

The Global Upgrade Pipeline

That streamlined process could allow much faster fixes to new bugs discovered in the field, faster exploitation of new technology, and faster countermeasures to new threats, that is, if the Army can work out a way to swiftly and securely deliver new code to combat units around the globe. “That’s a technical challenge we have to work through,” Jurand said.

If the Army can get the software pipeline to work worldwide, however, it opens up another form of frontline adaptability: having alternative algorithms available for vital functions, so the vehicle can switch to whatever software works best for a given situation. For instance, you might use one navigation program while on the road, then switch to another app, perhaps coded by a different company altogether, when you go cross-country. Or maybe even have specific algorithms optimized for specific terrains, like desert, swamp, or forest. Likewise, you might use one target-recognition AI for enemy tanks, another for infantry. Or perhaps use one targeting AI by night and one by day, or one tailored to defeat a particular enemy countermeasure. That switch might be done automatically by a higher-level piece of software or manually by the soldiers onboard, based on both their training and their personal experience of what works best where.

RELATED: Lighter, hybrid & highly automated: The Army’s next-gen armor

“It is very hard, technically, to make … one algorithm to rule them all,” Jurand said, “because certain algorithmic techniques will perform better in certain environments.” So it might be best to have multiple modules for any given function and swap between them.

“You’ve got to have sufficient processor space … to house two different two different software solutions to the same problem set,” Jurand acknowledged. “But that is not an uncommon thing” nowadays.

Engineers have always aimed to design new vehicles with more horsepower and stronger chassis than strictly needed, to allow a margin for growth, Dean said. That’s why the Bradley has been able to accommodate so many pounds of upgrades over the last four decades. In the future, he said, you’ll also need extra computing power.

“Future capabilities growth is largely going to be about how we handle data,” said Dean said. “We’re starting to see how … collecting and analyzing data, integrating that data, and then turning that data into information [from] which you generate combat capability is all going to be based very heavily on software.”

“Today, our mechanism for handling data on a platform is mostly the brain of the vehicle commander. He has a bunch of sensors which are feeding him information,” Dean continued. “I’m looking through a scope and I’m listening to a radio and I might have text coming over valid command display. He’s got to make sense of that.”

In the future, Dean said, artificial intelligence could help commanders impose order on this incoming flood of data, fast. That’s a crucial edge in combat, where shooting first often means living longest, and every second counts.